hckrnws
1) Support Gentoo, Alpine and *BSD, especially with code and/or donations.
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,
10) When you make a new app, make it available as a download outside of a OS shop/market app.
This is why more competition like System76 is important in Linux space. GNOME is pretty much a corporate controlled GUI. It sucks so much if you want to do anything advanced or productive (I use GNOME by the way). That is why I am excited for projects like COSMIC, Nix etc.
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 just wish they had invested in kde which always was a good gnome competitor. Instead they put more lipstick on gnome.
The article doesn't mention this: systemd is not well written software, and far from behaving robust and consistently. Take some time, look through the currently open issues on Github, see for yourself whether you consider this stable software. Machine hanging indefinitely during poweroff/reboot is one of the classics.
I'm not saying that good software has no bugs, but the kind of bugs reported tells much about the software.
> Machine hanging indefinitely during poweroff/reboot ...
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.
Fellow Troglodyte,
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).
The startx thing is mentioned (with a fix) in the release notes for 11.4 which I presume is when openSUSE made the change:
https://www.suse.com/releasenotes/i586/openSUSE/11.4/index.h...
Thanks
Yes, plain startx has stopped working from upstream defaults. I think it was related to Xorg now having to talk to seatd (or alternatives) to get access to the input/video devices.
In Debian it still works because Debian is slow with updates, but time is running.
I'll justify asking here because the thread is dead, it seems, probably the "2018".
Is there a clean, new method of configuring a persistent boot to cli? A link will do if an explanation is too much.
There isn't a single thing in the Linux ecosystem that is "stable". (And that's a good thing.)
How can you say its a good thing? I have 6 Laptops that cannot boot 6.0ff Linux due to kernel regressions. I'm running out of devices that can run Linux without crashing.
Isn't this quite the hot take? The situation is not that bad, at least in stable distributions like Debian.
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.
Yes, and? I'm supposed to be outraged at a good thing finally happening to Linux?
Where's the good thing? In making POSIX even more of a joke? In providing low quality "chase this API" target? In enforced obsolescence?
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.
I don't want or need these kinds of "standards".
> (And that's a good thing.)
As someone who does not want to be paged at 03:14, I disagree.
"Stability" has nothing to do with reliability. "Stability" is the ossification of worst practices due to corporate dysfunction. Some of the least reliable systems are also 100 percent "stable".
Great, a public bug tracker!</s>
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 Linux kernel is much stricter about hacky patches and regressions. This has led to beef between the kernel and system developers in the past. The famous "I'm f*cking tired of your code" was directed at a systemd developer.
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.
Approach to the project maintenance really seems to be a significant difference, thank you. It would not account for most of the early attacks (when systemd was not adopted so wildly yet), nor the types of arguments ("unix philosophy", or "corporate takeover" like in this article)
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.
When systemd broke tmux (which isn't a Linux project, but ported from OpenBSD) and instead of reverting or fixing their own bug, systemd devs went to the OpenBSD folks and asked them to work around the bug that they caused themselves. This is ragebait-level insolence:
The criticisms also apply to the linux kernel.
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.
I’ll take it over bash scripts any day. I’ve never had a single issue in production for years
This comment is always made in every single systemd thread, and it is and always was a false dichotomy.
Absolutely true. As a counterpoint, we had Bash scripts for years in production, and never had any problems, either.
Yeah it is, but I’m not aware of a good alternative that is widely used and supported
You didn't have any issues, so you never had the pain of diagnosing some systemd-related problem.
> You didn't have any issues, so you never had the pain of diagnosing some systemd-related problem.
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.
systemd fighting against other daemons without any warnings and error messages is my absolute favorite.
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?
> not being able to format output of "list-units" for easy machine readability are close seconds.
Seems like 'systemctl -o json list-units' might be what you want.
While it's noted that it's undocumented behavior (-o is non-existent in systemctl man page), so it might go away tomorrow, it's not a bad start. However what I want is more like
systemctl -o json list-units --type=service --state=active
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.
As of systemd 252, this is undocumented functionality. -o is only specified for systemctl status.
I noticed that, tried it anyway, and it worked. Would probably be helpful if it was properly documented.
This always ends up being a sore subject.
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.
The conspiracy I follow is systemd is the result of a bunch of noobs trying to duplicate the Mac experience on linux. Such as the focus on laptop over traditional multi-user systems. And a desire to minimize boot time.
See also, "wayland replaces X" for only the use cases tech bros know about.
It's not a conspiracy when they are more or less open about what their goals are.
I think GP was trying to be sarcastic. Or else, what exactly is supposed to be bad about trying to minimize boot time?
there is a bit of sarcasm in there, but most server and desktop machines stay on all the time. Amortized over 1000 days of uptime, that 30 second boot time is not worth messing with.
Microsoft broke suspend to ram with its Modern Standby [1] around 5 years ago. So fast boot times is a thing again )
[1] https://learn.microsoft.com/en-us/windows-hardware/design/de...
> Such as the focus on laptop over traditional multi-user systems.
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.
There are many multi user systems still in use. Think HPC, universities, places where the security requirements do not allow code / data to be shared by access from a users laptop. Operations vs. Development. Operations is much more likely to be multi-user.
> When was the last time you actually saw a true multi-user system other than large corporate Citrix environments?
Now. Yes, Employees all do have laptops, but the shared servers are beefy af.
At least at Google ~10 years ago, the dev laptops were used to SSH into beefy workstations where all the real work gets done.
~5 years ago, you SSH'ed into your Linux workstation under your desk, or your equivalent VM.
although blaze builds didn't do the real work on your machine, but farmed it it to cloud machines.
Developers are users. Stop forgetting that.
A few thoughts as to why systemd is as tolerated as it is:
* 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.
The reason eliminating writable /etc is a good thing is that it enables read-only system installs like SteamOS and Fedora Silverblue. Read-only OSes are amazing for stability, reproducibility, and recoverability.
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.)
Wayland also killed hobbyist window managers, pretty much like systemd kills Linuxes based on other init systems.
This post presents nearly no bona-fides and is a massive wall of conspiracy minded thinking. It casts the anti-systemd faction in a terrible immature light.
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.
[dead]
Crafted by Rajat
Source Code