The motivation behind systemd (2018)
unixdigest.com
unixdigest.com
2) Support alternatives such as sysvinit, openrc, eudev with code and/or donations.
3) Support minimalist and console userspace software such as busybox, sysvinit, feh, fbpdf, support window managers that are still independent of *kit, support any platforms that big tech have no use of.
4) Encourage projects to stay independent of systemd, udev and, if possible, dbus too, although the dbus and udev battles are practically lost at this point.
5) Watch out for new dependencies being added to important projects such as xorg, gtk, qt, mesa, etc. and actively resist/oppose them.
6) Contribute to libraries that fake systemd/udev/dbus presence in a system and allow compiling dependent packages without actually having those packages installed.
7) Support mentainance of linux console! Fight to keep stuff such as scrollback buffer in the linux kernel.
8) If you really have lots of time, contribute to alternatives that sabotage big tech, such as ReactOS, OpenOffice, GIMP, etc.
And most importantly,
9) When you make a new website, support basic browsers without javascript (links, lynx, dillo, netsurf).10) When you make a new app, make it available as a download outside of a OS shop/market app.
Edit: My point is not that systemd is bad. I personally haven't had any issues with systemd. I would just like more competition to companies like RedHat so they don't end up controlling our computing like Microsoft and Google did.
I does so many things that you wonder why you have different applications for these things in other DEs or operating systems for that matter.
I'm not saying that good software has no bugs, but the kind of bugs reported tells much about the software.
I'm one of those troglodytes who still starts things from /etc/rc.d/rc.local
Since this is not the systemd way systemd sometimes decides that it can't terminate these on shutdown. And the timeout for shutting down rc.local stuff is infinite. This causes the occasional hang until hard reset. I can manually change the timeout to something else, but any update tends to put back the infinite timeout. I suppose I should learn how to do it the systemd way.
I have booted single user for the last decade, using startx to initiate the desktop environment. In Debian, it always worked, allowing me to observe the console output prior and address anything unusual before going gui. Switching to OpenSuse, the behavior is different, but I got start-xfce4 to work. Any obvious reasons this is different in OpenSuse? I've read that startx is deprecated, well, that and some interesting stuff about flat earth.
Oh, and a genuine systemd peeve; the infamous ctrl-alt-del burst nonsense, where rapid succession (x7) reboots the system, even with the screen locked (unless with physlock).
https://www.suse.com/releasenotes/i586/openSUSE/11.4/index.h...
In Debian it still works because Debian is slow with updates, but time is running.
Is there a clean, new method of configuring a persistent boot to cli? A link will do if an explanation is too much.
As someone who does not want to be paged at 03:14, I disagree.
Systemd is taking over as an interface. It's almost to Linux what Win32 is to NTDLL. Linux is still there, but more and more you can't code against the kernel, you have to code against systemd.
Systemd does not provide stable APIs. For that, a standarization process is required and has not been followed. Or at least a conservative approach to API and ABI, like Linux kernel itself has.
The whole thing is following a big ball of mud approach that has previously resulted in Linux distros having up to 5 sound APIs active at the same time. One of which is Lennart's work and getting obsolesced. (PulseAudio, much better written than systemd, by Pipewire. Because it cannot handle video and realtime.)
To achieve its aims it has to be actually good, well written, have a working minimal core feature set and be version compatible.
So far this has not happened for init.
If seriously, can someone explain to me the difference in attitude towards systemd and linux kernel? Almost all arguments against systemd stay valid, when applied to linux kernel, but I don't recall people campaining for decades to delete Linus and replace linux with Hurd or Minix3.
Is it a political thing? A cultural thing?
The article even mentions the elimination of seats on the linux foundation's board for "community" members, and the increase in seats allocated to corporate members.
The linux foundation today is pretty much completely controlled by corporate interests.
Linus is still the benevolent dictator, but as time passes, and Linus finally retires, unless something changes the future of control of the linux kernel will go farther and farther from it's roots as a user/contributor project in the "free software" spirit.
To provide a definition of the primary difference between "open source" and "free software" development models: Free software development is primarily by a group of users, for themselves and other users. Open source is a business model of using community s/w development for a project that is ultimately intended to be sold for profit.
One is development of software by a group of users for their use, the other is commercial product development. That's not to say that product development is inherently evil, but it does have very different objectives compared to s/w developed by users for their own use.
Linux started as a free software project where contributors were users, and has morphed into an open source product development project.
While searching through the systemd issues, i noticed various form of that issue (systemd spamming logs) still persist. And Lennart doing their "you are holding it wrong"... nothing has changed since Linus' rant.
I mean, Linus is not known for mincing words or avoiding beef either.
Is the style of personality (Linus/Lennart) at play?
I mean, this is some doctorate degree on internet sociology level of beef here.
My personal pet peeve is doing a `ps -elfH` and seeing systemd-ask-password at the leaf of a process tree just sitting there:
* https://www.freedesktop.org/software/systemd/man/latest/syst...
Why are asking for a password? Which password? For what service? Can I get the prompt for it somehow? Can I echo something to?
I've had this happen in the past with mysqld, and I had to resort to running /usr/sbin/mysqld from the CLI manually to get any kind of error or logging messages.
Not being able to list which components are enabled and not being able to format output of "list-units" for easy machine readability are close seconds.
I mean, if OpenStack guys has figured this out, self-proclaimed demigods of Linux can do that, amirite?
Seems like 'systemctl -o json list-units' might be what you want.
systemctl -o json list-units --type=service --state=active
I can add --terse for single line output to prevent adding jq to the pipe for processing that JSON.Maybe instead of writing a bit better code and actually documenting these options, they can just absorb jq as jsonctl, who knows.
Sorry, I kinda get angry when I encounter shenanigans like undocumented functionality, or hostile-replacing a daemon because they felt like replacing something really working well for the last 20ish years, just for fun, you know.
I don't want to tell anyone what to do.
The early fears of mission creep seem well founded to me. Among whatever wonders achieved by systemd, I'm personally disturbed by its increasing ubiquity. I was always extremely grateful for Linux and the many applications available. I also value consistency. I can't immediately name all the things that have changed, some better and some for worse, but Cron comes to mind, which I typically can't use on a systemd distro. Often, when looking up a forgotten command, it's now systemd or its cli interface systemctl that has replaced it. And I dread a situation where systemd and network-manger are my only options for wifi, which has been the case for me in opensuse, where connman, wpa-supplicant, iwd don't work and the good old days of making/etc/resolved immutable fail to preserve my DNS configuration. I know there are ways around this, but nothing easy so far for me.
Perhaps in the end it will all prove for the best. For now it seems systemd is eating Linux and without facetiousness, such distros could reasonably be renamed systemd-untu/ian/arch/etc.
I think the best course is to beat it back to where it was supposed to stay and restrain it there. Because I cannot predict the future and don't really know how all will unfold, I maintain two distros, one systemd and one openrc. This helps flatten the learning curve in the event systemd does eventually devour Linux, while allowing me to hold onto to something that is what seems, ie Linux - the creation that has been my stalwart companion for almost 20 years.
There is much I could say critical of systemd, but not with sufficient authority that it would be well received by either 'side'. I've read that, eg Debian, has made the endeavors if Devuan more onerous than would be expected by their original statements on the optionality of systemd. I've read a lot more, much that I don't fully understand and some that appears to make sense.
Foremost, it is the increasing pervasiveness of the beast that alarms me. It really is growing, and intended or not, dependencies are forming - and that's scheduled to be a problem.
Personally, I hope that others will hold out and support alternative distros, such as Alpine, Void, PCLinux, Gentoo, (Chimera?) and others, especially the standalone ones. Maybe systemd will consumate into something great, though I cannot presently foresee it.
See also, "wayland replaces X" for only the use cases tech bros know about.
When was the last time you actually saw a true multi-user system other than large corporate Citrix environments? Computers aren't expensive any more, every employee gets issued a laptop these days.
Developers go where users go, that's it.
Now. Yes, Employees all do have laptops, but the shared servers are beefy af.
although blaze builds didn't do the real work on your machine, but farmed it it to cloud machines.
[1] https://learn.microsoft.com/en-us/windows-hardware/design/de...
* Integrating systemd into Debian didn't cause any apparent disruption to the Debian release cycle (https://en.wikipedia.org/wiki/Debian#Sarge_and_later_release...). Meanwhile, according to TFA, forking Debian to keep not having systemd (when it already didn't) took longer than that release cycle, while starting most of the way through it. Any early adopters essentially missed an entire version.
* People who oppose systemd apparently would say things in 2018, and update them in 2023, like
> The latest invention by Lennart Poettering called systemd-homed is presented as a new way to handle home directories, whereas it really just is a way to get one step closer to eliminating /etc, which is something Red Hat has dreamed about for a long time.
while neither explaining why "eliminating /etc" would be a bad thing, nor evidencing such a "dream" (in an article that does evidence many other things), nor apparently noticing that /etc hadn't gone anywhere in those 5 years (and still hasn't - as I write this, there are nearly 2500 files recursively in my /etc). More generally, no explanation is forthcoming about how "development... [being] almost completely hijacked by major companies" has resulted in any actual harmful effect on the software.
The FOSS world had the choice to discriminate against corporate interests; instead, for years I listened to arguments about why I shouldn't be able to make my software et gratis et libre to hobbyists while charging a substantial fee to businesses, and about how this is incompatible with what they were trying to do (as explained by the OSI).
* Relatedly, the apparent evidence that "Red Hat wants to become the next Microsoft Windows" consists of systemd supposedly helping to "make desktop systems like GNOME function like Microsoft Windows.", and that Poettering wants Linux to be able to run on all hardware and not have "pointless differences between distributions".
If I need to think about which distribution I'm using, I think it's only fair for it to make meaningful differences; if I hop distros, why would I want to run into arbitrary and capricious road bumps?
As for GNOME, I have to wonder if the author has used that software. And again, I don't understand why it should be a bad thing if, e.g., Cinnamon provides a (vaguely) Windows-like UI. (Never mind that this is a case where the actual GNOME product had to be forked to actually "make it function like Microsoft Windows"!)
* End users are, in all likelihood, not running into the supposed issues with systemd as software (I haven't) while having a poor experience with a bunch of application-level stuff that gets very little support. (Speaking of GNOME - I especially have had a poor experience with their stuff. And one of the biggest reasons I'd consider switching away from Mint is to avoid the feeling of vendor lock-in I'm getting from it.)
----
tl;dr: systemd opponents tend to come across to me as conspiracy theorists - legit, by-the-book definition ones, who allege a secret (albeit not that secret) plan by a group (Microsoft, RedHat, and collaborators at various other distros) to do something harmful. The problem is, they seem to be terrible at describing the harm they apparently see as self-evident, while paying less attention to other serious problems in the Linux world unrelated to systemd. That doesn't make their argument less valid, but it does make me very much less inclined to care about it.
I find that if you actually take the time to try to understand what the goals behind systemd features are and read the mailing list discussions, without hopping on the conspiracy train, I find a lot of really good ideas.
Sure, systemd has issues, but systemd is similar to Git in that regard. The software has issues, but the foundational concepts are solid.
(Tangent: Wayland is also similar. The protocol is fine, but Wayland's issue is that it replaces 90% of the features that users need from X with nothing, and forcing other people to fill in the feature gap they created.)
Some day our society may grow up to have information-consumption standards, may recognize dangled dog whistling bait for it's low quality self. Some day. I hope. Please, maybe.