New Group Calls For Boycotting Systemd

[Luke_Wolf]

I should clarify a bit:
In that post I was referring to basic human error: Less typing means less mistakes. Often people will use javascript, or python, or some other something that isn't nearly as fast as say, just C code, but it is much easier to read, harder to screw up, and less to write.

On the other hand, if you're talking about using C vs C, then I would say simple is always better (assuming it does the exact same thing) and usually not worth the little bits of speed you might get. When I say simple, it often means shorter, but not always. I find that if it's easily understood, it's also easy to debug, and that wins over really confusing short or long code any day.

If you're typing everything by hand then sure, otherwise strong static typing wins every time because then you can tool it with things like static analysis particularly with the advent of things like Clang and Roslyn.

[interested]

First, check out what runit can do before you thumb your nose at busybox too much.

First, let me say that I find Busybox a really cool and useful project. Second, I am sure the also will be a niche for simple script based init systems in the embedded market for years to come. That said, I simply don't think runit is close to feature parity to systemd.

Second, capability bounding sets can prevent any descendents of a process from gaining a capability...but that's not really where the main problem is. Usually, someone triggers a bug in a process that's already running with the privileges they want.

Perhaps, but you have already made the attacker approach more difficult with just a single keyword in a text config file. Add another text line, and now the attacker can't read or write to /boot or /home and /dev/dsp. A third line, and now he can only write to a secure /tmp.

"Linux capabilities" isn't a magic wand (see link here: http://0pointer.de/blog/projects/security.html ) . But it is useful nevertheless. The problem with Capabilities are they weren't used by eg. upstream projects. systemd have changed that; even though upstream projects haven't heard of the concept, distro maintainers can use it by simply editing the service files. So instead of relying on systemd administrators to harden each individual running process, a basic form of security comes bundled for free with the distro.

Nonetheless, I might write a CLI tool to exec with bounding sets ("withcaps"), just because it seems interesting.

Very cool project.

Anyhow, I tried building it...
Delete the configure test for ln --relative that autoconf insisted on sneaking in despite there being absolutely no use of it. I'm using Alpine Linux, so ln is the busybox implementation.
Install libcap-dev and gperf (why must I install gperf to compile this?)
Pass just about every disable option there is; it still checks for Python...
Try to build.
Disable a CFLAG that gcc doesn't like.
Now, try to build again.
# error: neither secure_getenv nor __secure_getenv are available.
That will be trivial to fix, if I just patch my libc:

#include "libc.h"
char * secure_getenv(const char *name)
{
return libc.secure ? 0 : getenv(name);
}

I think only glibc is officially supported at the moment, simply not to compromise security etc. I guess the other libc implementations will get the missing features as time goes by.

There is also some difference when building systemd from git or from the tarball. The requirements can be found here: https://github.com/systemd/systemd

AFAIK, gperf generate uses the kernel headers to generate a keyboard list, but it shouldn't be a runtime requirement, only a build requirement.

Auto config of hot plugged devices?
eudev, mdev, nldev, hotplug2...
Launching of appropriate services when needed...isn't that what inetd does?
What you just described is systemd reimplementing a large number of features of other daemons as new daemons.

(x)inetd and systemd aren't completely overlapping. LP has a good discussion and comparison about both in these links, especially the second.

http://0pointer.de/blog/projects/instances.html

http://0pointer.de/blog/projects/inetd.html

This link further explains the advantages of the systemd approach: http://0pointer.de/blog/projects/socket-activation.html
like:
"If a service is upgraded we can restart the service while keeping around its sockets, thus ensuring the service is continously responsive. Not a single connection is lost during the upgrade."

[gens]

I'm sorry, but what's wrong with writing like a normal person? Your posts are like some kind of brain virus, if I read to many of them I get a headache.

you are excused
well.. if they are hard for you to read, it is not because of formatting
the only difference between my and regular formatting are, as pointed out, dots and capital letters
just subtract 32 from the first letter in a line and replace \n with ". " (hint: you can just XOR 32 to make a capital from lowercase)

reason are that i write as i speak, calmly (as tone is hard to read from letters)
as a bonus it exposes those who value formatting over substance (some of whom write and/or speak very... clearly(most of the time), but miss the point)
also shift sometimes gets stuck

do you want me to write simple english ?
tough luck, i actually like to use advanced features of a language (like double commas)
if there is something you do not understand, please do ask instead of being an asshat (and if you just don't like me for whatever reason, just note it if it burns you so much)

[Zetbo]

Okay, Lennart haters! What did you use when Ulrich Drepper was the maintainer of glibc? You could not use glibc, because maintainer was a dick. It probably was a lot of work to port all software to use a different libc. You should now start contribute to your favorite init. That way your $favoriteinitsystem might stay afloat.

[curaga]

a) Uli was actually a competent maintainer
b) he did not turn it into an all-devouring tentacle monster

There are different kinds of dicks, ya know.

[sdack]

(x)inetd and systemd aren't completely overlapping. LP has a good discussion and comparison about both in these links, especially the second.

http://0pointer.de/blog/projects/instances.html

http://0pointer.de/blog/projects/inetd.html

This link further explains the advantages of the systemd approach: http://0pointer.de/blog/projects/socket-activation.html
like:
"If a service is upgraded we can restart the service while keeping around its sockets, thus ensuring the service is continuously responsive. Not a single connection is lost during the upgrade."

And yet does systemd not solve the problems just the symptoms and sugar-coats trivial issues as if trying to distract from it. It requires to statically code the relationship of services into its configuration. Take the relationship of NFS to DNS for example. NFS can, but does not have to use DNS. It can use IP numbers, it can use the /etc/hosts file and it can use a DNS server. The exact moment when NFS requires DNS to resolve a host name is also not defined by its start, but by the first access to a (auto) mount point, which requires the DNS lookup.

Systemd does not actually know when or if a service needs another service, but it requires us to start services anyway and to hard-code their relationships into its configuration.

The added sugar of keeping sockets around is also questionable. Firstly, because any application using sockets needs to deal with broken sockets due to the nature of networks. It gives them a fault tolerance and systemd's feature is not something these would suddenly need. Secondly, it may not always be a good idea to keep a socket open during an upgrade, because systemd cannot know what is being upgraded and why, and so the feature can confuse the applications when it would have been better to close the socket. The feature can be a bonus, but only when it is being used knowingly. It cannot be used in general and is more likely to lead to worse implementations of services when these start to rely on this feature instead of keeping a degree of fault tolerance.

[interested]

The added sugar of keeping sockets around is also questionable. [snip]

Jeeze, now the use of sockets is being condemned because systemd uses it.

Anyway, widespread industrial adoption of systemd exactly because of systemd's use of sockets to enable instantiated services says otherwise. With Systemd you can pack many more services into the same rackspace, saving money on both hardware, cooling and electricity.

Massive, rapid parallel deployment of services on demand is what systemd does so well. You can even use it for instantiated OS containers.

Like Linux, systemd is all about solving real world problems in a ever changing technological environment, as fast and easy as possible. This is why both projects are successful.

[robclark]

If you like to admit it or not, but we are in the middle of it. You do take part in the discussion and this thread is only one of many. It shows people care even when trying not to

Afaict the only thing we are in the middle of is a few people shouting and whining and not actually doing much about it, and various low grade IT news sites fanning the flames. Meanwhile, the ones who actually do the work to put together distros have been deciding that, hey, systemd is actually pretty good, and is the best solution for the majority of their users.

like robclark above who is making an attempt at alienating users to resolve his problems.

???

I'm not entirely sure what libelous statements like that are hoping to achive.

To be clear here: I do not work on systemd or any project which directly uses it. I am simply a satisfied customer. I have used upstart, sysv init, and many years ago the old-school /etc/rc bsd stuff, and have had the opportinity to tinker w/ using each to start up random stuff at boot. And I've debugged 'em all too. I may even have a small patch in systemd to fix a bug I was hitting a year or two back with some rather odd hw (although technically, that was udev).

As an x/graphics/drm dev, I am thrilled that the "systemd cabal" is tackling some of the problems w/ VT and handover from login/dm to user X session (or wayland). If people really knew how that stuff worked originally, they surely wouldn't be saying "everything is peachy, why do we need to change".

What I'm less thrilled about is a vocal minority who wants to hold back development on fixing these and other issues simply becaues they do not understand them. Fortunately, it seems that decisions made by (at least the mainstream distros) are taken by people who actually understand some of these issues.

But, that said, if you really don't want to use systemd, then don't. It won't offend me. No one is holding a gun to your head. If your $distro_of_choice switches to systemd, stay on an older version.. or fork it.. or switch to a different distro. This isn't windows here.. you have all the src code you need. No one is stopping you.

[sdack]

Jeeze, now the use of sockets is being condemned because systemd uses it.

Anyway, widespread industrial adoption of systemd exactly because of systemd's use of sockets to enable instantiated services says otherwise. With Systemd you can pack many more services into the same rackspace, saving money on both hardware, cooling and electricity.

Massive, rapid parallel deployment of services on demand is what systemd does so well. You can even use it for instantiated OS containers.

Like Linux, systemd is all about solving real world problems in a ever changing technological environment, as fast and easy as possible. This is why both projects are successful.

No. Sockets have been used for a long time and systemd does not make room for more services suddenly. All it does is to speed up the boot and shutdown times a little bit. If you think we should use these gains to add more services then we are getting back to where we started.

The problem you fail to see is that while inetd was designed to break the relationships of services open, to force these into using fault tolerant designs and so that we can have flexible systems with few points of failures and without fail cascades, is systemd now going into the opposite direction and weaves the services together again and tries to fix what does not need fixing. What it leads to, if we let it, is to daemon processes, where we allow each to have their own design philosophy including opposing designs, designs with large dependencies and with no fault tolerance, because systemd is not actually helping here, but makes an attempt at "herding cats". Or only take yourself as an example. You already think we could use systemd to bloat the OS with more processes. And you are just one of the many more "cats" to come.

I do not think you have understood much of what is systemd is trying to fix and what it is failing at.

[ceage]

No. Sockets have been used for a long time and systemd does not make room for more services suddenly. All it does is to speed up the boot and shutdown times a little bit.

Actually, that's not all it does. Speed was never even the primary motivation behind it. In fact, socket activation solves the exact problem (manual configuration of relationships between services) that you described in your previous post. The developers explained that part more than once BTW. Of course, the decision as to whether a daemon uses static configuration or socket activation or both is up to the sysadmin and/or the authors of that specific daemon.