New Group Calls For Boycotting Systemd

[pal666]

I don't like systemd for my own reasons (killed consolekit, swallowed udev, created hard /usr dependency).

typical. "I don't like systemd for my own reasons (here goes bunch of misinformed bullshit)".
systemd haters should join forces with flat earth society

[Isedonde]

What I hear a lot from experienced sysadmins is this: "systemd doesn't bring many benefits to me while making more work for me because I have to convert some custom app startup script to operate in the systemd format"

So I'm not a professional sysadmin. I only have a home server where I do sysadmin tasks.

I want to add that systemd actually brings a very important benefit in exactly that area, startup "scripts": They are 100 times easier to write. So yes, there is some extra work for the admin because he has to convert initscripts to systemd units. However, once that is done, adding custom app startups / daemons is a matter of a minute or two. Using sysvinit this is much worse. Sure, you can hack something together using templates to auto-generate most of the boilerplate etc, but that is some maintenance burden as well and probably results in scripts that are very limited in what they can do. While systemd provides full-blown daemon management / supervision / logging with just a few lines in a configuration file.

Of course, systemd even knows how to use "good" old init scripts to launch daemons. You don't get all the nice new features, but I guess it should improve at least things like reliable daemon shutdown when you request the daemon to stop, which isn't guaranteed by sysvinit.

So easier startup "script" setup combined with incredibly powerful journal logging => makes sysadmin life much easier. There is some migration work to do, of course, unless you want to keep using deprecated init scripts.

[0xBADCODE]

No. The result would be /bin would get so crowded that some executables would likely need to be renamed. /usr/bin is already heavily crowded. Also /bin is meant for executables used mainly by administrators, while /usr is meant for all users.

Very minor technical details. At the end of day /usr/bin is also crowded and crowd in /usr/bin isn't anyhow different than crowd in just /bin. And who can use what is up to ***permissions***.

Here we can meet some mumbling about separating system files and user-installed files. But with package manager this division is virtually non-existant - maintainers can offer some base defaults as metapackage (like "ubuntu-minimal") but it is really up to me what I would use and once preliminary configuration is complete, that's what I consider my own "base system" and it does not matches maintainers views. The only thing which is required is to make sure that when new package added to repository, there are no conflicting files. This requirement is not anyhow new at all.

[quote]What is an idiocy is trying to fix what is not broken. This is in part what Gnome 3, pulseaudio and now systemd have been doing, even when it is being done accidentally by the way it is being introduced and developed. They all have been introduced while being far from feature-complete.
Idiocy is when you insist everyone should ride horse when people tend to prefer airplanes, trains and cars. And systemd is actually implementing many things which were always dealt by local administrators as custom in place hacks. Needless to say it suxx a lot. And just telling that there is no problem does not solves it. It just gives me a valid reason to offer sysv lovers to GTFO and use their crap. And I would prefer init system aware of VMs, snapshots, containers and somesuch.

You see, if I mess things up, I can revert snapshot on VM in something like 30 seconds. Then I can try to create another version of future, where previous mistake does not exists. This worked for me about 10 years as VMs. And I do think that inability to do it on system installed on bare hardware is, erm, strange. It should mix together and melt in seamless ways, making it universal and powerful mechanic to deal with multiple states, be it hardware machine or VM, container or whatever. That's how I want to see my future. And you can GTFO and ride the horse instead of driving the car because I do not see how horses were broken. Yet, cars replaced them.

Nothings screws up things more than lack of ambitions about better future. Feel free to use CP/M and Multics - they were working, dammit.

[Akka]

1453ad actually. The Byzantine Empire was Eastern Roman Empire proper.

So according to mirex, systemd has a lot of life left.

[nanonyme]

No. The result would be /bin would get so crowded that some executables would likely need to be renamed. /usr/bin is already heavily crowded. Also /bin is meant for executables used mainly by administrators, while /usr is meant for all users.

Incidentally you are wrong. /bin and /usr/bin are for all users, /sbin and /usr/sbin are for administrators. The only reason for /bin is that it's a hack for when your root cannot for exotic reasons be mpunted on early boot

[sdack]

Incidentally you are wrong. /bin and /usr/bin are for all users, /sbin and /usr/sbin are for administrators. The only reason for /bin is that it's a hack for when your root cannot for exotic reasons be mpunted on early boot

No. /sbin and /usr/sbin are meant for static binaries (and hence the s), but this has been watered done for some time now. In the past could one in fact find copies of executables of /bin in /sbin, too, but without having the need for shared libraries. It made it possible to have /lib on another device and in case of a failure allowed one to use some of the commands. This is also why you still find most of the disk-related commands such as mount and cfdisk still in /sbin, even though these are all shared binaries now (at least here on my Debian box).

[robclark]

What I hear a lot from experienced sysadmins is this: "systemd doesn't bring many benefits to me while making more work for me because I have to convert some custom app startup script to operate in the systemd format" At my own employer I am not sure how RHEL7 will be accepted when RHEL6 has a big "footprint".

well, this fellow appears to be a sysadmin, with a different opinion about systemd:

https://www.youtube.com/watch?v=-97qqUHwzGM

I'm not really sure where the systemd is not for servers stuff originated, but afaict it isn't the case.

at any rate, rhel6 was upstart, which is also not sysvinit.

[nanonyme]

No. /sbin and /usr/sbin are meant for static binaries (and hence the s), but this has been watered done for some time now. In the past could one in fact find copies of executables of /bin in /sbin, too, but without having the need for shared libraries. It made it possible to have /lib on another device and in case of a failure allowed one to use some of the commands. This is also why you still find most of the disk-related commands such as mount and cfdisk still in /sbin, even though these are all shared binaries now (at least here on my Debian box).

Huh, really? I was pretty sure the s was about superuser as lusers do not have /sbin and /usr/svin in PATH on any *nix I've ever used

[ryao]

Did you actually read the article? It says first that systemd has to restart to upgrade, but then later on admits that there is actually a built-in mechanism to avoid having to restart.

It is called execve(2). If the new process fails to start, the kernel panics. sysvinit is not much better in this regard because a bad update will break the system there too. However, being incredibly minimal means that it needs far fewer updates than systemd and updates are not really a problem for it.

If you compare to sysv alone, then yes. If you compare to sysv AND all the shell scripts, then no.

The shell scripts are sysvrc, not sysvinit. Here are the contents of sysvinit:

equery files sysvinit
 * Searching for sysvinit ...
 * Contents of sys-apps/sysvinit-2.88-r7:
/bin
/etc
/etc/init.d
/etc/init.d/reboot.sh
/etc/init.d/shutdown.sh
/etc/inittab
/sbin
/sbin/bootlogd
/sbin/fstab-decode
/sbin/halt
/sbin/init
/sbin/killall5
/sbin/poweroff -> halt
/sbin/reboot -> halt
/sbin/runlevel
/sbin/shutdown
/sbin/telinit -> init
/usr
/usr/bin
/usr/include
/usr/include/initreq.h
/usr/lib
/usr/lib/debug
/usr/lib/debug/sbin
/usr/lib/debug/sbin/bootlogd.debug
/usr/lib/debug/sbin/fstab-decode.debug
/usr/lib/debug/sbin/halt.debug
/usr/lib/debug/sbin/init.debug
/usr/lib/debug/sbin/killall5.debug
/usr/lib/debug/sbin/runlevel.debug
/usr/lib/debug/sbin/shutdown.debug
/usr/share
/usr/share/doc
/usr/share/doc/sysvinit-2.88-r7
/usr/share/doc/sysvinit-2.88-r7/Changelog.bz2
/usr/share/doc/sysvinit-2.88-r7/Install.bz2
/usr/share/doc/sysvinit-2.88-r7/Propaganda.bz2
/usr/share/doc/sysvinit-2.88-r7/README.bz2
/usr/share/doc/sysvinit-2.88-r7/bootlogd.README.bz2
/usr/share/doc/sysvinit-2.88-r7/sysvinit-2.86.lsm.bz2
/usr/share/man
/usr/share/man/man1
/usr/share/man/man5
/usr/share/man/man5/initscript.5.bz2
/usr/share/man/man5/inittab.5.bz2
/usr/share/man/man8
/usr/share/man/man8/bootlogd.8.bz2
/usr/share/man/man8/fstab-decode.8.bz2
/usr/share/man/man8/halt.8.bz2
/usr/share/man/man8/init.8.bz2
/usr/share/man/man8/killall5.8.bz2
/usr/share/man/man8/poweroff.8
/usr/share/man/man8/reboot.8
/usr/share/man/man8/runlevel.8.bz2
/usr/share/man/man8/shutdown.8.bz2
/usr/share/man/man8/telinit.8
/usr/src
/usr/src/debug
/usr/src/debug/sys-apps
/usr/src/debug/sys-apps/sysvinit-2.88-r7
/usr/src/debug/sys-apps/sysvinit-2.88-r7/sysvinit-2.88dsf
/usr/src/debug/sys-apps/sysvinit-2.88-r7/sysvinit-2.88dsf/src
/usr/src/debug/sys-apps/sysvinit-2.88-r7/sysvinit-2.88dsf/src/bootlogd.c
/usr/src/debug/sys-apps/sysvinit-2.88-r7/sysvinit-2.88dsf/src/dowall.c
/usr/src/debug/sys-apps/sysvinit-2.88-r7/sysvinit-2.88dsf/src/fstab-decode.c
/usr/src/debug/sys-apps/sysvinit-2.88-r7/sysvinit-2.88dsf/src/halt.c
/usr/src/debug/sys-apps/sysvinit-2.88-r7/sysvinit-2.88dsf/src/hddown.c
/usr/src/debug/sys-apps/sysvinit-2.88-r7/sysvinit-2.88dsf/src/ifdown.c
/usr/src/debug/sys-apps/sysvinit-2.88-r7/sysvinit-2.88dsf/src/init.c
/usr/src/debug/sys-apps/sysvinit-2.88-r7/sysvinit-2.88dsf/src/init.h
/usr/src/debug/sys-apps/sysvinit-2.88-r7/sysvinit-2.88dsf/src/initreq.h
/usr/src/debug/sys-apps/sysvinit-2.88-r7/sysvinit-2.88dsf/src/killall5.c
/usr/src/debug/sys-apps/sysvinit-2.88-r7/sysvinit-2.88dsf/src/runlevel.c
/usr/src/debug/sys-apps/sysvinit-2.88-r7/sysvinit-2.88dsf/src/shutdown.c
/usr/src/debug/sys-apps/sysvinit-2.88-r7/sysvinit-2.88dsf/src/utmp.c

If you consider lines of code to reflect maintainability, then sysvinit + a RC system generally outperform systemd in this area.

[sdack]

Huh, really? I was pretty sure the s was about superuser as lusers do not have /sbin and /usr/svin in PATH on any *nix I've ever used

I am not sure if the sbin directories were already present in early BSD. They must have come with dynamic linking and around SVR4. It is not a Linux thing and Linux never really tried to be 100% UNIX compatible.