Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd

[erendorn]

You see a rather idealized world don't you?

Have you ever considered this fact: If/when every Linux distribution is using "systemd" by default, the uniqueness of Linux distributions will disappear?

What do you have then? Well, you have that now and just don't see it do you? It's called "Microsoft Windows". What choice will we have then?

Redhat and who else? SuSE? Ubuntu? I think that Debian will hang on due to it's developer community. Gentoo will survive just so it can quietly annoy the others just by it's very existence.

In your idealized world we can expect many Linux distributions to fall into the depths of obscurity because there will be nothing to differentiate them...other than a fancy GUI...and that is due to the fact they will all be very very similar "underneath" since "similarity == compatibility".

Because for the last 15 years there has been soo many different init systems and sooo many display servers...
I just don't believe that Linux distributions must have different places or conventions for "hostname" to be unique.

[TheBlackCat]

Have you ever considered this fact: If/when every Linux distribution is using "systemd" by default, the uniqueness of Linux distributions will disappear?

You seriously don't see any difference between distros besides how they write their init scripts? Things like which packages they include, how bleeding-edge they are, which architectures they target, how they deal with patent issues, how they deal with non-foss software, how they deal with third-party packages, how often they release, how long they support old releases, what sort of support they offer, none of that matters at all?

[gens]

The simplest way that I can understand systemd is: systemd targets compatibility with the Linux kernel and stuff, and everything else targets systemd. In the end we get excellent performance and compatibility across distributions.

thing is..
the kernel is a state machine
like when you do a "mount /what/ever" (the mount syscall gets called) it sets up the whatever you mounted and changes/adds to the what we see as the filesystem

now systemd (as in the actual daemon) is another state machine that adds a layer in between
and it communicates with the above layer using dbus (afaik)

so no on performance
not that it matters in this case, since, again, it is all about setting up a state machine

http://www.gamedev.net/page/resources/_/technical/game-programming/state-machines-in-games-r2982

a fun look at state machine theory, if you are interested

[Guest]

You see a rather idealized world don't you?

Have you ever considered this fact: If/when every Linux distribution is using "systemd" by default, the uniqueness of Linux distributions will disappear?

What do you have then? Well, you have that now and just don't see it do you? It's called "Microsoft Windows". What choice will we have then?

Redhat and who else? SuSE? Ubuntu? I think that Debian will hang on due to it's developer community. Gentoo will survive just so it can quietly annoy the others just by it's very existence.

In your idealized world we can expect many Linux distributions to fall into the depths of obscurity because there will be nothing to differentiate them...other than a fancy GUI...and that is due to the fact they will all be very very similar "underneath" since "similarity == compatibility".

Linux is about choice (except for building block, that is Linux kernel itself).
Systemd however should not be depended on by virtually anything, since its main functions are:
- initialize system after kernel loaded up
- start all the daemons needed
- keep track of running state of all the daemons
- keep track of runtime dependencies for each daemon so they can be started in parallel fashioun
- save all the output from daemons in its journalctl, this is the hard thing to do actually, since historically:

• there is no POSIX doctrine dictating how/where should the logs be stored
• some daemons use stdout/stderr
• some connect to syslog
• same uses their own logging facilities
• and so on ...

There is virtually no reason for any user software to work or depend on systemd (not gdm, not X, not anything else), discounting logging facilities, after you get to Xorg, the job of systemd is done.

PS: yeah, I know, systemd has their own dbus, udev and nowadays takes care of everythig, from module autoloading to service autostart via dbus.
Having udev as a part of systemd was a HUGE mistake, so even ubuntu users nowadays have systemd installed only because it packs udev with it.
Gentoo forked udev before they merged with systemd some years ago, but i'm not sure how well maintained it is actually and wheather it makes sense to maintain it.
Still, I'm strongly opposed to having anything but the systemd rely on systemd if you know what I mean.

[Guest]

Aditionally:
There pretty much never was realy uniqness of distributions, there are finite number of choices in packages:

• Init system (sysvinit, upstart, systemd, openrc)
• c library (glibc, uclibc)
• WM (kde, gnome, many others but majority uses kde/gnome)
• package managers (or more like 'package file formats', deb, rpm, tgz and their daemons)

Apart from c library, you pretty much have free choice in all end-user software on ANY distro.
Different packaging formats drain resources from open-source development and they are generally a BAD thing and they HURT linux desktop community, big time.

One could argue that all these package managers are main reason for linux not being successfull on desktop (not zillion distributions, but their zillion package managers multiplying resources wasted on QA).

One nice example is Android, since there is only one UI, one market, one package manager, they can do whatever they want (and yes, there are many distributions, like cyanogen).
Since android had 'empty market' in front of them, they needn't to care about compatibility with others.

This is well known dowfall and people have talked about it past 20 years, but nobody ever tried to do anything about it.

[TheBlackCat]

Systemd however should not be depended on by virtually anything, since its main functions are:
- initialize system after kernel loaded up
- start all the daemons needed
- keep track of running state of all the daemons
- keep track of runtime dependencies for each daemon so they can be started in parallel fashioun
- save all the output from daemons in its journalctl, this is the hard thing to do actually, since historically:

• there is no POSIX doctrine dictating how/where should the logs be stored
• some daemons use stdout/stderr
• some connect to syslog
• same uses their own logging facilities
• and so on ...

There is virtually no reason for any user software to work or depend on systemd (not gdm, not X, not anything else), discounting logging facilities, after you get to Xorg, the job of systemd is done.

This is simply wrong. You are operating under the mistake assumption that systemd is solely an init for daemons. It isn't, it is a generic system for handling services. This can include general system daemons, and up to this point largely has been restricted to that, but there is nothing in systemd's design that restricts it to that, and other software is considering using it for other things.

For example KDE is planning on replacing the inefficient and ancient bash startup script and replacing it with systemd when run under wayland. This isn't bloat by systemd, it is just that systemd's architecture is flexible enough that it can be useful for other things besides simply starting and stopping daemons. So why try to enforce artificial limitations that prevent it from being used where it is helpful?

[TheBlackCat]

Different packaging formats drain resources from open-source development and they are generally a BAD thing and they HURT linux desktop community, big time.

Packaging formats is a minor issue. There are at most three major package formats, only two of which are commonly targeted by third-party packagers. And there are tools like Alien to convert between them.

The problem isn't the formats, the problem is the dependencies. If you build an arbitrary rpm for openSUSE, it probably won't install on RHEL, despite the fact that they are both rpm-based distributions. Same with Ubuntu and Debian. The problem is that the packages will be built against different versions of dependencies, quite likely with different names, built with different options, with files installed in different places. Of course if you are careful you might be able to build a generic rpm or deb that works across multiple distros by targeting LSB, but if you just pull a random package out of a repo almost certianly won'y work. Having one package format won't fix that. If it did, then everyone would just be using Alien to convert everything.

One nice example is Android, since there is only one UI, one market, one package manager, they can do whatever they want (and yes, there are many distributions, like cyanogen).

Cyanogenmod isn't a distro in any meaningful sense of the word. It is more like a respin or variant, like Ubuntu vs. Kubuntu. It uses the same toolchain, same package versions, same naming conventions, same file locations. It is fully "binary-compatible".

[Guest]

@Blackcat comments, not sure if you really tried for legit comment or are merely trolling me (I think former).
I've got quite a few invectives stuck in my throat, but I'm trying it bo civil on forums lately.

[TheBlackCat]

@Blackcat comments, not sure if you really tried for legit comment or are merely trolling me (I think former).
I've got quite a few invectives stuck in my throat, but I'm trying it bo civil on forums lately.

Right, because of course invectives is a valid response to a detailed post where I provide specific reasons for my conclusions

[Guest]

Ok, will respond to you while trying to keep it civil:

"This is simply wrong. You are operating under the mistake assumption that systemd is solely an init for daemons. It isn't, it is a generic system for handling services."

My exact point was that it INIT system shouldn't be doing anything else and rest of the fucnctionality deserves separate project. So your counterargument about systemd failing at this is that systemd failing is failing at this.

"This can include general system daemons, and up to this point largely has been restricted to that, but there is nothing in systemd's design that restricts it to that, and other software is considering using it for other things. "

It should be restricted to that, your words (also mine), but it isn't. When you install systemd on a laptop, it overrides any acpid functionality and when you close lid, it suspends by default (this has been reported and criticized, but nobody has changed default config). And thats just one example.

No software should be using systemd for anything, but indeed, many software packages do because they are reliant on udev (back to my criticizm).

"For example KDE is planning on replacing the inefficient and ancient bash startup script and replacing it with systemd when run under wayland. "

Why would KDE even use any 'ancient bash startup script'. When X is started, you tell it to execute either WM directly (via ancient script like startx) or exec xdm, gdm, kdm which in turn execute WM.

There is virtually no reason to interact with systemd, systemd should only start X which then does rest of the job (or Weston).

This works for ages and there is no reason to fix it or make it dependant upon systemd (back to philosofy "linux is about choice".
"So why try to enforce artificial limitations that prevent it from being used where it is helpful? "
Answered above.

"The problem isn't the formats, the problem is the dependencies."

This is true and I provided nice video "why linux sucks" that explains this in much more detail and comes form a developer. As an QA tester and developer I'm well aware of this, but I didnt wanted to go to too much detail so I just linked the video.

"The problem is that the packages will be built against different versions of dependencies, quite likely with different names, built with different options, with files installed in different places."

We are not living back in day of static libraries anymore and libraries can be built without propper linkage and still be linked properly most of the time.

This is much easier than it used to be, nowadays packaging is lagely automated and fairly easy, but it still requires some manpower (redhat maintainers could attest to this, despite them having huge servers and automated scripts that do packaging and linkage checks).

"Of course if you are careful you might be able to build a generic rpm or deb that works across multiple distros by targeting LSB, but if you just pull a random package out of a repo almost certianly won'y work."

It should work most of the time and if not, most of the time it can be solved by LD_PRELOAD hacks.

"Having one package format won't fix that."

Never claimed it would, but it would be step in right direction.
These formats aren't just containers, they represent building processes and handle dependencies.

"Cyanogenmod isn't a distro in any meaningful sense of the word. It is more like a respin or variant, like Ubuntu vs. Kubuntu. It uses the same toolchain, same package versions, same naming conventions, same file locations. It is fully "binary-compatible"."

I would argue that by this logic there isn't a single distro in linux world, because very few distros bring their own stuff to the table.
Everything is "binary compatible" assuming one platform (I'm talking at ABI level).

Even if you take 32bit binary and its libs, its gonna work on 64bit gentoo (assuming the owner has multilib and 32bit support compiled in kernel).


Phew, quite an answer, it has few simplifications, but else it would be much longer.
Now go watch "Why linux rox" and "why linux sucks" on youtube, it has all the arguments
(discounting systemd stuff that was brought upon us only recently).