18 ms·

Linux greybeards release beta of systemd-free Debian fork

147 points by based2 11y ago

CSDude 11y ago
Init should be just this: http://git.suckless.org/sinit/tree/sinit.c http://git.suckless.org/sinit/tree/sinit.c , systemd incorparates too much funcitonality IMO, I cant get used to it. Well, but its a free world, I have even written a Go init, some guy did Rust based, and upstart is still being used by Ubuntu 14.04, I like choices, and happy to see this alternative as well.
- geofft 11y ago
  1. If the only thing you needed from init was to reap reparented zombie processes and manage to not die, why have init at all? Why not tell the kernel to skip reparenting processes (and just reap them internally if their parent is dead) and not treat pid 1 as special, allowing it to exit? That's less userspace code and less kernel code. 2. Speaking of kernel code, have you looked at how much stuff is going on in the kernel? Why does pid 1 get this much scrutiny, but the kernel, which definitely can't die, gets a free pass? On my system there are 77 kernel threads. Seventy-seven! What are they all doing?? And there are plenty of alternative kernels you can use. Multiple ones even have Linux binary compatibility. 3. Is the argument for suckless init the same as that for EWONTFIX init (on which it is based)? If so, would a fork of systemd that split it into two processes, PID 1 that reaps reparented zombies and tells PID 2 about it (over a one-way pipe, so PID 1 has no increased attack surface), be an acceptable option?
  - chris_wot 11y ago
    For point 2, I think you can use: ps -eLf | grep '\[' I put in a grep root for good measure: ps -eLf | grep '\[' | grep root Incidentally, why would a zombie process need to be reparented? Surely it has just not been removed from the process table and all that needs to occur is to remove it fully... I can understand reparenting an orphan process, but a zombie process?
    - geofft 11y ago
      A ps roughly like that is how I got the number. That doesn't explain what they do. I'm sure I could dig into kernel sources, but... for instance, why am I running "xfsalloc", "xfs_mru_cache", and "xfslogd" when I have no XFS file systems? The point I'm making is not so much that I'm curious (although I am), but that the kernel is exempt from the scrutiny that systemd gets, and the kernel has a ton of fragile crap running at full privilege. If systemd even shipped three XFS-specific binaries, people would be upset, but the kernel can run three persistent kernel threads and nobody cares.
      - chris_wot 11y ago
        You either have the xfs filesystem module loaded or compiled into your kernel. I just tested this out: chris@libreoffice-ia64:~$ ps -eLf | grep '\[' | grep xfs chris@libreoffice-ia64:~$ sudo modprobe xfs [sudo] password for chris: chris@libreoffice-ia64:~$ ps -eLf | grep '\[' | grep xfs root 6731 2 6731 0 1 16:53 ? 00:00:00 [xfsalloc] root 6736 2 6736 0 1 16:53 ? 00:00:00 [xfs_mru_cache] chris@libreoffice-ia64:~$ chris@libreoffice-ia64:~$ sudo rmmod xfs chris@libreoffice-ia64:~$ ps -eLf | grep '\[' | grep xfs chris@libreoffice-ia64:~$
        geofft 11y ago
        I mean, I know exactly why it's there. :-) GRUB's os-prober is trying to mount all filesystems as all possible types, which autoloads xfs.ko. My point isn't so much what my three kernel threads are doing as why nobody asks these questions, in general, about the kernel. Just about every criticism of systemd applies double to the kernel, but nobody is forking Debian to replace the kernel. (And very few people are contributing to the existing efforts already in Debian to officially support alternative kernels.)
        chris_wot 11y ago
        Ah, I'm following :-) I think perhaps the kernel is more esoteric than systemd, and as a team they have proven themselves over time. I think they get a fair amount of scrutiny from competitors (the BSDs, and Microsoft) and they have a very robust development process so that might explain why it's not as controversial.
- witty_username 11y ago
  > functionality That is, actually doing the work of init i.e. spawning daemons and services.
  - marcosdumay 11y ago
    Well, it makes sense that whatever spawns the daemons also keeps track of them, restarts them on failure, controls containers, disposes of zombie processes, and helps debugging init scripts. It makes no sense for such tool to control network interfaces, logging, device sync, power mode changes, and well... I'm certainly forgetting one or two dozen systemd modules.
    - chris_wot 11y ago
      Sure it does. Letting systemd handle startup dependencies is a very good thing, IMO. You configure some unit files to allow for one unit to start after another, otherwise they run in parallel. Not sure what the issue is with that? As for those other tools... well, the systemd init process doesn't manage those either. The anciliary modules do, and quite well too really. I'm not entirely sure why people think that this is much different to running a SysV script to execute start a daemon!
- JdeBP 11y ago
  Ahem! * https://news.ycombinator.com/item?id=8904429 https://news.ycombinator.com/item?id=8904429 * http://unix.stackexchange.com/a/197472/5132 http://unix.stackexchange.com/a/197472/5132
  - chris_wot 11y ago
    Those StackExchange answers are awesome.
lottin 11y ago
Nice, but from the users' standpoint it would've been better if they had worked with Debian rather than rolling out their own distro.
- etiam 11y ago
  The problem sort of is that (the rest of) Debian wouldn't work with them on this.
  - tmptmp 11y ago
    You are quite right, as the overall Debian's stance on systemd was far from praiseworthy. They allowed themselves to be pushed around too far by the "end-user" (desktop-users) mentality of the gnome and few such other upstreams. This is a very good news. Indeed it would have better if the Debian had been a little bit more flexible and sensible on this issue. Congrats Devuan folks! My heartfelt thanks too. Edit: added my thanks and clarification for desktop-user.
    - mwfunk 11y ago
      How dare they consider end users! What is the world coming to?!?
      - tmptmp 11y ago
        I am not against them considering the end users. But getting pushed around by "end-user" (please read desktop-user) focus is way too unacceptable behavior, especially for a community like Debian. edit: added clarification for end-user.
        afarrell 11y ago
        > getting pushed around by end-user focus is way too unacceptable behavior why?
        11y ago
mwcampbell 11y ago
Counterpoint from a former systemd skeptic who now likes it: http://changelog.complete.org/archives/9655-count-me-as-a-systemd-convert http://changelog.complete.org/archives/9655-count-me-as-a-sy...
- tyingq 11y ago
  It's a reasonable counterpoint, but limited to the part of systemd that manages starting and stopping services. It also takes over virtual terminals, syslog services, login management, network interface configuration, dhcp, system time, udev device management, containers (machined, dbus, cgroups). That, to me, is where more of the concern lies.
  - ktRolster 11y ago
    Indeed, trying to get a full understanding of systemd is not easy, it's so large. It's like trying to understand a large piece of corporate software.
    - nine_k 11y ago
      Also, the point of switching and studying is not clear. If all you need is service startup and keeping up, a few more polished tools exist with a dramatically ssmaller footprint.
      - ktRolster 11y ago
        "a few more polished tools exist with a dramatically smaller footprint." Which tools did you have in mind?
        JdeBP 11y ago
        To learn about the wide range of toolsets that have been available for decades, start with these: * http://blog.darknedgy.net/technology/2015/09/05/0/ http://blog.darknedgy.net/technology/2015/09/05/0/ * http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/daemontools-family.html http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/da...
Nursie 11y ago
I like systemd from the perspective of a service-writer/maintainer, the service files are nice and simple and don't have the repeated boilerplate of old init scripts. However I still dislike its monolithic nature, its folding in of journaling and udev, and all the rest of the creep.
- nailer 11y ago
  Ditto the first part. I have a .service file for haproxy, one for my node app, one for rethinkdb, they generally just work. I understand people that dislike monoliths, but I also appreciate the DRY nature of systemd - the System V, bash, cron, at, various process monitors, syslog combo was a lot of code with a lot of overlap. I'd expect systemd is actually smaller in LoC that what it replaced.
ausjke 11y ago
Glad to see this coming out. https://www.devuan.org https://www.devuan.org Downloading via torrent now, it's 10G via torrent? Anyways it seems the file server there is under pressure now. I for one don't want to deal with systemd from the start. Never liked its intrusive, all-in-one, hard to debug design approach.
- jcoffland 11y ago
  Yeah, I dislike systemd but I'm not going to abandon the Debian Foundation over it.
  - stephenr 11y ago
    This is the real point. I have my issues with systemd. For example, I just had an interesting discussion on GH with Varnish packers about changing a daemon arg (in that case, the bind address/port). The way systemd "recommends" to change the arguments passed to a daemon is to write a drop-in file (i.e. /etc/systemd/system/service-name.service.d/something.conf) that overwrites the ExecStart line. To do so, you have to do: [Service] ExecStart= ExecStart=<original ExecStart line with wanted changes> For Varnish, this isn't the end of the world - it only needs a few arguments - but it's still a lot less simple than the pre-systemd "standard" for Debian, which is to use a /etc/defaults/<service> file to allow changing daemon args via variables. This method can be still used (via either EnvironmentFile, or via built-in systemd "Environment=" statements) but the former is specifically mentioned as "not recommended" by Lennart, and the use of Environment= in service files seems very much like a feature that no one is keen to acknowledge or make use of, and it has it's own issues, as the way variables, white space, escaping etc are handled is specific to systemd and not immediately intuitive for someone used to a shell environment. But as you said - those issues, are not enough to give up on the benefits of Debian stable. In theory, all packages in Debian stable that need an init script are supposed to still supply a sysvinit script (I was actually quite surprised by how many packages rely on systemd's ability to load sysvinit scripts and don't ship their own systemd service file) so you could choose to use sysvinit instead of systemd, for now at least. I do appreciate the theoretical goal - you describe how your daemon should be started, and let pid1 handle the specifics of actually starting it - to me that makes it much easier for a lot more people to create reliable daemon packages. I just wish the project wasn't taking such a "everything plus the kitchen sink" approach.
cm3 11y ago
One major problem with systemd is that beta software is released as stable and incorporated in distros. I've just realized that systemd-coredumpd is used to save crashes in the journal and write the files somewhere to /var. This has the problem that I have to vacuum or nuke the journal if I want to remove knowledge of past crashes because coredumpctl tool has no delete command. And coredumpctl hard-codes GDB as the debugger. To fix all of this I've overwritten the systctl.d file and made it write somewhere I know and can find without the use of an unfinished tool. I have also regularly had it happen that bootup would intermittently hang up or shutdown as well. There are also unfixed warnings and errors during shutdown on multiple machines. My conclusion is that systemd uses the broader population for beta testing, even if you don't follow Fedora Rawhide or Arch rolling.
- chris_wot 11y ago
  Try setting Storage=external in coredump.conf [1] - you seem to have it set to both, which I have to agree is probably less than ideal. 1. https://www.freedesktop.org/software/systemd/man/coredump.conf.html https://www.freedesktop.org/software/systemd/man/coredump.co...
  - cm3 11y ago
    Nope. I've scoured previous bug report and discussions and the only sure way was to prevent systemd from swallowing core dumps. It had the nice side effect that I learned the format string and configured it to my personal needs. But having to reverse engineer in order to remove crashes is not stable software and just a tech preview. If I wanted to be cynical, I'd believe anything coming out of systemd, regardless of quality, is accepted as the new way while discarding existing ways as obsolete. I should add to my startup hangup remark that I never before had a startup problem that was intermittent with plain old stupid init from 1994 up until systemd became the distro default.
    - chris_wot 11y ago
      Odd. Must be a bug, did you report it yourself?
INTPenis 11y ago
I can't believe anyone would like to keep using sysvinit-scripts or RC-scripts. I love bash, I love nitpicking about how to use bash along with the other bash nazis in #bash@freenode. But I would never put myself through sysvinit again. I thoroughly enjoy using distros like CentOS 7, Fedora 23, RHEL7. They're a joy to manage and work with, in part thanks to Systemd. I never want to debug, troubleshoot, or even look at another sysvinit-script again. :)
- lottin 11y ago
  I've been using Linux for the last 15 years and I don't remember ever having to fiddle with any init scripts.
  - chris_wot 11y ago
    I used to. It wasn't fun, but it wasn't terrible either. And I probably overused rc.local...
  - guitarbill 11y ago
    Until you install something like Gerrit, or GoCD, which have absolutely appalling init scripts. And then you find out that e.g. Gerrit sets some ulimits in the init script. Yuck!
- CaptSpify 11y ago
  If all systemd did was sysvinit-script replacement, I'd be 100% behind it. I agree with you, sysvinit-scripts are terrible. It's all the other stuff, and the lack of modularity, that makes me dislike it.
  - themartorana 11y ago
    Agreed. And upstart didn't suck for that.
- hiddennetwork 11y ago
  BSD handles all of this better than Linux. Text file. Easy. Linux has grown far too "complex". I like how OpenBSD adds modern touches yet keeps the OS free from binary blobs. systemd addresses some issues, but at the cost of complexity. I dislike binary blobs in my systems, hence, my servers run OpenBSD.
jcoffland 11y ago
One giant program to rule them all was never the Unix way. System's monolithic architecture will be its downfall. Rather than stabilize I predict that systemd will get more and more complicated and eventualy fall due to unwieldy maintenance problems at which point someone will come up with a better more modular system.
- userbinator 11y ago
  It's ironic that one of the design goals (or was that just the marketing blurb) of systemd was "modularity".
  - mhurron 11y ago
    Systemds molecularity is 'we'll write a systemd module to handle that.'
    - chris_wot 11y ago
      What's wrong with that? I think I quite like this "molecularity", I'd like to see more of it!
      - mhurron 11y ago
        Ok that's it, enough internet for me today.
- geofft 11y ago
  Wasn't it? Multics was the modular system, Unix was the one where they said "That's silly, let's stick everything in a single kernel and not bother with all the flexibility because we don't need it." People seem to ignore the kernel for some reason, but it is literally one giant program to rule them all, and it works very well. There have been many efforts to modularize it and move most of the complexity into independent units, and none have particularly worked out.
  - 11y ago
cisstrd 11y ago
No point in discussing systemd anymore quite frankly, it won, doubt that it's good it did, doubt the methods by which it won - I do both - but it won. Many of the major distributions are not really following the Unix philosophy anymore, heck, some stopped quite a long time ago to do so. I run sever operating systems because I like to have the control, the minimalism, the elegance, the security. By trying to be more of a desktop orientated system, Linux actually looses what attracts people like myself to using it. I doubt they care, I don't think they have to, just as I don't have to use it. "This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface."[1] "Much of the power of the UNIX operating system comes from a style of program design that makes programs easy to use and, more important, easy to combine with other programs. This style has been called the use of software tools , and depends more on how the programs fit into the programming environment - how they can be used with other programs - than on how they are designed internally. But as the system has become commercially successful and has spread widely, this style has often been compromised, to the detriment of all users. Old programs have become encrusted with dubious features. Newer programs are not always written with attention to proper separation of function and design for interconnection. [...] This style was based on the use of tools : using programs separately or in combination to get a job done, rather than doing it by hand, by monolithic self-sufficient subsystems, or by special-purpose, one-time programs. [...] One thing that UNIX does not need is more features. It is successful in part because it has a small number of good ideas that work well together. Merely adding features does not make it easier for users to do things - it just makes the manual thicker. The right solution in the right place is always more effective than haphazard hacking."[2] Still reading at this point? Great systemd free Linux distributions: Gentoo, Funtoo, Void Linux, among many others and there is also something called BSD (FreeBSD, OpenBSD, DragonflyBSD)... you should check it out. Also see www.suckless.org [1] http://www.amazon.com/Quarter-Century-UNIX-Peter-Salus/dp/0201547775 http://www.amazon.com/Quarter-Century-UNIX-Peter-Salus/dp/02... [2] http://harmful.cat-v.org/cat-v/unix_prog_design.pdf http://harmful.cat-v.org/cat-v/unix_prog_design.pdf
- geofft 11y ago
  The "Unix philosophy" of text streams hasn't worked, and arguably never worked. BSD sockets aren't quite text streams. Terminals aren't quite text streams. Shellshock existed because someone decided that serializing functions via text streams was a good idea. And if you look at the things you care about when running a daemon process -- sessions, controlling terminals, reliable restarts (without killing the wrong process), logging, starting dependencies in the right order, dropping privileges reliably etc. -- none of those things are good ideas that work well together. You can clearly see that things like double-forking and detaching from controlling terminals and syslog were all bolted on later, because the original system didn't work well, and the hacks don't work well either. I run servers, and I'm excited about systemd because it makes all these things actually work. The Unix philosophy gave me tools that do one thing and kinda sorta do them okay, if you're lucky. systemd does multiple things, and it does them all well. Back when we ran FreeBSD, we had hard-coded sleeps to wait for the network and NFS to come up before we continued with boot, and we had regular problems with being too aggressive with those sorts of hacks and having machines that would get stuck before launching sshd. That is straight-up not a problem with systemd.
eb0la 11y ago
I understand this because I can't get used to systemd. The learning curve should be better than rc.local for my taste. Problem is systemd helps you booting fast and this is important both in the cloud (where every minute is a billed), and in telecom (where you have a stringent SLA to cover).
- chris_wot 11y ago
  I would have thought a fast boot would be important to pretty much everyone...
  - gkya 11y ago
    Why? When I used Arch Linux I did not ever turn off my laptop, but hibernate it. I only ever booted it when I stupidly forgot to plug it in before the battery runs out. And 10-20 seconds spend on a sequential boot every 10-20 days is just no time. We spend at least 100x that time in the toilet every day.
    - chris_wot 11y ago
      I stand corrected.
meddlepal 11y ago
Meh. Systemd is pretty great. The *Nix purists hate it, but it solves a lot of problems and does it fairly consistently. I love using it in Fedora now where journald has basically replaced syslog completely.
- ferrari8608 11y ago
  Honestly journald is probably the only thing I don't really like about systemd and not for the reason you might think I'm about to say. I just rarely need to use it, because everything pretty much just works 99% of the time. So I end up forgetting how to use journalctl by the time I need it again and have to Google/man. Yeah I know, that's my own problem.
phantom_oracle 11y ago
Everybody mentions the Unix philosophy and that is a very valid point, but I would like to mention the freedom philosophy that open-source/Linux gives (or used to). These guys who wanted systemd muscled their way in to get this software into the Debian system. They also adopted an "all or nothing" approach, depriving the greater community of something bigger than "do 1 thing and do it well", which is "freedom to do as you wish and choose". Debian wouldn't have split had they maintained they made systemd opt-in or Poettering and co. maintained their own Debian-systemd version. That didn't gel well with Redhats version of what Open Source is, and so many were deprived of their freedom to NOT CHOOSE systemd BUT still use Debian. For all the talk of how good/bad systemd is, the proponents for systemd should remember how they deprived others with the freedom to choose, no matter how "ignorant" or "backwards" the detractors are (or how "shit" sysvinit is).
- the_why_of_y 11y ago
  https://lists.debian.org/debian-devel-announce/2014/08/msg00001.html https://lists.debian.org/debian-devel-announce/2014/08/msg00...
d02 11y ago
It is amusing and unsurprising that, in 91 comments, the word Devuan is used a total of 2 times.
- JdeBP 11y ago
  I've just mentioned it. So it's 3 now. (-: What you observe is emblematic of the problem with Devuan, and a few of the Devuan people themselves acknowledge it. So much of the discussion centres upon "how to remove evil libsystemd0" and suchlike that what is lost is the supposedly intentional focus of the Devuan project on init freedom. That surely means the freedom to run systemd as well as to not run it. * https://lists.dyne.org/lurker/message/20150208.110824.579d179c.pt.html https://lists.dyne.org/lurker/message/20150208.110824.579d17... And as you can see, that bleeds over into the press coverage seeking headline material.
lucideer 11y ago
Given the popularity of systemd as a discussion topic on HN, I'm surprised there isn't much about OpenRC[0]. Does anyone know if Devuan have given it any consideration? [0] https://lwn.net/Articles/512719/ https://lwn.net/Articles/512719/
SwellJoe 11y ago
Don't fork in anger. There's such a long history of projects starting out of a desire to not change, and so many of them (most, I would wager) fizzle out soon after. Being against some specific feature or architectural change is not the same as having a future vision that can drive a person to work on something, for no pay, for years or decades. Anger fades...the people you're angry at ignore the new project, making it unsatisfying in terms of vengeance. And, again, it just doesn't stick with you the way a desire to do something new and better does. I'm not even saying systemd is great (it's good and bad in all sorts of novel ways), I'm just saying that the people who are just reacting against it, when the industry and community has been so clear about it being the future they are passionate about, are unlikely to do anything more than spin their wheels for a few months, and then fade away (as a project, I hope they all stick around as contributors to OSS things).
JdeBP 11y ago
This is press coverage. The actual announcement page is discussed at https://news.ycombinator.com/item?id=11593674 https://news.ycombinator.com/item?id=11593674 .

147 points by based2 11y ago

Init should be just this: http://git.suckless.org/sinit/tree/sinit.c http://git.suckless.org/sinit/tree/sinit.c , systemd incorparates too much funcitonality IMO, I cant get used to it. Well, but its a free world, I have even written a Go init, some guy did Rust based, and upstart is still being used by Ubuntu 14.04, I like choices, and happy to see this alternative as well.

geofft 11y ago
1. If the only thing you needed from init was to reap reparented zombie processes and manage to not die, why have init at all? Why not tell the kernel to skip reparenting processes (and just reap them internally if their parent is dead) and not treat pid 1 as special, allowing it to exit? That's less userspace code and less kernel code. 2. Speaking of kernel code, have you looked at how much stuff is going on in the kernel? Why does pid 1 get this much scrutiny, but the kernel, which definitely can't die, gets a free pass? On my system there are 77 kernel threads. Seventy-seven! What are they all doing?? And there are plenty of alternative kernels you can use. Multiple ones even have Linux binary compatibility. 3. Is the argument for suckless init the same as that for EWONTFIX init (on which it is based)? If so, would a fork of systemd that split it into two processes, PID 1 that reaps reparented zombies and tells PID 2 about it (over a one-way pipe, so PID 1 has no increased attack surface), be an acceptable option?
- chris_wot 11y ago
  For point 2, I think you can use: ps -eLf | grep '\[' I put in a grep root for good measure: ps -eLf | grep '\[' | grep root Incidentally, why would a zombie process need to be reparented? Surely it has just not been removed from the process table and all that needs to occur is to remove it fully... I can understand reparenting an orphan process, but a zombie process?
  - geofft 11y ago
    A ps roughly like that is how I got the number. That doesn't explain what they do. I'm sure I could dig into kernel sources, but... for instance, why am I running "xfsalloc", "xfs_mru_cache", and "xfslogd" when I have no XFS file systems? The point I'm making is not so much that I'm curious (although I am), but that the kernel is exempt from the scrutiny that systemd gets, and the kernel has a ton of fragile crap running at full privilege. If systemd even shipped three XFS-specific binaries, people would be upset, but the kernel can run three persistent kernel threads and nobody cares.
    - chris_wot 11y ago
      You either have the xfs filesystem module loaded or compiled into your kernel. I just tested this out: chris@libreoffice-ia64:~$ ps -eLf | grep '\[' | grep xfs chris@libreoffice-ia64:~$ sudo modprobe xfs [sudo] password for chris: chris@libreoffice-ia64:~$ ps -eLf | grep '\[' | grep xfs root 6731 2 6731 0 1 16:53 ? 00:00:00 [xfsalloc] root 6736 2 6736 0 1 16:53 ? 00:00:00 [xfs_mru_cache] chris@libreoffice-ia64:~$ chris@libreoffice-ia64:~$ sudo rmmod xfs chris@libreoffice-ia64:~$ ps -eLf | grep '\[' | grep xfs chris@libreoffice-ia64:~$
      - geofft 11y ago
        I mean, I know exactly why it's there. :-) GRUB's os-prober is trying to mount all filesystems as all possible types, which autoloads xfs.ko. My point isn't so much what my three kernel threads are doing as why nobody asks these questions, in general, about the kernel. Just about every criticism of systemd applies double to the kernel, but nobody is forking Debian to replace the kernel. (And very few people are contributing to the existing efforts already in Debian to officially support alternative kernels.)
        chris_wot 11y ago
        Ah, I'm following :-) I think perhaps the kernel is more esoteric than systemd, and as a team they have proven themselves over time. I think they get a fair amount of scrutiny from competitors (the BSDs, and Microsoft) and they have a very robust development process so that might explain why it's not as controversial.
witty_username 11y ago
> functionality That is, actually doing the work of init i.e. spawning daemons and services.
- marcosdumay 11y ago
  Well, it makes sense that whatever spawns the daemons also keeps track of them, restarts them on failure, controls containers, disposes of zombie processes, and helps debugging init scripts. It makes no sense for such tool to control network interfaces, logging, device sync, power mode changes, and well... I'm certainly forgetting one or two dozen systemd modules.
  - chris_wot 11y ago
    Sure it does. Letting systemd handle startup dependencies is a very good thing, IMO. You configure some unit files to allow for one unit to start after another, otherwise they run in parallel. Not sure what the issue is with that? As for those other tools... well, the systemd init process doesn't manage those either. The anciliary modules do, and quite well too really. I'm not entirely sure why people think that this is much different to running a SysV script to execute start a daemon!
JdeBP 11y ago
Ahem! * https://news.ycombinator.com/item?id=8904429 https://news.ycombinator.com/item?id=8904429 * http://unix.stackexchange.com/a/197472/5132 http://unix.stackexchange.com/a/197472/5132
- chris_wot 11y ago
  Those StackExchange answers are awesome.

lottin 11y ago

Nice, but from the users' standpoint it would've been better if they had worked with Debian rather than rolling out their own distro.

etiam 11y ago
The problem sort of is that (the rest of) Debian wouldn't work with them on this.
- tmptmp 11y ago
  You are quite right, as the overall Debian's stance on systemd was far from praiseworthy. They allowed themselves to be pushed around too far by the "end-user" (desktop-users) mentality of the gnome and few such other upstreams. This is a very good news. Indeed it would have better if the Debian had been a little bit more flexible and sensible on this issue. Congrats Devuan folks! My heartfelt thanks too. Edit: added my thanks and clarification for desktop-user.
  - mwfunk 11y ago
    How dare they consider end users! What is the world coming to?!?
    - tmptmp 11y ago
      I am not against them considering the end users. But getting pushed around by "end-user" (please read desktop-user) focus is way too unacceptable behavior, especially for a community like Debian. edit: added clarification for end-user.
      - afarrell 11y ago
        > getting pushed around by end-user focus is way too unacceptable behavior why?
        11y ago

mwcampbell 11y ago

Counterpoint from a former systemd skeptic who now likes it: http://changelog.complete.org/archives/9655-count-me-as-a-systemd-convert http://changelog.complete.org/archives/9655-count-me-as-a-sy...

tyingq 11y ago
It's a reasonable counterpoint, but limited to the part of systemd that manages starting and stopping services. It also takes over virtual terminals, syslog services, login management, network interface configuration, dhcp, system time, udev device management, containers (machined, dbus, cgroups). That, to me, is where more of the concern lies.
- ktRolster 11y ago
  Indeed, trying to get a full understanding of systemd is not easy, it's so large. It's like trying to understand a large piece of corporate software.
  - nine_k 11y ago
    Also, the point of switching and studying is not clear. If all you need is service startup and keeping up, a few more polished tools exist with a dramatically ssmaller footprint.
    - ktRolster 11y ago
      "a few more polished tools exist with a dramatically smaller footprint." Which tools did you have in mind?
      - JdeBP 11y ago
        To learn about the wide range of toolsets that have been available for decades, start with these: * http://blog.darknedgy.net/technology/2015/09/05/0/ http://blog.darknedgy.net/technology/2015/09/05/0/ * http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/daemontools-family.html http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/da...

Nursie 11y ago

I like systemd from the perspective of a service-writer/maintainer, the service files are nice and simple and don't have the repeated boilerplate of old init scripts. However I still dislike its monolithic nature, its folding in of journaling and udev, and all the rest of the creep.

nailer 11y ago
Ditto the first part. I have a .service file for haproxy, one for my node app, one for rethinkdb, they generally just work. I understand people that dislike monoliths, but I also appreciate the DRY nature of systemd - the System V, bash, cron, at, various process monitors, syslog combo was a lot of code with a lot of overlap. I'd expect systemd is actually smaller in LoC that what it replaced.

ausjke 11y ago

Glad to see this coming out. https://www.devuan.org https://www.devuan.org Downloading via torrent now, it's 10G via torrent? Anyways it seems the file server there is under pressure now. I for one don't want to deal with systemd from the start. Never liked its intrusive, all-in-one, hard to debug design approach.

jcoffland 11y ago
Yeah, I dislike systemd but I'm not going to abandon the Debian Foundation over it.
- stephenr 11y ago
  This is the real point. I have my issues with systemd. For example, I just had an interesting discussion on GH with Varnish packers about changing a daemon arg (in that case, the bind address/port). The way systemd "recommends" to change the arguments passed to a daemon is to write a drop-in file (i.e. /etc/systemd/system/service-name.service.d/something.conf) that overwrites the ExecStart line. To do so, you have to do: [Service] ExecStart= ExecStart=<original ExecStart line with wanted changes> For Varnish, this isn't the end of the world - it only needs a few arguments - but it's still a lot less simple than the pre-systemd "standard" for Debian, which is to use a /etc/defaults/<service> file to allow changing daemon args via variables. This method can be still used (via either EnvironmentFile, or via built-in systemd "Environment=" statements) but the former is specifically mentioned as "not recommended" by Lennart, and the use of Environment= in service files seems very much like a feature that no one is keen to acknowledge or make use of, and it has it's own issues, as the way variables, white space, escaping etc are handled is specific to systemd and not immediately intuitive for someone used to a shell environment. But as you said - those issues, are not enough to give up on the benefits of Debian stable. In theory, all packages in Debian stable that need an init script are supposed to still supply a sysvinit script (I was actually quite surprised by how many packages rely on systemd's ability to load sysvinit scripts and don't ship their own systemd service file) so you could choose to use sysvinit instead of systemd, for now at least. I do appreciate the theoretical goal - you describe how your daemon should be started, and let pid1 handle the specifics of actually starting it - to me that makes it much easier for a lot more people to create reliable daemon packages. I just wish the project wasn't taking such a "everything plus the kitchen sink" approach.

cm3 11y ago

One major problem with systemd is that beta software is released as stable and incorporated in distros. I've just realized that systemd-coredumpd is used to save crashes in the journal and write the files somewhere to /var. This has the problem that I have to vacuum or nuke the journal if I want to remove knowledge of past crashes because coredumpctl tool has no delete command. And coredumpctl hard-codes GDB as the debugger. To fix all of this I've overwritten the systctl.d file and made it write somewhere I know and can find without the use of an unfinished tool. I have also regularly had it happen that bootup would intermittently hang up or shutdown as well. There are also unfixed warnings and errors during shutdown on multiple machines. My conclusion is that systemd uses the broader population for beta testing, even if you don't follow Fedora Rawhide or Arch rolling.

chris_wot 11y ago
Try setting Storage=external in coredump.conf [1] - you seem to have it set to both, which I have to agree is probably less than ideal. 1. https://www.freedesktop.org/software/systemd/man/coredump.conf.html https://www.freedesktop.org/software/systemd/man/coredump.co...
- cm3 11y ago
  Nope. I've scoured previous bug report and discussions and the only sure way was to prevent systemd from swallowing core dumps. It had the nice side effect that I learned the format string and configured it to my personal needs. But having to reverse engineer in order to remove crashes is not stable software and just a tech preview. If I wanted to be cynical, I'd believe anything coming out of systemd, regardless of quality, is accepted as the new way while discarding existing ways as obsolete. I should add to my startup hangup remark that I never before had a startup problem that was intermittent with plain old stupid init from 1994 up until systemd became the distro default.
  - chris_wot 11y ago
    Odd. Must be a bug, did you report it yourself?

INTPenis 11y ago

I can't believe anyone would like to keep using sysvinit-scripts or RC-scripts. I love bash, I love nitpicking about how to use bash along with the other bash nazis in #bash@freenode. But I would never put myself through sysvinit again. I thoroughly enjoy using distros like CentOS 7, Fedora 23, RHEL7. They're a joy to manage and work with, in part thanks to Systemd. I never want to debug, troubleshoot, or even look at another sysvinit-script again. :)

lottin 11y ago
I've been using Linux for the last 15 years and I don't remember ever having to fiddle with any init scripts.
- chris_wot 11y ago
  I used to. It wasn't fun, but it wasn't terrible either. And I probably overused rc.local...
- guitarbill 11y ago
  Until you install something like Gerrit, or GoCD, which have absolutely appalling init scripts. And then you find out that e.g. Gerrit sets some ulimits in the init script. Yuck!
CaptSpify 11y ago
If all systemd did was sysvinit-script replacement, I'd be 100% behind it. I agree with you, sysvinit-scripts are terrible. It's all the other stuff, and the lack of modularity, that makes me dislike it.
- themartorana 11y ago
  Agreed. And upstart didn't suck for that.
hiddennetwork 11y ago
BSD handles all of this better than Linux. Text file. Easy. Linux has grown far too "complex". I like how OpenBSD adds modern touches yet keeps the OS free from binary blobs. systemd addresses some issues, but at the cost of complexity. I dislike binary blobs in my systems, hence, my servers run OpenBSD.

jcoffland 11y ago

One giant program to rule them all was never the Unix way. System's monolithic architecture will be its downfall. Rather than stabilize I predict that systemd will get more and more complicated and eventualy fall due to unwieldy maintenance problems at which point someone will come up with a better more modular system.

userbinator 11y ago
It's ironic that one of the design goals (or was that just the marketing blurb) of systemd was "modularity".
- mhurron 11y ago
  Systemds molecularity is 'we'll write a systemd module to handle that.'
  - chris_wot 11y ago
    What's wrong with that? I think I quite like this "molecularity", I'd like to see more of it!
    - mhurron 11y ago
      Ok that's it, enough internet for me today.
geofft 11y ago
Wasn't it? Multics was the modular system, Unix was the one where they said "That's silly, let's stick everything in a single kernel and not bother with all the flexibility because we don't need it." People seem to ignore the kernel for some reason, but it is literally one giant program to rule them all, and it works very well. There have been many efforts to modularize it and move most of the complexity into independent units, and none have particularly worked out.
- 11y ago

cisstrd 11y ago

No point in discussing systemd anymore quite frankly, it won, doubt that it's good it did, doubt the methods by which it won - I do both - but it won. Many of the major distributions are not really following the Unix philosophy anymore, heck, some stopped quite a long time ago to do so. I run sever operating systems because I like to have the control, the minimalism, the elegance, the security. By trying to be more of a desktop orientated system, Linux actually looses what attracts people like myself to using it. I doubt they care, I don't think they have to, just as I don't have to use it. "This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface."[1] "Much of the power of the UNIX operating system comes from a style of program design that makes programs easy to use and, more important, easy to combine with other programs. This style has been called the use of software tools , and depends more on how the programs fit into the programming environment - how they can be used with other programs - than on how they are designed internally. But as the system has become commercially successful and has spread widely, this style has often been compromised, to the detriment of all users. Old programs have become encrusted with dubious features. Newer programs are not always written with attention to proper separation of function and design for interconnection. [...] This style was based on the use of tools : using programs separately or in combination to get a job done, rather than doing it by hand, by monolithic self-sufficient subsystems, or by special-purpose, one-time programs. [...] One thing that UNIX does not need is more features. It is successful in part because it has a small number of good ideas that work well together. Merely adding features does not make it easier for users to do things - it just makes the manual thicker. The right solution in the right place is always more effective than haphazard hacking."[2] Still reading at this point? Great systemd free Linux distributions: Gentoo, Funtoo, Void Linux, among many others and there is also something called BSD (FreeBSD, OpenBSD, DragonflyBSD)... you should check it out. Also see www.suckless.org [1] http://www.amazon.com/Quarter-Century-UNIX-Peter-Salus/dp/0201547775 http://www.amazon.com/Quarter-Century-UNIX-Peter-Salus/dp/02... [2] http://harmful.cat-v.org/cat-v/unix_prog_design.pdf http://harmful.cat-v.org/cat-v/unix_prog_design.pdf

geofft 11y ago
The "Unix philosophy" of text streams hasn't worked, and arguably never worked. BSD sockets aren't quite text streams. Terminals aren't quite text streams. Shellshock existed because someone decided that serializing functions via text streams was a good idea. And if you look at the things you care about when running a daemon process -- sessions, controlling terminals, reliable restarts (without killing the wrong process), logging, starting dependencies in the right order, dropping privileges reliably etc. -- none of those things are good ideas that work well together. You can clearly see that things like double-forking and detaching from controlling terminals and syslog were all bolted on later, because the original system didn't work well, and the hacks don't work well either. I run servers, and I'm excited about systemd because it makes all these things actually work. The Unix philosophy gave me tools that do one thing and kinda sorta do them okay, if you're lucky. systemd does multiple things, and it does them all well. Back when we ran FreeBSD, we had hard-coded sleeps to wait for the network and NFS to come up before we continued with boot, and we had regular problems with being too aggressive with those sorts of hacks and having machines that would get stuck before launching sshd. That is straight-up not a problem with systemd.

eb0la 11y ago

I understand this because I can't get used to systemd. The learning curve should be better than rc.local for my taste. Problem is systemd helps you booting fast and this is important both in the cloud (where every minute is a billed), and in telecom (where you have a stringent SLA to cover).

chris_wot 11y ago
I would have thought a fast boot would be important to pretty much everyone...
- gkya 11y ago
  Why? When I used Arch Linux I did not ever turn off my laptop, but hibernate it. I only ever booted it when I stupidly forgot to plug it in before the battery runs out. And 10-20 seconds spend on a sequential boot every 10-20 days is just no time. We spend at least 100x that time in the toilet every day.
  - chris_wot 11y ago
    I stand corrected.

meddlepal 11y ago

Meh. Systemd is pretty great. The *Nix purists hate it, but it solves a lot of problems and does it fairly consistently. I love using it in Fedora now where journald has basically replaced syslog completely.

ferrari8608 11y ago
Honestly journald is probably the only thing I don't really like about systemd and not for the reason you might think I'm about to say. I just rarely need to use it, because everything pretty much just works 99% of the time. So I end up forgetting how to use journalctl by the time I need it again and have to Google/man. Yeah I know, that's my own problem.

phantom_oracle 11y ago

Everybody mentions the Unix philosophy and that is a very valid point, but I would like to mention the freedom philosophy that open-source/Linux gives (or used to). These guys who wanted systemd muscled their way in to get this software into the Debian system. They also adopted an "all or nothing" approach, depriving the greater community of something bigger than "do 1 thing and do it well", which is "freedom to do as you wish and choose". Debian wouldn't have split had they maintained they made systemd opt-in or Poettering and co. maintained their own Debian-systemd version. That didn't gel well with Redhats version of what Open Source is, and so many were deprived of their freedom to NOT CHOOSE systemd BUT still use Debian. For all the talk of how good/bad systemd is, the proponents for systemd should remember how they deprived others with the freedom to choose, no matter how "ignorant" or "backwards" the detractors are (or how "shit" sysvinit is).

the_why_of_y 11y ago
https://lists.debian.org/debian-devel-announce/2014/08/msg00001.html https://lists.debian.org/debian-devel-announce/2014/08/msg00...

d02 11y ago

It is amusing and unsurprising that, in 91 comments, the word Devuan is used a total of 2 times.

JdeBP 11y ago
I've just mentioned it. So it's 3 now. (-: What you observe is emblematic of the problem with Devuan, and a few of the Devuan people themselves acknowledge it. So much of the discussion centres upon "how to remove evil libsystemd0" and suchlike that what is lost is the supposedly intentional focus of the Devuan project on init freedom. That surely means the freedom to run systemd as well as to not run it. * https://lists.dyne.org/lurker/message/20150208.110824.579d179c.pt.html https://lists.dyne.org/lurker/message/20150208.110824.579d17... And as you can see, that bleeds over into the press coverage seeking headline material.

lucideer 11y ago

Given the popularity of systemd as a discussion topic on HN, I'm surprised there isn't much about OpenRC[0]. Does anyone know if Devuan have given it any consideration? [0] https://lwn.net/Articles/512719/ https://lwn.net/Articles/512719/

SwellJoe 11y ago

Don't fork in anger. There's such a long history of projects starting out of a desire to not change, and so many of them (most, I would wager) fizzle out soon after. Being against some specific feature or architectural change is not the same as having a future vision that can drive a person to work on something, for no pay, for years or decades. Anger fades...the people you're angry at ignore the new project, making it unsatisfying in terms of vengeance. And, again, it just doesn't stick with you the way a desire to do something new and better does. I'm not even saying systemd is great (it's good and bad in all sorts of novel ways), I'm just saying that the people who are just reacting against it, when the industry and community has been so clear about it being the future they are passionate about, are unlikely to do anything more than spin their wheels for a few months, and then fade away (as a project, I hope they all stick around as contributors to OSS things).

JdeBP 11y ago

This is press coverage. The actual announcement page is discussed at https://news.ycombinator.com/item?id=11593674 https://news.ycombinator.com/item?id=11593674 .