back to article Systemd adds filesystem mount tool

The developers behind Systemd, the alternative to sysvinit, have added a mount tool to their user space bootstrapper. The mount tool landed during the weekend in this merge. It gives Systemd users a systemd-mount command, letting the mount command pull in dependencies and use auto-mounting logic. Developer Lennart Poettering …

  1. Anonymous Coward
    Anonymous Coward

    Do one thing and do it well

    1. Anonymous Coward
      Anonymous Coward

      Zawinski's law of software envelopment:

      "Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can."

    2. Anonymous Coward
      Anonymous Coward

      1970 thinking. When computers could barely do one thing at a tine per user. Repeating over and over outdated ideas acritically means just to remain stuck in the past. Just like religions do.

      1. Anonymous Coward
        Anonymous Coward

        re: 1970 thinking.

        The fact that you think computers can do more than one thing at a time, rather than spend a tiny amount of time doing one thing then swtiching to another one, shows a staggering lack of understanding. I hope you're not engineering anything I have to work on....

        1. richardcox13

          Re: re: 1970 thinking.

          >The fact that you think computers can do more than one thing at a time, rather

          > than spend a tiny amount of time doing one thing then swtiching to another one,

          > shows a staggering lack of understanding

          And when was the last time you used a computer without multiple CPUs/cores?

          Current systems really do multi-task.

        2. bombastic bob Silver badge
          Unhappy

          Re: re: 1970 thinking.

          "The fact that you think computers can do more than one thing at a time, rather than spend a tiny amount of time doing one thing then swtiching to another one, shows a staggering lack of understanding."

          er, you forgot about 'multi-core' dude. Sorry, but I mostly agree with your rant against the "1970 thinking" statement, except that one little detail...

          so my quad core CPU can do 4 things at once [and when I write a multi-threaded algorithm, it really does!]. But yeah time-slice thread scheduling on a single core DOES give "the illusion" of doing multiple things at once, while really doing 'what you said'.

          1. analyzer

            Re: re: 1970 thinking.

            Er - no 'dude' muti-core is just multi cpus.

            You can call it a core since that is common practice but each core is a cpu in its own right and can only do one thing at a time then switch to another. These multi core things used to be called CPU Modules, just you kiddies forget the modules bit.

            1. Brewster's Angle Grinder Silver badge

              Re: re: 1970 thinking.

              Nobody's mentioned SIMD yet. Surely that counts as doing multiple things at once?

              1. Anonymous Coward
                Anonymous Coward

                Re: re: 1970 thinking.

                All the people taking about parallelism don't seem to understand it as an engineering principle. This is more an argument against, for example, the "god object" anti-pattern in OO programming. One thing doing too much which makes maintenance impossible.

                As for SIMD, that's Single Instruction! I write GPU shaders. It's extremely important to write them efficiently; branch-less, and using the least number of the least complex instructions possible.

                The program does one thing (calculate a single pixel), but has to do it over 2 million times per frame.

            2. bombastic bob Silver badge
              Facepalm

              Re: re: 1970 thinking.

              "These multi core things used to be called CPU Modules, just you kiddies forget the modules bit."

              eh? I don't think you're talking about the same thing I'm talking about... [but whatever]

              if you want to split hairs, then yes, a single CPU CORE will do 'one thing at a time' based on a single thread of execution being 'one thing'. [must I _really_ go this far to avoid ambiguity?]

              I consider a multi-core CPU to, in and of itself, be "one CPU" (being as all the other hardware and memory bus is pretty much shared). So from _THAT_ perspective, the CPU can do mutliple 'things' at one time, i.e. multiple threads of execution simultaneously executing on the multiple cores.

              semantics - what a pain

        3. Anonymous Coward
          Facepalm

          Re: re: 1970 thinking.

          Multi-core much? A Baker's dozen computers of my own here and only one, the Intel Galileo, is the only single core. [My room mates add more, only one of which, the stand-alone XP, is also single core.]

        4. This post has been deleted by its author

        5. Andrew Richards

          Re: re: 1970 thinking.

          Original post wasn't explicitly suggesting that "computers can do more than one thing at a time" is their understanding of how it all works. Do lots of things by rapidly switching between them so you usual can't tell is close enough. Calm down, pedant.

          But... my hard disk is retrieving data and will cause an interrupt to awaken a suspended thread and interrupt the current one (not that I'll notice) so it is doing more than one thing at a time. I think the network card is busy doing its stuff too. And that's before we talk "cores". Misunderstanding is yours, I think...

        6. John Hughes

          Re: re: 1970 thinking.

          The fact that you think computers can do more than one thing at a time, rather than spend a tiny amount of time doing one thing then swtiching to another one, shows a staggering lack of understanding.

          Uh...

          $ cat /proc/cpuinfo | grep processor

          processor : 0

          processor : 1

          processor : 2

          processor : 3

      2. Doctor_Wibble
        Trollface

        > do one thing at a tine per user

        This is a process forking thing, right?

        .

        [ tumbleweed ....@.. ]

        .

        *sigh*

        1. ds6 Silver badge

          single clap

      3. bombastic bob Silver badge
        Mushroom

        "1970 thinking." (by an anon, naturally)

        I was 10 years old in 1970. I learned programming on punch cards and these pencil mark 'mark sense' cards that used the same hollerith code. I don't know exactly what you're implying by all of that "1970 thinking" comment, but whenever I hear "remain stuck in the past" I think of an arrogant millenial calling us "gramps" or "old fart" and assuming we're stone-age neanderthals for recognizing 'what works' vs 'new, shiny'.

        Show some RESPECT, you young whipper-snapper! And read Arthur C. Clarke's "Superiority".

        "Do one thing and do it well". It's an excellent philosophy when it comes to making small utilities that have many many uses. Like a knife. Not a "super-doohickey-2D-flugly-GUI-the-metro" knife, but a general purpose 'works for many things' knife, which can often be repurposed in ways its inventor never DREAMED of, because "do one thing and do it well".

      4. Doctor Syntax Silver badge

        "1970 thinking"

        Ken Thompson thinking.

    3. hplasm
      Mushroom

      Do one thing, Poettering-

      Fuck Off- and do it well.

    4. Ken Hagan Gold badge

      The article goes into some detail about how the new command does dependency checking that "mount" never did ... and then uses the aforementioned to do the mount.

      So it is a pretty good example of what you just wrote. Somehow though, I think you were being sarcastic. Unfairly in this case.

    5. ElReg!comments!Pierre

      I don't care about "new"

      One of my sysV servers (6-month uptime with zero downtime, so a rookie server) was inadvertently rebooted (unplugged, as it happens). Uptime is now in the single-digit hours. I investigated and found that systemd (which I NEVER installed manually) is now the init, I can't desinstall it without physical acces (it was happy enough to intall itself without that, though) and it randomly unplugs peripherals (storage, network, etc). I am not entirely happy about that. In 2 days I will be in the server's physical location, systemd's gonna fly through the window, and this time I'm going to pin it out forever.

  2. Christian Berger

    Solving problems that do not exist anymore

    The people who are targeted by this have mostly moved on to Tablets and Smartphones using Android or IOS. The remaining people understand that you must mount and unmount drives or use cloud or network services. And even if they don't, just mounting it sync will get rid of file corruption for the rest.

    Now this wouldn't be a problem if he'd simply write his own version of mount which would just replace any mount you'd want. The problem is that there are dependencies. You will probably no longer be able to use systemd without that new mount, and you will probably not be able to use that new mount without systemd. I mean that whole systemd thing wouldn't be a problem if Poetterling would have just started his own operating system and leave the rest of the Linux community.

    1. asdf

      Re: Solving problems that do not exist anymore

      > if Poetterling would have just started his own operating system

      That's a lot of unnecessary risk and expense when Red Hat (his employer) has shown clearly how much more lucrative it is to get rich off the back of other people's code.

    2. Colin Tree

      Re: Solving problems that do not exist anymore

      I moved to Slackware to avoid systemd.

      Yes it might be time for two branches of Linux

      classical sysinit and new-sort-of systemd

      You might even call the systemd branch forked.

      Re: Creating problems that didn't exist yet

      1. Anonymous Coward
        Anonymous Coward

        Re: Solving problems that do not exist anymore

        I'm seriously contemplating *BSD.

        pfSense is lighting the way.

        1. asdf

          Re: Solving problems that do not exist anymore

          >I'm seriously contemplating *BSD.

          I love the BSDs but sadly for many it won't be a suitable replacement yet because its support on laptops is not great (has real problems with suspend and resume on a lot of hardware) and it doesn't have a native Steam client. For a simple office type desktop at home it is great. Although will have to see if Gnome 3 (dumpster fire DE aside gtk is really important) and other FOSS becoming basically Linux only how much that hurts BSD long term.

          1. bombastic bob Silver badge
            Devil

            Re: Solving problems that do not exist anymore

            "I love the BSDs but sadly for many it won't be a suitable replacement yet "

            I've used FreeBSD for a long time. There are often "linuxy" things written into applications by people who believe that ALL open source operating systems are linux, and have things like systemd running (etc.). So the 'ports' maintainers have to write patches and workarounds for things to compensate. Dbus was one of those patched things, and has had issues with file mounting because of it. gnome wants to mount that file system because you plugged it in, dammit, regardless of what YOU want, and oh you configured it NOT to, so it's not on the desktop... yet you still have to use 'umount -f' to unmount because, DBus.

            so yeah, linuxy things being assume/done in the design, ports maintainers have to patch it, does not always work perfectly afterwards.

            and this goes back to adding a mount utiltiy to systemd...

            WHAT is going to happen on SYSTEMS THAT DO NOT USE SYSTEMD??? Are the desktop people just going to ASSUME that systemd is tehre, and invoke it's version of the mount utility on your behalf?

            I hope not.

            (smiling daemon logo 'cause I'm on FreeBSD at the moment)

          2. ds6 Silver badge
            Megaphone

            Re: Solving problems that do not exist anymore

            GTK is pretty well updated on BSD, so I don't think there's much to worry about. While Gnome is questionable on how much uproar would be generated if it were to drop everything but mainstream Linux distros, I very much doubt there would be no one rioting if it were to happen to GTK. It drives too much of desktop *nix to not be available on every platform.

            Even if it were to go Linux-only, you already know there would be a fork for it, or at least a replacement.

        2. John Crisp

          Re: Solving problems that do not exist anymore

          "pfSense is lighting the way."

          Take a look at Opnsense, a pfsense fork

          1. Anonymous Coward
            Anonymous Coward

            Re: Solving problems that do not exist anymore

            Take a look at Opnsense, a pfsense fork

            I did. I saw "Backup to Google Drive". Apparently listed as a positive feature.

            What could possibly go wrong with that ??

            So I stopped right there.

      2. eswan

        Re: Solving problems that do not exist anymore

        "I moved to Slackware to avoid systemd."

        I recently moved back to slackware. Ran slackware from ver. 3 (Now with ELF binaries!) to

        around ver. 7, then jumped to Debian for aptitude. Returning to slackware feels like putting

        on a pair of comfortably worn shoes.

  3. Anonymous Coward
    Anonymous Coward

    I am stupid

    I was clearly mistaken when I thought that udisks (alright, udisks2) already pretty much did this, and that udisks was implemented for systemd through polkit/D-Bus.

    But the properly set up udisks already automounts drives, and automatically cleans everything up if you yank the drive. It does it by default in most distros. The Ubuntu I'm using now does it without having to write any rules. But Windows isn't a model for a solution: it will still potentially corrupt either file or filesystem if you yank the drive at the wrong point.

    So the idea is that now systemd will run fsck on a drive if it's detected to be corrupted when you connect it. Okay, great. But we can do that anyway, if we want. And from what I'm reading this doesn't actually make that any easier than using udisks and fsck. And udisks, despite what Lennart says there, does not explicitly expect the drive to be unmounted before it's pulled:

    https://udisks.freedesktop.org/docs/latest/gdbus-org.freedesktop.UDisks2.Filesystem.html

    "If the device is removed without being unmounted (e.g. the user yanking the device or pulling the media out) or unmounted in a way that bypasses the Unmount() method (e.g. unmounted by the super-user by using the umount(8) command directly), the device will be unmounted (if needed) and/or the mount point will be cleaned up."

    No, it *should* be unmounted, just like you *should* always use "Safely remove drive" in Windows. But there is a specific case in udisks for dealing with what happens when it's not. Systemd-mount does not offer any feature on mount that udisks can't do. And it does not offer protection against yanking the drive. It offers a remedial solution involving calling fsck on mount (which udisks can do). That's not protection. That's called shutting the stable door after the horse has bolted. There is *no* solution to the physical removal problem except not doing it, and it's wrong to paint this as such.

    I like systemd. I much prefer it to the alternatives. It has actually made my life a whole bunch easier. But you know, this isn't necessary. There aren't any problems with udisks2 that are fixed with this. All this really means for me - given that the majority of systemd distributions use an all-in approach to features - is that I'm going to have to either disable systemd-mount, or I'm going to spend a whole bunch of time fighting with it to stop it trying to automount or auto-fix removable drives. It's a potential disaster area when you're trying to deal with drives that need recovery or repair and systemd-mount comes along and fires up fsck as soon as you plug it in.

    Not necessary. Lennart needs to stop fixing things that aren't broken, and really stop implying that everyone in the community he serves is a relic. He's starting to prove people right about calling him arrogant and single minded. In that Reddit thread, he sounds like he's always sounded toward Linux: every developer is stuck in the past. Which he then uses as an excuse to push for changes that really just let systemd take over that little bit more. "I can't believe we're doing this when no-one uses USB drives any more!" says Lennart, implying that he's the saviour of all the dinosaurs that still do, and that once again he's the progressive developer that really pays attention to the world around him.

    Here's hoping the distro devs kick back on this one and just never implement it.

    1. bazza Silver badge

      Re: I am stupid

      "Not necessary. Lennart needs to stop fixing things that aren't broken, and really stop implying that everyone in the community he serves is a relic. He's starting to prove people right about calling him arrogant and single minded. In that Reddit thread, he sounds like he's always sounded toward Linux: every developer is stuck in the past. Which he then uses as an excuse to push for changes that really just let systemd take over that little bit more. "

      Ah well, that's the problem in these days when so much has already been done. Pottering has a salary to earn, and he can earn it so long as he's fixing "problems". If he were to say something like "nope, nothing needed", then RedHat would be wondering what else to do with him.

      Other software houses are similar. Look at MS - they have a team of people whose job it is to scientifically measure "Usability", and design things that are more "Usable". They did pretty well with Windows 7, but should have been sacked immediately afterwards. They weren't sacked, and we ended up with Windows 8, 8.1 and 10 as a result. The Office ribbon came out of the same bunch of people.

      The hardest thing ever for a software developer is to admit that, in some respects, software can be "finished", or at least gets to a point where maintenance is needed, not revolution. Fortunately there are bunches out there who are much more cautious with their approach - FreeBSD, Solaris, etc. Even the Linux kernel devs are somewhat cautious - "don't break user land".

      The same is true with senior management. Getting a new director in the company is a guarantee that there's going to be a lot of mucking about, regardless as to whether their predecessor had set things up properly or not. Arrrggghhhh! Weirdly this kind of behaviour has generated a whole sub-profession for those who go around cleaning up the mess caused by others who cannot resist making changes for change's sake.

      1. Doctor Syntax Silver badge

        Re: I am stupid

        Sorry, bazza, I can only update once.

        1. Fatman
          Thumb Up

          Re: I am stupid

          <quote>Sorry, bazza, I can only update once.</quote>

          Don't worry, because I also upvoted him.

  4. Anonymous Coward
    Anonymous Coward

    Amok

    When will this madness be ended?

    1. Anonymous Coward
      Anonymous Coward

      Re: Amockery

      When you stop posting on El Reg and grab your pitchfork!

    2. asdf

      Re: Amok

      When systemd starts becoming more and more unstable spaghetti code on production systems and people learn the hard way what happens when PID 1 goes down because its doing way too much. Then again Windows is still around so who knows.

      1. asdf

        Re: Amok

        Just to spell it out for perhaps newer users to *nix if PID 1 (ie now basically systemd in Linux land) goes down the kernel is required to panic (BSOD in Windows terminology). Therefore systemd is so much more than an init replacement its proponents (basically Red Hat) claim. Its stability now on the majority of Linux distros is as important as the stability of the Linux kernel itself. Therefore, Red Hat shoving shit into PID 1 has a lot more to do with Red Hat business and political reasons than technical ones. Sadly the one thing Red Hat has shown at least me is they basically drive a whole lot of the development in Linux land these days so they can get away with this.

        Good read - http://ewontfix.com/14/

    3. Doctor Syntax Silver badge

      Re: Amok

      When you move to a BSD?

  5. Anonymous Coward
    Linux

    A Redditor writes :)

    @dosida: "Hey Lennart. Out of curiosity (and I mean no disrespect with this) but since you want to improve the functionality and efficiency of mount why not work with whoever's maintaining the mount/umount utility and patch that instead of rewriting it and bundling it with systemd?"

    "Why is mount's place in systemd instead of its own individual package? Why should systemd, which is (unless I'm mistaken) an init system and its role stops right after the kernel loads... deal with mounts? Why not rewrite or push patches to udevs which is more appropriate to deal with pluggable devices?"

  6. JoeF

    systemd is evil.

    Now that Microsoft has ported their Powershell to Linux, I fully expect systemd to soon require it.

    Time to get rid of systemd.

    1. Charles 9

      And replace it with WHAT? Definitely not SysV which falls flat with dynamic hardware which is the norm these days on most systems.

      1. Anonymous Coward
        Anonymous Coward

        "And replace it with WHAT?"

        OpenRC seems to work fine for me. Still waiting for a valid reason that would make me want to migrate away from it to systemd, but then I use a distro which allows the choice. (Gentoo)

      2. Christian Berger

        Dynamic hardware?

        "Definitely not SysV which falls flat with dynamic hardware which is the norm these days on most systems."

        I'm sorry, but systems with "dynamic hardware" are getting less and less common. Laptops rarely have PCMCIA or PCCard slots any more, and even if they have them, they are rarely used. Network cards used to be something you could unplug, today they are a standard part of your chipset, and even if you install additional ones, those are typical PCI-Express based by now.

        I mean there used to be a time when your computer might have had 2 PCI network cards a non-PnP ISA one and one that was PnP and it actually dependent on the order in which the modules were loaded how those cards were named, however today you just have one network card, and if you have more that's all on the same bus, which will always be scanned the same way.

        The same goes for "multi user" features, particularly "multi seated" features. Yes, that used to be a cool feature back in the early 2000s, but today you can literally buy a Raspberry Pi acting as an X-Server for less than a special multiseat graphics card would set you back.

      3. bombastic bob Silver badge
        Trollface

        what do you mean 'dynamic hardware' ? Plugging USB stuff in?

        on FBSD I can configure the system to take specific actions when a USB device of a particular type is plugged in. I think you can do the same on a basic Linux system as well, particularly one without systemd on it. I haven't looked at this capability in a while, though.

        There's no advantage to running systemd. It's merely "this generation" doing things THEIR way, because it's THEIR TURN. It makes them *feel* important.

        [this is also how we ended up with 3 phone OSs, written and force-fed onto customers' desktop computers, being recently excreted out of Redmond - this generation saying "it's OUR turn to do it OUR way now!"]

        1. Vic

          on FBSD I can configure the system to take specific actions when a USB device of a particular type is plugged in. I think you can do the same on a basic Linux system as well, particularly one without systemd on it.

          Yes. Such things were a problem when I first started using Linux (about 17 years ago), but were fixed a very long time back. It's ancient history...

          Vic.

    2. Doctor Syntax Silver badge

      "I fully expect systemd to soon require it."

      I fully expect systemd to fork it and incorporate it.

    3. asdf

      systemd the cancer

      >Time to get rid of systemd.

      Even if you do use another init the way the systemd had wormed itself as being a dependency for an ever widening amount of FOSS if you don't currently require at least having it on your system now (or at least an ever more complicated shim) you will in two years tops.

      1. Anonymous Coward
        Anonymous Coward

        Re: systemd the cancer

        That's the bit that always confuses me. Why on earth should anything have a dependency on a particular init?

      2. ds6 Silver badge

        Re: systemd the cancer

        Then I'll make my own damn software, init-agnostic. I'm sure there's no shortage and will never be a shortage of creators that don't want to use systemd[icking] and are curmudgeonly enough to develop their own software in defiance, or just want to write clean, portable software with inplementation details up to distro maintainers, package creators, and independent end-users.

  7. asdf

    good ole PID 1

    Well since Red Hat doesn't own the kernel code outright the next best thing for them is to shove as much as shit into PID 1 as possible (are they trying to get rid of processes by you only needing one?). Red Hat has one goal, makes as much money as possible on support by making as much FOSS Linux only as possible. When you look at it from that point of view you have to admire their success even what it has come at the expense of. They did it by churning out more code with tangled dependencies than people could fork around in a short time period (see systemd, Gnome, udev, etc).

    1. Anonymous Coward
      Anonymous Coward

      Re: good ole PID 1

      SystemD will prove to be as good for Linux as Windows 10 is for Microsoft.

      1. asdf

        Re: good ole PID 1

        What's Linux competition other than Win10 and or Mac? Proprietary Unix is on its last legs and the BSDs are woefully lacking development resources. Sadly Red Hat is going to get to define the next de facto POSIX.

        1. Christian Berger

          Actually the point of the UNIX philosophy

          "Proprietary Unix is on its last legs and the BSDs are woefully lacking development resources."

          Well one of the beautiful things about the UNIX philosophy is that it allows you to get lots of bang for the buck. While the BSD people might only have very little resources, they can simply spend it on their operating system.

          I mean systemd is mostly about wasting programmers lives. Things like "binary log files" not only need code to generate those files, but also code to read and fix those files. On contrast, text based files can be simply written with basic programming language features, features you need anyhow. They can be read with any software that reads text. Having everything as text saves you from having to have lots and lots of specialized code. I know that, because in a previous job I have written a small unixoid operating system. It's amazing how far you can get with just a simple text editor, a file system and a simple shell.

  8. Skymonrie

    I am spartacus

    Definition of systemd: systemd is a system and service manager

    Definition of food: sustenance to keep animals alive

    Both of the above have become so much more, not always for the better. Systemd has made life better in some respects but just as people can binge eat and become obese, it is getting out of hand.

    Very soon there is going to come a point where this is systemd Linux, not gnu linux. I'm not against having the choice but, we need to start calling it what it really is. Like an earlier commentor said, this is like windows10. Something a lot of people hate but the same people can get along with windows7.

    Call it what it is and end the evermore bitter divide forming in the linux ecosphere because of this one talented maniac. One person can change everything and right now people just don't understand

    1. werdsmith Silver badge

      Re: I am spartacus

      There are people that would wish to take leadership on linux and become the de facto linux in much the same way that Faecebook wants to become the de facto www.

      It's lucrative.

      In order to do that they must runaway with development and come up enhancements that they can lead on.

      1. Doctor Syntax Silver badge

        Re: I am spartacus

        "enhancements"

        I take it you're using the word in its widest possible sense.

  9. bombastic bob Silver badge
    Mushroom

    it's already bad enough with dbus...

    it's already bad enough with dbus, trying to auto-mount things when I don't want it to, or causing me to have to use "umount -f" because it partially locks something somewhere internally without telling me about it...

    Making systemd have even WORSE behavior, trying to automount things you don't EVER want mounted, like an SD card you're about to do a "dd if=image.img of=/dev/sdcard" or similar to, is JUST another thing that would get in the way and potentially cause system cluster-blank screwups down the road...

    and I don't care WHAT file system was on that SD card 10 seconds ago... and the LAST thing I want is some "smart" systemd doohickey AUTO-MOUNTING it, or [worse] FORCING ME TO USE THEIR UTILITY TO UN-AUTO-MOUNT before I can do what I *REALLY* want...

    [and if I had to *KILL* an 'fsck' process on that drive, because systemd "FELT" it needed it, when I wanted to _OVERWRITE_ _THE_ _FILE_ _SYSTEM_ I think I'd throw the CPU box through a window and scream until my ears bled)

    1. Anonymous Coward
      Anonymous Coward

      Re: it's already bad enough with dbus...

      Well then, you're not the typical user. The typical user expects to be able to access the card from the moment they stick it in. Perhaps the image writer should be smart enough to realize this ahead of time and request a dismount of the card before writing to it.

      You gotta remember that "doing one thing" and "doing it well" are two separate things, things depends on each other, and cascades happens when things start "doing it wrong". If you expect people to leave Windows, you need to make things easy for them because the "one thing" they want to do, over and above all else, is "get their work done...toot sweet".

      1. MSLiermann

        Re: it's already bad enough with dbus...

        @AC:

        "Well then, you're not the typical user. The typical user expects to be able to access the card from the moment they stick it in."

        The typical Linux user runs servers, and most of what systemd does is of benefit to desktop users, hence irrelevant for most actual real-world requirements.

      2. phuzz Silver badge

        Re: it's already bad enough with dbus...

        But the typical linux user would rather mount file systems themselves (by hand, via a command line).

        Users who want modern fripperies like an OS that will assume that because you plugged that USB stick in, maybe you'd like to access it, already use Windows or OSX (or more likely, don't own a traditional computer at all).

        1. Charles 9

          Re: it's already bad enough with dbus...

          "Users who want modern fripperies like an OS that will assume that because you plugged that USB stick in, maybe you'd like to access it, already use Windows or OSX (or more likely, don't own a traditional computer at all)."

          And that attitude is why people will never be temtped away from Windows, no matter how much you want them to for security reasons or whatnow. Make up your minds.

          1. Adrian 4

            Re: it's already bad enough with dbus...

            "And that attitude is why people will never be temtped away from Windows, no matter how much you want them to for security reasons or whatnow. Make up your minds."

            We don't WANT them too. We're just nice, and hate to see them suffering, so we suggest they use what we're using. We'd quite like manufacturers to stop only serving WIndows customers, but apart from that we really don't care. If they like Windows, they're welcome to it.

            1. Anonymous Coward
              Anonymous Coward

              Re: it's already bad enough with dbus...

              "We don't WANT them too. We're just nice, and hate to see them suffering, so we suggest they use what we're using. We'd quite like manufacturers to stop only serving WIndows customers, but apart from that we really don't care. If they like Windows, they're welcome to it."

              No, you DEMAND it because people don't live in isolation. Vulnerable users get pwned, and their computers in turn end up in botnets and other stuff that clogs the Internet and ends up attacking YOU. So you demand one of two things: (1) a license to use a computer, which is impractical because computers are kept on private property, or (2) that people move to OS's where security doesn't play second fiddle to profit.

      3. Down not across

        Re: it's already bad enough with dbus...

        Well then, you're not the typical user. The typical user expects to be able to access the card from the moment they stick it in. Perhaps the image writer should be smart enough to realize this ahead of time and request a dismount of the card before writing to it.

        Without asking?

        Even Microsoft's excuse for an OS will pop up a dialog box telling you it can't read the disk (ok well IIRC it tells asks you if you would like to format it or something silly) or doesn't understand its filesystem. I have had that happen when accidentally inserting wrong flash drive and the popup saved overwriting a portable BSD boot drive that I had not remembered to label as such.

        I really really do not want systems trying to be clever and doing stuff behind my back thinking they know better.

        1. Doctor Syntax Silver badge

          Re: it's already bad enough with dbus...

          "I really really do not want systems trying to be clever and doing stuff behind my back thinking they know better."

          This. As soon as you try to double-guess what the user wants to do you're apt to close off a lot of alternatives that the user might actually have wanted. Less is more.

          1. Charles 9

            Re: it's already bad enough with dbus...

            But if you DON'T double-guess, the AVERAGE user gets lost. Always remember, if you know what you're doing, you're in the minority, and the average user's money outvotes your money...by a large margin.

      4. bombastic bob Silver badge
        Megaphone

        Re: it's already bad enough with dbus...

        "Well then, you're not the typical user. The typical user expects to be able to access the card from the moment they stick it in. "

        WHY! SHOULD! POWER! USERS! BE! TREATED! LIKE! IDIOTS! BECAUSE! SOME! LUSERS! ARE! IDIOTS!???

        ok done shouting now.

        you do *NOT* fix things by LAMING the operating system. Micro-shaft did this with Win-10-nic. let's *NOT* do this with Linux.

    2. asdf

      Re: it's already bad enough with dbus...

      >it's already bad enough with dbus...

      Wait until Red Hat has the power to get kdbus on most distros like it did systemd and can then effectively ignore the GPL on the Linux kernel code, Red Hat proprietary OS coming soon to a computer near you). Then you are going to miss the days of just dbus.

  10. John Robson Silver badge

    I've forgotten...

    What was the problem systemD tried to solve?

    Was it just that init scripts were human readable?

    1. Charles 9

      Re: I've forgotten...

      It's trying to manage a system that keeps changing at all levels.

      SysVInit was designed decades ago when hardware was static. Thus you hear stories of init scripts that reverse the order of network adapters (really bad when the system is a firewall).

      1. Mike Pellatt

        Re: I've forgotten...

        Thus you hear stories of init scripts that reverse the order of network adapters

        That got fixed nearly a decade ago. Though some recent Bright Ideas seem to be trying to un-fix it.

        1. DainB Bronze badge

          Re: I've forgotten...

          They already did. You now have choice of three naming conventions for network interfaces on RHEL7 none of which working correctly until you explicitly specify MAC address for interface in old school way. And don't even get me started about changing output of ifconfig for absolutely no reason other than change itself, broke quite a few scripts around here.

    2. herman

      Re: I've forgotten...

      Yea, init and log files were human readable. It is obviously not a good idea to have humans around computers. Systemd finally solves the whole PEBKAC thing as people abandon Linux.

    3. R3sistance

      Re: I've forgotten...

      sysvinit is a relic that lacks way too many modern features.

      SystemD actually manages your processes, sysvinit just invokes scripts and forgets if the process is even running, it doesn't even care about the quality of your script. It's down to the developers/administrators to even ensure that what is there, is readable and functional. Systemd actually allows you to configure things properly, have dependency chains and the ability to respawn processes on failure. Systemd is far more friendly with modern hardware compared to sysv. Perhaps SystemD is not the best replacement but it's still a superior one to sysvinit. Fact is hardware changes and as hardware changes, software needs to keep up to pace, the problem is sysvinit is not up to pace, there is the problem.

      1. Doctor Syntax Silver badge

        Re: I've forgotten...

        "the ability to respawn processes on failure."

        Let's start from the assumption that a process should not fail.

        If it has failed what should an admin do about it? It might have failed, for instance, because the process had lost one of its disks.

        Investigating would be a good idea. In fact it's such a good idea that the correct sequence is investigate, fix, restart. In that circumstance is it a good idea to have some automated process restart it before the admin has chance to look at the problem? Apart from the impediment to investigating the cause of failure there's a chance that the automated restart might corrupt data. If the process fails on restart we have the prospect of systemd running round like an ADHD child repeatedly crashing the system.

        Oh, yes, I could set up systemd to not restart that process. So why would I want to have it in the first place?

        1. Anonymous Coward
          Anonymous Coward

          Re: I've forgotten...

          "Investigating would be a good idea. In fact it's such a good idea that the correct sequence is investigate, fix, restart. In that circumstance is it a good idea to have some automated process restart it before the admin has chance to look at the problem? Apart from the impediment to investigating the cause of failure there's a chance that the automated restart might corrupt data. If the process fails on restart we have the prospect of systemd running round like an ADHD child repeatedly crashing the system."

          Or it could've just hiccuped, which tends to happen more often than you think. Or perhaps it was just accidentally killed in some way. Put it this way. A single failure can be a fluke. But if the restart fails, then perhaps you should look into it. If you're worried about the restart corrupting things, you should be more worried about the running process corrupting things, too, which no checking system will detect.

        2. R3sistance

          Re: I've forgotten...

          "Investigating would be a good idea. In fact it's such a good idea that the correct sequence is investigate, fix, restart."

          In the meantime, let's just leave the corporate website offline since me not being a machine myself, I am asleep and in bed. If you have sysadmins on hand 24/7 then great, do that. But in reality you rarely have the right people around all the time and often the failures tend to be simple things. Also I have not seen the type of corruption occur that you are talking about, but this maybe because I try to set-up things to not break in the first place. If your application is something that MIGHT corrupt data then sure, you might not want it to auto-restart. If like the type of things I deal with, you have methods of recovery such as Galera SSTs or it's apache services that have no permissions to write to file to begin with, it's usually not that much of an issue.

          But more so, systemd has other lovely things it can do on failure, it's not pretty but it is possible to make systemd send an e-mail or run another service, sysvinit has nothing.

          1. Down not across

            Re: I've forgotten...

            But more so, systemd has other lovely things it can do on failure, it's not pretty but it is possible to make systemd send an e-mail or run another service, sysvinit has nothing.

            Why is that a problem? sysvinit is what it is supposed to be. init.

            If you have some processes that may die or need to be restarted should they die, that can be done outside PID 1.

            I had an issue (this was probably nearly 30 years ago or something) where I did need some process(es) to stay up no matter what and it wasn't exactly hard to write up a quick watchdog script to check for the processes and restart (and send notification) if they were found not to be running.

            You don't need to reinvent init for that.

            1. Anonymous Coward
              Anonymous Coward

              Re: I've forgotten...

              "If you have some processes that may die or need to be restarted should they die, that can be done outside PID 1."

              No, because PID 1 started it! Any other process doing what PID 1 started means another process is usurping init. I would call that dangerous because it breaks the hierarchy.

              1. John Robson Silver badge

                Re: I've forgotten...

                Init starts the watchdog.... Heirachy retained, clarity brought to the world...

                1. Charles 9

                  Re: I've forgotten...

                  Watchdog crashes. What restarts the watchdog other than init, who's already asleep by your logic?

                  1. John Robson Silver badge

                    Re: I've forgotten...

                    So what happens if your precious (and now massively complex) systemD crashes, or gets stuck in a loop?

                    A watchdog can be coded in a handful of lines of your favoured shell script - it is therefore massively unlikely to crash an burn, since there is very little to go wrong.

                    Paranoia is good though, so I often use cron to run the watchdog every minute (or every 15 depending on the complexity of the process being watched) -it's fractionally slower than a tight looping check, but gives an acceptable level of response for everything except safety/life critical systems - and at far lower performance cost.

                    Now you ask what happens if cron fails? Not something I've ever seen actually - it's as reliable as init...

                    It also makes for nice easy reading, and the watchdog can call on mailx if it needs to notify you that something has died and been restarted.

                    Indeed it can also pop a flag file in a tmp directory and *not* restart the process more than once an hour, or until reset...

                    Does systemD have the option to 'try this three times, then give up and email, on success reset the counter after an hour'

          2. Doctor Syntax Silver badge

            Re: I've forgotten...

            "because I try to set-up things to not break in the first place"

            And if you do and they break then something serious is wrong. If it's running in a state you didn't intend it's not doing what you intended nor running in a way you anticipated and may well be corrupting stuff. Maybe the safest thing for the corporate website would actually be to be offline until morning. The alternative might be to be offline for a good while longer whilst you sort out the mess and restore from backup. I've always believed that a strong sense of paranoia is the first requirement for a good DBA.

            1. Anonymous Coward
              Anonymous Coward

              Re: I've forgotten...

              In which case it's the running process that's corrupting things. Meaning Murphy has struck and slipped through the cracks because no amount of safeguarding will detect the corruption occurring during a running process because it'll keep reporting back everything is hunky-dory. Meaning by the time it's crashes, you're already Up Crap Creek. It'll probably also mean the automatic restart fails, too, meaning you're no worse off than you were originally. OTOH, if it just hiccupped, an auto-restarting system will pick itself up instead of lie drunk on the floor while you're losing business and revenues by the minute while everyone's asleep.

        3. Vic

          Re: I've forgotten...

          Oh, yes, I could set up systemd to not restart that process

          And if you did want it to restart, inittab has had the "respawn" tag for as long as I can remember...

          Vic.

      2. Jason Bloomberg Silver badge

        Re: I've forgotten...

        Systemd is far more friendly with modern hardware compared to sysv. Perhaps SystemD is not the best replacement but it's still a superior one to sysvinit.

        Systemd seems to have noble aims, is fine on paper, and, when it works well and one never needs to alter anything, it does seem to be better.

        When things don't work or one wants to change how things work it often turns out to be a whole different story.

        There seems to be parallels with the move from IPv4 to IPV6; rather than just fix what was lacking, get everyone on-board with 'that makes sense', there was a jump to something quite different.

        1. Anonymous Coward
          Anonymous Coward

          Re: I've forgotten...

          "rather than just fix what was lacking, get everyone on-board with 'that makes sense', there was a jump to something quite different."

          Because with IPv4, to fix what was lacking took more than just a band-aid (because part of the problem wasn't JUST running out of addresses but ALSO untangling complicated routing tables that were causing the Internet to lag).

          Similarly, trying to set up a system that can handle dynamic hardware (especially essential systems on dynamic hardware) means creating a system that, unlike SysV, doesn't make assumptions. Plus there's the matter of containers and virtual machines with inconsistent configurations.

      3. bombastic bob Silver badge
        Unhappy

        Re: I've forgotten...

        I've never had a problem using the old System V method which was decades-stable. Debian had a really nice way of ensuring that startup and shutdown scripts execute in the right order. I've also never seen network adaptors 'reverse' (and I run multi-home machines, so there). And FreeBSD still uses good ol' System V stuff [only simpler and with /etc/rc.conf to help you].

        No, systemd was done because THEY COULD. Someone must've got a wild hair stuck up his anus and *felt* that the whole sysinit process needed to be re-designed from scratch. It became "his baby" with all of the "feel good about yourself" that goes with it.

        Arthur C. Clarke's "Superiority" talks about this kind of thinking, too.

        (WHY was it again that they LOST the war? heh)

        1. Vic

          Re: I've forgotten...

          I've never had a problem using the old System V method which was decades-stable

          SysV scripts can be a little intimidating at first; you'll notice that the systemd-proponents seem to like to make a fuss about how many lines they are. But that length is a strength, IMO, not a weakness; you have the operation of the script laid out explicitly for your examination, rather than hidden within an executable. SysV scripts are very debuggable, and trivially modified if you want *your* box to do something different to what the package maintainer wanted.

          Now I daresay that much or all of what I want to do is possible within systemd - but that involves learning another control system. I already know Bourne-shell scripting - I think it's pretty much certain that any successful *nix admin will - so all we're really doing here is taking an easily-readable, debuggable script written in a language I understand well and replacing it with a configuration file for an executable I don't know and can't readily inspect. That's obfuscation.

          I've also never seen network adaptors 'reverse' (and I run multi-home machines, so there)

          I have when you change the physical hardware. I'm not sure I really know how to identify a particular card except by its PCI position (fragile) or its MAC address (somewhat more resilient).

          The former could probably be done with udev or similar (I've never done it, and never expect to, since it's a horrible way of doing things). The latter is trivial. I can't actually think of a third way...

          Vic.

          1. Charles 9

            Re: I've forgotten...

            "SysV scripts can be a little intimidating at first; you'll notice that the systemd-proponents seem to like to make a fuss about how many lines they are. But that length is a strength, IMO, not a weakness; you have the operation of the script laid out explicitly for your examination, rather than hidden within an executable. SysV scripts are very debuggable, and trivially modified if you want *your* box to do something different to what the package maintainer wanted."

            That's also its weakness because it makes them delicate, allowing them to fail in obscure ways that results in a cascade where the reported point of failure isn't really the point where it started to go wrong.

            Plus SysV doesn't use dependency triggering but delays. Not good if you need a quick turnaround like for a container.

            1. Vic

              Re: I've forgotten...

              That's also its weakness because it makes them delicate, allowing them to fail in obscure ways that results in a cascade where the reported point of failure isn't really the point where it started to go wrong

              That's just nonsense. Explicit scripting is inspectable; the point of failure is trivially found.

              Plus SysV doesn't use dependency triggering but delays.

              Again, not true; the only time a script will delay is if there is good reason to do so - which a systemd initialisation will also need to do. The only difference in terms of how te two ytems are supposed to work is that systemd is asynchronous whereas SysV is synchronous. That makes SysV more robust and more easily debugged, and it makes systemd faster.

              And if that had been the extent of what systemd had done, there wouldn't be this recurring argument. But it isn't; most of us couldn't really care whether the start system is sync or async, what we care about is that far too much code is getting subsumed into systemd. That smacks of very poor design.

              Vic.

    4. Munchausen's proxy
      Pint

      Re: I've forgotten...

      "What was the problem systemD tried to solve?

      Was it just that init scripts were human readable?"

      And syslogs. Don't forget the syslogs.

    5. John Hughes

      Re: I've forgotten...

      Was it just that init scripts were human readable?

      Init scripts are readable? What planet are you writing from?

      Have you ever seen a systemd unit file? This is unreadable?

      [Unit]

      Description=OpenBSD Secure Shell server

      After=network.target auditd.service

      ConditionPathExists=!/etc/ssh/sshd_not_to_be_run

      [Service]

      EnvironmentFile=-/etc/default/ssh

      ExecStart=/usr/sbin/sshd -D $SSHD_OPTS

      ExecReload=/bin/kill -HUP $MAINPID

      KillMode=process

      Restart=on-failure

      RestartPreventExitStatus=255

      Type=notify

      [Install]

      WantedBy=multi-user.target

      Alias=sshd.service

      I'm not going to include the 174 line shell script this replaces (that sources various other shell scripts).

  11. -tim

    The auto mount/ idle soft unmount solution issue is a good way to deal with removable media and has been for decades in other operating systems. I expect OS X 10.10 is doing the same thing. It appears that there is some sort of loop back file system pointing to the real device. The problems in Mac land is that $ cd /Volumes/UNTITLED; ls -l will often return ". not found" at random times. Oddly enough I've never seen things disappear from the gui systems.

  12. PenGun

    Systemd is evil. BSD init is the one true way and Slackware 14.2 is out. Rejoice!

  13. Steve Graham
    Facepalm

    Reinventing...

    But our wheel is so much better than that old thing!

  14. P. Lee

    Can I just add

    I hate binary log files.

    I don't need /var/log/messages to be in a database format. There isn't enough random access of these things to warrant database usage. Now I need some journal doohicky instead of cat, less and grep.

    Its just another level of complexity I don't need. I don't need to do db queries, chained greps are fine.

    I'm happy for parse-able formats, just don't hide the data away somewhere I can't get to it.

    1. Anonymous Coward
      Anonymous Coward

      Re: Can I just add

      There are a number of reasons for it. A key one is security. What's to stop a log message being faked, for example, unless you add structure to the system to allow gatekeeping? Gatekeeping can also be critical if the log system encounters a Thundering Herd problem. Also, what do you do when the data you want to log is necessarily binary, such as a firmware dump caused by a fault?

      1. Doctor Syntax Silver badge

        Re: Can I just add

        "A key one is security."

        Remote logging.

        1. Charles 9

          Re: Can I just add

          "Remote logging."

          Can still be faked by a rogue process. How do you block rogue logging when it can do everything a real process can do with ASCII, including process and timestamps?

      2. Munchausen's proxy

        Re: Can I just add

        "Also, what do you do when the data you want to log is necessarily binary, such as a firmware dump caused by a fault?"

        The existence and location of a dump file need to be logged. The contents don't need to be incorporated into the log file.

        1. Anonymous Coward
          Anonymous Coward

          Re: Can I just add

          Battened-down (likely read-only) filesystem. No write access to the system EXCEPT via the log.

  15. CrazyOldCatMan Silver badge
    Stop

    And thus..

    .. the process of Windowsification of linux continues.

    Which is why I'm now switching to FreeBSD.

    1. Charles 9

      Re: And thus..

      Well, what do you expect? More people don't know their way around a computer then do, yet their actions have repercussions that can affect you. What would you do to correct this problem?

      1. CrazyOldCatMan Silver badge
        FAIL

        Re: And thus..

        > What would you do to correct this problem?

        Not give a personality-challenged ego-maniac access to mess up things? Switch to a distribution that doesn't use systemd? Use *BSD? Not give one company the power to take desktop linux in the same (failed) direction that Windows has gone with more and more obfustication and disdain for anything that doesn't fit the lead programmers world view?

        Systemd is a sledgehammer to crack a nut and explicitly violates one of the prime tenets of unix/linux ("do one thing well") and reduces the ability to have human-readable inputs and outputs. Sure - yes - you *can* have text logs, but it isn't the default. And to respond to the earlier point about security - if someone already owns the box to the extent that they can fake text log entries, they can surely fake binary log entries..

        1. Charles 9

          Re: And thus..

          "if someone already owns the box to the extent that they can fake text log entries, they can surely fake binary log entries.."

          Not if they only control ONE process (which they're using to post fake log messages using text formatting tricks). The thing with gatekeeping is that it's a lot harder to fake it since the gatekeeper knows which process is emitting which message. And the ONLY way to enforce this is to use a more-complicated logging format that allows for discrimination. You simply CANNOT do this correctly with a text-based log; it's too simple for that. To put it in perspective. If all you have to work with is a single bit (1 or 0), how do you correctly inform when a coin flip lands edge?

          1. GrumpenKraut
            Facepalm

            Re: And thus..

            > And the ONLY way to enforce this is to use a more-complicated logging format that allows for discrimination.

            Bollocks. I really hope you do not work with computers.

            1. Charles 9

              Re: And thus..

              "Bollocks. I really hope you do not work with computers."

              Bollocks on the bollocks. If you say a log can be reliably kept with nothing but ASCII, explain how you can say a coin landed edge when all you have to work with is a single bit: 1 or 0? Language can hit limits. Just as some things simply cannot be expressed in a yes or no, so some things cannot be reliably said in just ASCII. That's why there's such a thing as necessary complexity.

              1. Munchausen's proxy
                Pint

                Re: And thus..

                " If you say a log can be reliably kept with nothing but ASCII, explain how you can say a coin landed edge when all you have to work with is a single bit: 1 or 0?"

                Uh, that's exactly -- I mean EXACTLY -- the point of ASCII logging; you are not limited to a circumscribed description:

                Aug 22 22:30:12 localhost flipd: INFO: Coin landed on edge

                I think it's you who will have a problem expressing an incommensurate event in a number system that doesn't include a representation of the event's state.

                1. Charles 9

                  Re: And thus..

                  No, because if I can control a process's logging, I can do this, too (note, in this example ONE process wrote this):

                  [ rogue ] Something innocuous happened

                  [ fake process ] Something fake happened

                  How do you keep a rogue process from making a fake tag when the process can match any tagging the logging system uses?

                  1. Vic

                    Re: And thus..

                    How do you keep a rogue process from making a fake tag when the process can match any tagging the logging system uses?

                    Even if you can - and your newline argument is bogus - all you're doing is cluttering the logfile; you're not removing any genuine logging, just adding a bit of noise.

                    And if the log you're trying to dibble with has a separate file (e.g. maillog), you don't get to write to that file anyway. Putting sendmail messages into /var/log/messages will ring every alarm bell there is...

                    Vic.

              2. bombastic bob Silver badge
                WTF?

                Re: And thus..

                " If you say a log can be reliably kept with nothing but ASCII, explain how you can say a coin landed edge when all you have to work with is a single bit: 1 or 0?"

                uh, WHAT? [what does that have to do with a daemon logging a message into a system log]

                it's like a 'straw man' argument. you invented some weird exception and then expect that to disprove the opposing position. I don't think your logic is working very well here.

                ASCII text is about as free form as you can possibly want. you can be verbose or terse, use numbers or words or an entire freaking paragraph. whatever you want. I think I'll stick with that, as it's easy to use 'less /var/log/whatever'

          2. Doctor Syntax Silver badge

            Re: And thus..

            "If all you have to work with is a single bit (1 or 0), how do you correctly inform when a coin flip lands edge?"

            ?

            1. Charles 9

              Re: And thus..

              How do you know which process REALLY said what if all you have to work with is ASCII, which the pwned process is fully capable of using as well, meaning there's no way to distinguish a well-disguised fake log output pretending to be another process from the actual process. The range of your output is too limited to properly distinguish between them. Anything you can try to use within the ASCII range to safeguard them, the rogue process can mimic. It's a rogue edge case, just like you have no way to say a coin flip landed edge (the LITERAL edge case) if all you have to work with is 0 (heads) and 1 (tails). See where I'm going with this? Properly safeguarding the log from rogue output requires something beyond ASCII. It's a necessary complexity.

              1. Vic

                Re: And thus..

                How do you know which process REALLY said what if all you have to work with is ASCII

                syslog tells you - both process name and PID. So your mythical pwned process could put whatever it likes on the line after that - but only the truly clueless would not notice that the very beginning of each line tells you exactly where the message came form.

                Vic.

                1. Charles 9

                  Re: And thus..

                  "syslog tells you - both process name and PID. So your mythical pwned process could put whatever it likes on the line after that - but only the truly clueless would not notice that the very beginning of each line tells you exactly where the message came form."

                  The fake process newlines its log and creates a fake tag that ticks all the marks. And the log has to be able to newline in case of structured text output like a hex dump.

                  1. Vic

                    Re: And thus..

                    The fake process newlines its log

                    Newlines are stripped out by syslog...

                    Vic.

          3. John Robson Silver badge

            Re: And thus..

            "If all you have to work with is a single bit (1 or 0), how do you correctly inform when a coin flip lands edge?"

            Easy - that's the 1, with the 0 representing landing on a face...

        2. Anonymous Coward
          Anonymous Coward

          Re: And thus..

          "Systemd is a sledgehammer to crack a nut and explicitly violates one of the prime tenets of unix/linux ("do one thing well")"

          It does one thing: manages a dynamic, ever-changing system. Thing is, managing a dynamic system properly requires a lot of data and control. It's sort of like Machiavelli's The Prince. Once you rely on lots of little things, you end up with process chains, and you know what they say about chains (IOW, in the real world, you can't rely on every process to "do it well" and instead have to assume one or more will "do it wrong"). It creates multiple points where the chain can break, and these breaks can cascade in unpredictable ways.

          1. bombastic bob Silver badge
            Devil

            Re: And thus..

            "It does one thing: manages a dynamic, ever-changing system."

            I've never seen one of those. Do they even exist?

            sledge hammer not required. System V for me.

            1. Charles 9

              Re: And thus..

              PCI and PCI Express are not fixed buses. You have to POLL them to learn what they house. Universal Serial Bus has to be polled. So does 1394 IINM. Unlike with most ARM configurations (fixed memory map), the system doesn't know what's in the system at the initial bootup, and the configuration change at runtime (like with USB and 1394 which can hotplug).

              1. Vic

                Re: And thus..

                PCI and PCI Express are not fixed buses. You have to POLL them to learn what they house. Universal Serial Bus has to be polled.

                So what? We've been doing that for *years*.

                systemd does not add new functionality in this area - it just does the same old stuff in a different way. This is why some of us are pushing back - what was there wasn't fundamentally broken. It didn't need reinventing, and it didn't need replacing with an opaque blob that will be much harder to troubleshoot when something goes wrong.

                Vic.

                1. Charles 9

                  Re: And thus..

                  "systemd does not add new functionality in this area - it just does the same old stuff in a different way. This is why some of us are pushing back - what was there wasn't fundamentally broken."

                  If that were true, why are there constant complaints about things breaking? What I see is a bunch of bodges on top of bodges, and the thing about bodges is that they don't usually hold that well.

                  If I had to put it in a nutshell, I say the whole UNIX model is broken because it relies on a level of trust you can't guarantee anymore. You simply can't rely on everything in the chain to "do it well"; odds are at least one thing will "do it wrong" instead, which is why things keep breaking.

                  1. Vic

                    Re: And thus..

                    If that were true, why are there constant complaints about things breaking?

                    There aren't. There are claims of such from people who would replace SysV. I've a zero breakage on any machine I own or control. And I don't know anyone who has.

                    The one complaint you *can* throw against SysV is that it is quite slow. Yes, it is. It's a synchronous start. That really doesn't bother me in the slightest.

                    What I see is a bunch of bodges on top of bodges

                    Well, everyone is entitled to an opinion. What I see is a tried-and-tested system that works effectively and doesn't need to subsume every other system in the OS.

                    which is why things keep breaking.

                    Says you. Those of us who have done this for a living for many years don't see things breaking unless someone has been dibbling with them - as is the case for NetworkManager, PulseAudio, and systemd. I'll find the common cause there one day...

                    Vic.

                    1. Charles 9

                      Re: And thus..

                      "Says you. Those of us who have done this for a living for many years don't see things breaking unless someone has been dibbling with them - as is the case for NetworkManager, PulseAudio, and systemd. I'll find the common cause there one day..."

                      That's because you're not working in the consumer sphere, where configurations aren't so hard and fast. At least with servers the setup's predictable and easy to tune. Not so easy when your monitor may be hooked up to a USB adapter and manufacturers aren't so forthcoming. Why do you think Valve has such a hard time getting game developers to code for Linux despite having such a strong distribution system in Steam?

                      1. Vic

                        Re: And thus..

                        That's because you're not working in the consumer sphere, where configurations aren't so hard and fast

                        Yes I am. I was supporting GNU/Linux desktops before RH decided that there was no business there. Whilst I do fewer now than at my peak, I'll wager I still support far more end-users than you do.

                        Configurations might not be "hard and fast" - there is significant variation between each site I attend - but that has not been simplified by systemd in the slightest; the contrary is actually true, since SysV is far more discoverable, since it supports tab-completion properly.

                        Not so easy when your monitor may be hooked up to a USB adapter and manufacturers aren't so forthcoming.

                        If you've got a reasonable river, that just works. If you haven't got a driver, it doesn't. Replacing SysV with systemd is entirely orthogonal to that situation; if it work with the latter, it will work with the former,.

                        Why do you think Valve has such a hard time getting game developers to code for Linux despite having such a strong distribution system in Steam?

                        I don't know. I don't follow Valve's affairs. But I can guarantee you that a lack of systemd has nothing to do with it, although I could believe that systemd's pervasion throughout the assorted subsytems of the OS might put some off.

                        Vic.

  16. Doctor Syntax Silver badge

    I'm running a non-systemd Debian here. USB drives etc mount just fine. Is this to fix an existing bug in systemd? If not I can't see a problem it fixes.

    1. GrumpenKraut
      Devil

      Systemd fixes only problems that exists inside Poettering's head.

      When the first big & fat systemd-based attack comes out I'll be laughing my arse off. Non-systemd Debian here as well.

      1. Anonymous Coward
        Anonymous Coward

        Why bother when they can just leapfrog init and go straight to the kernel at PID 0?

      2. Charles 9

        At least if it's systemd you know where to look: systemd.

        Whereras with a gestalt exploit, the actual point of attack may be so obscure no one knows where to look because the exploit takes advantage of systems that are greater than the sum of their parts. EVERY SINGLE COMPONENT works exactly to spec, yet when you put them together, then things go wrong. And since the component makers don't talk to or understand each other...

        1. Vic

          At least if it's systemd you know where to look: systemd.

          And, as systemd grows ever more bloated, that becomes less and less useful. Pointing at a box and saying "the problem is somewhere in that computer" tells you nothing; only by dissecting the problem can you eliminate it. If you can't divide the monolith wherein lies the issue, there's a limit to what you can do about it.

          EVERY SINGLE COMPONENT works exactly to spec, yet when you put them together, then things go wrong.

          Even if that situation were to arise - and it's hypothetical, not real - systemd doesn't help you one little bit. You've still got a complex set of components, you've merely obfuscated the startup mechanism.

          Vic.

          1. Anonymous Coward
            Anonymous Coward

            "And, as systemd grows ever more bloated, that becomes less and less useful. Pointing at a box and saying "the problem is somewhere in that computer" tells you nothing; only by dissecting the problem can you eliminate it. If you can't divide the monolith wherein lies the issue, there's a limit to what you can do about it."

            You get the same problem the other way. If you divide every little thing, you end up with a chain with a bunch of weak links that aren't very obvious maintained by people who may not be there anymore and you may not be in a position to go it alone.

            "Even if that situation were to arise - and it's hypothetical, not real - systemd doesn't help you one little bit. You've still got a complex set of components, you've merely obfuscated the startup mechanism."

            But at least you know who to complain to when things go wrong.

            1. Vic

              You get the same problem the other way. If you divide every little thing, you end up with a chain with a bunch of weak links that aren't very obvious maintained by people who may not be there anymore and you may not be in a position to go it alone.

              No you don't - because you can inspect each and every link in the chain with ease. It takes very little skill to add instrumentation[1] to a SysV script that will tell you *exactly* what it's trying to do. The same cannot be said for systemd; you can only turn on debugging and hope that it tells you what you want.

              But at least you know who to complain to when things go wrong.

              Many of us have tried complaining to Poettering over the years when things go wrong. He's not renowned for taking any notice.

              Vic.

              [1] Changing #! /bin/bash to #! /bin/bash -x in line 1 is often a good start, an really not that difficult to do...

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like