1. 28

Lennart Poettering commented on reddit.

  1.  

  2. 15

    Auto fsck when you plug in a device?… this is going to make forensics a nightmare.

    1. 15

      Yes. I don’t get the whole “everything has to be done automatically” philosophy. Apart from security concerns automounters always enraged me. I don’t want a daemon to mount my disk if all I need to do is using fdisk/mkfs or dd.

      1. 31

        I don’t think it’s a stretch to suggest that for most people, most of the time they’re plugging in a disk in order to transfer data to/from it. In that case, automounting the drive is a natural expected behavior that saves time and work for the end user.

        While there certainly are users such as yourself who may frequently be making use of fdisk/dd/etc, I suspect it’s a relatively uncommon case in general. I can see how it doesn’t work for you, but I’ve never seen an automount configuration that couldn’t be disabled by an informed user.

        Given that, “enraged” seems a bit of an extreme response to such tools.

        1. 13

          It’s even one of the common jokes I remember people liked to use 10 years ago re: Linux on the desktop. USB drive on windows: plug it in, it shows up. USB drive on OSX: plug it in, it shows up. USB drive on Linux: [consult dmesg to find device names, issue cryptic series of command-line operations, probably after su'ing to root]

          1. 12

            i thought with windows it was: “plug it in, congratulations your machine is now infected!”

        2. 4

          I don’t get the whole “everything has to be done automatically” philosophy

          Getting ready for Linux desktop?

      2. 31

        does this remind anyone of embrace, extend, extinguish? I feel like RedHat is doing just that with this systemd nonsense. systemd sure seems on a slow and steady trajectory on to replacing most if not all of the userland. I can’t see how that’s a positive thing for Linux or the community; but I can think of a billion reasons why RedHat would love, love, love that.

        here’s to hoping for more OpenBSD users who end up donating money and usable code to the project! :D

        1. 20

          And it’s a pretty ingenious scheme. I won’t even question if systemd actually works or not, but just the fact that more and more distros jump onboard is making me worry. Just like with internet providers who give all of their customers the same make of router having a monoculture with systemd, trying to replace all important layers of userspace, can open the doors for a lot of problems.

          Other than e.g. a simple mount tool interfacing the kernel, which you can easily implement in 325 LOC (http://git.suckless.org/ubase/tree/mount.c), I doubt many people will inspect the systemd code. You said it looks like an EEE tactic by RedHat, but I think RedHat has sold itself to the NSA which is interested in having 0days within the Linux userspace. I think it is just a matter of time until the news of a NSA-exclusive 0day within RedHat-software like pulseaudio and systemd is found.

          Until this day, stop repeating the false song of the systemd monoculture. Even if systemd was the best software in the world we are selling the flexibility of the Linux userspace to a monoculture. And I have to remind you that systemd has many issues, even though it might work for you.

          1. 7

            does this remind anyone of embrace, extend, extinguish? I feel like RedHat is doing just that with this systemd nonsense. systemd sure seems on a slow and steady trajectory on to replacing most if not all of the userland. I can’t see how that’s a positive thing for Linux or the community; but I can think of a billion reasons why RedHat would love, love, love that.

            Always the same comments on systemd stories. That got old a couple of years ago. The point of systemd, and pulseaudio, and probably other software part of this “embrace, extend, extinguish” agenda is to get better sane default behavior, even across distributions. I for one welcome this! It works perfectly fine on my Fedora desktop and CentOS servers. I just like to get stuff done and try to follow the “new” best practices by reading the excellent! RHEL documentation. Embrace it and learn it, instead of fighting it, it works great! I’d rather hate a bit on firewalld or NetworkManager in the server context :)

            here’s to hoping for more OpenBSD users who end up donating money and usable code to the project! :D

            This I always hope for! I’m doing my share by buying some stuff from the OpenBSD store and advocating it whenever I can, unfortunately don’t use it (directly) myself, but I love the project, the philosophy and appreciate the benefit it brings to Linux distributions :)

            1. 23

              to get better sane default behavior

              This would be a lot easier to believe if pulse actually worked. Instead it recently started muting everything when I plug my headphones in, but only about 40% of the time, whereas 20% of the time it merely sets the volume to zero without muting. Before pulse came along everything worked flawlessly every time.

              1. 14

                Totally agree with this. I recently switched to FreeBSD because of systemd, and I’m OK with a more monolithic approach to releasing the kernel with the base userland utilities. Systemd/PulseAudio just don’t work though.

                FreeBSD’s sound system is configured with a 3 line file. System initialization is done in one file with about 15 lines (not hundreds of lines scattered about a /etc/init.d directory). With PulseAudio to get sound working, it’s a 20 line Alsa file, plus twiddling values in a GUI (that’s one way to really irritate me). Yes, I’m sure there’s a config file somewhere that can be edited by hand, but I haven’t seen a standard way of doing that. Oh, and Pulse always breaks after I add new hardware. Everytime. It’s sucks at having any kind of sane defaults.

                1. 8

                  I’ll just throw in my story. 100% of the time PA has worked for me. Every morning I get on a conference call and plug my USB headset in. The audio and microphone are redirected to the headset properly. This is on a laptop running Xubuntu so maybe other Linux distributions have a lower success rate.

                  1. 7

                    All that sort of stuff has worked for me pretty well since I switched to Linux in the early 2000s, modulo driver support for the various hardware (not really an issue with the sound system).

                    When Pulse came out, various programs would randomly stop outputting audio. Over time, things eventually improved so that it worked just fine for me, with no visible difference to before pulse audio existed. I’m not sure what it’s supposed to buy me, tbh.

                    1. 4

                      It probably works fine on Lennart’s laptop too.

                2. 5

                  I am all in for supporting OpenBSD. But I don’t get this kind of weird reasoning, ‘Red Hat tries to own the whole user land, let’s all move to some other operating system where user land is owned by one organization’.

                  IMO, Linux should move exactly in this direction. One can debate whether systemd is the right implementation, but it would be much better to have a coherent, integrated, base system like the BSDs. It makes it easier to deploy software to multiple Linux distributions, it makes it easier to educate people in one and all Linux systems, improvements benefit everyone, more integration is possible. Many of these arguments have traditionally been made in favor of the BSDs.

                  1. 13

                    Sure but unfortunately it impacts the whole ecosystem. I don’t care how Linux moves under a single umbrella company. I do care when they ask tmux to add systemd specific code and are becoming hard dependencies for things like Gnome. Suddenly you might see the amount of software that can still run on non-Linux machines suddenly drop - that’s what I’m afraid of.

                    1. 8

                      I do care when they ask tmux to add systemd specific code

                      And again people are using double standards. If it’s some systemd-specific change to a project, half the internet is up in arms to flame systemd. If it’s modifications for OpenBSD’s pledge, everyone (particularly here) sings praises. UNIX projects have always needed a hodge-podge of platform-specific code because of the lack of uniformity between unices and even within unices (Linux distributions in particular).

                      are becoming hard dependencies for things like Gnome

                      Isn’t that GNOME’s choice? Presumably, they don’t want to stick to pure POSIX (SUSv4) plus X11 to facilitate a modern desktop environment.

                      All in all, I see this more as the failure of the Open Group et al. to make meaningful standards for UNIX workstations in 2016. In the meanwhile, OS X took most of that marketshare and Microsoft is will probably do some more once their NT Linux personality/subsystem is out of beta.

                      Note: I don’t think systemd is perfect and I agree that its reach is quite wide. But I would argue that fragmentation in Linux is a problem that is an order of magnitude more serious than potential deficiencies in systemd are. So, if systemd can reduce fragmentation significantly, I see that as a large net gain. I am always surprised that FreeBSD/OpenBSD aren’t gaining more traction, since they are much nicer UNIX systems (exactly because they are well-integrated/documented).

                      1. 22

                        I may be to close to explain without bias, but here goes. I don’t mean to say this is the absolute truth, but perhaps explains the double standard.

                        OpenBSD pledge is designed to make things better. There’s no ulterior motive of making things worse for everyone else. pledge gets its share of hype, and makes OpenBSD attractive, but absence of pledge probably doesn’t interfere with users of other systems.

                        systemd is also designed to make things better. All these disparate tasks finally consolidated under one umbrella. But it feels like there’s another agenda, to actually make life difficult for the people who don’t use systemd. That can be true or not true, it’s a feeling. I think though it’s fair to say not using systemd incurs costs and consequences unlike not using pledge.

                        1. 4

                          systemd is also designed to make things better. All these disparate tasks finally consolidated under one umbrella. But it feels like there’s another agenda, to actually make life difficult for the people who don’t use systemd.

                          How does make that difficult? systemd is not operating in a vacuum. It’s other projects (GNOME and others) that choose to rely more and more on systemd features. I think it is a logical consequence of a sizeable majority of developers in such projects being Linux users who don’t care much about other systems. Most Linux distributions with a sizeable user base have moved to systemd.

                          To most people, Linux and OS X have won the UNIX wars, so why bother with other ‘marginal’ systems?

                          1. 9

                            To most people, Linux and OS X have won the UNIX wars, so why bother with other ‘marginal’ systems?

                            I heard that exact line over and over again around 1995-2000. Though it was ‘Windows & OS X’ back then.

                            Even Mac OS X had doubtful future back then. The iPhone changed a lot in that area. Think where you are placing your bets. We don’t know what the next big thing will be based on.

                            1. [Comment removed by author]

                              1. 3

                                Whether they needed or not is up for the Debian Developers to decide, which they did in a very messy and complicated vote.

                              2. 1

                                Systemd is monolithic, if Ubuntu say wants to replace it with something else they now have to add in a mount command (As well as all the existing functionality). This makes it tricky, erring on impossible depending on the size of the distro to ever experiment with separate mount command. If mount should work entirely differently on my platform for some reason I now have to maintain a systemd patch, I can’t just fork mount and maintain my own independent project.
                                Note, this might not be an accurate description the mount situation, I just picked it as an example because it was mentioned in the article.

                                1. 6

                                  Excuse me, what? The mount command from util-linux stays as it always was, no one is dropping it nor replacing it with something else. What ubuntu needs to “add in” should they move out of systemd?

                        2. 4

                          I think people are particularly suspicious of red hats motives. Who pays for red hat and are their interests aligned with my interests?

                          1. 3

                            Well, “Our customers are just like you.” is prominently featured as the title of this page: https://www.redhat.com/en/customers – they must be aligned with your interests, right? :)

                            I’d like to think Red Hat has best interests in mind as they push forward with this. After all, they are the certainly betting it all on being able to sell Linux. But, the best interests that they have in mind, are the IT organizations that have to install, maintain and choose to continue purchasing Red Hat, not every day schmucks that just want a nice desktop “Unix” system that isn’t OS X.

                            1. 3

                              the best interests that they have in mind, are the IT organizations that have to install, maintain and choose to continue purchasing Red Hat

                              I do have to wonder - does systemd result in more resilient, easier to configure/support server systems (which, arguably, is where Red Hat gets most of its OS sales)? I really can’t answer that question, particularly as it seems to me that a lot of the changes that are being made are desktop focussed.

                              1. 1

                                From practical experience, some aspects of systemd benefit server use as well. E.g. the restart policy for services that can be specified in unit files [1] is a very welcome improvement over SysV init scripts (or Upstart). Combined with effective process tracking via cgroups, the policy can be set to automatically restart services on failure.

                                [1] https://www.freedesktop.org/software/systemd/man/systemd.service.html#

                      2. 8

                        The title of the article is clickbait. It gives the assumption that the systemd will now make mount(2) calls, while it will still fork out to mount(8).

                        1. 2

                          As easy as it is to criticise systemd (and boy, is it easy), some of the things it does have some reasonable thinking behind them (albeit the implementations have not all aligned well with Unix principles). Even this mount change does have some merit for desktop systems - if I’m not mistaken, OS X also does an auto fsck. But (and this is a big but), a lot of the changes are aimed solidly at improving the desktop experience, a market that must be minuscule for Red Hat. And as a result of these desktop-focussed changes, servers now have to endure all of this nonsense because almost all distros have been quick to adopt systemd (Gentoo is, I think, the one notable exception).

                          1. 1

                            Gentoo is, I think, the one notable exception

                            Slackware and Alpine also (SysV and OpenRC respectively).

                          2. -2

                            What leads people to design interfaces like that?

                            $ systemctl --journalctl unit-types -mount source::fstab/dev/sda1 dest::disk-path/local/systemd/media/disk1

                            1. 12

                              Permalink to the comment

                              I figure it’s not obvious to many that the above is utter nonsense. The actual syntax for this tool to mount /dev/sda1 is like this:

                              systemd-mount /dev/sda1
                              

                              You are welcome.