Comment Re:Fade Away (Score 1) 41
No, probably not. Most people have made their peace with systemd and I think it'll persist.
No, probably not. Most people have made their peace with systemd and I think it'll persist.
But you are not making sense. (And it's "Her", by the way, not "Him".)
As the person I replied to pointed out, if systemd doesn't quite do what you need, you can always fall back on a script. So the common use cases are easy and the uncommon ones are possible.
Now I personally have not encountered a use case that systemd couldn't handle natively, but I'm willing to admit that such use cases exist, in which case... you use a script that you call from a systemd unit. Problem solved.
I never began as a "proprietary UNIX guy" for two reasons; one is that I'm not a guy and second is I used SunOS and Solaris mostly as a student and a little bit on the job, and this was back in the day before SMF, etc. when the system was much more BSD-like.
The problem with appealing to "the UNIX way" is that nobody really knows what that is, beyond a few vague generalities. Systemd itself is not one monolithic program, by the way. It consists of 38 small purpose-built executables (on Debian 13, anyway), all of them under 1MB in size. Though I guess they do dynamically link to a bunch of other stuff.
I'd say a lot of small purpose-built tools is "the UNIX way"
Anyway, I'd rather use a system that accepts changes than one that's doctrinaire and rigid and becomes ossified.
I agree with you about the binary logging. Not everything about systemd is better than what came before, but also, not everything is worse.
You can still have plain-text logging and AFAIK Debian still generates the normal plain-text log files by default.
I also get annoyed with ifconfig and ip, and iwconfig vs iw, etc. but AFAIK those are not Poettering's doing and are not related to systemd.
BTW, I think the reason for ip instead of ifconfig and route was to add support for different routing tables, which are supported by the Linux kernel but were not supported by the old userspace tools.
And also, the ipchains / iptables / nft transitions were annoying. But c'est la vie.
ELI5 means: "Explain Like I'm 5"
Appealing to "the UNIX way" is just silly. UNIX has been around for over 50 years, and it evolves as people figure out better ways to do things.
The problem with systemd and unit scripts is that they cannot do all the things that a script can do, so you often wind up using a script anyway.
I would say: very rarely, not often. Looking at the units on my machine, none of them uses an auxiliary script to start or stop a service.
My devices are Sonoff S31s that cost me $7 apiece at CloudFree, though I see the price has been raised to $11, or $14 if you want them pre-flashed with Tasmota or ESPHome. (I did the flashing myself.)
Also, the critical server in question happens to be a Raspberry Pi, so to power-cycle it remotely pretty much means doing it at the outlet.
Systemd units are plain text files, you know.
I honestly don't understand the visceral hate for systemd. I've been using UNIX since 1989 and Linux since 1994, so I have plenty of experience with old ways of doing things.
Systemd, at least in my experience, just works and writing systemd unit files is easier than writing sysvinit scripts. So when Debian switched to it, it was fine. I adapted.
I used software to turn on and off a light on an irregular schedule while I was away on holiday. On at 30 minutes after sunset and off a random time between 11:00PM and 12:30PM. Makes the house look a bit more lived in and was fun to script.
I have some remotely-controllable WiFi plugs. I use them in emergency to power-cycle my main server if I'm far from home and the server locks up. There are good uses for remotely-controllable plugs and switches.
But they don't rely on any cloud provider; they run Tasmota and I control them directly via their Web interface or API.
OK, I know the article says some routes are "difficult or expensive to electrify" but I have to call BS on that. Surely it can't be more difficult or expensive to use an old, proven technology rather than batteries and high-power chargers?
Or, you could use these magical things called overhead wires or the less-obtrusive third rails to supply energy to the train along the entirety of the route. And not even need batteries.
Why batteries? We've had technology (called "wires" or "third rails") to deliver electrical energy to trains for about 100 years now. Why not just electrify the route?
Cory Doctorow or his writings have appeared in The New York Times, on CBC, on the BBC, and in The Atlantic. I guess none of those count as "major media", eh?
It seems that more and more mathematicians are using a new, high level language named "research student".