Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Open Source Idle Linux

In Which Linus Torvalds Makes An 'Init' Joke (lkml.org) 358

Long-time Slashdot reader jawtheshark writes: In a recent Linux Kernel Mailing List post, Linux Torvalds finishes his mail with a little poke towards a certain init system. It is a very faint criticism, compared to his usual style. While Linus has no direct influence on the "choices" of distro maintainers, his opinion is usually valued.
In a discussion about how to set rlimit default values for setuid execs, Linus concluded his email by writing, "And yes, a large part of this may be that I no longer feel like I can trust "init" to do the sane thing. You all presumably know why."

In Which Linus Torvalds Makes An 'Init' Joke

Comments Filter:
  • by QuietLagoon ( 813062 ) on Saturday July 15, 2017 @11:47AM (#54814183)
    I don't know why. Can someone explain? thanks.
    • by darkHanzz ( 2579493 ) on Saturday July 15, 2017 @11:53AM (#54814227) Journal
      Presumably, this is a poke towards systemD. It has suffered from feature-creep, which directly opposes the unix-philosophy of doing only one thing, but doing it well. Recently, there was a problem with, I believe the DNS server which is part of systemD.
      • by TWX ( 665546 ) on Saturday July 15, 2017 @12:50PM (#54814623)

        So SystemD is the Emacs of init?

        • systemd is absolutely the emacs of init. I've been using emacs since the 90s and I would never switch to something else. All that time I was wish for a better init system. Now I have the init system that I want to keep using for the next 30 years.

          • by TWX ( 665546 ) on Saturday July 15, 2017 @01:20PM (#54814831)

            So what editor do you use?

          • It is probably worse. Systemd gobbles up external features because it is inherently incompatible with the packages implementing them. And feature creep is just the smallest evil, the biggest evil is, during this furious re-implementation, they introduce new bugs.

            • biggest evil is, during this furious re-implementation, they introduce new bugs.

              NOTABUG WONTFIX.

              This function returns EFUCKYOU on attempted use.

            • The only sad part is, if everyone here used all the energy they have to hate on SystemD, to actually fix those bugs, we wouldn't be having these discussions about how buggy it is.

        • by gweihir ( 88907 )

          No. Emacs works well, given enough resources.

        • by MrKaos ( 858439 )

          So SystemD is the Emacs of init?

          As a vi user, I would not insult Emacs that way.

          systemd is the svchost of linux, except that svchost is for windows and they don't want systemd either.

      • Re: (Score:2, Interesting)

        by Anonymous Coward
        Yeah. systemD supports the Windows-philosophy of doing almost everything, but doing it half-assed. Besides, what's wrong with having the DNS server be part of the init system?
        • Re: (Score:2, Informative)

          by Anonymous Coward

          > doing it half-assed.

          Like logging. Logging is critical for both troubleshooting and security. With sys V init scripts, even if the error wasn't logged to syslog, you'd at least see it on the console instead of so often seeing nothing with systemd.

        • by gweihir ( 88907 )

          Indeed. That is the main problem with it. On wonders whether this is an indicator of plain incompetence?

      • by Anonymous Coward on Saturday July 15, 2017 @01:07PM (#54814747)

        Don't forget the recent severity 9.8 CVE regarding invalid username handling [nist.gov] that Poettering closed as NOTABUG [github.com]. It's a trainwreck of bad design driven by an egotistic idiot.

        • by gweihir ( 88907 )

          And that is the core problem. This moron cannot recognize what is important and what is not. Add the fanatic followers he has and that whole thing becomes extremely dangerous.

    • by TechyImmigrant ( 175943 ) on Saturday July 15, 2017 @12:05PM (#54814289) Homepage Journal

      Make no mistake, this is a turf war.

      Who's in charge? The user? The kernel? Ring-0?
      The answer to this is different depending on the topic. The topic here is init and who gets to say what the rlimits are and how. There are lots of other topics - random numbers, filesystems, network attach-detatch, routing etc. For all these things and many more there has been a turf war along the lines of "We will fix this in the kernel!", "Oh no you won't, we will fix this with our daemon", "Oh no you won't, my userland administration tool will fix this".

      This is generally fine, but for each there will be a slashdot thread with many jerks represented.

      • by QuietLagoon ( 813062 ) on Saturday July 15, 2017 @12:12PM (#54814331)

        ...For all these things and many more there has been a turf war along the lines of "We will fix this in the kernel!", "Oh no you won't, we will fix this with our daemon", "Oh no you won't, my userland administration tool will fix this"....

        At that point, the need for an overall system-level architect comes into play. Someone who looks at the overall system, its architecture and design goals and decides the best way to implement features and fixes.

        .
        To this Linux outsider, it seems that systemd was implemented more because someone decided to do it, rather than being done because it was the appropriate solution to a problem.

        • Re: (Score:2, Interesting)

          by Grishnakh ( 216268 )

          To this Linux outsider, it seems that systemd was implemented more because someone decided to do it, rather than being done because it was the appropriate solution to a problem.

          No, it's both. There was a valid problem: sysvinit was decrepit and unsuitable for modern systems, as seen by the fact that every other Unix system out there has abandoned it and has something that resembles systemd in some way (Solaris has SMF, MacOSX has something else).

          But because there's no overall system-level architect, some g

          • by Anonymous Coward on Saturday July 15, 2017 @12:56PM (#54814669)

            sysvinit was decrepit and unsuitable for modern systems,

            This is complete bullshit. My (modern) computer worked perfectly fine before systemd. There was zero improvement after my preferred distro replaced init with systemd. Maybe it booted up 2 seconds faster? I don't know, it's linux, I don't ever fucking reboot it. The only change in my life was how much time I had to spend learning systemd bullshit that added ZERO VALUE to my use of linux on my pc.

            So you better get a LOT more specific as to which system was "unsuited" for sysvinit before you start making blanket statements like that or people are going to continue to call you out on your bullshit.

          • by TWX ( 665546 ) on Saturday July 15, 2017 @01:19PM (#54814825)

            That's because in-part design-by-committee ends up with the noisiest, stupidest person on the committee calling the shots, that project ends up catering to the lowest common denominator.

            A large part of why Linux itself is successful is that while there's a lot of input, there's a single point of decision making in the form of Torvalds himself, and he's both smart enough to generally make good choices, and to listen to the debate and weigh the arguments to make a decision.

            Lennart Poettering is no Linus Torvalds. Perhaps something to replace System V and BSD inits is necessary, but Poettering's work with pulseaudio is itself incomplete; the init system is far too important to trust to him when his sound daemon, a relatively small but important piece of the desktop system, isn't really finished to a polished state.

            Besides, with the advent of the VM model for hosting and "cloud" where VMs are created and destroyed on an as-needed basis and automatically, stripping down the init process to the bare-minimum needed for a VM and using some kind of staging system to spawn the right conditions in the VM init process is probably more important than some all-knowing, all-seeing system that seems more tailored toward long-running, general-purpose computing anyway. The problem that SystemD solves isn't the new problem, it's the old one.

            • by Anonymous Coward

              ... The problem that SystemD solves isn't the new problem, it's the old one.

              systemd actually solves a problem?

              Like hell.

              It's a solution in search of a problem from a close-minded CODER who never saw anything he couldn't solve by writing MORE crap code.

              Poettering has a hammer - MUST WRITE MOAH CODEZ!!! - and to him, every damn thing is a nail. His solution is ALWAYS to write more of his own code to do ANYTHING. That's why systemd reinvents all kinds of crap it doesn't need to.

              Poettering is a close-minded, unthinking amateur.

            • What do you call design by committee but adopt by technical evaluation?

              I mean the systemd project itself may be shit, but for some reason all the technical maintainers of distros who have nothing to do with systemd think the opposite.

            • by MrKaos ( 858439 )

              Poettering's work with pulseaudio

              Holy crap, that steaming turd called pulse was Poettering's work? Fuck me that explains so much now.

          • Re: (Score:2, Interesting)

            by Anonymous Coward

            incorrect so stop spreading FUD...

            sysvinit is perfectly fine. The issue was sysvrc & more specifically the really bad sh coders that redhat had.
            SysVinit as init, ie pid1 is good enough... its boots from the kernel, its launches RC, it reaps zombines and it shuts down the system. THAT IS ALL INIT NEEDS TODO.

            Sure pid2 might need to be more complex BUT PID1 does not! especially if you need todo an update w.r.t. RC, which with systemd needs a reboot DERP!

            SysVInit is very simple and does its job well; runit

        • by Megol ( 3135005 ) on Saturday July 15, 2017 @02:00PM (#54815023)

          ...For all these things and many more there has been a turf war along the lines of "We will fix this in the kernel!", "Oh no you won't, we will fix this with our daemon", "Oh no you won't, my userland administration tool will fix this"....

          At that point, the need for an overall system-level architect comes into play. Someone who looks at the overall system, its architecture and design goals and decides the best way to implement features and fixes.

          .

          To this Linux outsider, it seems that systemd was implemented more because someone decided to do it, rather than being done because it was the appropriate solution to a problem.

          Unlike most complainers (some that simply doesn't understand systemd at all) systemd solves a number of real world problems created by the disconnect of how computers used to be used (let's call it "static" configuration) and how a system is used today (... "dynamic" configuration).
          If systemd is so bloated, reinvents the whole of Linux, is a Microsoft conspiracy etc. why is that it actually solves (most) problems with older init systems? Why is it modern Unix systems have similar "dynamic" init systems rather than the old? Why is it nobody else actually created a modern init system that can be used for the same things as systemd but "follows the Unix philosophy"*?

          In a was systemd is kind of a hack - but that is because it tries to integrate into the Unix design and allow it to do things it wasn't designed to do. In some cases maybe systemd have to much of hack in it but again: where is the alternative?

          Note: I don't really like systemd.

          (* I strongly maintain that people taking about 1) doing one thing well being a Unix thing rather than a design thing 2) thinking that philosophy is actually applied to modern Unix systems are seriously confused)

          • Before SystemD, when I restarted a service|daemon, I would see a console message when the service stopped/restarted or failed. With SystemD I see absolutely nothing for success or failure. Improvement? Certainly fucking not. Needing to do a PS|GREP on the service is hardly an improvement over anything.

          • by dbIII ( 701233 )

            why is that it actually solves (most) problems with older init systems

            I hear that line a LOT but nobody ever seems to provide examples of even trivial problems solved.

        • by gweihir ( 88907 )

          Indeed. Linus is an excellent kernel architect, but he fails pretty seriously on the system level.

    • The joke is, it isn't doing anything wrong, people just don't "trust" it because change is scary.

      It was a brilliant version of the joke because both sides can laugh at each other.

      And everybody gets to keep the init system they wanted, except for the people that don't know how, who will probably whine a lot even though it doesn't affect people not fiddling with it.

      • by bferrell ( 253291 ) on Saturday July 15, 2017 @01:25PM (#54814867) Homepage Journal

        I quote myself...

        More pointedly, systemD has recently been found declareing usernames that are considered valid by the system at large and by POSIX standards, to be invalid and selecting a new userid at random (on some very common systems, root) and silently running processes under that user id.

        This is an EXTREMELY non-standard behavior and as such, unexpected by the user community at large. By many, it is considered a security breech. Based on the comment from Linus, I suspect he does not consider this to be sane behavior.

        The systemD developer community has demonstrated reluctance to correct this observed behavior.

        This isn't "change is scary". This is, the damned thing is broken and the developers went into Pewee Herman mode (I meant to do that! I won't fix it).

        THAT is scary. The rude and dismissive attitude around the cult of SystemD is even more scary.

        • This is an EXTREMELY non-standard behavior and as such, unexpected by the user community at large.

          The counter-argument was that it is not supported by distros already, for many years, for other reason, so there is no good reason for systemd to support it.

          • Point in fact, distros DID support it, which is how the issue was discovered.
            Some wrapped the command that did it, but most didn't.

            The core issue isn't the bug. The core issue is the pattern of rude and dismissive responses to the bugs.

          • What do you mean "not supported". There were some scraps of documentation in some places saying it wasn't supported, and documentation in other places (e.g. POSIX) saying it was. There is no real Linux userland standard, so this was really just systemd people unilaterally declaring it to be so and blaming users for the massive hole.

    • Re: (Score:2, Insightful)

      by bferrell ( 253291 )

      More pointedly, systemD has recently been found declareing usernames that are considered valid by the system at large and by POSIX standards, to be invalid and selecting a new userid at random (on some very common systems, root) and silently running processes under that user id.

      This is an EXTREMELY non-standard behavior and as such, unexpected by the user community at large. By many, it is considered a security breech. Based on the comment from Linus, I suspect he does not consider this to be sane behavio

  • by Anonymous Coward on Saturday July 15, 2017 @11:52AM (#54814221)

    Linus knows his time is short

    Repent, Linus, and maybe systemd will allow your kernel to run as a background process for housekeeping and legacy tasks.

  • by Mostly a lurker ( 634878 ) on Saturday July 15, 2017 @12:03PM (#54814275)

    Surely in the systemd era, we should be deprecating setuid on executables, and replacing it with some kind of systemd api. This provides a much more modern "unified" approach then all that minimalist, modular rubbish that infected the system for so long.

    • I know you're trying to be funny, but for those who don't know it, setuid executables have been deprecated since a while.

      $ ls -l /bin/ping
      -rwxr-xr-x 1 root root 44104 Nov 8 2014 /bin/ping

      See? No setuid bit, and still able to mess with raw packets.

      The old setuid thing has been replaced with granular capabilities(7) bits, which are stored in a "security.capability" extended attribute.

      $ getcap /bin/ping /bin/ping = cap_net_raw+ep

  • Joke? (Score:2, Funny)

    by amiga3D ( 567632 )

    It init funny. Not at all.

    • how about stigginit to init with sigint?

      (head asplodes)

    • It init funny. Not at all.

      Well, your comment is funny at least. But I'm not seeing the attempted humor in Linus' line... it just seems like a plain old comment. ... unless they were talking about GNU scanner software.

  • You were warned (Score:5, Insightful)

    by Anonymous Coward on Saturday July 15, 2017 @01:01PM (#54814693)

    SystemD is a trainwreck from day one and just keeps on piling more of it. If it were only init, things would've been more than fine. But no. It's a whole project of reinvented crapware that is reinvented BADLY. And distros blindly install more and more from the "project". Like Ubuntu and their idiotic decision to switch to systemd-resolved which was wrought with nothing but trouble, rendered Ubuntu 17.04 dead in the DNS water for a month since its release! I wonder which maintainer got paid to subvert Ubuntu with that.

    * networkd assuming dhcp client role, but then not renewing lease (freedesktop bug #82731 -- open for 3 years now!!), among many other issues
    * resolved assuming DNS resolver role, but then not being nearly compliant with RFC, among many other issues, some even serious security vulnerabilities
    * consoled taking over console, but then someone realized it's a REALLY dumb idea so they scraped it (for now)
    * timesyncd assuming ntpd role, but then doing stupid things like defaulting to Google NTP which is NOT a normal NTP service! Asked by google to not do that, responded EWONTFIX (systemd github issues #437), among many other issues ...

    In fact, it's even bad at being "just an init". Good luck with those NFS mounts and systemd. Good luck with "A start job is running" when it encounters a trivial situation that every. other. init. can. work. around.

    It's a shitshow fueled by arrogance of "we know better than all of you combined", just a quick look in the github issues is sufficient to see this. It's so out of control, that issues found to be 10 on vulnerability scales are closed as not a bug (CVE-2017-1000082).

    Every software has bugs, but systemd bugs are closed EWONTFIX because the principal developer has zero clue about modern operating systems. The principal developer of an init for a traditionally server oriented operating system* who, by his own words, never administered servers. And who, by his own words, disables read ahead prefetch because "systemd developers all run laptops with SSDs and don't need it"....... !!

    It's a sinking ship, rats are fleeing, and more and more professionals are getting SICK of it. You were warned, you laughed, you called us luddites, now enjoy the turd.

    *) With a server market share of more than 50% (look up Netcraft monthly stats), and a desktop market share of 1% -- so guess where the priorities are

    • by Frosty Piss ( 770223 ) * on Saturday July 15, 2017 @03:38PM (#54815525)

      I am not questioning you opinions on systemd, particularly since my father, a retired CE and lifelong *nix user dislikes it with a passion. But I'm way to ignorant of the dirty mechanics and politics of Linux to understand how, with so many presumably knowledgeable folks who dislike systemd, it became a standard in the more popular distros. Does it solve some vexing issue for the maintainers of these distros? What do these people find so compelling as to make such a fundamental change?

      • by chihowa ( 366380 ) on Saturday July 15, 2017 @07:24PM (#54816671)

        It's a trojan horse story.

        Maintaining unit files seemed easier than maintaining sysvinit scripts, so the distro maintainers liked it (along with a couple of other init replacement contenders). It's also shiny and new and backed by RedHat.

        There was feature creep and capricious architectural design before most distros picked it up, but perhaps people didn't think that it would keep getting worse and worse. Now the project encroaches on more and more system roles and doesn't play well with the existing tools.

      • by sad_ ( 7868 )

        because other projects started integrating systemd parts. other distro's could either drop those projects (but they were popular), or use systemd and continue to offer said projects.
        and all in all, systemd does offer some benefits, or rather said promises, but it just does too much and keeps evolving as 'the blob' growing bigger and bigger. when other distro's stepped in, it was still something small'ish.

    • Re: (Score:2, Informative)

      by thegarbz ( 1787294 )

      If you're going to bitch about bugs, there are so many to bitch from. But the ones you linked seem perfectly reasonable won'tfixs.

      - One single person reporting that DHCP leases don't renew even though his logs show that the client attempted renewal. If this were worth looking at there'd be thousands of confirmations. Why should the bug be fixed if it can't be confirmed?
      - Defaulting to google's NTP service is perfectly reasonable given the complete lack of alternatives. As shown in the bug tracker you are sp

      • by rl117 ( 110595 )
        Look, NFS mounting is broken. BROKEN. It works a small percentage of the time, but most of the time it fails to mount anything successfully at boot. The mount exists, but any attempt to use the mount results in an IO error. systemd fundamentally failed to bring up the NFS services properly, leading to a non-functional system. I can log in on the console, unmount everything, then remount it and it works perfectly after that manual fix. But on a day to day basis, I can't rely on using NFS mounts with sy
  • some things use systemd, others use the init.d scripts and the /etc/default/ (even in debian 9 the latest) systemd appears to not use /etc/default or you need to generate the systemd file from it.

    Then you have to daemon-reload systemd to try out

    Finding these systemd startup scripts is a nightmare if you need to adjust them.

    Maybe we upgrade linux to bsd nextime.

  • ...it's not only not clear that we want to do this... - Linus Torvalds (https://lkml.org/lkml/2017/7/6/577)

  • I am using gentoo now, but devuan is looking like it might be a decent distro.

CChheecckk yyoouurr dduupplleexx sswwiittcchh..

Working...