21 ms·

Linus: “I no longer feel like I can trust ‘init’ to do the sane thing”

350 points by cnst 9y ago

Rjevski 9y ago
I would assume this is about systemd. Personally my experience with it has been great - the occasional screw-ups (they did happen - something related to dbus made all systemctl commands fail until a reboot) were nothing compared to the time I gained not having to worry about prehistoric initscripts. So while it isn't perfect, it's IMO a step in the right direction, if only by lowering the barrier to entry to actually using and managing the thing. If you are worried about stability then you shouldn't rely on a single machine anyway. Personally I manage systemd screw-ups (though I haven't had one in production yet - all of them were on my personal machines while monkeying around with Archlinux) just like any other hardware failure - by making sure my app/service stays available even if I yank the power cord from the machine.
- SwellJoe 9y ago
  It seems obvious he is referring to systemd. I like systemd, but Linus hates it when people break userspace, and systemd has broken userspace a lot. Poettering seems to take the advice of "release early and often" to heart and pushes things into widespread usage long before they're quite fully baked. PulseAudio was awful for years, and then it was good and we all stopped complaining about it. systemd was kinda crap for months after it became widespread...a ton of breakage, including in ways that were occasionally dangerous. We're lucky, I guess, that systemd didn't take as long as PulseAudio to stop sucking all the time (systemd still sucks some of the time, but what it replaced sucked a lot, too). So, yeah, you can't break userspace if you want Linus on your team, and systemd has broken userspace now and then.
  - asveikau 9y ago
    You seem to exist in a fictional universe where pulseaudio "got good" and doesn't suck. All these years later I have never seen that be the case. I think a much more likely explanation is that desktop Linux is less common since the rise of OS X in the "Unix-like developer machine" market so there are now fewer people noticing it sucks.
    - pcr0 9y ago
      I was one of those developers with an OS X machine who decided to buy a Thinkpad and throw Ubuntu on it. pulseaudio worked out of the box for me and I definitely preferred it over the stunted OS X audio mixer that doesn't even let you define per-application audio.
      - isatty 9y ago
        The MacOS mixer is pretty much the epitome of "just works" even though I agree with you that it doesn't let you control levels per application. However I've been using the MacOS sound system (not just the mixer) for many years through many devices (mics, external dacs, HDMI transports, DP etc) and it has always worked without any problems.
        pfranz 9y ago
        I don't have much personal experience, but I /often/ hear about OSX users very wary of updating MacOS because of issues with sound equipment. This goes back to Classic. It may have gone away in the past 3-5 years, but the stigma is still there.
    - Rjevski 9y ago
      What were your problems exactly? In my case I used Linux full time from late 2012 to early 2014 and during that time I haven't had a single problem related to it, all while running bleeding edge Archlinux. The only issue was with bluetooth headphones but I'm pretty sure it was more with BlueZ being a pile of garbage than Pulseaudio being bad, given that BlueZ was giving me problems with all sorts of other (non sound) peripherals as well.
      - LukeShu 9y ago
        Are you actually using PulseAudio? Having run Arch (well, Parabola) since 2011, I haven't had any problems with PulseAudio... because I've never installed PulseAudio. Actually, I did have a problem with Wine and lib32-libpulse lagging slightly behind the video (where it's only a fraction of a second off, but enough that it doesn't feel like the words match the faces); and then I figured out how to get Wine to use ALSA, just like everything else.
  - throwaway2048 9y ago
    Its nothing to do with "release early and often", its gems like this that they refuse to fix over ridiculous hubris. https://github.com/systemd/systemd/issues/6237 https://github.com/systemd/systemd/issues/6237 Its going to end up exactly like glibc under Drepper, where distributions are forced to have a mile of patches because obviously broken shit isn't patched because the maintainers are too arrogant to admit fault.
    - grandinj 9y ago
      I dont see any signs of "refuse to fix" there. I see a calm and reasonable discussion and an acknowledgement that some things need improving. Perhaps they refused to fix it in exactly the way the reporter wanted, but that's a far cry from arrogant refusal.
      - bigbugbag 9y ago
        > yes, it's a feature that we don't permit invalid user names(...) So, yeah, I don't think there's anything to fix in systemd here. I understand this is annoying, but still: the username is clearly not valid. > systemd is not the one coming up with the restrictions on user names, and while some distributions are less restrictive, many do enforce the same restrictions as we do. In order to make systemd unit files portable between systems we'll hence enforce something that resembles more the universally accepted set, rather than accept the most liberal set possible. These are pretty clear "refuse to fix". Though I do agree that this is a poor example to illustrate the point.
      - isatty 9y ago
        What I saw was poettering spouting garbage about what he thinks is an invalid user name (when in reality, it is not and common tools like useradd don't complain about it). As the owner for a critical service like systemd (I don't use it, I prefer openRC on gentoo), he should know better.
        Steeeve 9y ago
        grrr... your init system should not dictate what a valid username is. Your init system should use whatever users you've configured. I don't like your name. Therefore you get root. How on earth did this init system become so prevalent?
  - otterley 9y ago
    How, exactly, has systemd "broken user space"? That's clear neither from the lkml thread, nor here. I'm not sure what this discussion even has to do with systemd; and I'm not even sure how you can "break user space" from a user space program, which init is. You might be able to modify your descendants' environment, but the rules under which that can happen are maintained and enforced by the kernel. It seems to me that if user space programs can do undesirable things, that's the fault of the kernel itself. To be sure, setting those boundaries and rules is one of the kernel's main jobs.
    - SwellJoe 9y ago
      There are a couple of inits in common usage on Linux; systemd is now the most popular and ships standard on the most popular distributions. I can't imagine Linus would be feeling grouchy toward a nearly defunct init (that had been in use mostly unchanged since the 90s), so we're left with systemd. Unless you've got a better idea about what he means? It is not a secret that kernel devs have a love-hate relationship with systemd, and have for years. That's why Linus said, "You all presumably know why." He was speaking with context that everyone on the LKML already knows. First result when I google it (but it's been a thing for a long time and on many fronts with many interesting bugs and arguments): http://www.phoronix.com/scan.php?page=news_item&px=MTY1MzA http://www.phoronix.com/scan.php?page=news_item&px=MTY1MzA I don't really subscribe to the "systemd is terrible and is the worst thing that ever happened to Linux" theory, and I'm not trying to be one of those folks that takes every opportunity to make a thread about how much systemd sucks. I like systemd. I mean it when I say that. But, in this case, it seems obvious it is about systemd. I have a hard time coming up with another plausible theory. Edit: Also, now that I'm thinking about Linus and Poettering butting heads...well, that's hilarious. A couple of brilliant assholes arguing is funny to me. I dunno how much it's actually happened (and how much happened through proxies), but still. Funny.
      - microcolonel 9y ago
        But you said specifically "...and systemd has broken userspace a lot." What did you mean by this? It seems like a complete nonsense statement in the context of user space breakage of the form the kernel is responsible for. The main clash between the kernel maintainers and the systemd maintainers was over systemd reading the kernel argv in an error prone way to trigger debug information. Other than that the interactions seem completely minimal. Linus Torvalds uses systemd at work and at home.
  - Qantourisc 9y ago
    I still hear a friend complain he often has to restart pulse because sound just stops working for him. And IIRC there is still no way to set the maximum amount of audio-buffer (for the end-user, not from the applications; some people prefer the occasional buffer under-run over the higher delay).
  - simias 9y ago
    Well, pulseaudio is still pretty crap as far as I'm concerned. After an update last week Spotify won't work anymore and the sound in Firefox is glitchy. I haven't taken the time to investigate what caused that exactly, and I'm not exactly looking forward to it. Not that I was a huge fan of ALSA either. It always felt a bit over-engineered for my taste. I can understand needing something like that if you want to make professional audio equipment with the Linux kernel but for my desktop use case OSS has always worked just fine for me and it didn't randomly break after an update. As for systemd, it's bearable and it mostly does what it's supposed to do, but it still feels a bit unnecessary and its security track record is not stellar so far. I prefer the simplicity of the BSD init personally.
    - nol13 9y ago
      Seems to have settled down now(?) but firefox audio was def glitchy for a few releases after for me requiring system restarts to get sound back.
- gcb0 9y ago
  this is all nice when you ignore the tons of bug reports everyone else is getting because you decided to treat your users as testers. why do you think linus is complaining? because he can't get sound to work on his own box or because kernel invalid bugs are over the roof thanks to bogus init?
- gaius 9y ago
  I would assume this is about systemd. Personally my experience with it has been great - the occasional screw-ups (they did happen - something related to dbus made all systemctl commands fail until a reboot) were nothing compared to the time I gained not having to worry about prehistoric initscripts There is a vast gulf between two communities, people who run Ubuntu Beta for fun on their own PC, and people who run 10,000 RHEL boxes in Prod, and both communities tend to talk "at" each other and misunderstand where the other is coming from. The scenario you describe is something that would make one of the latter community recoil in horror.
  - derefr 9y ago
    There's a third, rather small community: the distro-makers, who nearly to a one are—if not in love—at least hold systemd in high regard. It's easy enough to understand their point of view: run through a Linux From Scratch install. You'll have to write your own init system. You'll be duct-taping a lot of things together, and your solution—while it might be something you're "proud of" in some sense—will definitely be lacking in engineering, no matter how much time you as one individual could ever throw at it. After the LFS experience—which is essentially the distro creation experience—coming back to regular (pre-systemd) distros made one feel rather different: it was very easy to see how each distro was, at its core, just someone else's duct-taped-together init system with a pile of hacks accumulated on top. There wasn't any real Engineering; there was no shared knowledge-base of best practices for doing this or that. Each distro was a evolutionary Galapagos island. From the LFS perspective, an init system that exists as its own standalone FOSS project, containing contributions from hundreds of interested parties and battle-tested engineering choices after coming-up-on-a-decade of use in virtually every scenario, is a wonderful thing. systemd is, finally, a reference implementation of an init system "at scale." If you want to build your own init system, you don't have to look at the init systems of 30 different distros to figure out what things each distro just did its own way for no reason, any more (which used to be "most things.") You can just start by looking at "what systemd does", and figure things out from there. Or you can use some systemd components, and some of your own.
    - PuercoPop 9y ago
- mfukar 9y ago
  systemd has a few nice ideas, and it might be alright for whatever your use case is. I'm working on a product which uses it as its init system, and it's an endless source of problems. Its flaws are deep and unfortunately pervasive.
- xaldir 9y ago
  As a user, I would agree, systemd kinda just works and it's nice. As a sysadmin however, I hate it so much. Not because I have to learn a new system which is nice, but because it breaks so much things. I had to rewrite scripts that just worked for years, I had to do a bit of black magic to make old software behave on newer distribs and it's just so frustrating. I get it that most of these things were not done in the right way but FFS, don't break my production stuff.
- kochthesecond 9y ago
  Oh yes, the init to systemd phase was brutal on arch. So many broken systems :(
- knorker 9y ago
  My problem with systemd is that is seems to have a policy (most certainly a history of actions, and that's really the significant thing) of NOT doing the sane thing, then being called out for it, and then having the systemd people defend not doing the right thing. I can trust someone who makes mistakes. I can't trust someone who refuses to accept that they regularly make mistakes. Nor can I trust their work.
- Aardwolf 9y ago
  They're not really following the philosophy I expect to see a unix-like OS, so my experience also wasn't great. Like turning logs into a binary format, and then later bugging out on it so when you try to read it with their convoluted command (where cat or less was sufficient in the past) it gave errors on its own mess and refused to display anything. Bugs happen, that's understandable, but simply the fact that they turn logs into a binary format shows their philosophy is different than the one I expect from a unix-like OS. And almost all distros are following them sadly...
  - shimon_e 9y ago
    Any reason why we can't have journaldfs?
- raverbashing 9y ago
  > If you are worried about stability then you shouldn't rely on a single machine anyway. Sorry, this is a complete BS "solution" You don't keep a broken piece of software running then put more redundancy to make it kinda stable. Redundancies are for when things break, not for when they're broken from the start Nobody takes off from a plane with one inoperative engine, both have to be turning, so in case one fails the other one can take over
  - digi_owl 9y ago
    Effectively what you are responding to is the ever more prevailing "cloud" mentality, where there is always another instance to spin up in a second if something where to break. http://www.commitstrip.com/en/2015/07/08/true-story-fixing-a-self-ddos/ http://www.commitstrip.com/en/2015/07/08/true-story-fixing-a... And while systemd may have started on the desktop (likely to "solve" the speed of repeated bootups when using a laptop "securely") increasingly its development is dictated by this cloud mentality (as is the development of various distros, as someone basically shouted to my virtual face over at LWN).
- btschaegg 9y ago
  I could imagine that Linus is also influenced by experiences such as [1][2]. After a couple of issues like that I can imagine that he has his doubts about some of systemd's behavior. [1]: https://bugs.freedesktop.org/show_bug.cgi?id=76935 https://bugs.freedesktop.org/show_bug.cgi?id=76935 [2]: https://lkml.org/lkml/2014/4/2/420 https://lkml.org/lkml/2014/4/2/420
- jankedeen 9y ago
  17 years on linux 20+ in *nix. systemd is ! init. There are other ways to introduce an init analog systems bus for functionality without replacing init. Wrongheaded and developed for the wrong reasons in the wrong way.
testcross 9y ago
The internals of systemd are maybe not the best. But the UI is definitely easier to grasp than what existed previously.
- ill0gicity 9y ago
  The UI is easier? I'm gonna need you to explain this.
  - Rusky 9y ago
    Declarative unit files are far easier to manage than fragile ad-hoc scripts.
    - brandonbloom 9y ago
      This is only a tiny piece of the experience though. What about journalctl? systemctl? etc? That stuff is alien vs tail -f or ./just/run/some.sh which works with everything _except_ systemd.
      - jhasse 9y ago
        You can google how to do the equivalent to `tail -f /var/log/foo.log` in a minute. What do you mean by ./just/run/some.sh?
        boomlinde 9y ago
        > You can google how to do the equivalent to `tail -f /var/log/foo.log` in a minute. Doesn't the fact that I have to google an alternative workflow for something that behaves consistently across pretty much all other software make its UI worse, at least in that regard? I get that maybe it's a justified trade-off, but that doesn't make the UI any better. > What do you mean by ./just/run/some.sh? I suppose just dumping an exec command into an executable file and call it a service.
        9y ago
ausjke 9y ago
Like what happened to git in the past, will Linus write a new init himself this time?
- saurik 9y ago
  Linus wrote git because BitKeeper was taken away from him due to the Andrew Tridgell incident, not because he disliked BitKeeper; he didn't even mind that it was closed source.
  - speeder 9y ago
    Decided to google about this... Found this article: https://www.pcworld.idg.com.au/article/129776/after_controversy_torvalds_begins_work_git_/ https://www.pcworld.idg.com.au/article/129776/after_controve... I wonder, how many people reading that article would predict the rise of stuff like GitHub and GitLab and the success of Git to the point of crushing CVS and making SVN decline in popularity?
    - ktRolster 9y ago
      CVS was already being kicked out the door at that time by SVN. A lot of people looked at Git as a potential replacement for SVN (at least, I did. Took several years for me to really 'get' it, though. I'm not sure even today I completely 'get' Git: there are a lot of possible workflows). I didn't dream of it in terms of GitHub.
      - bluGill 9y ago
        > I'm not sure even today I completely 'get' Git: there are a lot of possible workflows In my experience most people are using git with a svn workflow. They use github (gitlab, or something internal to the company) as the central server, and work only from the central server. Make github speak svn, and alias all the git commands to svn and they couldn't tell the difference.
        ktRolster 9y ago
TheAceOfHearts 9y ago
Here's something I don't understand... Why do so many people hate systemd but not macOS's launchd [0]? Don't they serve similar purposes? I've been digging into macOS for a few months now, and I'm pretty happy with their defaults. EDIT: I don't know why I'm being downvoted for asking a genuine question. I'm not a linux expert, so I'd love to hear your criticisms. [0] http://www.launchd.info http://www.launchd.info
- otterley 9y ago
  I suspect it's because nobody ever really has to touch launchd configurations because Macs aren't commonly used as Internet servers.
  - TheAceOfHearts 9y ago
    I've been happily using macOS server at home for a few months. It's not a production-ready deployment, but I haven't had any complaints. Aside from that, using it on my personal laptops has worked surprisingly well. Once I familiarized myself with the CLI tools, I haven't had any issues.
    - digitalzombie 9y ago
      > I've been happily using macOS server at home for a few months. It's not a production-ready deployment, but I haven't had any complaints. It's not on AWS. Your use case is just a hobby or one man shop or just one data point. It doesn't necessarily scale well for other use cases. I think what other people are pointing out is that companies aren't lining up to use it or replacing it over a linux server or window server.
  - dredmorbius 9y ago
    Anecdata: I wanted to set up a Mac box as a remote syslog server. It's running, IIRC, rsyslogd, which is to say, remote syslogd. All you've got to do is tweak the PLIST. Read the manages. They're out of date. Looked at the PLIST tools (not my thing). Doesn't seem to be an option. There used to be, back when PLISTs were actual files you could edit. That's gone away now though, best I can tell. Got a Linux box up and running, that now accepts remote logs.
gjvc 9y ago
The quote here in the title is missing the vital context -- the full quote is ""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.""
throw2016 9y ago
Making too many assumptions about the user environment is not smart. Then you start putting constraints and becoming defensive when these assumptions are questioned. This is becoming a pattern for systemd as is blaming everyone else. [1] Those who need the complexity or some features should adopt the technical debt, there is zero rationale to enable it by default and impose it on everyone. For instance if you have too many network interfaces and naming is a problem then switch on predictable network names which btw is anything but predictable for human beings and let the 97% who don't carry on. 12 digit random names are simply not predictable or better for human beings than eth0, wlan0? If there is a problem predictable network names is not the solution. Similarly if you need binary logging and an audit trail then turn on binary logging but don't impose it on everyone else. Its time to move beyond silly accusations of 'hate' etc every time there is a discussion about systemd because at the moment it just serves to deflect criticism and avoid accountability for questionable decisions. [1] https://github.com/systemd/systemd/issues/2407 https://github.com/systemd/systemd/issues/2407
- danieldk 9y ago
  Those who need the complexity or some features should adopt the technical debt, there is zero rationale to enable it by default and impose it on everyone. Indeed. Even if I have multiple ethernet interfaces, I'd prefer to map a MAC address to eth[0-9] myself. But most machines only have one ethernet interface and one WiFi interface anyway. These things pop up all over the place. E.g.: why would I want to have NetworkManager on a server, which never switch networks and need to set up a VPN connection? Why do I need firewalld on a server? I rarely need a zone-based firewall on my laptop (probably like most users, I just block all incoming traffic), let alone a server. Layer upon layer is piled to solve hypothetical situations that do not arise for > 90% of the population. (I do like systemd as a service manager, but systemd and the surrounding ecosystem has made it terribly difficult to understand and debug UNIX systems.)
  - mdekkers 9y ago
    why would I want [insert a systemd design decision] Because systemd wants to be The One Ring of Linux, and tries to be all things to all systems and all people.
stephenr 9y ago
I fucking hope not. Linus is clearly very smart, but user-facing tools is not what he's good at. Git is a perfect example of this. Mercurial and Git were created ridiculously close to each other, and their main features/use model are quite similar, and yet mercurial is literally years ahead in terms of usability. The results to a given command are 99% of the time, what you would intuitively expect. Now here's what I would love to see: Linus initiate a fork/rewrite/whatever of the init part of systemd, that keeps the concept of non-executing service definition files. They don't have to be compatible with systemd but that wouldn't necessarily be a bad thing either. Edit: actually, aiming for compatibility probably means having to reimplement systemd weirdness, so probably is a bad thing as I think about it.
- beefsack 9y ago
  It's quite frustrating seeing people complain about Git usability like it's some broadly accepted and objectively bad thing. As frivolous as anecdotes are, I took to Git very smoothly and I found it to operate in a very obvious and explicit fashion, particularly once I'd shifted my mental model from what I was using at the time (primarily SVN.) Git is a very powerful, flexible, reliable and efficient tool. I'd be over the moon if someone wrote an init system holding similar values.
  - stephenr 9y ago
    That's the thing: it is broadly accepted as having poor usability compared to other version control tools. If you haven't had those issues, you're one of the lucky ones. Edit: > Git is a very powerful, flexible, reliable and efficient tool. I didn't say it isn't any of those things. I said it's harder to use than competitors such as mercurial.
    - keymone 9y ago
      could you provide specific examples?
    - ShinTakuya 9y ago
      Do you have a source for this widespread acceptance? I mean I get that version control in general can be hard for new developers to wrap their heads around but I never really had trouble picking up git personally, and the interns at my workplace haven't had any significant trouble either besides needing some coaching in how rebase works.
cperciva 9y ago
I'd say that I no longer feel like I can trust 'git' to do the same thing either... but who am I kidding? I never trusted it to do the sane thing.
- dijit 9y ago
  You can say some negative things about git, but sanity is not one of them.
zdw 9y ago
systemd is a mess. A while ago I tried writing a script for CD ripping that ran when udev detected a music CD in the optical drive, ripped the CD, then ejected the disk. This kept failing. It turned out to be systemd having a hardcoded timeout of something like 30 seconds on any process launched by udev, that couldn't be changed without recompiling it from source, or having it fork off some other process group that lacked this limitation. From what I can tell, systemd has some of the worst sort of developer myopia, where whole swaths of legitimate use cases are actively destroyed.
- rlpb 9y ago
  It sounds like you're blocking udev while your script executes, and instead you should start a service from your udev script and then exit. For example, see systemd-run(1). > ...where whole swaths of legitimate use cases are actively destroyed. Your use case is fine. Your implementation doesn't fit with udev's design; that's all.
  - jononor 9y ago
    And I am fairly sure that this design predates systemd by several years.
  - deleted 9y ago
    [deleted]
  - zdw 9y ago
    I was having udev starting a separate ripping script as a background process, and it worked on pre-systemd udev systems. systemd kills the entire udev process tree (all children) including the ripping script after 30 seconds.
    - inopinatus 9y ago
      To fix this, perhaps it'll need to fork and detach the session, as per the standard daemonisation sequence. c.f. http://www.itp.uzh.ch/~dpotter/howto/daemonize http://www.itp.uzh.ch/~dpotter/howto/daemonize
yuhong 9y ago
I wonder why Poettering chose Kay Sievers to work on systemd in the first place.
theonemind 9y ago
Linus has the proverbial moral authority to bootstrap an init system and the technical skill to pull it off. Amusingly, this strikes me something like the chairman of the Federal reserve hinting that he thinks interest rates are too high. Hopefully, the systemd developers will take notice and clean up some of their act. (Not to insinuate anything. They have widely known problems in playing nice with other projects, taking feedback, etc.)
- SolarNet 9y ago
  waits patiently for Linus to get fed up with ___ enough to write it himself dies
  - theonemind 9y ago
    I don't really think he would, will, or wants to. But that he could, and actually might if he begins to feel that systemd hurts Linux, might create some positive pressure on the systemd developers. That's exactly the thing, like the fed. They have enough power that an implied threat can fix things (sometimes to some extent) without them actually taking any action.
  - striking 9y ago
    I mean, he wrote git for that reason.
- dredmorbius 9y ago
  At this point, less likely on systemd devs than those who employ them (Red Hat) and distro maintainers (Debian, Ubuntu, Fedora, Gentoo, Arch, etc.).
  - throwacct7835 9y ago
    Actually Gentoo still uses sysvinit by default, which is one of the reasons I like it. They also maintain a fork of udev (eudev) that doesn't require systemd.
    - 9y ago
dredmorbius 9y ago
Ted Ts'o, the Linux ext2/3/4 filesystem developer, posted this two days ago at G+ as well. Interesting discussion, particularly about 1) systemd's bad programming taste and complexity, and 2) Lennart Poettering's inability to admit when he is wrong. "For me a lot of "good taste" is about adding complexity when it's needed, and avoiding it when it's not needed. And if you do have complexity, making sure you have the tools so you can debug things when they break. And for me one of the things that I don't like about systemd is that it has added a lot of complexity, and when it breaks, trying to debug it can be almost impossible." Also: "Heck, I don't even I want to file bug reports, just so I can get abusive messages from Lennart. At least when Linus flames me, it's because I did something wrong which hurts users and which I d*mned well should have known better, given my years of experience in the community. Lennart just flames you because you're wrong, and he's right. By definition." And: "The high bit, in my opinion, is "not being able to admit you are wrong". If someone (such as Lennart) is always right, then it's impossible to have a technical discussion in a post-mortem to avoid similar problems in the future. In a company, if there are personnel issues like that, you can escalate to the person's manager, or use other mechanisms. In the open source world, all you can do is route around the damage. Whether you call the inability for someone to admit that he or she has contributed to the problem a "lie" or just that they were "mistaken" is really beside the point as far as I'm concerned." https://plus.google.com/+TheodoreTso/posts/EJrEuxjR65J https://plus.google.com/+TheodoreTso/posts/EJrEuxjR65J
- digi_owl 9y ago
  Ts'o strikes me as damn close to Torvalds in attitudes. The guy have been with the kernel for almost as long as Torvalds himself, happily developing EXT version after EXT version for it. The problem is with more recent people, that seem to be more "american" their approach. Always looking to climb the ranks and find new domains of development to undertake rather than stick with one area and become deeply proficient.
eleitl 9y ago
Gee, such a surprise. Why didn't you speak out about it earlier, then?
- bigato 9y ago
  I was thinking exactly this as I was reading the message. Linus was the one voice that could probably have prevented systemd from taking control. This comment strikes me as too little, too late. I just hope that the transition back to a saner solution, if it will ever happen, won't be too painful now. Or it could trigger mass migration out from Linux. I, for one, am living happily in BSD land by now.
- digi_owl 9y ago
  Because he do not want to get involved with userspace bikesheding (beyond posting rants about insane defaults in his distro of choice). He sees his domain beginning and ending with the kernel, and that's it. Sadly certain people below him, that he trust deeply, are not so content (some even support Poettering and crew). And i fear the day he hand off the keys to the kernel to them.
  - reactor4 9y ago
    Linus giving his opinion on userland is a far cry from bikeshedding though...
qb45 9y ago
Just wanted to say that the issue is about automatically copying rlimits from the init processes to all processes executing setuid binaries - apparently Linus thinks that init could possibly apply some rlimits to itself for its own purposes which wouldn't necessarily be suitable for copying to any other random process. IMO this idea with copying is in itself even less sane than init using rlimits on PID 1.
teddyh 9y ago
This is taking a quote out of context and trying to start the old usual systemd flamewar. Flagged.
- dpark 9y ago
  This isn't out of context. It's a direct quote and links to the full content of the email. Also "If you flag something, please don't also comment that you did." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
owaislone 9y ago
They [systemd] shouldn't piss him off too much. He will sit down for a week, come out with his own init system which will take over the world. /s but not entirely :)
dsfyu404ed 9y ago
This reminds me of a relevant joke. Systemd walks into a bar. It shoots the bar owner and proclaims itself to be the new owner. It then turns the bar into a farm, brewery and distillery, opens a casino, a freight rail line and an investment bank. Oh, and there's an init system thrown in there somewhere too.
floatingatoll 9y ago
Is there any useful comment anywhere on this post that talks about the technical meat of Linus' post here? He explicitly goes out of his way not to go into a long-form argument about systemd, and then HN dumps something like 150 points of comment karma into systemd. EDIT: Here are links to comments discussing the actual content of his email, in case anyone else came here for that and left wanting. https://news.ycombinator.com/item?id=14734868 https://news.ycombinator.com/item?id=14734868 https://news.ycombinator.com/item?id=14733973 https://news.ycombinator.com/item?id=14733973 -> https://plus.google.com/+TheodoreTso/posts/EJrEuxjR65J https://plus.google.com/+TheodoreTso/posts/EJrEuxjR65J EDIT: I read all the comments on this post, and I am disgusted to report that (as of this EDIT, nitpickers) the 2 above-linked comments are the sum total of actual replies to the content Linus was trying to discuss. I hope LKML had more self-control than HN. EDIT: 14733558, it was really excellent of you to try and defuse things, too.
- smhenderson 9y ago
  Yes, he specifically goes out of his way to refer to init as generically as possible. But then drops this line at the end of the post: 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. It's not hard to understand what he meant and for some of us it's articles like this on HN which give an opportunity to talk about systemd without being off topic. IMO the take away from the article is that systemd has become enough of a moving part that it would be unwise to rely on it for default anything. Maybe I read it wrong but there's my take on the technical argument against using init to set default limits on processes. There are already defaults in the kernel so use them and allow an override for admins that need one.
  - floatingatoll 9y ago
    It's impossible to misinterpret that he's referencing systemd, but that's not the point of his post. He's saying, "Kernel over here, Init over there, One way transaction". You're talking about whether Systemd is qualified to be init. He's talking about whether the Kernel-side or Init-side is responsible for defining a given value. He declares his bias clearly (trusts Kernel, doesn't trust Init, especially doesn't trust Init via Systemd) and then makes his point. I'm just deeply saddened that literally two comments out of a hundred bothered to discuss his point, that divide, at all.
jwilk 9y ago
For those who can't stand lklm.org UI, here's the mail on spincs.net: https://www.spinics.net/lists/kernel/msg2550717.html https://www.spinics.net/lists/kernel/msg2550717.html
Tharkun 9y ago
Systemd is a steaming turd. However, it's one we have to live with, and there doesn't seem to be anything better on the horizon. A good book on the subject might make things slightly better. However, it doesn't seem like anyone is interested in writing one :-(
codesurfer 9y ago
When so many think that something is wrong, maybe there is some truth about it... If even the creator have concerns, man, that's not a joke!
codesurfer 9y ago
When so many think that something is wrong, maybe there is some truth about it... If even the creator have concerns, man, that's not a joke!

350 points by cnst 9y ago

I would assume this is about systemd. Personally my experience with it has been great - the occasional screw-ups (they did happen - something related to dbus made all systemctl commands fail until a reboot) were nothing compared to the time I gained not having to worry about prehistoric initscripts. So while it isn't perfect, it's IMO a step in the right direction, if only by lowering the barrier to entry to actually using and managing the thing. If you are worried about stability then you shouldn't rely on a single machine anyway. Personally I manage systemd screw-ups (though I haven't had one in production yet - all of them were on my personal machines while monkeying around with Archlinux) just like any other hardware failure - by making sure my app/service stays available even if I yank the power cord from the machine.

SwellJoe 9y ago
It seems obvious he is referring to systemd. I like systemd, but Linus hates it when people break userspace, and systemd has broken userspace a lot. Poettering seems to take the advice of "release early and often" to heart and pushes things into widespread usage long before they're quite fully baked. PulseAudio was awful for years, and then it was good and we all stopped complaining about it. systemd was kinda crap for months after it became widespread...a ton of breakage, including in ways that were occasionally dangerous. We're lucky, I guess, that systemd didn't take as long as PulseAudio to stop sucking all the time (systemd still sucks some of the time, but what it replaced sucked a lot, too). So, yeah, you can't break userspace if you want Linus on your team, and systemd has broken userspace now and then.
- asveikau 9y ago
  You seem to exist in a fictional universe where pulseaudio "got good" and doesn't suck. All these years later I have never seen that be the case. I think a much more likely explanation is that desktop Linux is less common since the rise of OS X in the "Unix-like developer machine" market so there are now fewer people noticing it sucks.
  - pcr0 9y ago
    I was one of those developers with an OS X machine who decided to buy a Thinkpad and throw Ubuntu on it. pulseaudio worked out of the box for me and I definitely preferred it over the stunted OS X audio mixer that doesn't even let you define per-application audio.
    - isatty 9y ago
      The MacOS mixer is pretty much the epitome of "just works" even though I agree with you that it doesn't let you control levels per application. However I've been using the MacOS sound system (not just the mixer) for many years through many devices (mics, external dacs, HDMI transports, DP etc) and it has always worked without any problems.
      - pfranz 9y ago
        I don't have much personal experience, but I /often/ hear about OSX users very wary of updating MacOS because of issues with sound equipment. This goes back to Classic. It may have gone away in the past 3-5 years, but the stigma is still there.
  - Rjevski 9y ago
    What were your problems exactly? In my case I used Linux full time from late 2012 to early 2014 and during that time I haven't had a single problem related to it, all while running bleeding edge Archlinux. The only issue was with bluetooth headphones but I'm pretty sure it was more with BlueZ being a pile of garbage than Pulseaudio being bad, given that BlueZ was giving me problems with all sorts of other (non sound) peripherals as well.
    - LukeShu 9y ago
      Are you actually using PulseAudio? Having run Arch (well, Parabola) since 2011, I haven't had any problems with PulseAudio... because I've never installed PulseAudio. Actually, I did have a problem with Wine and lib32-libpulse lagging slightly behind the video (where it's only a fraction of a second off, but enough that it doesn't feel like the words match the faces); and then I figured out how to get Wine to use ALSA, just like everything else.
- throwaway2048 9y ago
  Its nothing to do with "release early and often", its gems like this that they refuse to fix over ridiculous hubris. https://github.com/systemd/systemd/issues/6237 https://github.com/systemd/systemd/issues/6237 Its going to end up exactly like glibc under Drepper, where distributions are forced to have a mile of patches because obviously broken shit isn't patched because the maintainers are too arrogant to admit fault.
  - grandinj 9y ago
    I dont see any signs of "refuse to fix" there. I see a calm and reasonable discussion and an acknowledgement that some things need improving. Perhaps they refused to fix it in exactly the way the reporter wanted, but that's a far cry from arrogant refusal.
    - bigbugbag 9y ago
      > yes, it's a feature that we don't permit invalid user names(...) So, yeah, I don't think there's anything to fix in systemd here. I understand this is annoying, but still: the username is clearly not valid. > systemd is not the one coming up with the restrictions on user names, and while some distributions are less restrictive, many do enforce the same restrictions as we do. In order to make systemd unit files portable between systems we'll hence enforce something that resembles more the universally accepted set, rather than accept the most liberal set possible. These are pretty clear "refuse to fix". Though I do agree that this is a poor example to illustrate the point.
    - isatty 9y ago
      What I saw was poettering spouting garbage about what he thinks is an invalid user name (when in reality, it is not and common tools like useradd don't complain about it). As the owner for a critical service like systemd (I don't use it, I prefer openRC on gentoo), he should know better.
      - Steeeve 9y ago
        grrr... your init system should not dictate what a valid username is. Your init system should use whatever users you've configured. I don't like your name. Therefore you get root. How on earth did this init system become so prevalent?
- otterley 9y ago
  How, exactly, has systemd "broken user space"? That's clear neither from the lkml thread, nor here. I'm not sure what this discussion even has to do with systemd; and I'm not even sure how you can "break user space" from a user space program, which init is. You might be able to modify your descendants' environment, but the rules under which that can happen are maintained and enforced by the kernel. It seems to me that if user space programs can do undesirable things, that's the fault of the kernel itself. To be sure, setting those boundaries and rules is one of the kernel's main jobs.
  - SwellJoe 9y ago
    There are a couple of inits in common usage on Linux; systemd is now the most popular and ships standard on the most popular distributions. I can't imagine Linus would be feeling grouchy toward a nearly defunct init (that had been in use mostly unchanged since the 90s), so we're left with systemd. Unless you've got a better idea about what he means? It is not a secret that kernel devs have a love-hate relationship with systemd, and have for years. That's why Linus said, "You all presumably know why." He was speaking with context that everyone on the LKML already knows. First result when I google it (but it's been a thing for a long time and on many fronts with many interesting bugs and arguments): http://www.phoronix.com/scan.php?page=news_item&px=MTY1MzA http://www.phoronix.com/scan.php?page=news_item&px=MTY1MzA I don't really subscribe to the "systemd is terrible and is the worst thing that ever happened to Linux" theory, and I'm not trying to be one of those folks that takes every opportunity to make a thread about how much systemd sucks. I like systemd. I mean it when I say that. But, in this case, it seems obvious it is about systemd. I have a hard time coming up with another plausible theory. Edit: Also, now that I'm thinking about Linus and Poettering butting heads...well, that's hilarious. A couple of brilliant assholes arguing is funny to me. I dunno how much it's actually happened (and how much happened through proxies), but still. Funny.
    - microcolonel 9y ago
      But you said specifically "...and systemd has broken userspace a lot." What did you mean by this? It seems like a complete nonsense statement in the context of user space breakage of the form the kernel is responsible for. The main clash between the kernel maintainers and the systemd maintainers was over systemd reading the kernel argv in an error prone way to trigger debug information. Other than that the interactions seem completely minimal. Linus Torvalds uses systemd at work and at home.
- Qantourisc 9y ago
  I still hear a friend complain he often has to restart pulse because sound just stops working for him. And IIRC there is still no way to set the maximum amount of audio-buffer (for the end-user, not from the applications; some people prefer the occasional buffer under-run over the higher delay).
- simias 9y ago
  Well, pulseaudio is still pretty crap as far as I'm concerned. After an update last week Spotify won't work anymore and the sound in Firefox is glitchy. I haven't taken the time to investigate what caused that exactly, and I'm not exactly looking forward to it. Not that I was a huge fan of ALSA either. It always felt a bit over-engineered for my taste. I can understand needing something like that if you want to make professional audio equipment with the Linux kernel but for my desktop use case OSS has always worked just fine for me and it didn't randomly break after an update. As for systemd, it's bearable and it mostly does what it's supposed to do, but it still feels a bit unnecessary and its security track record is not stellar so far. I prefer the simplicity of the BSD init personally.
  - nol13 9y ago
    Seems to have settled down now(?) but firefox audio was def glitchy for a few releases after for me requiring system restarts to get sound back.
gcb0 9y ago
this is all nice when you ignore the tons of bug reports everyone else is getting because you decided to treat your users as testers. why do you think linus is complaining? because he can't get sound to work on his own box or because kernel invalid bugs are over the roof thanks to bogus init?
gaius 9y ago
I would assume this is about systemd. Personally my experience with it has been great - the occasional screw-ups (they did happen - something related to dbus made all systemctl commands fail until a reboot) were nothing compared to the time I gained not having to worry about prehistoric initscripts There is a vast gulf between two communities, people who run Ubuntu Beta for fun on their own PC, and people who run 10,000 RHEL boxes in Prod, and both communities tend to talk "at" each other and misunderstand where the other is coming from. The scenario you describe is something that would make one of the latter community recoil in horror.
- derefr 9y ago
  There's a third, rather small community: the distro-makers, who nearly to a one are—if not in love—at least hold systemd in high regard. It's easy enough to understand their point of view: run through a Linux From Scratch install. You'll have to write your own init system. You'll be duct-taping a lot of things together, and your solution—while it might be something you're "proud of" in some sense—will definitely be lacking in engineering, no matter how much time you as one individual could ever throw at it. After the LFS experience—which is essentially the distro creation experience—coming back to regular (pre-systemd) distros made one feel rather different: it was very easy to see how each distro was, at its core, just someone else's duct-taped-together init system with a pile of hacks accumulated on top. There wasn't any real Engineering; there was no shared knowledge-base of best practices for doing this or that. Each distro was a evolutionary Galapagos island. From the LFS perspective, an init system that exists as its own standalone FOSS project, containing contributions from hundreds of interested parties and battle-tested engineering choices after coming-up-on-a-decade of use in virtually every scenario, is a wonderful thing. systemd is, finally, a reference implementation of an init system "at scale." If you want to build your own init system, you don't have to look at the init systems of 30 different distros to figure out what things each distro just did its own way for no reason, any more (which used to be "most things.") You can just start by looking at "what systemd does", and figure things out from there. Or you can use some systemd components, and some of your own.
  - PuercoPop 9y ago
mfukar 9y ago
systemd has a few nice ideas, and it might be alright for whatever your use case is. I'm working on a product which uses it as its init system, and it's an endless source of problems. Its flaws are deep and unfortunately pervasive.
xaldir 9y ago
As a user, I would agree, systemd kinda just works and it's nice. As a sysadmin however, I hate it so much. Not because I have to learn a new system which is nice, but because it breaks so much things. I had to rewrite scripts that just worked for years, I had to do a bit of black magic to make old software behave on newer distribs and it's just so frustrating. I get it that most of these things were not done in the right way but FFS, don't break my production stuff.
kochthesecond 9y ago
Oh yes, the init to systemd phase was brutal on arch. So many broken systems :(
knorker 9y ago
My problem with systemd is that is seems to have a policy (most certainly a history of actions, and that's really the significant thing) of NOT doing the sane thing, then being called out for it, and then having the systemd people defend not doing the right thing. I can trust someone who makes mistakes. I can't trust someone who refuses to accept that they regularly make mistakes. Nor can I trust their work.
Aardwolf 9y ago
They're not really following the philosophy I expect to see a unix-like OS, so my experience also wasn't great. Like turning logs into a binary format, and then later bugging out on it so when you try to read it with their convoluted command (where cat or less was sufficient in the past) it gave errors on its own mess and refused to display anything. Bugs happen, that's understandable, but simply the fact that they turn logs into a binary format shows their philosophy is different than the one I expect from a unix-like OS. And almost all distros are following them sadly...
- shimon_e 9y ago
  Any reason why we can't have journaldfs?
raverbashing 9y ago
> If you are worried about stability then you shouldn't rely on a single machine anyway. Sorry, this is a complete BS "solution" You don't keep a broken piece of software running then put more redundancy to make it kinda stable. Redundancies are for when things break, not for when they're broken from the start Nobody takes off from a plane with one inoperative engine, both have to be turning, so in case one fails the other one can take over
- digi_owl 9y ago
  Effectively what you are responding to is the ever more prevailing "cloud" mentality, where there is always another instance to spin up in a second if something where to break. http://www.commitstrip.com/en/2015/07/08/true-story-fixing-a-self-ddos/ http://www.commitstrip.com/en/2015/07/08/true-story-fixing-a... And while systemd may have started on the desktop (likely to "solve" the speed of repeated bootups when using a laptop "securely") increasingly its development is dictated by this cloud mentality (as is the development of various distros, as someone basically shouted to my virtual face over at LWN).
btschaegg 9y ago
I could imagine that Linus is also influenced by experiences such as [1][2]. After a couple of issues like that I can imagine that he has his doubts about some of systemd's behavior. [1]: https://bugs.freedesktop.org/show_bug.cgi?id=76935 https://bugs.freedesktop.org/show_bug.cgi?id=76935 [2]: https://lkml.org/lkml/2014/4/2/420 https://lkml.org/lkml/2014/4/2/420
jankedeen 9y ago
17 years on linux 20+ in *nix. systemd is ! init. There are other ways to introduce an init analog systems bus for functionality without replacing init. Wrongheaded and developed for the wrong reasons in the wrong way.

testcross 9y ago

The internals of systemd are maybe not the best. But the UI is definitely easier to grasp than what existed previously.

ill0gicity 9y ago
The UI is easier? I'm gonna need you to explain this.
- Rusky 9y ago
  Declarative unit files are far easier to manage than fragile ad-hoc scripts.
  - brandonbloom 9y ago
    This is only a tiny piece of the experience though. What about journalctl? systemctl? etc? That stuff is alien vs tail -f or ./just/run/some.sh which works with everything _except_ systemd.
    - jhasse 9y ago
      You can google how to do the equivalent to `tail -f /var/log/foo.log` in a minute. What do you mean by ./just/run/some.sh?
      - boomlinde 9y ago
        > You can google how to do the equivalent to `tail -f /var/log/foo.log` in a minute. Doesn't the fact that I have to google an alternative workflow for something that behaves consistently across pretty much all other software make its UI worse, at least in that regard? I get that maybe it's a justified trade-off, but that doesn't make the UI any better. > What do you mean by ./just/run/some.sh? I suppose just dumping an exec command into an executable file and call it a service.
        9y ago

ausjke 9y ago

Like what happened to git in the past, will Linus write a new init himself this time?

saurik 9y ago
Linus wrote git because BitKeeper was taken away from him due to the Andrew Tridgell incident, not because he disliked BitKeeper; he didn't even mind that it was closed source.
- speeder 9y ago
  Decided to google about this... Found this article: https://www.pcworld.idg.com.au/article/129776/after_controversy_torvalds_begins_work_git_/ https://www.pcworld.idg.com.au/article/129776/after_controve... I wonder, how many people reading that article would predict the rise of stuff like GitHub and GitLab and the success of Git to the point of crushing CVS and making SVN decline in popularity?
  - ktRolster 9y ago
    CVS was already being kicked out the door at that time by SVN. A lot of people looked at Git as a potential replacement for SVN (at least, I did. Took several years for me to really 'get' it, though. I'm not sure even today I completely 'get' Git: there are a lot of possible workflows). I didn't dream of it in terms of GitHub.
    - bluGill 9y ago
      > I'm not sure even today I completely 'get' Git: there are a lot of possible workflows In my experience most people are using git with a svn workflow. They use github (gitlab, or something internal to the company) as the central server, and work only from the central server. Make github speak svn, and alias all the git commands to svn and they couldn't tell the difference.
      - ktRolster 9y ago

TheAceOfHearts 9y ago

Here's something I don't understand... Why do so many people hate systemd but not macOS's launchd [0]? Don't they serve similar purposes? I've been digging into macOS for a few months now, and I'm pretty happy with their defaults. EDIT: I don't know why I'm being downvoted for asking a genuine question. I'm not a linux expert, so I'd love to hear your criticisms. [0] http://www.launchd.info http://www.launchd.info

otterley 9y ago
I suspect it's because nobody ever really has to touch launchd configurations because Macs aren't commonly used as Internet servers.
- TheAceOfHearts 9y ago
  I've been happily using macOS server at home for a few months. It's not a production-ready deployment, but I haven't had any complaints. Aside from that, using it on my personal laptops has worked surprisingly well. Once I familiarized myself with the CLI tools, I haven't had any issues.
  - digitalzombie 9y ago
    > I've been happily using macOS server at home for a few months. It's not a production-ready deployment, but I haven't had any complaints. It's not on AWS. Your use case is just a hobby or one man shop or just one data point. It doesn't necessarily scale well for other use cases. I think what other people are pointing out is that companies aren't lining up to use it or replacing it over a linux server or window server.
- dredmorbius 9y ago
  Anecdata: I wanted to set up a Mac box as a remote syslog server. It's running, IIRC, rsyslogd, which is to say, remote syslogd. All you've got to do is tweak the PLIST. Read the manages. They're out of date. Looked at the PLIST tools (not my thing). Doesn't seem to be an option. There used to be, back when PLISTs were actual files you could edit. That's gone away now though, best I can tell. Got a Linux box up and running, that now accepts remote logs.

gjvc 9y ago

The quote here in the title is missing the vital context -- the full quote is ""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.""

throw2016 9y ago

Making too many assumptions about the user environment is not smart. Then you start putting constraints and becoming defensive when these assumptions are questioned. This is becoming a pattern for systemd as is blaming everyone else. [1] Those who need the complexity or some features should adopt the technical debt, there is zero rationale to enable it by default and impose it on everyone. For instance if you have too many network interfaces and naming is a problem then switch on predictable network names which btw is anything but predictable for human beings and let the 97% who don't carry on. 12 digit random names are simply not predictable or better for human beings than eth0, wlan0? If there is a problem predictable network names is not the solution. Similarly if you need binary logging and an audit trail then turn on binary logging but don't impose it on everyone else. Its time to move beyond silly accusations of 'hate' etc every time there is a discussion about systemd because at the moment it just serves to deflect criticism and avoid accountability for questionable decisions. [1] https://github.com/systemd/systemd/issues/2407 https://github.com/systemd/systemd/issues/2407

danieldk 9y ago
Those who need the complexity or some features should adopt the technical debt, there is zero rationale to enable it by default and impose it on everyone. Indeed. Even if I have multiple ethernet interfaces, I'd prefer to map a MAC address to eth[0-9] myself. But most machines only have one ethernet interface and one WiFi interface anyway. These things pop up all over the place. E.g.: why would I want to have NetworkManager on a server, which never switch networks and need to set up a VPN connection? Why do I need firewalld on a server? I rarely need a zone-based firewall on my laptop (probably like most users, I just block all incoming traffic), let alone a server. Layer upon layer is piled to solve hypothetical situations that do not arise for > 90% of the population. (I do like systemd as a service manager, but systemd and the surrounding ecosystem has made it terribly difficult to understand and debug UNIX systems.)
- mdekkers 9y ago
  why would I want [insert a systemd design decision] Because systemd wants to be The One Ring of Linux, and tries to be all things to all systems and all people.

stephenr 9y ago

I fucking hope not. Linus is clearly very smart, but user-facing tools is not what he's good at. Git is a perfect example of this. Mercurial and Git were created ridiculously close to each other, and their main features/use model are quite similar, and yet mercurial is literally years ahead in terms of usability. The results to a given command are 99% of the time, what you would intuitively expect. Now here's what I would love to see: Linus initiate a fork/rewrite/whatever of the init part of systemd, that keeps the concept of non-executing service definition files. They don't have to be compatible with systemd but that wouldn't necessarily be a bad thing either. Edit: actually, aiming for compatibility probably means having to reimplement systemd weirdness, so probably is a bad thing as I think about it.

beefsack 9y ago
It's quite frustrating seeing people complain about Git usability like it's some broadly accepted and objectively bad thing. As frivolous as anecdotes are, I took to Git very smoothly and I found it to operate in a very obvious and explicit fashion, particularly once I'd shifted my mental model from what I was using at the time (primarily SVN.) Git is a very powerful, flexible, reliable and efficient tool. I'd be over the moon if someone wrote an init system holding similar values.
- stephenr 9y ago
  That's the thing: it is broadly accepted as having poor usability compared to other version control tools. If you haven't had those issues, you're one of the lucky ones. Edit: > Git is a very powerful, flexible, reliable and efficient tool. I didn't say it isn't any of those things. I said it's harder to use than competitors such as mercurial.
  - keymone 9y ago
    could you provide specific examples?
  - ShinTakuya 9y ago
    Do you have a source for this widespread acceptance? I mean I get that version control in general can be hard for new developers to wrap their heads around but I never really had trouble picking up git personally, and the interns at my workplace haven't had any significant trouble either besides needing some coaching in how rebase works.

cperciva 9y ago

I'd say that I no longer feel like I can trust 'git' to do the same thing either... but who am I kidding? I never trusted it to do the sane thing.

dijit 9y ago
You can say some negative things about git, but sanity is not one of them.

zdw 9y ago

systemd is a mess. A while ago I tried writing a script for CD ripping that ran when udev detected a music CD in the optical drive, ripped the CD, then ejected the disk. This kept failing. It turned out to be systemd having a hardcoded timeout of something like 30 seconds on any process launched by udev, that couldn't be changed without recompiling it from source, or having it fork off some other process group that lacked this limitation. From what I can tell, systemd has some of the worst sort of developer myopia, where whole swaths of legitimate use cases are actively destroyed.

rlpb 9y ago
It sounds like you're blocking udev while your script executes, and instead you should start a service from your udev script and then exit. For example, see systemd-run(1). > ...where whole swaths of legitimate use cases are actively destroyed. Your use case is fine. Your implementation doesn't fit with udev's design; that's all.
- jononor 9y ago
  And I am fairly sure that this design predates systemd by several years.
- deleted 9y ago
  [deleted]
- zdw 9y ago
  I was having udev starting a separate ripping script as a background process, and it worked on pre-systemd udev systems. systemd kills the entire udev process tree (all children) including the ripping script after 30 seconds.
  - inopinatus 9y ago
    To fix this, perhaps it'll need to fork and detach the session, as per the standard daemonisation sequence. c.f. http://www.itp.uzh.ch/~dpotter/howto/daemonize http://www.itp.uzh.ch/~dpotter/howto/daemonize

yuhong 9y ago

I wonder why Poettering chose Kay Sievers to work on systemd in the first place.

theonemind 9y ago

Linus has the proverbial moral authority to bootstrap an init system and the technical skill to pull it off. Amusingly, this strikes me something like the chairman of the Federal reserve hinting that he thinks interest rates are too high. Hopefully, the systemd developers will take notice and clean up some of their act. (Not to insinuate anything. They have widely known problems in playing nice with other projects, taking feedback, etc.)

SolarNet 9y ago
waits patiently for Linus to get fed up with ___ enough to write it himself dies
- theonemind 9y ago
  I don't really think he would, will, or wants to. But that he could, and actually might if he begins to feel that systemd hurts Linux, might create some positive pressure on the systemd developers. That's exactly the thing, like the fed. They have enough power that an implied threat can fix things (sometimes to some extent) without them actually taking any action.
- striking 9y ago
  I mean, he wrote git for that reason.
dredmorbius 9y ago
At this point, less likely on systemd devs than those who employ them (Red Hat) and distro maintainers (Debian, Ubuntu, Fedora, Gentoo, Arch, etc.).
- throwacct7835 9y ago
  Actually Gentoo still uses sysvinit by default, which is one of the reasons I like it. They also maintain a fork of udev (eudev) that doesn't require systemd.
  - 9y ago

dredmorbius 9y ago

Ted Ts'o, the Linux ext2/3/4 filesystem developer, posted this two days ago at G+ as well. Interesting discussion, particularly about 1) systemd's bad programming taste and complexity, and 2) Lennart Poettering's inability to admit when he is wrong. "For me a lot of "good taste" is about adding complexity when it's needed, and avoiding it when it's not needed. And if you do have complexity, making sure you have the tools so you can debug things when they break. And for me one of the things that I don't like about systemd is that it has added a lot of complexity, and when it breaks, trying to debug it can be almost impossible." Also: "Heck, I don't even I want to file bug reports, just so I can get abusive messages from Lennart. At least when Linus flames me, it's because I did something wrong which hurts users and which I d*mned well should have known better, given my years of experience in the community. Lennart just flames you because you're wrong, and he's right. By definition." And: "The high bit, in my opinion, is "not being able to admit you are wrong". If someone (such as Lennart) is always right, then it's impossible to have a technical discussion in a post-mortem to avoid similar problems in the future. In a company, if there are personnel issues like that, you can escalate to the person's manager, or use other mechanisms. In the open source world, all you can do is route around the damage. Whether you call the inability for someone to admit that he or she has contributed to the problem a "lie" or just that they were "mistaken" is really beside the point as far as I'm concerned." https://plus.google.com/+TheodoreTso/posts/EJrEuxjR65J https://plus.google.com/+TheodoreTso/posts/EJrEuxjR65J

digi_owl 9y ago
Ts'o strikes me as damn close to Torvalds in attitudes. The guy have been with the kernel for almost as long as Torvalds himself, happily developing EXT version after EXT version for it. The problem is with more recent people, that seem to be more "american" their approach. Always looking to climb the ranks and find new domains of development to undertake rather than stick with one area and become deeply proficient.

eleitl 9y ago

Gee, such a surprise. Why didn't you speak out about it earlier, then?

bigato 9y ago
I was thinking exactly this as I was reading the message. Linus was the one voice that could probably have prevented systemd from taking control. This comment strikes me as too little, too late. I just hope that the transition back to a saner solution, if it will ever happen, won't be too painful now. Or it could trigger mass migration out from Linux. I, for one, am living happily in BSD land by now.
digi_owl 9y ago
Because he do not want to get involved with userspace bikesheding (beyond posting rants about insane defaults in his distro of choice). He sees his domain beginning and ending with the kernel, and that's it. Sadly certain people below him, that he trust deeply, are not so content (some even support Poettering and crew). And i fear the day he hand off the keys to the kernel to them.
- reactor4 9y ago
  Linus giving his opinion on userland is a far cry from bikeshedding though...

qb45 9y ago

Just wanted to say that the issue is about automatically copying rlimits from the init processes to all processes executing setuid binaries - apparently Linus thinks that init could possibly apply some rlimits to itself for its own purposes which wouldn't necessarily be suitable for copying to any other random process. IMO this idea with copying is in itself even less sane than init using rlimits on PID 1.

teddyh 9y ago

This is taking a quote out of context and trying to start the old usual systemd flamewar. Flagged.

dpark 9y ago
This isn't out of context. It's a direct quote and links to the full content of the email. Also "If you flag something, please don't also comment that you did." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

owaislone 9y ago

They [systemd] shouldn't piss him off too much. He will sit down for a week, come out with his own init system which will take over the world. /s but not entirely :)

dsfyu404ed 9y ago

This reminds me of a relevant joke. Systemd walks into a bar. It shoots the bar owner and proclaims itself to be the new owner. It then turns the bar into a farm, brewery and distillery, opens a casino, a freight rail line and an investment bank. Oh, and there's an init system thrown in there somewhere too.

floatingatoll 9y ago

Is there any useful comment anywhere on this post that talks about the technical meat of Linus' post here? He explicitly goes out of his way not to go into a long-form argument about systemd, and then HN dumps something like 150 points of comment karma into systemd. EDIT: Here are links to comments discussing the actual content of his email, in case anyone else came here for that and left wanting. https://news.ycombinator.com/item?id=14734868 https://news.ycombinator.com/item?id=14734868 https://news.ycombinator.com/item?id=14733973 https://news.ycombinator.com/item?id=14733973 -> https://plus.google.com/+TheodoreTso/posts/EJrEuxjR65J https://plus.google.com/+TheodoreTso/posts/EJrEuxjR65J EDIT: I read all the comments on this post, and I am disgusted to report that (as of this EDIT, nitpickers) the 2 above-linked comments are the sum total of actual replies to the content Linus was trying to discuss. I hope LKML had more self-control than HN. EDIT: 14733558, it was really excellent of you to try and defuse things, too.

smhenderson 9y ago
Yes, he specifically goes out of his way to refer to init as generically as possible. But then drops this line at the end of the post: 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. It's not hard to understand what he meant and for some of us it's articles like this on HN which give an opportunity to talk about systemd without being off topic. IMO the take away from the article is that systemd has become enough of a moving part that it would be unwise to rely on it for default anything. Maybe I read it wrong but there's my take on the technical argument against using init to set default limits on processes. There are already defaults in the kernel so use them and allow an override for admins that need one.
- floatingatoll 9y ago
  It's impossible to misinterpret that he's referencing systemd, but that's not the point of his post. He's saying, "Kernel over here, Init over there, One way transaction". You're talking about whether Systemd is qualified to be init. He's talking about whether the Kernel-side or Init-side is responsible for defining a given value. He declares his bias clearly (trusts Kernel, doesn't trust Init, especially doesn't trust Init via Systemd) and then makes his point. I'm just deeply saddened that literally two comments out of a hundred bothered to discuss his point, that divide, at all.

jwilk 9y ago

For those who can't stand lklm.org UI, here's the mail on spincs.net: https://www.spinics.net/lists/kernel/msg2550717.html https://www.spinics.net/lists/kernel/msg2550717.html

Tharkun 9y ago

Systemd is a steaming turd. However, it's one we have to live with, and there doesn't seem to be anything better on the horizon. A good book on the subject might make things slightly better. However, it doesn't seem like anyone is interested in writing one :-(

codesurfer 9y ago

When so many think that something is wrong, maybe there is some truth about it... If even the creator have concerns, man, that's not a joke!

codesurfer 9y ago

When so many think that something is wrong, maybe there is some truth about it... If even the creator have concerns, man, that's not a joke!