New Group Calls For Boycotting Systemd

[sdack]

To the actual hardware, a single executable binary for any particular init task is a hell of a lot simpler than running a larger general purpose interpreter binary with an ascii script as the argument it is called with. Simple to the user and simple to the hardware are often directly opposite oneanother. A happy medium would be for each module to have simple, easy to understand source that compiles easily to the final binaries without a lot of otherwise unused build dependencies.

Honestly, I do not believe a hardware has either feelings or an understanding of what is hard, complex or simple. It is all just instructions and clock cycles.

But we do like to add instructions to applications that may seem redundant to some, but which has the purpose of helping others. This is why we use ASCII scripts, because it is human-readable. It serves more than just the purpose of being executable, but it is also educational and more maintainable. This has always been important to UNIX, and now to Linux, in order to attract young people to it and to allow them to make it theirs.

If we really were to turn everything into binary form and also moved away from source distributions then we are getting nearer to closed source. The software would run a bit better, but by ignoring the human factor will we make Linux boring to newer generations. Who will be left to carry Linux when it is cutting off its roots that have attracted generations of people to it? Who will be left to appreciate it?

I do not think the shit storm we are seeing is about technical issues. We all know that these can be resolved.

[interested]

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.

Neither sysvinit nor systemd are likely to have problems with an upgrade or need to reboot afterwards they have been upgraded. But if there for some reason was a problem that caused systemd to eg. hang, it can recover from it since it has a total supervision chain that includes itself.

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

I really don't think so. Because sysvinit etc. uses executable config files, they all depend on a shell too (systemd can use scripts, but can boot without any shell). There is also cron, sntp, syslog, dhcp and several more programs that must be included before there is even a resemblances of feature parity.

All in all this probably amount to at least the same amount of code without even getting feature parity with systemd. Some projects like cron or sntp are split among many different versions sometimes even without upstream development and bugfixing. I think many will be surprised to know that their Vixie cron/ISC cron hasn't had upstream development or security bugfixing for a decade.

I think a real world comparison between systemd code and and the code necessary to run a vaguely similar sysvinit system, will show that the systemd code is leaner and much better maintained.

The systemd project is simply better at attracting developers and contributors. (a dozen developers with commit access and +500 contributors). Probably because it is less fun to lonely maintain yet another crond fork, than being part of the core Linux development team. Probably looks better on peoples CV too.

[darkcoder]

The irony begins

So they don't like systemd because among other things is a big piece of software developed by a single group that cannot be replaced easily due to how it control things, but they suggest going to BSD which is another big piece of software (even bigger) developed by a single group, which also cannot be replaced easily.

[Krejzi]

This http://ewontfix.com/14 worries me!

I hate having to restart after updates. It's one of the things I love about linux (vs Windows), not having to restart after updates. And there's going to be increased attack surface with systemd use?

I have always been a big fan of Upstart. And was disappointed to see it "lose" in Ubuntu. But if systemd really is bringing what the ewontfix.com/14 article says, I don't see myself staying on a Linux desktop.

Good luck updating the kernel without a reboot then.

Also, you don't have to reboot when systemd is updated, you can reexec it as the article mentioned. Sure, that could go wrong but that doesn't mean it will (at least it never has for me and I'm sure also many other people).

[interested]

What exactly is so awful about the present init system that it needs to be replaced? Is your system not booting up now? My i3 with a mechanical hard drive boots up in 5 seconds running a regular init. Do you really think that I need it to boot up faster than that? Because I'm here now to tell you that I do not. I also do not need an init that is more than 10 times as complex as the one I am currently using either.

You seem to want to praise people who are willing to make an effort to lead everyone else down a garden path. Yet in the same breath you condemn us when we make an effort to resist a move into suspect territory. For you to have any credibility you are going to have to actually come up with some valid reasons for us to abandon what we already have.

No, people just doing shit isn't a valid reason either. What kind of a lemming are you?

There are actually many, extremely valid reasons why sysvinit and all similar primitive init systems must die. Sysvinit has been on the official death list for all Unix'es since the 1980's at least, and all certified Unix'es have abandoned it years ago.

Sysvinit was barely adequate for when needs where simple, but it has been hopelessly behind the new ways of doing computing this century.

It wasn't love nor technical reasons why sysvinit was allowed to survive so long on Linux, it was simply because Linux never had any central core development outside the kernel.

Like it or not, people who had enough of sysvinit started to develop a new init solution. They really did their homework well by studying all other init systems in order to make an alternative that was more than a small incremental improvement.

Unlike all other Linux init-systems, systemd is designed to satisfy the needs of all Linux systems, from small embedded devices (probably a +billion devices runs Linux). to pc's, tablets, small servers, giant mainframe servers, supercomputers, clusters, OS containers etc.

That systemd is vastly superior to sysvinit and all other script based Linux init system in every detail, and not by a small amount either, is the major reason why the entire Linux industry have accepted it.

[Krejzi]

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).

Wat?

http://www.pathname.com/fhs/pub/fhs-2.3.html#BINESSENTIALUSERCOMMANDBINARIES

http://www.pathname.com/fhs/pub/fhs-2.3.html#SBINSYSTEMBINARIES

[Guest]

I agree with you although I like german cars

Good for you

I don't want spend time arguing with you against german motorization and convicting you that japanese cars are better

[sdack]

Wat?

http://www.pathname.com/fhs/pub/fhs-2.3.html#BINESSENTIALUSERCOMMANDBINARIES

http://www.pathname.com/fhs/pub/fhs-...SYSTEMBINARIES

It is like I said. Its meaning has been watered down over the years. Linux does not make too much sense here when you think about it. It uses four directories /bin, /sbin, /usr/bin and /usr/sbin, and its explanation distinguishes between root and regular users as well as size, but a regular user cannot actually log in before the system has mounted all partitions nor should they be running anything during that time. So there is no need for four directories but only two. The four directories do come from a time when dynamic linking was introduced in UNIX. The LSB does not actually conflict with the original meaning, but only states the most basic expectation of what is to be found there. You could keep your porn collection in /sbin and it would not conflict with the LSB as long as you also keep the binaries in there, too.

And this is not even a joke. I actually know of admins who used their privileges and hid porn pics in dot-directories on the root partition of their workstation.

[Krejzi]

It is like I said. Its meaning has been watered down over the years. Linux does not make too much sense here when you think about it. It uses four directories /bin, /sbin, /usr/bin and /usr/sbin, and its explanation distinguishes between root and regular users as well as size, but a regular user cannot actually log in before the system has mounted all partitions nor should they be running anything during that time. So there is no need for four directories but only two. The four directories do come from a time when dynamic linking was introduced in UNIX. The LSB does not actually conflict with the original meaning, but only states the most basic expectation of what is to be found there.

I believe they may also come from the "small disk space" era, where /bin and /sbin should only contain files essential to boot up the system and mount other drives/partitions that contain everything else, even /usr. Today, there is no need for that unless you are working with embedded systems. But then again, they could still smash all the binaries (if any) in /bin for example. Archlinux went with "all for one" directory, where all binaries, be it system binaries from /sbin or /usr/sbin and essential binaries from /bin are placed in /usr/bin and the other 3 are symbolic link to it.

You could keep your porn collection in /sbin and it would not conflict with the LSB as long as you also keep the binaries in there, too. And this is not even a joke. I actually know of admins who used their privileges and hid porn pics in dot-directories on the root partition of their workstation.

That's what separate /boot is for :P Just umount it, hide your stash and mount it again - it's not that anything is using any files there while system is running.

[sdack]

I believe they may also come from the "small disk space" era, where /bin and /sbin should only contain files essential to boot up the system and mount other drives/partitions that contain everything else, even /usr. Today, there is no need for that unless you are working with embedded systems. But then again, they could still smash all the binaries (if any) in /bin for example. Archlinux went with "all for one" directory, where all binaries, be it system binaries from /sbin or /usr/sbin and essential binaries from /bin are placed in /usr/bin and the other 3 are symbolic link to it.

It was just /bin and /usr/bin first, and like you say out of lack of space, and later got duplicated to hold statically-linked binaries in the sbin-directories. This is why /sbin still contains the most basic disk commands. Why they abandoned the use of statically-linked binaries for important admin commands is unknown to me. Not only did it make sense back then, but it would still make sense today with regards to security.