I've never seen it approached with that kind of incompetence, in my professional life. Embedded is a system thing, not a hardware thing. You pick the system that will work. Ignoring the software side of things is ignoring the majority of the problem in embedded work. I would have agreed with you 20 years ago, but it's 2024, and why RPI is so often used for prototyping.
RPI is often useful for prototyping because it is cheap enough, but if you are not a very large company nobody will talk to you. This is both you can't get support from Broadcom, and worse your supply management cannot get contract signed (for small companies this doesn't matter you take what you can get, but larger companies often demand better support than they can get from pi)
That’s actually a great lesson in optimizing your product for adoption.
the trick in both cases is to know your customers!
This is a common pattern by the way. But easily the most irritating thing for me is the simple issue that you used to be able to just go to /var/log/lastlog to see what failed during the last boot and that just the other day I had to spend hours figuring what broke in the system that made journalctl not log properly. In the end I had to reinstall all currently installed packages.
https://www.reddit.com/r/archlinux/comments/zczdnq/systemctl...
For the last boot you can use "journalctl -b -1" as long as you enabled persistent logs. If you ended up reinstalling everything, I don't think we can say whether that was a systemd related issue or not.
I was curious what the current daily issues are.
I don't understand how you can read someone telling you that they want to suspend and then hibernate after a set duration, but A) not understand why this would be desirable, B) not understand that this is compatible with also hibernating at low battery, and C) not understand your own lack of comprehension.
Hyperbolic much?
Because if you actually read the whole issue, here we have one maintainer acting out of line of refusing to process the issue until another one (Yu Watanabe) interjects, says there is an issue and actually commit a patchset adding the option asked for.
I'm hedging my bets with "one of" because there might be something I've forgotten, but that specific series of events is like reading a transcript of The Trial if it happened in real life. It is seriously extremely annoying to me and I'm both intrigued and concerned that it doesn't even rank in your list.
They didn't used to "just work" like that before systemd.
System boot is faster. I can have fewer things started up in the background, and instead have them start up when needed. Restarting services works consistently. Every application doesn't have its own bespoke and half baked management scripts which don't work half the time. They don't all have to invent their own daemonization support and logging; you just log to the journal.
And that's just core systemd. Things like systemd-resolved give me proper support for split-DNS when using VPNs. systemd-networkd gives me consistent, powerful configurable networking setup that works across distros.
Is it perfect? No, I do still have some complaints with it. But it's a hell of a lot better than what it's replacing. I wouldn't ever go back to sysvinit or upstart, and many other parts of systemd are compelling alternatives to the things they replace, like systemd-networkd over ifupdown.
sorry, no, at least in any meaningful sense, because init already just worked for me.
and when something didn't, I could find how to fix it in a way that was transparent and I understood and could even modify or make better, without being connected to the internet looking for cargo cult incantations on stack overflow
init was a tool; systemd is an adversary
What kind of problems do you have with the part of systemd that replicates sysvinit /every other day/?
I think this right here hits at the crux of the issue.
There are people who like systemd because it's integration-tested with itself and its own defaults, so if you never change those defaults you don't have many problems.
Then there are people who don't like systemd because if you do have to change any of its defaults, it often doesn't go well. And, of course, the latter behavior as a box users are expected to live in is poisonous, because everyone is being conditioned to be passive and uniform.
No, it's not, this assumes that the other camp are all idiots.
Mainstream distros should be rock solid and boring.
Linux never got anywhere with the standard distros because they're all so different.
Tinkering is a different mindset (and has a different place) than professional engineering work.
Systemd is basically engineering, SysV & co. were basically old school tinkering/hacking.
In the same vein, don't be creative with bolt sizes. Be creative with what those bolts allow you to achieve. Be creative at a higher level. That should be the nature of humanity.
This is eliding the difference in what you want to be standardized.
Take system logging for example. You definitely want some standard interface to do it so all the different daemons and things can implement it once regardless of which system logger the distribution is using. But once it passes that data to the other program, it's under a different dominion of control which should operate as a black box with respect to the program generating the data and the rest of the system.
Because that's how you prevent ossification -- which is engineering. You want to make it so the other component can be improved or substituted. One system logger is designed to store the logs on a central server instead of the local machine, another supports modules so other people can easily write log-parsing scripts. And when you come up with a new idea for a third, you don't have to be on the systemd team to publish an independent implementation that other people can use as a drop-in replacement, instead of (not in addition to) the default one, without requiring it to be separately integrated with a dozen moving targets in the systemd repository.
What you're trying to do is to allow this:
> In the same vein, don't be creative with bolt sizes. Be creative with what those bolts allow you to achieve. Be creative at a higher level.
You want to standardize the bolt sizes, i.e. the interfaces between components. What you explicitly don't want is to replace bolts with having everything epoxied together.
But that's what happens when you e.g. integrate the logging system with the service manager, which is the sort of thing people are complaining about.
So I'd rather have the epoxy open source standard than no standard.
https://news.ycombinator.com/item?id=42039273
There are things that systemd does better than SysV and other things it does worse and you can want it to stop doing the things that are worse while still doing the things that are better.
Plenty of people changes systemd configuration all the time and it just goes fine. You live in fantasy.
Even op is basically saying: “my issue with systemd is that I dislike the timeout configuration of some services but I stubbornly refuse to change these configurable timeout durations because it would show that the problem was myself and I prefer blaming systemd.”
It takes no time whatsoever to get a boot graph with each services name and starting time. That’s an actual feature documented in the manual of systemd which solves OP issue. But of course it would require actually understanding something new and everything new is bad, isn’t it?
"since I have never experienced what you say, it must be fantasy"
> Even op is basically saying: “my issue with systemd is that I dislike the timeout configuration of some services but I stubbornly refuse to change these configurable timeout durations because it would show that the problem was myself and I prefer blaming systemd.”
This is a perfect example of toxicity; I have been successfully using systemd for years and I am entitled to point out what I dislike, I do not have to love everything of it, it's not a religion nor a cult. Your reply tells more about yourself than the topic of the discussion at hand.
> It takes no time whatsoever to get a boot graph with each services name and starting time. That’s an actual feature documented in the manual of systemd which solves OP issue. But of course it would require actually understanding something new and everything new is bad, isn’t it?
You're missing the point, the problem is not changing timeouts but preventing failure and achieving an overall deterministic behaviour out of your system, without ignoring failures. But I refuse further eating these baits, you seem more interested in creating some flames rather than having constructive discussions.
You are writing that you have been unsuccessfully using systemd for years because of the annoying timeout. I'm replying that it's entierely your fault because it takes seconds to make these timeouts disappear.
That's not toxicity. That's calling out some non sense on the internet.
That’s an issue with a daemon, not systemd. Anyone who used NFS saw that routinely on SysV init during the era when Red Hat distributions shut down networking before ensuring that the network mounts were unmounted.
The problem is that there isn’t a universally correct way to do this: if my web server has hung, SIGKILL is what I want to get the system back in a usable state as quickly as possible but if it’s a file system, database, etc. you have questions like losing data which aren’t trivial to answer (e.g. if it’s a transient error, waiting for it flush is good but if my storage had an irrecoverable error I might want write off that data as lost and focus on getting the service back up).
/etc/systemd/{user,system}.conf.d/dont-wait.conf:
[Manager]
DefaultTimeoutStopSec=5s
You can stop hating on systemd now, everything you needed was in `man systemd-system.conf` all along.
[1] https://community.kde.org/Distributions/Packaging_Recommenda...
Here's another example of cultism repressing any dissent.
Let me make a bullet points list for you:
* I do not hate systemd, I have never stated that, I have been using it for possibly longer time than you and love most of it
* I am entitled to write about what I don't like, you can disagree and move on, we all need to do this exercise on a daily basis
* there are cases where systemd will change the order of dependencies during boot, that's by design because systemd works in a way that tries to achieve states. It's not really enforcing a graph with order
* in a sufficiently complex system, this constitutes a source of non-determinism and it is basically undebuggable: you see the failure, learn about the corresponding configuration, change it and hope that you did the correct change (you have no way to test this until next random occurrence)
That's all, it's based on my experience; I write plenty units on a regular basis and 99% of the times everything goes very well.
"I'm afraid I can't do that, Dave."
They used to "just work" for _decades_ before systemd. Like, everything.
I see reasons for systemd as PID1 and it's great in that role, hands down.
Everything else looks like a malignant growth to me, including much praised journald and DoA pieces like resolved.
gives me #1 source of troubles on any desktop computer I have ever ran under the systemd era. I feel like resolved is specifically designed to be removed from fresh installations, sort of like a transparent peel on new devices' screens.
In my strong opinion, resolved is the most brain damaged part of systemd. Unconfigurable, unmaintainable, unmanageable.
> systemd-networkd gives me
Oh, there is no point in learning systemd-networkd. By the time you do Ubuntu folks will swap the set of the network initialization tools once again and you'll have to start over. Thankfully, 'apt install ifupdown' still works kind of like `apt install upstart` worked a few years ago.
People seem to think it is.
A lot of people claim the same, but the proof is in the real life pudding.
Don't forget that geeks idealize perfection and especially minimalist perfection.
One of them. The others didn't work out so well. That's a curiosity in and of itself.
> A lot of people claim the same, but the proof is in the real life pudding.
Those claims are true. Those systems exist. People use them. Every day. I've got tons of business riding on them. Systemd's defaults are simply a non starter for any real production environment.
> Don't forget that geeks idealize perfection and especially minimalist perfection.
They prefer a system which leaves the options open. Systemd removes them in the name of simplistic cohesion. It's all based on the flawed idea that linux will ever be a popular desktop operating system if you just make it work like windows does.
It misses the point on what computing is entirely, but hey, as long as it's "complete" implementation of this flawed vision I guess that's good enough for some people. And yet we're still no where near windows.
How many people eat McDonalds? Or buy in to countless other things that can be trivially demonstrated to be against their own interests.
I don't know about anyone else but I never heard the critiques of systemd to be based on any doomsday predictions.
Everyone knew it would function, and that it even serves one use case better than before.
The critique was only ever that it serves one purpose better at the expense of all others, and is a downgrade in flexibility and functionality from what already existed.
If you’re already starting like this it’s obvious that the following text will be non-scientific non-sense.
As a reminder: There is no such thing as “healthy food” and “unhealthy food”, there is just healthy and unhealthy nutrition.
Still baffles me that people think it would actually be legal to sell actual unhealthy food, i.e. poisonous food.
Also, “organic food” is just a marketing scam. If you think your nutrition is better off if you stick to nature, you’ve missed a large part of human history where people starved to death by the thousands every year because they exclusively relied on “organic food”.
systemd runs on billions of systems worldwide and everyone who ever professionally maintained enterprise servers understand what a bad approach the crude hack that SysVInit with its collection of shell scripts was.
What is poisonous food? You can sell plastic that breaks down into the environment and people are drinking it in water, eating it in fish. Is that legally sold poisonous food?
As for drugs:
> Alle Dinge sind Gift, und nichts ist ohne Gift; allein die Dosis macht, dass ein Ding kein Gift ist.
- Paracelsus, 1538
Personally, I like to add a bit more science and reasoning to my understanding rather than rely on quotes from someone in 1538.
Booze has been a staple of diets for a long time too. Doesn’t mean it’s not poison just because society is stupid enough to embrace it.
A quick web search will gladly provide evidence if you actually are interested.
Here’s a HN thread on an NPR article: https://news.ycombinator.com/item?id=26126183
Here’s a Canadian news agency article: https://www.cbc.ca/news/health/how-toxic-is-sugar-1.1894262
If you’re just going to knock everything off as “just your belief” then no amount of evidence will convince you.
Do you actually not understand what is wrong with McDonalds food? Or countless other similar low quality but legal products?
Do you actually not understand that terms like "healthy" and "poison" are not binary but a spectrum? And that every single thing has some aspects of both?
Do you actually not understand how a bag of sugar is not poison and legal to sell, and yet, if you ate one for dinner every night would not be good?
Do you actually not understand the point that popularity does not by itself prove or disprove anything? That great masses of people frequently voluntarily choose the inferior option for all kinds of reasons that aren't even all some form of lack of choice?
Do you actually not understand that that you are attempting to speak for "everyone who ever professionally maintained enterprise servers" TO some of them who quite robustly do not say any such thing?
> systemd runs on billions of systems worldwide and everyone who ever professionally maintained enterprise servers understand what a bad approach the crude hack that SysVInit with its collection of shell scripts was.
This is your opinion and not one held by all. It also ignores the various BSD system initialization scripts, which are explicitly not "SysVInit" related, and have been in use for decades.
I'm so sad I wasn't paying attention when Debian was choosing init systems... I would have burned a TON of time getting anything they claimed in good faith was missing in 'openrc' into it, had I known that that clusterfuck was going on.
See : the current apocalyptic and accelerating global biomass destruction directly caused by industrial farming.
The fact that you don’t like how organic food is marketed does not mean it is full bore a scam. It’s a real agricultural practice that exists. Organic eggs require far more freedom for chickens for example.
RPi took the form factor that was used for industrial control boards and made it into a usable desktop... which people use as a desktop (or home server). But it created a segment which really is neither. And a lot of the software just isn't written with that segment in mind. Maybe as it gets more popular, people will pay more attention. But currently it seems more of an expectations issue.
Users DID want systemd. Ask any sys admin, most much prefer systemd.
Also systemd doesn't "force" anything. Most distributions don't even ship all systemd projects, just a couple.
systemd-init IS small. The idea that systemd is a big ole monolith is just not true, and one glance at the git repo reveals that.
systemd is, of course,today a continuing shambling feature factory behemoth in which hundreds of product managers try to shoehorn in more mandatory features in order to cement grip on the platform. That's why you get this ridiculous dns nonsense, this ridiculous container nonsense, this ridiculous cron nonsense, hostnamed (!), the list is endless.
The technical argument is that it's a giant tasteless bag of ever increasing poorly implemented scope. The rest of Unix, by comparison, is generally not that way. If you pick up a BSD or even an alpine, you'll find that you don't need a bunch of badly written, hacked together garbage in order to get your work done. The system can be entirely readable and repeatable without cramming a bunch of cruft and poor decisions into pid 1.
The idea that systemd doesn't 'force' anything is, of course, hilarious. Systemd is designed to try to be the ultimate mandatory dependency for essentially everything on the system. That's the way Red Hat wanted it to be, and that's the way it is.
Every time someone mentions systemd, some random apologist dutifully trots out the idea that systemd-init is small and therefore systemd is not a monolith, checkmate. Of course, journald, libudev, localed, logind, hostnamed, homed, networkd, resolevd, systemd-boot, systemd-bsod, systemd-nspawn, timedated, timesyncd, tmpfiles, udevd, and all of the other array of dumbass bolted-on second-system-effect-driven product-managed nonsense somehow don't get mentioned.
Speculative and ideological. From a technical perspective, I don't care about this.
> despite all this being open source, were forbidden to modify or replicate
This isn't true - you're allowed to modify or replicate any parts of systemd and always have been.
> systemd is, of course,today a continuing shambling feature factory behemoth in which hundreds of product managers try to shoehorn in more mandatory features in order to cement grip on the platform
I'm not sure you understand what systemd is.
systemd is not a piece of software, systemd is an endeavor. Many, many projects are under "systemd", as in they have the name, but they are all individual binaries. Practically 0 distros include all systemd binaries, because they're optional. Many projects already existed before systemd, like gummi boot, and were just given the name.
> The rest of Unix, by comparison, is generally not that way
This is untrue, as systemd follows unix principles. systemd-init does one thing and one thing only - it's only the init system. systemd-networkd is just the network daemon. systemd-journald is just the logger. And on and on. Despite what you may think, they ARE optional, and distros mix and match constantly.
> without cramming a bunch of cruft and poor decisions into pid 1
Again, out of the dozens and dozens of binaries under the systemd umbrella, only one (1) runs under PID 1. This simply isn't true.
> Systemd is designed to try to be the ultimate mandatory dependency for essentially everything on the system. That's the way Red Hat wanted it to be, and that's the way it is
Speculation, ideological, and not evidence backed.
> Of course, journald, libudev, localed, logind, hostnamed, homed, networkd, resolevd, systemd-boot, systemd-bsod, systemd-nspawn, timedated, timesyncd, tmpfiles, udevd, and all of the other array of dumbass bolted-on second-system-effect-driven product-managed nonsense somehow don't get mentioned
Yeah... because those are separate programs. Maybe you just don't understand how computers work, but these programs are unrelated. They talk over IPC, they're not even linked together on any systems. You can take or leave any of them, and many distros do. Even Debian, the supposed systemd cocksucker, doesn't include half of these.
systemd CVEs: https://ubuntu.com/security/cves?package=systemd&limit=100
Rust PoC: https://github.com/KillingSpark/rustysd
> Rustysd is a service manager that tries to replicate systemd behaviour for a subset of the configuration possibilities. It focuses on the core functionality of a service manager, not requiring to be PID1 (aka init process).. core systemd functionality is not very hard to replicate.. the advantages of having a systemd-like service manager can be brought to many other platforms.. (like alpine linux, commonly used in docker containers and small vms) and freebsd.
* CVE-2022-3821 : off by one error leading to buffer overflow
* CVE-2022-2526 : use after free
* CVE-2021-33910 : "Memory Allocation with an Excessive Size Value" (not sure if this qualifies... not interested enough to read the source)
So now anyone wanting physical access to your host, just have to intercept plain-text communication with the BIOS (after secureboot did its thing), and reply with a new root password when the OS request bios key 11 or something. evil maids are living the dream.
Weird. In my professional life, I've found systemd's logging to be woefully lacking when compared to systems that just run every daemon through syslog (or -even more retro- "each daemon writes stdout & stderr to disk, which then gets sent to your log sink of choice").
What I usually find is that a ton of information never, ever makes it into journalctl, so I always need to go to the actual log files on disk. [0]
On top of that, journalctl just fucking giving up when logs have been rotated is totally bogus. (If this has been fixed, then the fix hasn't made its way to the systems I work with.)
ALSO, have they fixed the issue where minor data corruption just totally fucks your log file to death... rather than what happens with regular log files and you get an unreadable section that's bracketed by good data?
[0] Yes, you could reasonably say "Well, those services are not correctly configured to log to journalctl!". But my point here is that I see this happen so often that journalctl is like my tenth stop for log messages, rather than my first.
A lot. Plenty embedded Linux stuff still ships with 256 MB or 512 MB RAM, and the wishlist for features in the software running on top is always getting longer than initially planned...
But of course the average has moved up, and it's not unusual to see systemd in embedded systems either (while I don't have a number at hand, the 250MB number seems off to me). The space is big, and different constraints and rules at different points in there.
I'm not saying software is any more efficiently written these days but I do think it's important to recognize that just the act of pushing more pixels on its own requires more RAM.
(Your WiFi router probably has 256 or 512 MB of RAM)
Container startup ordering, startup dependency management, socket handling and all things timing and network related are frankly a complete mess in modern infrastructure. Even, surprisingly in well maintained projects like k8s. I find myself shaking my head at problems solved by systemd a decade ago far too often.
Come fucking on. I ran systemd on a 32Mb MIPS board (RouterBoard from Mikrotik) just fine.
The RES column is incredibly misleading in this case, because systemd is the first app in the system. So it gets charged for loading the entire glibc and the supporting cast of libraries.
If you want to look at the true usage, check the RssAnon value:
> root@kmipsrv:/proc/1# cat /proc/1/status | grep RssAnon
> RssAnon: 3220 kB
You can also pare this down a bit.
Similarly for journald:
> root@kmipsrv:/proc/1# cat /proc/231/status | grep RssAnon
> RssAnon: 640 kB
So in reality, systemd works just fine for the vast majority of embedded platforms. If you can spare 3Mb of RAM, then you can run a full-blown dependency management system with reliable recovery, logging integration, and event-driven device management. Soon with support for verified boot with hardware root-of-trust.
The minimum binaries size that can be obtained by trivial removals is around 2Mb.
OpenWRT should just stop being stubborn and integrate it. They dropped support for 4Mb devices loooooong ago, and recently bumped the minimum specs to 16Mb.
> systemd does not work well with musl which is very popular in embedded linux.
Systemd can work with musl with a small compatibility shim, I did it about 9 years ago. Somebody did that again: https://catfox.life/2024/09/05/porting-systemd-to-musl-libc-...
Why? If it fails to provide benefits commensurate to the effort required to integrate it, then there's no reason to do the work.
OpenWRT is for routers and access points... devices which usually have a fixed [hardware] configuration, and very little need for the absurdly-complex (and in my professional experience, often subtly buggy) event-driven systems that systemd provides. "Every system everywhere gets to use the same unit files" isn't a significant benefit in practice... EVERYTHING that needs nontrivial pre-/post- start/stop verification and/or configuration has systemd run a shell script (or other such helper) anyway... so you only get to just write a unit file and call it a day in the most trivial of cases.
Now it can host telephony services, full-blown Docker orchestration systems, etc. So you get all the pleasures of complex systems running on antiquated infrastructure.
> so you only get to just write a unit file and call it a day in the most trivial of cases.
What "start/stop verification"? Give examples, please. Systemd natively supports device dependencies, network status, other services, etc.
It's a very rare case when you _need_ shell in systemd.
What features that systemd provides that aren't provided by openrc, runit, monit, openrc's init system, etc, etc, etc that are needed by software like Asterisk, Docker/runc, Kubernetes, and similar?
If what OpenWRT is running works fine to bring that up, then systemd doesn't have any relevant compelling features that aren't provided by another init system. Switching away from something just because it's "antiquated" is a great resume-building tactic, but it's a pretty poor strategy when your objective is to keep things that have been working working with a minimum of effort.
> What "start/stop verification"? Give examples, please.
One example (out of many) are pre-start, pre-stop, and pre-restart configuration file correctness verification so that a typo or thinko doesn't bring a service down.
A concrete example of this is Gentoo's running of 'named-checkconf' in BIND 9's service file [0]. Gentoo's BIND 9 systemd unit file [1] tries, but probably does not do the same thing... I don't know if 'ExecStartPre' runs before systemd brings down a service on a 'restart' action, but I bet you that it definitely does not run on service stop.
I just checked and Ubuntu 22 does NOT do this sort of checking for its bind9 package, which is pretty wild.
> It's a very rare case when you _need_ shell [or other such helpers] in systemd.
Then you're either running "seatbelts off" (maybe without even knowing that you are), or you rarely deal with anything nontrivial. This need comes up a LOT in my day-to-day.
[0] <https://gitweb.gentoo.org/repo/gentoo.git/tree/net-dns/bind/...> [2]
[1] <https://gitweb.gentoo.org/repo/gentoo.git/tree/net-dns/bind/...>
[2] You might look at that file and be like "wow, TL;WR", but do try to notice how much of that file is dedicated to creating useful, human-readable status messages and error messages with good corrective instructions. If you care at all about your sysadmins, that complexity has to go somewhere, and that somewhere cannot be inside a systemd unit file... systemd just doesn't provide the features required to do that (and it would be kind of insane for the devs to even try).
Dependencies, watchdogs, start only when the given network interfaces are available, declarative configuration so that can be partially customized, etc.
> If what OpenWRT is running works fine
Unless you try to update it. And end up with merge conflicts in the /etc directory. And then it stops booting, and you have to get in via the serial port.
No, OpenWRT is most definitely not fine. It's stuck in the past, and doesn't support automated rollback, configuration management, etc.
> A concrete example of this is Gentoo's running of 'named-checkconf' in BIND 9's service file [0]
Wow, what a... But named config has always been a disaster zone.
With systemd _none_ of that crap is needed. It can use its own namespacing and cgroup support to ensure that BIND9 can't read outside of its allowlisted tree.
If you want to run /usr/bin/named-checkconf, then it's just an ExecStartPre directive in the unit file. And unlike SysV that just fails to run and forces you to dig into the logs, systemd provides you a nice status saying that the pre-exec had failed.
> You might look at that file and be like "wow, TL;WR", but do try to notice how much of that file is dedicated to creating useful, human-readable status messages and error messages with good corrective instructions.
Yeah, and hanging indefinitely, forcing me to do a trip to the datacenter at night (true story): https://lwn.net/Articles/619565/
So, briefly:
1) That's a list of systemd features. Some of which are nice to have, but none of which are needed for the software I mentioned.
2) On-upgrade merge conflicts for entirely-unmodified-from-their-stock-settings system configuration files are why I gave up on Ubuntu. Systemd doesn't solve anything here.
3) Systemd doesn't handle BIND configuration... or any non-systemd application configuration. And most nontrivial init systems (with systemd as one notable exception) have facilities for printing info, warn, and error messages in service startup files rather than demanding that you pick through the application logs to find out why startup failed.
And here's an example of how a network service can be confined in its own network namespace: https://www.cloudnull.io/2019/04/running-services-in-network... - with zero shell needed, btw.
> The rest of flash was used for persistent storage, bootloaders, and calibration data.
So you couldn't spare around 1Mb of compressed flash or 2Mb of uncompressed flash for systemd?
> This is very common for older routers and APs which is the whole reason that OpenWRT exists.
That hasn't been the case in quite some while.
And it won't matter anymore, there is no price difference between 32Mb and 64Mb NOR or NAND flash. It's literally the same cost.
Absolutely not.
> That hasn't been the case in quite some while
These routers and APs still exist and are in use. Yes, they are 10+ years old, but they're still out there. One of the main goals of OpenWRT is to support legacy networking hardware that vendors abandoned.
So basically, you're dealing with devices that use obsolete hardware and are designed to be extra-brittle (no safety margin), with a built-in planned obsolescence (what if the new update requires just a bit more space for "calibration data"?). Got it.
sysvinit indeed fits perfectly. Make the system extra unreliable, to provide a stimulus to buy a newer version.
> One of the main goals of OpenWRT is to support legacy networking hardware that vendors abandoned.
And OpenWRT abandoned this goal. OpenWRT also can do nothing about firmware vulnerabilities in the old WiFi chipsets.
Moreover, 10 years ago, systems with 32Mb were already common.
> And OpenWRT abandoned this goal.
They have not. Individual devices get too old to be supported, but there are plenty of 16 MB devices they still support. Its true that basically every device now has 32MB or more of flash, but there are still plenty out there that don't.
> with a built-in planned obsolescence (what if the new update requires just a bit more space for "calibration data"?). Got it.
The calibration data is from the factory to tune the wifi radios, it doesn't change since its specific to that individual device. I really hate to reply like this on HN, but you don't seem to know what you're talking about. The kinds of constraints you deal with in embedded networking are different than that in general computing. There's a reason systemd wasn't used, and there's a reason OpenWRT devs went through the trouble of developing their own init system. Just because you can't fathom those reasons doesn't mean they don't exist.
procd is only slightly better than sysvinit, it has the same ideas, and only adds simple and incorrectly implemented event triggers. And yes, I spent days debugging issues that it caused.
E.g. a USB drive for the logs becomes slow and changes the startup order, so now openvpn starts before the interface acquires the IPv6 address. Boom, broken IPv6 routing.
> They have not. Individual devices get too old to be supported, but there are plenty of 16 MB devices they still support. Its true that basically every device now has 32MB or more of flash, but there are still plenty out there that don't.
And systemd can live just fine at 16MB. I ran it on RouterBoards with 32MB (the smallest ones available) in 2014. It has grown a bit since then, but it can be slimmed down (remove compressors, auditing, SELinux/AppArmor, etc.).
> The calibration data is from the factory to tune the wifi radios, it doesn't change since its specific to that individual device. I really hate to reply like this on HN, but you don't seem to know what you're talking about.
The entire firmware for WiFi chips that were available during 16MB era is around 500KB-1MB. So it must be some other mysterious "calibration" data.
So you're thinking about more and more corner cases, that require the stars to be just right for the size of systemd to matter.
These weren't corner cases, they were everyday reality. We had to intentionally slim down the firmware size to get it to fit comfortably since we added quite a bit of application code. Like I said before, we got a recovery firmware down to ~3MB, and the normal firmware (without our application) was ~8MB. Every megabyte counts at that point, so having a 1MB init system would be a non-starter. We were buying commodity hardware, so we did lots of shopping and there were still plenty of 16MB APs on the market 10 years ago.
You're right its not a problem if you buy new hardware, but OpenWRT is used to support older devices with limited hardware specs. Its one of the reasons people install it, to give new life to old hardware (rather than being forced to buy a new device).
By the way, I use and like systemd on full size computers. I actually know of a product that runs a full rpm based distro (with systemd) on an embedded device and it works great. But systemd isn't one size fits all.
When configuring boot media, like an SD card, for an embedded ssystem that is not the running system where the configuration is occurring, this is an impediment. There is systemd-firstboot, etc, but this is not as convenient as just being able to set config options on the mounted (non-booted) embeddded media.
I've never liked it, I still don't like it, and I think the number of people in this camp is understated by the article.
However, I am still running it. As other posts have mentioned, switching distributions is a major hasstle, especially if you've built tools using the distro's architecture. For me, this is archlinux.
Although, I am in the process of testing and migrating to void linux. Which is systemd free, and hosts ARM and x86 binary package repositories.
systemd follows the drop-in config file model where configuration snippets are placed into directories (like .d/ directories in Debian). It should not be necessary to run utilities from the target system in order to configure it on mounted media.
Drop unit files for services, sockets, filesystem mounts, timers, etc onto the mounted media and they will be detected when the target system boots.
systemctl --root /path/to/sd/card/ <...>
I really don't know what the problem is suppoaed to be.
Lennart
At the very least, SysVInit requires a shell for running init scripts which systemd doesn’t need for native service files.
Should these issues be fixed by CPU/IO schedulers? Are there any systemd realtime tasks involved?
Eudev and elogind ARE mantained and used in voidlinux and gentoo, and anyways being that embedded it doesn't seem clear to me where would the "hard dependency of a very essential software on some systemd-thingd" happen.
I won't pretend there aren't occasional weird problems... but there's always a solution, here's a recent example: https://github.com/systemd/systemd/issues/34683
Memory use is irrelevant to me: every embedded Linux device I've been paid to work on in the past five years had over 1GB of RAM. If I'm on a tiny machine where I care about 8MB RSS, I'm not running Linux, I'm running Zypher or FreeRTOS.
That's not true, systemd has an explicitly documented and supported initrd interface: https://systemd.io/INITRD_INTERFACE/
It's actually really easy, there's rarely a reason for the initrd to be more complex than a single 50-line busybox script on an embedded device with built-in drivers.
Dracut is used both in Void Linux and on Alpine without systemd and with busybox.
It even runs continuous integration with musl based containers.
It has an init:
$ /home/busybox-1.35 init --help
BusyBox v1.35.0 (2022-01-17 19:57:02 CET) multi-call binary.
Usage: init
Init is the first process started during boot. It never exits.
It (re)spawns children according to /etc/inittab.
Signals:
HUP: reload /etc/inittab
TSTP: stop respawning until CONT
QUIT: re-exec another init
USR1/TERM/USR2/INT: run halt/reboot/poweroff/Ctrl-Alt-Del script
That is almost by definition not an embedded device. There's a reason we have vfork().
That’s not typical at all. I’ve done a lot of work with production runs in the millions. There is no way we’d put that much RAM on a device unless it was absolutely, undeniably required for core functionality.
That doesn't pass the sniff test. Look at retail RAM prices. Certainly the magnitude of the price is quite different than buying individual RAM chips at quantity, but the costs do scale up as RAM size goes up. Hell, look at RAM chip prices: you are definitely going to increase the price by more than a negligible amount if you 2x or 3x the amount of RAM in your design.
Also consider the Raspberry Pi, since the article mentions it quite a bit: RAM size on the Pi is the sole driver of the different price points for each Pi generation.
So no, at those sizes price really does not change all that much, and installing 512MB of RAM instead of 64MB only increases the product's cost by $0.15. It's a commodity made on legacy processes, things like packaging, testing, and handling far outweigh the cost of the actual transistors inside the chip.
[0]: https://www.lcsc.com/product-detail/DDR-SDRAM_Winbond-Elec-W...
[1]: https://www.lcsc.com/product-detail/DDR-SDRAM_Winbond-Elec-W...
[2]: https://www.lcsc.com/product-detail/DDR-SDRAM_Samsung-K4B2G1...
[3]: https://www.lcsc.com/product-detail/DDR-SDRAM_Samsung-K4B4G1...
[4]: https://www.lcsc.com/product-detail/DDR-SDRAM_Samsung-K4A8G1...
I remember arguing as well with people about 0.10$ components. They told me it was a no go, not even a point of bringing it up. Sometimes even a 0.01$ is a big deal.
There are a lot of other factors involved with respinning hardware which make an upgrade a lot more expensive than simply a BOM increase. I can definitely understand why an existing product wouldn't be upgraded, but for a new product going to a bigger memory chip is a far smaller hurdle. The added software engineering time for working around RAM limitations can easily outweigh any money saved on the BOM, with choosing a smaller chip ending up being penny-wise pound-foolish.
And indeed, an extra $0.10 or even $0.01 can be a big deal. But those cheap systems usually aren't powerful enough to meaningfully run Linux in the first place: just because you can technically hack a $1.00 RP2040 or ESP32 into running Linux doesn't mean it is a good idea to actually do so. If your product is both cheap enough that it represents a significant fraction of your BOM and high-volume enough that you can afford the engineering time in the first place, why not use a purpose-built embedded OS like Zephyr?
In my experience production people will eat your soul for a single resistor if they can cut costs on it.
Also, just because something holds true at large numbers doesn't mean it scales all the way down. Either due to economies of scale, or the negligibly different architecture/components at that size.
In Automotive (i.e. telematics devices) you'll want a separate MCU for CAN-bus. For example, if you are doing Request-Response model you'll want to make use of the built-in filters. Besides, it is unlikely that a modem would support the CAN interface.
In Cellular IoT you'll prefer a separate MCU as it is much easier to port to different hardware. For example, you can hook-up the module via UART and use CMUX (AT/GNSS/PPP) and you'll cover 80%+ of the modules available in the market with very minimal specific implementation layers to enter into these modes.
Been a while since I was in the digital signage space but a lot of the equipment runs of the shelf RK3288 plugged into commercial displays. 2GB of RAM was pretty common. IIRC's though LG's WebOS TV's have minimum 2GB of RAM in the digital signage space directly built into the units themselves. I believe Samsung Tizen based units has similar RAM.
My router has 1GB of RAM in it. But even my cheapest routers have 128 to 256 MB of RAM. The Cisco 9300 Catalyst switches have about 8 GB of RAM, but switches with beefy amounts of RAM are getting pretty common now, even if somewhat pricey.
Yeah there's massive swathes of embedded space that's tiny. But the higher end stuff isn't exactly out of reach anymore. The RK3288's IIRC ran about $20 a unit at the time before I left the industry.
In 2014 i got myself a second- or third-hand thinkpad X220, released in 2011, off eBay. It came with 8gb ram (two 4GB sticks) but it supported 16GB ram as well (two 8gb sticks).
The laptop (Asus A8Jc) I got when I was a teenager in ~2005 came with a dual core intel cpu and 1GB ram. So "512mb desktops" are way older than that.
If they can't afford those specs then you're approaching the group of people who can't afford a computer in the first place.
I recently wanted an MP3 player for an art project. Local stores don't sell mp3 players anymore, they only sell smartphones. So I bought an MVNO smartphone for $40. When I charged it up and tried to use it, I thought maybe it was broken, because it would take 10-30 seconds to load a settings menu or app. Nope, all these bargain carrier-branded phones are that slow. The hardware is [somewhat] old, but the new Android OSes run like molasses on them. It was like going back in time. Remember how Windows 98 would make your hard drive screech for a good couple minutes as it struggled to juggle the swap memory so you could open MS Word? That's the experience with most software today with "affordable" hardware even a few years old.
So using Windows XP is often the only choice, if you don't have a lot of money, like 1/3rd of the planet. (And it's not just the third world. 59% of American households with K-12 school kids don't have a working computer, or it works too slowly to be useful)
So you bought a new phone for $40, and it was a POS?
My kids use my old iPhone 7, which is in the same price bracket and is nothing like that. Its fast enough for Roblox, Minecraft, and certainly fast enough for a web browser.
I have an old Dell USFF that I use for server purposes, but its a Skylake (so newer than what was the original conversation), with ssd and 16Gb, and that was <£50. That can boot with systemd in under 5 seconds. It can boot to the full Gnome desktop in under 6 seconds. Firefox can start and get the Office.com site up in less than 3 seconds.
Because thats what were talking about.
> But desktops with those specs are <$100, probably less than $50.
I just checked eBay. Yes they still are.
DESCRIPTION vfork() was originally used to create new processes without fully copying the address space of the old process, which is horrendously inefficient in a paged environment. It was useful when the purpose of fork(2) would have been to create a new system context for an execve(2). Since fork(2) is now efficient, even in the above case, the need for vfork() has diminished. vfork() differs from fork(2) in that the parent is suspended until the child makes a call to execve(2) or an exit (either by a call to _exit(2) or abnormally). ... HISTORY The vfork() function call appeared in 3.0BSD with the additional semantics that the child process ran in the memory of the parent until it called execve(2) or exited. That sharing of memory was removed in 4.4BSD,
The gap between “over 1GB of RAM” and 8MB RSS contains the vast majority of embedded Linux devices.
I, too, enjoy when the RAM budget is over 1GB. The majority of cost constrained products don’t allow that, though.
That’s said, it’s more than just RAM. It increases boot times (mentioned in the article) which is a pretty big deal on certain consumer products that aren’t always powered on. The article makes some good points that you’ve waved away because you’ve been working on a different category of devices.
Of all currently existing Linux devices running around the world right this moment? Maybe.
But of new devices? Absolutely not, and that's what I'm talking about.
> The majority of cost constrained products don’t allow that, though.
They increasingly do allow for it, is the point I'm trying to make.
And when they don't: there are far better non-Linux open source options now than there used to be, which are by design better suited to running in constrained environments than a full blown Linux userland ever can be.
> It increases boot times (mentioned in the article) which is a pretty big deal on certain consumer products that aren’t always powered on. The article makes some good points that you’ve waved away because you’ve been working on a different category of devices.
I've absolutely worked on that category of devices, I almost never run Linux on them because there's usually an easier and better way. Especially where half a second of boot time is important.
The trouble with "new" is that it keeps getting old.
There would have been a time when people would have said that 32MB is a crazy high amount of memory -- enough to run Windows NT with an entire GUI! But as the saying goes, "what Andy giveth, Bill taketh away". Only these days the role of Windows is being played by systemd.
By the time the >1GB systems make it into the low end of the embedded market, the systemd requirements will presumably have increased even more.
> there are far better non-Linux open source options now than there used to be, which are by design better suited to running in constrained environments than a full blown Linux userland ever can be.
This seems like assuming the conclusion. The thing people are complaining about is that they want Linux to be good in those environments too.
Those days are long gone though, for better or worse.
We live in the 2020s now and ram is plenty. The small computers we all carry in our pockets (phones) usually have between 4 and 16g GB ram.
And the progress has kind of stalled:
https://aiimpacts.org/trends-in-dram-price-per-gigabyte/
We've been stuck at ~$10/GB for a decade. There are plenty of devices for which $10 is a significant fraction of the BOM and they're not going to use a GB of RAM if they can get away with less. And if the hardware price isn't giving you a free ride anymore, not only do you have to stop the software from getting even bigger, if you want it to fit in those devices you actually need it to get smaller.
You can say the free lunch is still there, but it's gone from a buffet to a stick of celery.
I do not think the monster CPUs running Android or iOS nowadays are representative of embedded CPUs.
RAM still requires power to retain its contents. In devices that sleep most of the time, decreasing the amount of RAM can be the easiest way to increase battery life.
I would also think many of the small computers inside my phone have less memory. For example, there probably is at least one CPU inside the phone module, a CPU doing write leveling running inside flash memory modules, a CPU managing the battery, a CPU in the fingerprint reader, etc.
The gap between 16MB RAM and 64MB RAM doesn't exist, though. Literally doesn't, the components have the same cost down to a cent in the BOM.
And if you can have 64MB, then there's systemd's own true memory use (around 3-4MB) is completely immaterial.
just look at wifi routers. in the usa and China they are all sold with 64 or 128mb ram. south America and Europe they are all 16 or 32 for no clear reason.
My ISP provided router also does VPN, VoIP, mesh networking, firewalling, and it's towards the lower end of feature set (as it's offered for free and not a fancy router I bought).
Are you talking about devices from the early 2000?
I don't know where you're getting your data from but it's clearly wrong or outdated. These are the most often sold routers in Czechia on Alza (the largest online retailer) under $100:
- TP-Link Archer AX53 (256MB)
- TP-Link Archer AX23 (128MB)
- TP-Link Archer C6 V3.2 (128MB)
- TP-Link Archer AX55 Pro (512MB?)
...
- Mercusys MR80X (256MB)
- ASUS RT-AX52 (256MB)
https://www.alza.cz/EN/best-sellers-best-wifi-routers/188430...
Is it really the case? On desktops it is significantly faster than all the other alternatives. Of course if you do know your hardware there is no need for discovering stuff and the like, but I don't know. Would be interested in real-life experiences because to me systemd's boot time was always way faster than supposedly simpler alternatives.
Later, when I got myself a laptop with an SSD, I discovered that what my older Arch configuration could do on an HDD is what systemd could do only with an SSD.
but the "faster boot" you're remembering are actually a joke at the time. since the team working on it were probably booting vms all the time, the system was incredible aggressive on shutdown and that was the source of it. something like it reboots so fast because it just throws everything out and reboot, or something. i don't really care much for the jokes but that was why everyone today remembers "systemd is fast".
Nowadays if you start anything more serious from your user session (e.g. start a qemu vm from your user shell) it will get SIGHUP asap on shutdown, because systemd doesn't care about non service pids. but oh well.
...which is where the jokes about "systemd is good for really fast reboots" came from mostly.
It's trivial to run these as a user service, which can linger afterwards. Also, systemd has a configurable wait time before it kills a process (the "dreaded" 2 mins timer is usually something similar)
I'm not sure what you mean by "properly" but didn't initng and upstart (and probably some others I can't recall) do the parallel stuff before systemd?
Systemd already parallelises by default so I don't know what insanely strange things you were doing but I fail to see how it could bring boot time form 11s to 1 minute. Also, it's very easy to get a list of every services enabled with systemctl (systemctl list-unit-files --state=enabled) so I don't really know what your point about a giant graph is.
If you're working in the embedded space it's surely worth a little bit of time to optimize something like this.
All the smaller systems with no RAM run on baremetal anyway. There's no room and no need to run Linux or a threaded RTOS. Much less security headaches also.
Both x86 and Linux (page cache) rely on caches for performance.
I was running Emacs on a 486 with something like 16 MB of RAM. Don't remember the HDD size.
The Emacs executable I built from source is about 28 MB. Honestly I don't know what else is needed besides that executable that'd be really big.
Is it really that problematic that it wouldn't work with 512 MB of RAM and 4 GB of storage?
https://packages.debian.org/sid/emacs-common
(yes, it does fit, but it takes up way more space than I'd like...)
Ooh ooh, I know! It's to improve systemd for the use-cases outlined and build a really great open source init/process manager.
Also, at $DAYJOB, we run into mysterious systemd failures and misbehaviors at least once a year (usually for things that should be super straightforward). Every one of these failures and misbehaviors we've run into has been met with a "Wow. That's weird. Sucks to be you, I guess." with a dash of "No, we won't be updating the documentation to mention that." if the actual behavior is contrary to the documentation.
In short, while it may be true (I really don't know) that the systemd project welcomes changes and patches, IME it's pretty clearly true that if you're working on a problem that the project management doesn't understand, and/or doesn't want to think through, your work won't be considered. [0]
[0] Which, fine, it's not my project, so I don't get to tell you what to work on. Doesn't mean I have to like it or recommend that people use it.
> we run into mysterious systemd failures and misbehaviors at least once a year
The most detail my NDA permits me to get into is that our most recent failure was that the systemd cron replacement gets in a state where it refuses to ever schedule a scheduled task and that the systemd folks were like "aw, shucks" about it.
PS: personally I like systemd more that the script mess which preceded it. But the are some outstanding issues with it to be improved.
https://github.com/systemd/systemd/issues/8398
FWIW, I'm generally a fan of systemd. That's a pretty minor issue in the grand scheme of things and it's not really "mysterious" -- the behaviour was consistent but didn't line up with the documentation.
In my experience, almost every time I hit an issue with systemd, it's when I'm interacting with it at a (relatively) low level. e.g. Monitoring / controlling units via D-Bus. There is theoretically enough documentation to do that, but it's often incomplete or ambiguous and you're left trying to figure out systemd's behaviour via experimentation.
But as I said, this isn't _really_ a dig against systemd. Even if monitoring service state transitions via D-Bus is finnicky, it's a heck of a lot easier than the alternatives with busybox init or whatever.
People already did the latter (sadly no-one used it because there was no mechanism that forced distros to adopt it), and would do the former if the systemd maintainers would let them.
Why keep this huge monolithic system running in the background after it has served its purpose?
Also, with ai, would it be possible to redraw the lines within systemd between the separate domains/concerns, then redistribute the functions back to where they conceptually belong? Then you can refine those changes to make them more standardized and universal instead of interdependent and centralized.
Basically the author says that everyone else has stupid rants that doesn't stand but himself has valid claims so that in the end we have a proof that there are a few valid technical rants!
That being said, the main problem with systemd from the beginning is that it is a cancer. It was explicitly designed to prevent as much as possible the modularity and intercompatibility. Kind of opposite to the POSIX way even I think.
Despite what is pretended, doing the things would probably not have impacted features, like boot speed but it was key for them to shove through our throat the usage of systemd in a "all or nothing" way.
And udev or logind are good example of that.
- It’s built into BusyBox and is very lightweight - Configuration is dead simple (everything is basically shell scripts in the filesystem; no special config language) - Includes logging functionality with rotation - Easily controllable from other applications using named pipes - It’s an almost perfect embodiment of the Unix philosophy: a series of small, single-purpose executables (svlogd, runsv, runsvdir, etc), with no strange config file formats or protocols.
Regarding udev, it’s entirely possible to run an embedded system without it if your device has a fixed set of peripherals, doesn’t need to handle hotplugged hardware, and uses a fixed set of kernel modules. In Yocto, you can define a dummy device manager recipe and boom, no udev. As a bonus, removing udev can shave several seconds off your boot time.
The RAM usage isn't being calculated correctly. You can easily run systemd on very limited systems.
As for systemd, it's an interesting set of tools, and one can if one wishes pick which ones are active in a system, if that system is complex enough to be running Linux (or other compatible OS) to begin with.
It is basically about small tools, limited in scope, that solve a problem surgically and comprehensively. They work together by mixing and matching to solve the problem.
systemd is sort of like if microsoft word took on system init. In the beginning it was small, but now it is web based and does videoconferencing.
I don't know, it is sort of like busybox, replacing other system components in a limited Minimum Viable Product way, but more like limited function, not limited resources.
And it's slow. Windows 11 boots in 5 seconds on my laptop, Ubuntu 22 used to take about a minute before I finally made the switch.
The command to list services enabled on boot is also completely esoteric: systemctl list-unit-files --state=enabled
On VMs you can get to within 200ms for a full system.
You can use `systemd-analyze critical-chain` to visualize the boot process. The slowdown is likely caused by something unexpected.
Try measuring a reboot instead. On modern Windows versions with “fast startup” enabled, the “Shutdown” button is a lie: it logs you out and hibernates the system instead of actually shutting it down. (This is important if you dual boot, because it means you can’t safely access the Windows partition in the interim.)
I'm okay with that. How do I enable this on Ubuntu?
Same goes for service startup - why does start-stop-daemon discards stdout/stderr instead of logging it? This would be trivial to fix, but somehow this was not available until upstart (and then systemd) did it.
Some of the oldest init systems made decisions that were sensible at the time but not so much now, e.g. when storage is hundreds of thousands of dollars per GB you don't want to log everything, when it's tens of cents per GB you do. But you can obviously make a non-monolithic init system that causes output to be stored to a log instead of being discarded.
So then systemd comes in, solves some of the old problems and independently, unnecessarily introduces new ones by being a huge monorepo that lacks clean and stable interfaces between its own components, inhibiting anyone else from providing a viable competing implementation of an individual component.
Then people complain about the latter and the defense that comes back is of the former. But that's no defense -- we could instead be making the good change and not the bad change.
That's exactly what Microsoft did back in the era with Word and others, just like GP stipulated.
It's actually a suite of tools that do solve individual problems comprehensively. Not as small as the programs in coreutils, but still not a huge monolith.
for example timesyncd is barebones and not super accurate when it comes to timekeeping, while chrony and ntp actually manage the system time.
similar - systemd-boot is barebones, systemd-networkd is barebones (but has gotten more MVP-featured in a busybox way), etc
Maybe 10 more years and everyone will be used to things, and people won't be arguing about chesterton's fence.
https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_...
It's a suite of tools created with hate to the unix philosophy. That's something that all of them have in common. There was no reason to create systemd timers as cron worked just fine for decades.
It's a suit of a tools each doing one thing and communicating together via a message bus. How exactly is that hating the "unix philosophy" whatever that means? From where I stand, it's extremely close to the way Unix has ever done things. The design is even directly lifted from the boot system of a certified Unix.
Thus they are created out of political or ego reasons.
There's a major disconnect, I've seen, from what systemd haters proclaim and what is reality. Nobody is forcing anything, you don't have to use 99% of systemd, it's not a monolith, and many people do want the features. To be clear, this isn't my opinion - this is the truth. You can find all this out by perusing the repos and mailing list.
Really? I have yet to see one. Kids, maybe. Experiences sysadmins may appreciate systemd as PID1, but almost everything else is pure cancer.
> There's a major disconnect, I've seen, from what systemd haters proclaim and what is reality.
I can certainly agree with that.
> Nobody is forcing anything
... until distro maintainers decide to move crucial tasks to systemd-timers from cron, change resolved to systemd-resolved, switch from ntpd to whatever its called, remove sudo in favor of another systemd thing, etc. But sure, you are free to not use any. Except the only *nix thing left is the Linux kernel. Soon to be systemd-kernel.
I've been building and automating data centers for years now. Systems has greatly simplified my life. I use all of the systems tooling; timesyncd, networkd (which is actually does _more_ unlike what is stated above, go read the man page), timers (better than cron, again go read the man page) resolved.
Not only does it solve a lot of problems, the configuration file format consistent across the tools, and the configuration is consistent _across distros_. I can write large swaths of automation that just works on most modern Linux distros.
Anyway, I'm not one to argue on the Internet. But I'm absolutely tired of hearing that's it's a dumpster fire. Sure, there are legitimate complaints and use cases where it might not be a good fit, but that holds true for all software. But, there is a reason so many distros switched to it. It's objectively better than the way things were. Those of us that deal with this stuff day in and day out are not going back to the way it was.
"Unix philosophy" is throwing crap at the problem, until it kinda-sorta works on the developer's machine.
The best designs, sadly, don't win out. The ones that win out are the ones that serve the interests of the largest players. And the largest players are usually RedHat, Google, and other vendors, who just want to get "their" needs met and move on. They couldn't give a fig about compatibility with some other random tiny project, or an embedded device. And those people working on tiny projects aren't in the room when "standards" are decided for the entire community.
There are some hold-outs. Slackware went a long time without it, but next release will unfortunately use systemd. I've run Alpine Linux (systemd-free, so far) as my laptop OS for years. I'll probably switch to another distro that's more user friendly, is easier to contribute to. But it's embarrassing and annoying that we have to pretend to be systemd-compatible just to run a desktop. We should call it "GNU/Systemd/Linux" since it's now one big monolith.
So it would seem the GP has been taken in by some rumor somewhere.
[1] https://ftp.ussg.indiana.edu/linux/slackware/slackware64-cur...
README.TXT [2] also does not contain the string "systemd"
ANNOUNCE.15.0 [3] also does not contain the string "systemd"
If such a 'note' were included in the last release (15.0) it should have been in one of the above three files. So there is nothing in the release that appears to indicate a shift to systemd.
[1] https://ftp.ussg.indiana.edu/linux/slackware/slackware64-15....
[2] https://ftp.ussg.indiana.edu/linux/slackware/slackware64-15....
[3] https://ftp.ussg.indiana.edu/linux/slackware/slackware64-15....
Also unlike the complaints about systemd in the article, Wayland is well suited to embedded. Automotive Grade Linux was an early adopter. It's desktop usage that has taken longer.
Taking notes on which distros dont run systemd, for when I want to make some money over christmas.
https://security.gentoo.org/glsa
https://security.archlinux.org/issues/all
^ (ctrl+f systemd)
Among the components of systemd, the part that has the lowest added value for our use is dbus. It's designed primarily for desktops and useless for most of our systems, but unfortunately, it is also a hard requirement for systemd.
If you want to do the size of embedded where this matters, you also probably want a smaller libc like musl, and then buildroot and busybox are your friends.
Is this even a serious post.
> The majority of Linux users are uninterested in the pros and cons of systemd. A small number are violently opposed to it, and a small number are violently opposed to those who are opposed to it.
Starting out by framing systemd in terms of opposition deliberately steers attention away from the issues that drive its adoption. The tone is moderate, but this is not good faith argumentation.
> I think there’s little argument that the main target for systemd is a general-purpose computer, with a modern, integrated graphical desktop
That is one of the targets. The main target is servers that run the web of services typically required to back up modern applications. What if an application depends on a resource server which itself depends on a remote filesystem being mounted and an event service running. Theoretically that can work with System V init, but how tricky is that to put in place and make robust? Administrators for systems vending complex interdependent services are the main target and always have been.
> Unfortunately, what makes systemd good for general-purpose desktop applications
Get it wrong and then run with it. Failing to understand what is driving adoption of systemd leads to arguments about it that don't really go anywhere.
> The more fundamental problem is that the people who most like systemd are distribution managers. Sure, there are administrators who like it, and defend it vigorously; but most end users and administrators don’t really care.
Not distribution managers, but system administrators. They are the ones with the complex needs that systemd serves. As such they advocate for it and because of the lack of working alternatives distribution managers switch to it in order to please the largest number of clients. Thinking of systemd in terms of desktop systems and distribution managers means misunderstanding why it is there in the first place.