I don't think there's a problem with the idea of systemd. Having a standard way to handle process start-up, dependencies, failures, recovery, "contracts", etc... isn't a bad, or unique, thing -- Solaris has Service Manager, for example. I think there's just too many things unnecessarily built into systemd rather than it utilizing external, usually, already existing utilities. Does systemd really need, for example, NFS, DNS, NTP services built-in? Why can't it run as PID 2 and leave PID1 for init to simply reap orphaned processes? Would make it easier to restart or handle a failed systemd w/o rebooting the entire system (or so I've read).
In short, systemd has too many things stuffed into its kitchen sink -- if you want that, use Emacs:-)
[ Note, I'm a fan and long-time user of Emacs, so the joke's in good fun. ]
I don't think there's a problem with the idea of systemd. Having a standard way to handle process start-up, dependencies, failures, recovery, "contracts", etc... isn't a bad, or unique, thing -- Solaris has Service Manager, for example.
the difference is that solaris is - was - written and maintained by a single vendor. they have - had - the resources to keep it running, and you "bought in" to the sun microsystems (now oracle) way, and that was that. problems? pay oracle some money, get support... fixed.
free software is not *just* about a single way of doing things... because the single way doesn't fit absolutely *all* cases. take angstrom linux for example: an embedded version of GNU/Linux that doesn't even *have* an init system! you're expected to write your own initialisation system with hard-coded entries in/dev. why? because on an embedded system with only 32mb of RAM there *wasn't room* to run an init service.
then also we have freebsd and netbsd to consider, where security is much tighter and the team is smaller. in short: in the free software world unlike solaris there *is* no "single way" and any "single way" is guaranteed to be a nightmare pain-in-the-ass for at least somebody, somewhere.
this is what the "majority voting" that primarily debian - other distros less so because to some extent they have a narrower focus than debian - completely failed to appreciate. the "majority rule" decision-making, for all that it is blindly accepted to be "How Democracy Works" basically pissed in the faces of every debian sysadmin who has a setup that the "one true systemd way" does not suit - for whatever reason, where that reason ultimately DOES NOT MATTER, betraying an IMPLICIT trust placed by those extremely experienced users in the debian developers that you DO NOT fuck about with the underlying infrastructure without making it entirely optional.
now, it has to be said that the loss of several key debian developers, despite the incredible reasonable-ness of the way that they went about making their decision, made it clear to the whole debian team quite how badly they misjudged things: joey hess leaving with the declaration that debian's charter is a "toxic document" for example, and on that basis they have actually tried very hard to undo some of that damage.
the problem is that their efforts simply don't go far enough. udisk2, policykit, and several absolutely CRITICAL programs without which it is near flat-out impossible to run a desktop system - all gone. the only way to get those back is to add http://angband.pl/debian/ [angband.pl] to/etc/apt/sources.list and use the (often out-of-date) nosystemd recompiled versions of packages that SHOULD BE A PERMANENT PART OF DEBIAN.
in essence: whilst debian developers are getting absolutely fed up of hearing about systemd, they need to accept that the voices that tell them that there is a problem - even though those voices cannot often actually quite say precisely what is wrong - are never, ever, going to stop, UNTIL the day that the role played by http://angband.pl/debian/ [angband.pl] is absorbed into the main debian packaging, providing "Replaces / Provides / Conflicts" alternatives of pulseaudio, libcups, bsdutils, udev, util-linux, uuid-runtime, xserver-xorg and many more - all with a -nosystemd extension on the package name.
ONLY WHEN it is possible for debian users to run a debian system COMPLETELY free of everything associated with systemd - including libsystemd - will the utterly relentless voices and complaints stop, because only then, FINALLY, will people feel safer about running a debian system where there is absolutely NO possibility of harm, cost or inconvenience caused by the poisonous and utterly irresponsible attitude shown by pottering, with his blatant disregard for security, good design practices, and complete lack of respect for other peoples' valuable input by abruptly and irra
the difference is that solaris is - was - written and maintained by a single vendor. they have - had - the resources to keep it running, and you "bought in" to the sun microsystems (now oracle) way, and that was that. problems? pay oracle some money, get support... fixed.
Worth mentioning that Solaris Service Manager has its share of problems, too.
That and the fact that systemd is incompatible (yes, incompatible) with existing init systems. Otherwise it would be a simple configuration option whether to use systemd or something that has stood the test of time.
Nice lie you go there. And yes, I do run Debian with sysv init. It is possible but there are problem areas and some things break. It is not fully supported. Hence systemd is _not_ compatible.
systemd is compatible. It may be the case that some things are not compatible with sysvinit, but surely it's the job of people who want to use sysvinit to make sure things are compatible with it.
This is free software -- the rule is people scratch their own itches. If you want something done then you'd better do it yourself and stop whining that other people aren't doing the job.
Stop lying and pretending you do not exactly know what this is about. At that point we can have a civil exchange. At the moment you are simply an _enemy_.
Stop lying and pretending you do not exactly know what this is about. At that point we can have a civil exchange. At the moment you are simply an _enemy_
I am, of course, the enemy of all lying toads.
I have no interest in having a "civil exchange" with lying toads.
What is this "about", lying toad, tell us, stop beating around the bush.
I especially appreciate doing something as simple as pointing to a different nameserver and having systemd decide it needs to drop all open network connections and reinitialize them.
I don't think there's a problem with the idea of systemd. Having a standard way to handle process start-up, dependencies, failures, recovery, "contracts", etc... isn't a bad, or unique, thing -- Solaris has Service Manager, for example.
I think there's just too many things unnecessarily built into systemd rather than it utilizing external, usually, already existing utilities. Does systemd really need, for example, NFS, DNS, NTP services built-in? Why can't it run as PID 2 and leave PID1 for init to simply reap orphaned processes?
Those things do run as separate daemons. They're not all crammed into PID 1. The actual systemd program (PID 1) just handles starting and stopping services, and is similar to (and inspired by) launchd [wikipedia.org] on macOS.
It's OK to continue using those conventional, non-systemd services, and Debian at least (don't know about other distros) generally does so.
Heck Fedora, which is usually portrayed as the Lennart playground for systemd because "Red Hat" doesn't even use -networkd, -resolved or -timed instead preferring NetworkManager, <none> (there's been debate about unbound as a caching daemon in the past but they didn't go anywhere), and chrony for those roles.
The problem is, everybody hates all of those alternate things. It doesn't matter if it's SM or launchd or systemd, they all suck worse than init because they cause problems.
I think there's just too many things unnecessarily built into systemd rather than it utilizing external, usually, already existing utilities. Does systemd really need, for example, NFS, DNS, NTP services built-in? Why can't it run as PID 2 and leave PID1 for init to simply reap orphaned processes? Would make it easier to restart or handle a failed systemd w/o rebooting the entire system (or so I've read).
I think you are confused.
Here is the service unit file for systemd-timesyncd [github.com] From this it should be quite apparent that: 1)No, systemd (the pid 1) isn't an NTP service. The systemd project includes a different time synchronisation service that is built using the systemd libraries to work better during sytemd boot under certain conditions [freedesktop.org] than other clients (such as ntpd, chronyd etc.) that work perfectly adequately with systemd under normal conditions. 2)The service doesn't run as root, but as a dedicated use
It's the implementation. (Score:5, Insightful)
I don't think there's a problem with the idea of systemd. Having a standard way to handle process start-up, dependencies, failures, recovery, "contracts", etc... isn't a bad, or unique, thing -- Solaris has Service Manager, for example. I think there's just too many things unnecessarily built into systemd rather than it utilizing external, usually, already existing utilities. Does systemd really need, for example, NFS, DNS, NTP services built-in? Why can't it run as PID 2 and leave PID1 for init to simply reap orphaned processes? Would make it easier to restart or handle a failed systemd w/o rebooting the entire system (or so I've read).
In short, systemd has too many things stuffed into its kitchen sink -- if you want that, use Emacs :-)
[ Note, I'm a fan and long-time user of Emacs, so the joke's in good fun. ]
Re:It's the implementation. (Score:5, Interesting)
I don't think there's a problem with the idea of systemd. Having a standard way to handle process start-up, dependencies, failures, recovery, "contracts", etc... isn't a bad, or unique, thing -- Solaris has Service Manager, for example.
the difference is that solaris is - was - written and maintained by a single vendor. they have - had - the resources to keep it running, and you "bought in" to the sun microsystems (now oracle) way, and that was that. problems? pay oracle some money, get support... fixed.
free software is not *just* about a single way of doing things... because the single way doesn't fit absolutely *all* cases. take angstrom linux for example: an embedded version of GNU/Linux that doesn't even *have* an init system! you're expected to write your own initialisation system with hard-coded entries in /dev. why? because on an embedded system with only 32mb of RAM there *wasn't room* to run an init service.
then also we have freebsd and netbsd to consider, where security is much tighter and the team is smaller. in short: in the free software world unlike solaris there *is* no "single way" and any "single way" is guaranteed to be a nightmare pain-in-the-ass for at least somebody, somewhere.
this is what the "majority voting" that primarily debian - other distros less so because to some extent they have a narrower focus than debian - completely failed to appreciate. the "majority rule" decision-making, for all that it is blindly accepted to be "How Democracy Works" basically pissed in the faces of every debian sysadmin who has a setup that the "one true systemd way" does not suit - for whatever reason, where that reason ultimately DOES NOT MATTER, betraying an IMPLICIT trust placed by those extremely experienced users in the debian developers that you DO NOT fuck about with the underlying infrastructure without making it entirely optional.
now, it has to be said that the loss of several key debian developers, despite the incredible reasonable-ness of the way that they went about making their decision, made it clear to the whole debian team quite how badly they misjudged things: joey hess leaving with the declaration that debian's charter is a "toxic document" for example, and on that basis they have actually tried very hard to undo some of that damage.
the problem is that their efforts simply don't go far enough. udisk2, policykit, and several absolutely CRITICAL programs without which it is near flat-out impossible to run a desktop system - all gone. the only way to get those back is to add http://angband.pl/debian/ [angband.pl] to /etc/apt/sources.list and use the (often out-of-date) nosystemd recompiled versions of packages that SHOULD BE A PERMANENT PART OF DEBIAN.
in essence: whilst debian developers are getting absolutely fed up of hearing about systemd, they need to accept that the voices that tell them that there is a problem - even though those voices cannot often actually quite say precisely what is wrong - are never, ever, going to stop, UNTIL the day that the role played by http://angband.pl/debian/ [angband.pl] is absorbed into the main debian packaging, providing "Replaces / Provides / Conflicts" alternatives of pulseaudio, libcups, bsdutils, udev, util-linux, uuid-runtime, xserver-xorg and many more - all with a -nosystemd extension on the package name.
ONLY WHEN it is possible for debian users to run a debian system COMPLETELY free of everything associated with systemd - including libsystemd - will the utterly relentless voices and complaints stop, because only then, FINALLY, will people feel safer about running a debian system where there is absolutely NO possibility of harm, cost or inconvenience caused by the poisonous and utterly irresponsible attitude shown by pottering, with his blatant disregard for security, good design practices, and complete lack of respect for other peoples' valuable input by abruptly and irra
Re: (Score:2)
the difference is that solaris is - was - written and maintained by a single vendor. they have - had - the resources to keep it running, and you "bought in" to the sun microsystems (now oracle) way, and that was that. problems? pay oracle some money, get support... fixed.
Worth mentioning that Solaris Service Manager has its share of problems, too.
Re: (Score:1)
That and the fact that systemd is incompatible (yes, incompatible) with existing init systems. Otherwise it would be a simple configuration option whether to use systemd or something that has stood the test of time.
Re: (Score:1)
That and the fact that systemd is incompatible (yes, incompatible) with existing init systems
systemd is very compatible with sysvinit.
therwise it would be a simple configuration option whether to use systemd or something that has stood the test of time.
On Debian there is a simple configuration command to switch between systemd and sysvinit.
Re: (Score:2)
Nice lie you go there. And yes, I do run Debian with sysv init. It is possible but there are problem areas and some things break. It is not fully supported. Hence systemd is _not_ compatible.
Re: (Score:1)
there are problem areas and some things break
Like what? Bug reports?
systemd is compatible. It may be the case that some things are not compatible with sysvinit, but surely it's the job of people who want to use sysvinit to make sure things are compatible with it.
This is free software -- the rule is people scratch their own itches. If you want something done then you'd better do it yourself and stop whining that other people aren't doing the job.
Re: (Score:2)
Stop lying and pretending you do not exactly know what this is about. At that point we can have a civil exchange. At the moment you are simply an _enemy_.
Re: (Score:1)
Stop lying and pretending you do not exactly know what this is about. At that point we can have a civil exchange. At the moment you are simply an _enemy_
I am, of course, the enemy of all lying toads.
I have no interest in having a "civil exchange" with lying toads.
What is this "about", lying toad, tell us, stop beating around the bush.
Re: (Score:2)
Aha, truth at last. Thanks for that.
Re: (Score:1)
I, unlike you, always speak the truth.
What is this "about" in your diseased mind? Why will you not say? Are you, rightly, afraid that people will laugh at you?
Re: (Score:1)
I especially appreciate doing something as simple as pointing to a different nameserver and having systemd decide it needs to drop all open network connections and reinitialize them.
Re: (Score:2)
well, at least emacs has a justification; Stallman wanted to write a complete os, and actually did so, it just happens to be called emacs ;).
But I have no worries, we will replace that redhat init that's makin' such a fuss...
Re: (Score:2)
Stallman wanted to write a complete os, and actually did so, it just happens to be called emacs ;).
IIRC, EMACS isn't fully capable of concurrency (and only recently gained any form of it - but it's not universally compatible).
Re: (Score:2)
I don't think there's a problem with the idea of systemd. Having a standard way to handle process start-up, dependencies, failures, recovery, "contracts", etc... isn't a bad, or unique, thing -- Solaris has Service Manager, for example.
yeah, and sfm on solaris is just horrible too.
Re: (Score:2)
Those things do run as separate daemons. They're not all crammed into PID 1. The actual systemd program (PID 1) just handles starting and stopping services, and is similar to (and inspired by) launchd [wikipedia.org] on macOS.
Re: (Score:2)
It's OK to continue using those conventional, non-systemd services, and Debian at least (don't know about other distros) generally does so.
Heck Fedora, which is usually portrayed as the Lennart playground for systemd because "Red Hat" doesn't even use -networkd, -resolved or -timed instead preferring NetworkManager, <none> (there's been debate about unbound as a caching daemon in the past but they didn't go anywhere), and chrony for those roles.
Re: (Score:2)
I don't have a problem with the idea of comunism. That does not mean it works.
Re: (Score:2)
Solaris has Service Manager, for example.
The problem is, everybody hates all of those alternate things. It doesn't matter if it's SM or launchd or systemd, they all suck worse than init because they cause problems.
Re: (Score:2)
I think there's just too many things unnecessarily built into systemd rather than it utilizing external, usually, already existing utilities. Does systemd really need, for example, NFS, DNS, NTP services built-in? Why can't it run as PID 2 and leave PID1 for init to simply reap orphaned processes? Would make it easier to restart or handle a failed systemd w/o rebooting the entire system (or so I've read).
I think you are confused.
Here is the service unit file for systemd-timesyncd [github.com] From this it should be quite apparent that:
1)No, systemd (the pid 1) isn't an NTP service. The systemd project includes a different time synchronisation service that is built using the systemd libraries to work better during sytemd boot under certain conditions [freedesktop.org] than other clients (such as ntpd, chronyd etc.) that work perfectly adequately with systemd under normal conditions.
2)The service doesn't run as root, but as a dedicated use
Re: (Score:1)
How dare you attack the great and perfect Emaos! Oh wait, you said Emacs? Never mind. Please return to your normal programing.