> Why would a server use a different init system than a desktop or embedded device?
The futzing around with resolv.conf(5) for one.
I take to setting the immutable flag on the file given all the shenanigans that "dynamic" elements of desktop-y system software does with the file when I want the thing to never change after I install the server. (If I do need to change something (which is almost never) I'll remove/re-add the flag via Anisble's file:attr.)
Of course nowadays "init system" now also means "network settings" for some reason, and I have often have to fight between system-networkd and NetworkManager on some distros: I was very happy with interfaces(5), also because once I set the thing on install on a server, I hardly have to change it and the dynamic-y stuff is an anti-feature.
SystemD as init replacement is "fine"; SystemD as kitchen-sink-of-the-server-with-everything-tightly-coupled can get annoying.
> Why would a server use a different init system than a desktop or embedded device?
The server and desktop have a lot more disk+RAM+CPU than the embedded device, to the point that running systemd on the low end of "just enough to run Linux" would be a pain.
Outside embedded, though, it probably works uniformly enough.
Why compare a "full-featured", do-everything OS like Ubuntu with something pre-systemd when you're concerned about memory consumption?
I just checked a random debian 12 system (with systemd) running a bunch of services at home, and here's what I see:
$ free -m
total used free shared buff/cache available
Mem: 3791 320 2235 1 1313 3471
Swap: 99 0 99
Seems like usage is pretty much on par with your expectation. The largest consumers are systemd-journal which is storing logs in RAM, and filebeat which is relatively wasteful w/ memory. systemd itself (without the journal buffer log) consumes maybe 20-30 MB.
On one (coreelec) systemd has 7M of resident data, of which 5.5M are shared libraries; by comparison, the numbers for sshd are respectively 6M and 3.5M.
On an OpenWRT machine without systemd (it's using procd) there are 700k of resident data. So the "cost" of systemd seems to be ~5M. Certainly I wouldn't run systemd on an old router with 16MB of RAM, but the cost is two orders of magnitude less than 1G-300M.
If this is a hard job for you well maybe get another career mate. Especially now with LLMs.
The thing to me is that services sometimes do have cause to be more complex, or more secure, or to be better managed in various ways. Over time we might find (for ex) oh actually waiting for this other service to be up and available first helps.
And if you went to run a service in the past, you never know what you are going to get. Each service that came with (for ex) Debian was it's own thing. Many forked off from one template or a other. But often forked long ago, with their own idiosyncratic threads woven in over time. Complexity emerged, and it wasn't contained, and it crrtainly wasn't normalized complexity across services: there would be dozens of services each one requiring careful staring at an init script to understand, with slightly different operational characteristics and nuance.
I find the complaints about systemd being complex almost always look at the problem in isolation. "I just want to run my (3 line) service, but I don't want to have to learn how systemd works & manages unit: this is complex!". But it ignores the sprawl of what's implied: that everyone else was out there doing whatever, and that you stumble in blind to all manners of bespoke homegrown complexity.
Systemd offers a gradient of complexity, that begins with extremely simple (but still offering impressive management and oversight), and that lets services wade into more complexity as they need. I think it is absolutely humbling and to some people an affront to see man pages with so so so many options, that it's natural to say: I don't need this, this is complex. But given how easy it is, how much great ability to see the state of the world we get that SysV never offered, given the standard shared culture tools and means, and given the divergent evolutionary chaos of everyone muddling through init scripts themselves, systemd feels vastly more contained, learnable, useful, concise, and less complex than the nightmares of old. And it has simple starting points, as shown at the top, that you can add onto and embelish onwards as you find cause to move further along the gradient of complexity, and you can do so in a simple way.
It's also incredibly awesome how many amazing tools for limiting process access, for sandboxing and securing services systemd has. The security wins can be enormous.
> Because last time I wrote systemd units it looked like a job
Last, an LLM will be able to help you with systemd, since it is common knowledge with common practice. If you really dislike having to learn anything.
Yeah, I've been using Claude and Codex to create bespoke systemd services for my random tools and automation stuff and have been really impressed by how easy it is and how rock solid they are once setup. It's really nice not living in constant terror that a reboot, network connectivity loss or gentle breeze will cause my duct taped scripts to collapse under their own weight.
I dunno man. The past was a shit show & you seem extremely resistant to trying at all.
I struggle to figure out what it is that the systemd haters club actually struggles with, what is actually the hard parts. I do in fact sometimes use a 3 line .service file and it works fine. It feels like there is a radically conservative anti progress anti learning anti trying force that is extremely vocal that shows up all the time everywhere in any thread, to protest against doing anything or learning anything. I really really am so eager to find the learnable lessons, to find the hard spots, but it's almost entirely the same low grade discursive trashing with no constructive or informative input.
It feels like you use emotional warfare rather than reason. The culture I am from is powerless against that if that's all you bring but I also feel no respect for a culture that is so unable to equivocate what the fuck it's problems actually are. Imo we all need a social defense against complaints that are wildly vacuous & unspecific. Imo you are not meeting any baselines for taking your whinges seriously.
Until you need to actually dive deep into complicated scenarios. In sysv init you were on your own, which could be for better or for worse. In the world of systemd you either do as LP says or you do not at all.
That was almost 15 years ago and the support is evidently not as useful.
Also it's entirely contained within a program that creates systemd .service files. It's super easy to extract it in a separate project. I bet someone will do it very quickly if there's need.
I don't know how to verify what the website does, but I think that in a few minutes I'll be able to put together a CURL call that does what we're hoping the website does.
> We used to have 12-16+ hour workdays, no days off, etc. None of that is true anymore - the great battles have been fought and won, and nobody is going back.
The 8 hour workday is not guaranteed to office workers anymore.
Exactly. It is already wasting enormous amounts of energy for silly inefficient AI nonsense. The price of energy will go up due to high demans and at the same time it also produces a lot of heat. I am not seeing a very optimistic future for mankind...
> It carries all of the biases us humans have and worse the biases that are present in the information we chose to explicitly share online
This is going to be a huge problem. Most people assume computers are unbiased and rational, and increasing use of AI will lead to more and larger decisions being made by AI.
Strict liability by IP address is not the norm, not even in Germany any more. It's not illegal to have a botnet infect your computer either. Since they promise not to use your connection for illegal things, it's their fault if they break that.
> the person / team who would go on to actually crack brain-like AI would be remembered closer to Hitler than to Einstein
I completely agree. I think that the people who are funding AI research are essentially attempting to create slaves. The engineers actually doing the work have either not thought it through or don't care.
> Assuming it comes with consciousness, which I think is fair to presume, brain-like AI seems to me like a technology that shouldn't be made.
"Fair to presume" is a good way to put it. I'm not convinced that being "like a brain" is either necessary or sufficient for consciousness, but it's necessary to presume it will, because consciousness is not understood well enough for the risk to be eliminated.
> Windows is permanently segregated to a VM for development
Have you been able to get a debugger working for this? Last time I tried to develop C++ this way, the Visual Studio debugger would not work from within a VM.
In the Boston area, the bus drivers seem particularly likely to react to this by the second bus passing the first (even by crossing a double yellow: traffic laws are generally optional here).
In the article this is presented as a symptom of how bad the bunching is, but as a rider it feels like this helps the problem: new riders are now getting on the bus that's less full.
Passing would only be a temporary solution since the new front bus will now have the delayed position, and the more crowded bus that was passed will have the expedited position and will shortly overtake the front one. They will essentially travel at the same rate and stay bunched in this scenario.
It might make more sense, when the delay to the front bus gets to within a given time of the rear bus' expected arrival time (maybe 1 minute, maybe more, maybe less), the lead bus simply switches to a state where it only picks up when a stop is requested by a passenger until it gets to within some time differential from its scheduled arrival time.
That would suck for some people to watch it pass but realistically, if it wasn't skipping stops, the wait for leap-frogging platoon would be closer to that off the rear bus anyway.
Can't speak to the Deck HW or Steam OS specifically, but the SilentPatch and GInput mods have been working great for me on Proton under Linux Mint.
[0]https://cookieplmonster.github.io/mods/gta-vc/
reply