I think Josh addresses a good point here: systemd provides features that distributions want, but other init systems are actively calling non-features. That’s a classic culture clash, and it shows in the systemd debates - people hate it or love it (FWIW, I love it). I’m also highly sympathetic to systemd’s approach of shipping a software suite.
Still, it’s always important to have a way out of a component. But the problem here seems to be that the scope of an init system is ill-defined and there’s fundamentally different ideas where the Linux world should move. systemd moves away from the “kernel with rather free userspace on top” model, others don’t agree.
What I find so confusing - and please know this comes from a “BSD guy” and a place of admitted ignorance - is that it seems obvious the natural conclusion of these greater processes must be that “Linux” is eventually something closer to a complete operating system (not a bazaar of GNU/Linux distributions). This seems to be explicitly the point.
Not only am I making no value judgement on that outcome, but I already live in that world of coherent design and personally prefer it. I just find it baffling to watch distributions marching themselves towards it.
But it does create a monoculture. What if you want to run service x on BSD or Redox or Haiku. A lot of Linux tools can be compiled on those operating systems with a little work, sometimes for free. If we start seeing hard dependencies on systemd, you’re also hurting new-OS development. Your service wont’ be able to run in an Alpine docker container either, or on distributions like Void Linux, or default Gentoo (although Gentoo does have a systemd option; it too is in the mess of supporting both init systems).
We’ve had wildly divergent Unix and Unix-like systems for years. Haiku and Mac OS have no native X11. BSDs and System V have different init systems, OpenBSD has extended libc for security reasons. Many System V based OSes (looking at you, AIX) take POSIX to malicious compliance levels. What do you think ./configure is supposed to do if not but cope with this reality?
Has anyone considered or proposed something like systemd’s feature set but portable to more than just linux? Are BSD distros content with SysV-style init?
A couple of pedantic nits. BSDs aren’t distros. They are each district operating systems that share a common lineage. Some code and ideas are shared back and forth, but the big 3, FreeBSD, NetBSD and OpenBSD diverged in the 90s. 1BSD was released in 1978. FreeBSD and NetBSD forked from 386BSD in 1993. OpenBSD from NetBSD in 1995. So that’s about 15 years, give or take, of BSD before the modern BSDs forked.
Since then there has been 26 years of separate evolution.
It’s true that systemd is comparatively featureful, and I’ll extend your notion of shipping a software suite by justifying some of its expansion into other aspects of system management in terms of it unifying a number of different concerns that are pretty coupled in practice.
But, and because of how this topic often goes, I feel compelled to provide the disclaimer that I mostly find systemd just fine to use on a daily basis: as I see it, the problem, though, isn’t that it moves away from the “free userspace” model, but that its expansion into other areas seems governed more by political than by technical concerns, and with that comes the problem that there’s an incentive to add extra friction to having a way out. I understand that there’s a lot of spurious enmity directed at Poettering, but I think the blatant contempt he’s shown towards maintaining conventions when there’s no cost in doing so or even just sneering at simple bug reports is good evidence that there’s a sort of embattled conqueror’s mindset underlying the project at its highest levels. systemd the software is mostly fine, but the ideological trajectory guiding it really worries me.
I’m also highly sympathetic to systemd’s approach of shipping a software suite.
What do you mean here? Bulling all distro maintainers until they are forced to setup your software as default, up to the point of provoking the suicide of people who don’t want to? That’s quite a heavy sarcasm you are using here.
How was anyone bullied into running systemd? For Arch Linux this meant we no longer had to maintain initscripts anymore and could rely on systemd service files which are a lot nicer. In the end it saved us work and that’s exactly what systemd tries to be a toolkit for initscripts and related system critical services and now also unifying Linux distro’s.
huh? Red Hat and Poettering strongarmed distribution after distribution and stuffed the debian developer ballots. This is all a matter of the public record.
I don’t think skade intended to be sarcastic or combative. I personally have some gripes with systemd, but I’m curious about that quote as well.
I read the quote as being sympathetic towards a more unified init system. Linux sometimes suffers from having too many options (a reason I like BSD). But I’m not sure if that was the point being made
I value pieces that are intended to work well together and come from the same team, even if they are separate parts. systemd provides that. systemd has a vision and is also very active in making it happen. I highly respect that.
I also have gripes with systemd, but in general like to use it. But as long as no other project with an attitude to move the world away from systemd by being better and also by being better at convincing people, I’ll stick with it.
I interpreted it as having fewer edges where you don’t have control. Similar situations happen with omnibus packages that ship all dependencies and the idea of Docker/containers. It makes it more monolithic, but easier to not have to integrate with every logging system or mail system.
If your philosophy of Linux is Legos, you probably feel limited by this. If you philosophy is platform, then this probably frees you. If the constraints are doable, they often prevent subtle mistakes.
As much as I hate to sound negative: I think the ship has sailed already. systemd is the de-facto standard system layer (not just init system) like glibc is the de-facto standard libc. Other options may exist, but they’re the path of vastly higher resistance. Application developers will jump on the abstractions that systemd provides and for good reason: Linux+glibc doesn’t provide the primitives you want to write a modern application.
Pushing against systemd is just delaying the inevitable. It’s here to stay, it’s got everyone (Debian, Ubuntu, Fedora, RHEL, openSUSE, SLES) on board now, and there’s compelling technical no reason to jump off. I don’t like it, but I’ve come to terms with it and its idiosyncrasies, even if I’d have preferred to start with either a port of SMF or launchd instead of yet another reinvented wheel. Trivializing systemd to “just” an init system also misses the whole point of what systemd has become—a higher layer of abstraction for the entire system.
We’ve lost the IPC war (instead of creating a more kernel-integrated solution in the wider *NIX ecosystem, DBus over UNIX domain sockets has won as the message passing IPC), it’s just a matter of time until we’re going to lose the system layer war. What other *NIX-likes like the BSDs and illumos will do when the inevitable systemdization of the desktop comes, I don’t know, but it’s likely not going to be pretty to be on the receiving end.
Every time systemd “debate” comes up, I point people to this wonderful talk, by a self proclaimed ‘BSD guy.’ It’s really good, and if you have any opinion at all on systemd, it’s absolutely worth giving a watch (or five like I have).
It is a good talk, and he makes a lot of good points about having a solid system layer. I’m kinda curious what various BSD communities are thinking about when it comes to making a system layer. Has it just been this guy or have there been any core developers on the FreeBSD or OpenBSD teams that have had discussions about implementing a system layer?
I feel like all these systemd features could just be different projects instead of systemd modules, and have some kind of contracts within dbus so a service can say “I want a temp file” and dbus can say “I have a registered tmp file provider” and then the service can send a standard structured message saying what kind of file they need, the ACLs, etc, and the provider hand it back a bunch of file descriptors.
Like instead of these things being added to systemd, go more the Java route of “here are all our interfaces” and “here are the systemd implementations.” That way you could say swap out the tempfile service with one that keeps the backend in Reddis or memory instead of actual files. It’d actually be a heavier implementation in some ways, but it would be much more standardized.
some kind of contracts within dbus so a service can say “I want a temp file” and dbus can say “I have a registered tmp file provider”
THIS! This is precisely the level of unnecessary abstraction that baffles decent people. This is the root of all evil. It drives me crazy and very angry. How can a “registered tmp file provider” be a socially acceptable idea? We have tmpfile(3) and mkstemp(3), and they work very well, and they have direct interfaces in any programming language. Why do some folks want to break such beauty with useless abstractions? Why would you want to start a “negotiation” or a “contract” with dbus just for a damn temporary file?
We have tmpfile(3) and mkstemp(3), and they work very well, and they have direct interfaces in any programming language. Why do some folks want to break such beauty with useless abstractions?
Coming from a microkernel point of view, I actually sympathize to some extent.
Having small services take care of miscellaneous tasks is advantageous because of the single-responsibility principle. Additionally, assuming you take DBus for granted as a universal interface everywhere, it helps you skirt around OSes where mkstemp(3) and tmpfile(3) don’t exist for whatever reason since it’s now no longer your problem. Finally, the same thing as with shared libraries applies: Fix a bug once, fix it everywhere, and you can’t evade the rule this time because you can’t statically link against DBus services.
That said, a temp file DBus service in particular seems like overkill.
assuming you take DBus for granted as a universal interface everywhere, it helps you skirt around OSes where mkstemp(3) and tmpfile(3) don’t exist
Do such systems exist outside of your imagination? How could some system support dbus and not common posix features? I find the opposite case quite often: on bsd and minimal systems, I make a point to avoid dbus at all costs.
I’m glad to hear that. I’ve been using Gentoo since 2012 and I really appreciate their dedication towards init-system-diversity.
The Debian developers were optimistic and kind-hearted in regard to systemd, hoping that it would not expand further despite having a monopoly. The systemd developers seized more and more control, suffocating more and more aspects of the user space below it.
Does systemd work? Yes. Does it work better than sysvinit? Definitely. But this is not the point! The point is that it should not matter which init system you run when trying to run a desktop environment or something else high in user space. Systemd has become too complicated and a huge baggage. Another matter is that systemd drastically increases Red Hat’s influence on the Linux ecosystem in general. Wasn’t pulseaudio enough?
The approach to possibly adopt elogind is a good thing. It brings many technological advances brought by systemd, but keeps it manageable and well-separated; as it should be.
I read this the other way around, more as a move that might end token init-system diversity because it’s a large burden with few people interested in doing the work. (Which, might be argued, proves the point of those claiming systemd’s non-modular approach results in “embrace extend extinguish”.)
Systemd has become too complicated and a huge baggage.
I was thinking about this recently, and was surprised to realize that there hasn’t ever been a major fork or reimplementation of systemd, desipte Lennart claiming that the concept is modular…
there is, e.g. elogind is a fork of systemd-logind.
Or what would you consider “fork”? After all “systemd” is just like “KDE” or “OpenBSD”, a project developing on many different pieces of software, so it’s not like you can fork it — you can fork individual parts, like you can fork KDE’s Plasma desktop, or systemd’s login daemon, or OpenBSD’s SSH server.
The entire debate about systemd fascinates me as an expression of FLOSS culture. The way I see it, systemd is a boon for two classes of users - the few who manage huge amounts of “machines” (i.e. “the cloud”), and the many who use Linux as a workstation or on a laptop, where they seldom have any reason to bother about how a service starts, or is scheduled.
The class of users who don’t like systemd seem to be the Mittelstand - the sysadmin of a few dozen machines, the user of a VPS who manages a lot of their own services to participate in the open web. They’re reliant on the “folk wisdom” of their own experience, and the substrate of blog and forum posts explaining how to set stuff up. Having to learn a new way of dealing with this stuff feels unnecessary - it worked fine before! The issues that systemd is set up to deal with have never impacted them.
had a few problems with systemd in the cloud that wouldn’t have happened with other init systems
I don’t care about startup time anywhere, but I also don’t use autoscaling
my laptop shuts down slower now
if you have bare metal, the 20s saved with systemd don’t compare to the 3min RAM check…
Overall systemd solved all the problems I never had. Not as a laptop user, not as a small-scale system admin, but ok - I didn’t work with cloud stuff before it happened.
You shut your laptop down? I haven’t turned a laptop off (until I sell it) in a decade. They crash from time to time, and restart for updates, but I can’t think of a reason to turn one off unless you’re selling it or putting it into storage.
my private laptops: I use them once or twice a month, why would I keep all 3 (one is very old and only used every few months) of them running all the time?
Even without a RAM check, a typical HP server still takes a good minute or two to POST and then prepare all of the firmwares for things like HBAs, NICs, sensors, RAID arrays etc before you even get as far as the operating system bootloader. I imagine the same to be true on most “server-grade” tin.
I am in “the user of a VPS” category myself and I use Debian. I had some experience of writing init scripts and I am glad I don’t have to do this anymore.
I also happen to SRE a huge Linux fleet at work, which uses a custom task supervisor written before systemd.
I am all for more diversity and experimentation in init systems (e.g. one written in Rust would be great to experiment with, given a well-defined format for service files).
I also happen to SRE a huge Linux fleet at work, which uses a custom task supervisor written before systemd.
I see this once in awhile and always wonder why. Enterprise distros since RHEL 6 (released in 2011!) ship with upstart as an init system, which is a great process manager. I don’t understand the need for installing yet another process manager.
I’ve recently switched to Devuan for some of my systems, and the possibility of running something simpler and less pervasive than systemd would make me reconsider.
On my laptop I’m running Fedora, so systemd, but it was never a problem anyway.
On my laptop I’m running Fedora, so systemd, but it was never a problem anyway.
why is it a problem on the server then? IMHO, juggling daemons on a desktop workstation is much more involved that on a server where you mostly fire-and-forget a very limited amount of daemons and where normally there aren’t even any users logged in.
Those systems are not powerful servers. They’re small and limited devices, that I’d like to keep as simple as I can. I try to keep the set of installed software minimal, basically :)
I was just reading about init-system diversity within NixOS. I was wondering if anyone could provide a few links detailing the Red Hat connection to systemd? Thanks in advance!
Lennart Poettering, the principal author of systemd works for Red Hat. Yes, the same Red Hat that has been running a Linux distribution since 1995 and contributes a lot of code to the Linux kernel.
I haven’t been following all this too closely, so I found this quite surprising:
If we’re really going to continue to fully support sysvinit, […]
While I’m a systemd fan myself I can understand why some folks might want a non-systemd init system, but if in Debian that means sysvinit, well, no wonder nobody wants to do that work. I hope the Debian folks can find a way to be rid of it.
I think Josh addresses a good point here: systemd provides features that distributions want, but other init systems are actively calling non-features. That’s a classic culture clash, and it shows in the systemd debates - people hate it or love it (FWIW, I love it). I’m also highly sympathetic to systemd’s approach of shipping a software suite.
Still, it’s always important to have a way out of a component. But the problem here seems to be that the scope of an init system is ill-defined and there’s fundamentally different ideas where the Linux world should move. systemd moves away from the “kernel with rather free userspace on top” model, others don’t agree.
Since systemd is Linux-only, no one who wants to be portable to, say, BSD (which I think includes a lot of people) can depend on its features anyway.
Which is why I wrote “Linux world” and not “Unix world”.
systemd has a vision for Linux only and I’m okay with that. It’s culture clashing, I agree.
What I find so confusing - and please know this comes from a “BSD guy” and a place of admitted ignorance - is that it seems obvious the natural conclusion of these greater processes must be that “Linux” is eventually something closer to a complete operating system (not a bazaar of GNU/Linux distributions). This seems to be explicitly the point.
Not only am I making no value judgement on that outcome, but I already live in that world of coherent design and personally prefer it. I just find it baffling to watch distributions marching themselves towards it.
But it does create a monoculture. What if you want to run service x on BSD or Redox or Haiku. A lot of Linux tools can be compiled on those operating systems with a little work, sometimes for free. If we start seeing hard dependencies on systemd, you’re also hurting new-OS development. Your service wont’ be able to run in an Alpine docker container either, or on distributions like Void Linux, or default Gentoo (although Gentoo does have a systemd option; it too is in the mess of supporting both init systems).
We’ve had wildly divergent Unix and Unix-like systems for years. Haiku and Mac OS have no native X11. BSDs and System V have different init systems, OpenBSD has extended libc for security reasons. Many System V based OSes (looking at you, AIX) take POSIX to malicious compliance levels. What do you think
./configureis supposed to do if not but cope with this reality?Has anyone considered or proposed something like systemd’s feature set but portable to more than just linux? Are BSD distros content with SysV-style init?
A couple of pedantic nits. BSDs aren’t distros. They are each district operating systems that share a common lineage. Some code and ideas are shared back and forth, but the big 3, FreeBSD, NetBSD and OpenBSD diverged in the 90s. 1BSD was released in 1978. FreeBSD and NetBSD forked from 386BSD in 1993. OpenBSD from NetBSD in 1995. So that’s about 15 years, give or take, of BSD before the modern BSDs forked.
Since then there has been 26 years of separate evolution.
The BSDs also use BSD init, so it’s different from SysV-style. There is a brief overview here: https://en.m.wikipedia.org/wiki/Init#Research_Unix-style/BSD-style
I think the answer to that is yes and no. Maybe the closets would be (open) solaris smf. Or maybe GNU Shepherd or runit/daemontools.
But IMNHO there are no good arguments for the sprawl/feature creep of systemd - and people haven’t tried to copy it, because it’s flawed.
It’s true that systemd is comparatively featureful, and I’ll extend your notion of shipping a software suite by justifying some of its expansion into other aspects of system management in terms of it unifying a number of different concerns that are pretty coupled in practice.
But, and because of how this topic often goes, I feel compelled to provide the disclaimer that I mostly find systemd just fine to use on a daily basis: as I see it, the problem, though, isn’t that it moves away from the “free userspace” model, but that its expansion into other areas seems governed more by political than by technical concerns, and with that comes the problem that there’s an incentive to add extra friction to having a way out. I understand that there’s a lot of spurious enmity directed at Poettering, but I think the blatant contempt he’s shown towards maintaining conventions when there’s no cost in doing so or even just sneering at simple bug reports is good evidence that there’s a sort of embattled conqueror’s mindset underlying the project at its highest levels. systemd the software is mostly fine, but the ideological trajectory guiding it really worries me.
What do you mean here? Bulling all distro maintainers until they are forced to setup your software as default, up to the point of provoking the suicide of people who don’t want to? That’s quite a heavy sarcasm you are using here.
Link?
How was anyone bullied into running systemd? For Arch Linux this meant we no longer had to maintain initscripts anymore and could rely on systemd service files which are a lot nicer. In the end it saved us work and that’s exactly what systemd tries to be a toolkit for initscripts and related system critical services and now also unifying Linux distro’s.
huh? Red Hat and Poettering strongarmed distribution after distribution and stuffed the debian developer ballots. This is all a matter of the public record.
Link? This is the first time I am hearing about it.
I’m also confused, I followed the Debian process, and found it very through and good. The documents coming out of it are still a great reference.
I don’t think skade intended to be sarcastic or combative. I personally have some gripes with systemd, but I’m curious about that quote as well.
I read the quote as being sympathetic towards a more unified init system. Linux sometimes suffers from having too many options (a reason I like BSD). But I’m not sure if that was the point being made
Edit: grammar
I value pieces that are intended to work well together and come from the same team, even if they are separate parts. systemd provides that. systemd has a vision and is also very active in making it happen. I highly respect that.
I also have gripes with systemd, but in general like to use it. But as long as no other project with an attitude to move the world away from systemd by being better and also by being better at convincing people, I’ll stick with it.
I interpreted it as having fewer edges where you don’t have control. Similar situations happen with omnibus packages that ship all dependencies and the idea of Docker/containers. It makes it more monolithic, but easier to not have to integrate with every logging system or mail system.
If your philosophy of Linux is Legos, you probably feel limited by this. If you philosophy is platform, then this probably frees you. If the constraints are doable, they often prevent subtle mistakes.
As much as I hate to sound negative: I think the ship has sailed already. systemd is the de-facto standard system layer (not just init system) like glibc is the de-facto standard libc. Other options may exist, but they’re the path of vastly higher resistance. Application developers will jump on the abstractions that systemd provides and for good reason: Linux+glibc doesn’t provide the primitives you want to write a modern application.
Pushing against systemd is just delaying the inevitable. It’s here to stay, it’s got everyone (Debian, Ubuntu, Fedora, RHEL, openSUSE, SLES) on board now, and there’s compelling technical no reason to jump off. I don’t like it, but I’ve come to terms with it and its idiosyncrasies, even if I’d have preferred to start with either a port of SMF or launchd instead of yet another reinvented wheel. Trivializing systemd to “just” an init system also misses the whole point of what systemd has become—a higher layer of abstraction for the entire system.
We’ve lost the IPC war (instead of creating a more kernel-integrated solution in the wider *NIX ecosystem, DBus over UNIX domain sockets has won as the message passing IPC), it’s just a matter of time until we’re going to lose the system layer war. What other *NIX-likes like the BSDs and illumos will do when the inevitable systemdization of the desktop comes, I don’t know, but it’s likely not going to be pretty to be on the receiving end.
Every time systemd “debate” comes up, I point people to this wonderful talk, by a self proclaimed ‘BSD guy.’ It’s really good, and if you have any opinion at all on systemd, it’s absolutely worth giving a watch (or five like I have).
it’s spelled “systemd” ;-)
Or sÿstëmd because it’s always a high holiday 🙃
The fact that there’s a whole section about using the name on their website is awfully telling.
oof, fixed
Missed one:
not all instances :)
Is there a good synopsis, or transcript, of it anywhere?
Not that I know of unfortunately. It works well enough to just throw it on in the background though :)
For me it just doesn’t. I get back to concentrating on code or whatever else and realize I haven’t heard anything.
That was a great watch, thanks!
It is a good talk, and he makes a lot of good points about having a solid system layer. I’m kinda curious what various BSD communities are thinking about when it comes to making a system layer. Has it just been this guy or have there been any core developers on the FreeBSD or OpenBSD teams that have had discussions about implementing a system layer?
I feel like all these systemd features could just be different projects instead of systemd modules, and have some kind of contracts within dbus so a service can say “I want a temp file” and dbus can say “I have a registered tmp file provider” and then the service can send a standard structured message saying what kind of file they need, the ACLs, etc, and the provider hand it back a bunch of file descriptors.
Like instead of these things being added to systemd, go more the Java route of “here are all our interfaces” and “here are the systemd implementations.” That way you could say swap out the tempfile service with one that keeps the backend in Reddis or memory instead of actual files. It’d actually be a heavier implementation in some ways, but it would be much more standardized.
THIS! This is precisely the level of unnecessary abstraction that baffles decent people. This is the root of all evil. It drives me crazy and very angry. How can a “registered tmp file provider” be a socially acceptable idea? We have tmpfile(3) and mkstemp(3), and they work very well, and they have direct interfaces in any programming language. Why do some folks want to break such beauty with useless abstractions? Why would you want to start a “negotiation” or a “contract” with dbus just for a damn temporary file?
Coming from a microkernel point of view, I actually sympathize to some extent.
Having small services take care of miscellaneous tasks is advantageous because of the single-responsibility principle. Additionally, assuming you take DBus for granted as a universal interface everywhere, it helps you skirt around OSes where mkstemp(3) and tmpfile(3) don’t exist for whatever reason since it’s now no longer your problem. Finally, the same thing as with shared libraries applies: Fix a bug once, fix it everywhere, and you can’t evade the rule this time because you can’t statically link against DBus services.
That said, a temp file DBus service in particular seems like overkill.
Do such systems exist outside of your imagination? How could some system support dbus and not common posix features? I find the opposite case quite often: on bsd and minimal systems, I make a point to avoid dbus at all costs.
I’m glad to hear that. I’ve been using Gentoo since 2012 and I really appreciate their dedication towards init-system-diversity.
The Debian developers were optimistic and kind-hearted in regard to systemd, hoping that it would not expand further despite having a monopoly. The systemd developers seized more and more control, suffocating more and more aspects of the user space below it.
Does systemd work? Yes. Does it work better than sysvinit? Definitely. But this is not the point! The point is that it should not matter which init system you run when trying to run a desktop environment or something else high in user space. Systemd has become too complicated and a huge baggage. Another matter is that systemd drastically increases Red Hat’s influence on the Linux ecosystem in general. Wasn’t pulseaudio enough?
The approach to possibly adopt elogind is a good thing. It brings many technological advances brought by systemd, but keeps it manageable and well-separated; as it should be.
I read this the other way around, more as a move that might end token init-system diversity because it’s a large burden with few people interested in doing the work. (Which, might be argued, proves the point of those claiming systemd’s non-modular approach results in “embrace extend extinguish”.)
I was thinking about this recently, and was surprised to realize that there hasn’t ever been a major fork or reimplementation of systemd, desipte Lennart claiming that the concept is modular…
there is, e.g. elogind is a fork of systemd-logind.
Or what would you consider “fork”? After all “systemd” is just like “KDE” or “OpenBSD”, a project developing on many different pieces of software, so it’s not like you can fork it — you can fork individual parts, like you can fork KDE’s Plasma desktop, or systemd’s login daemon, or OpenBSD’s SSH server.
There was uselessd and a few others I can’t find now. They’re all abandoned though.
https://github.com/abandonware/uselessd
The entire debate about systemd fascinates me as an expression of FLOSS culture. The way I see it, systemd is a boon for two classes of users - the few who manage huge amounts of “machines” (i.e. “the cloud”), and the many who use Linux as a workstation or on a laptop, where they seldom have any reason to bother about how a service starts, or is scheduled.
The class of users who don’t like systemd seem to be the Mittelstand - the sysadmin of a few dozen machines, the user of a VPS who manages a lot of their own services to participate in the open web. They’re reliant on the “folk wisdom” of their own experience, and the substrate of blog and forum posts explaining how to set stuff up. Having to learn a new way of dealing with this stuff feels unnecessary - it worked fine before! The issues that systemd is set up to deal with have never impacted them.
Disagree. I am exactly a user of all 3 groups and
Overall systemd solved all the problems I never had. Not as a laptop user, not as a small-scale system admin, but ok - I didn’t work with cloud stuff before it happened.
You shut your laptop down? I haven’t turned a laptop off (until I sell it) in a decade. They crash from time to time, and restart for updates, but I can’t think of a reason to turn one off unless you’re selling it or putting it into storage.
work laptop: true, I usually don’t shut it down
my private laptops: I use them once or twice a month, why would I keep all 3 (one is very old and only used every few months) of them running all the time?
Who runs a RAM check in the modern world? Seems like a complete waste of time to me.
(Feel free to convince me otherwise - I’m always open to persuasive arguments!)
Even without a RAM check, a typical HP server still takes a good minute or two to POST and then prepare all of the firmwares for things like HBAs, NICs, sensors, RAID arrays etc before you even get as far as the operating system bootloader. I imagine the same to be true on most “server-grade” tin.
I am in “the user of a VPS” category myself and I use Debian. I had some experience of writing init scripts and I am glad I don’t have to do this anymore.
I also happen to SRE a huge Linux fleet at work, which uses a custom task supervisor written before systemd.
I am all for more diversity and experimentation in init systems (e.g. one written in Rust would be great to experiment with, given a well-defined format for service files).
I see this once in awhile and always wonder why. Enterprise distros since RHEL 6 (released in 2011!) ship with upstart as an init system, which is a great process manager. I don’t understand the need for installing yet another process manager.
I’ve recently switched to Devuan for some of my systems, and the possibility of running something simpler and less pervasive than systemd would make me reconsider.
On my laptop I’m running Fedora, so systemd, but it was never a problem anyway.
why is it a problem on the server then? IMHO, juggling daemons on a desktop workstation is much more involved that on a server where you mostly fire-and-forget a very limited amount of daemons and where normally there aren’t even any users logged in.
SystemD is a problem on the server because of the problems it has caused me there.
Those systems are not powerful servers. They’re small and limited devices, that I’d like to keep as simple as I can. I try to keep the set of installed software minimal, basically :)
I was just reading about init-system diversity within NixOS. I was wondering if anyone could provide a few links detailing the Red Hat connection to systemd? Thanks in advance!
Lennart Poettering, the principal author of systemd works for Red Hat. Yes, the same Red Hat that has been running a Linux distribution since 1995 and contributes a lot of code to the Linux kernel.
I haven’t been following all this too closely, so I found this quite surprising:
While I’m a systemd fan myself I can understand why some folks might want a non-systemd init system, but if in Debian that means sysvinit, well, no wonder nobody wants to do that work. I hope the Debian folks can find a way to be rid of it.