Can an HN mod change the title? The committee has not voted in favor of systemd (yet).
Debian committee members vote for systemd as init system
61–70 of 152 posts
Re: Debian committee members vote for systemd as init system
#62Can anyone give a quick rundown of the different init systems? For the most part it can get confusing for a non day to day system administrator when I am trying to get a program to "run on boot". Between rc.local, init.d, run levels, etc. sometimes it is just frustrating.
I can give a simplified overview of the major difference as I understand it (the difference being the method by which each init system starts its daemons on boot):
sysvinit/bsdinit - Starts daemons in serial (i.e. synchronously). Considered slow and outdated by today's standards.
upstart/launchd - Starts daemons in parallel, based on which daemons depend on each other (If B depends on A, A is started first. If C doesn't depend on anything. C is started at the same time as A. If D depends on C, D is started at the same time as B, and so on).
systemd - Creates all the necessary sockets for each daemon beforehand, and starts nearly all processes in parallel.
Aside from that, they're all configured differently, but if the competition is primarily over speed, systemd wins every time due to its clever design. the newer inits also include a lot of handy tools that aren't part of a traditional init, but that's a different story.
Re: Debian committee members vote for systemd as init system
#63Earlier quoted context omitted.
There are no working ports of upstart to non-linux, and up until 2 months ago no-one was even trying to. It's about as portable as systemd (i.e. with a bunch of work and if you don't mind forking it).
systemd fairly strongly depends on linux cgroups for process monitoring and management, no? I don't believe there's a suitable analog in any of the BSDs.
BSD has jails and rctl for controlling users resources limits and other analogous tools for process monitoring. The issue is systemd was not designed with portability in mind. Taking full advantage of Linux's features is fine for some distros, but Debian's philosophy has always been grounded in stability and portability.
Re: Debian committee members vote for systemd as init system
#64Earlier quoted context omitted.
Upstart was created before systemd. Edit: Upstart was a great sysvinit replacement, at least during those years before systemd appeared.
That's not compelling.
The 'compelling' reason was "sysv has a ton of problems". Upstart was an earlier attempt to resolves those problems - whether it does those well or not doesn't mean that there wasn't a compelling reason to create it.
Re: Debian committee members vote for systemd as init system
#65Not a surprise, was there a compelling reason for upstart at all?
systemd breaks LXC and lmctfy. systemd is not event based (matter of taste, I guess, but I prefer Upstart's model).
What are you talking about? CoreOS uses docker + systemd extensively and docker is just a pretty wrapper ontop of lxc.
https://coreos.com/docs/launching-containers/launching/getti...
Re: Debian committee members vote for systemd as init system
#66Can anyone give a quick rundown of the different init systems? For the most part it can get confusing for a non day to day system administrator when I am trying to get a program to "run on boot". Between rc.local, init.d, run levels, etc. sometimes it is just frustrating.
I know less about the new Linux ones, but a brief summary of the two big "traditional" ones: Linux systems traditionally use "SysV Init", the init system from AT&T UNIX System V (1983). It's the one that has: 1) run levels; and 2) a pile of shell scripts in /etc/init.d that run on run-level changes. Run levels probably make most sense if you think of Ye Olde Mainframe booting: first it initializes core services, then…
> (I believe commercial Unixes like Solaris also moved to dependency-based init in the 2000s).
You are correct. Solaris 10 introduced SMF (http://docs.oracle.com/cd/E23824_01/html/821-1451/dzhid.html...), which kicks quite a bit of ass.
Services are defined in XML files called manifests, which specify dependencies (including filesystems and network connectivity), the user and group to run as, timeouts for start/stop, and a bunch of other stuff.
The cool part is that, while the manifest files are static, SMF doesn't actually use them directly. The service definitions get slurped into a DB, and you can change properties (such as the whether or not the service is enabled, the user to run as, and pretty much anything else the manifest author thought of) on the fly, without editing a manifest or mucking with symlinks.
SMF also starts services in parallel (Solaris/OpenSolaris boot really, really quickly), and services that die are automatically restarted (so long as they're dying again too quickly).
Re: Debian committee members vote for systemd as init system
#67Re: Debian committee members vote for systemd as init system
#68Those are the votes for systemd: https://lists.debian.org/debian-ctte/2014/02/msg00294.html https://lists.debian.org/debian-ctte/2014/02/msg00283.html https://lists.debian.org/debian-ctte/2014/02/msg00297.html https://lists.debian.org/debian-ctte/2014/02/msg00282.html For anyone wondering, 4 votes are enough because Bdale's vote (the chairman of the Technical Committee) count as two votes in case of a draw. EDIT: see…
Fwiw, the only other vote that's been cast so far, which is in the other direction (3 people haven't yet voted): https://lists.debian.org/debian-ctte/2014/02/msg00288.html
I agree with that vote. Since Debian is still committed to BSD, they aren't going to drop sysvint once the next-gen init system is in place.
Re: Debian committee members vote for systemd as init system
#69I'm very doubtful as to whether it was within the Technical Committee's role to rule on this. After all, there is nearly a consensus on the fact that systemd is the superior init system. The question of whether certain kernels should have more features by default at the expense of portability is a matter of policy, and not a technical decision.
Re: Debian committee members vote for systemd as init system
#70Not a surprise, was there a compelling reason for upstart at all?
Upstart was created before systemd. Edit: Upstart was a great sysvinit replacement, at least during those years before systemd appeared.
sysv init was created before upstart, so it clearly must be even better? Your argument makes no sense...