it's also why corporate software is so shit - it's shiny in all the ways it needs to be shiny for management to make the decision, but it's a pain for the actual users.
the trick in both cases is to know your customers!
the trick in both cases is to know your customers!
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.
> 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.
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.
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?
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.
See : the current apocalyptic and accelerating global biomass destruction directly caused by industrial farming.
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.
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.
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.
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.
/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.
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).
"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.
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...
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.
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.