101–110 of 332 posts
I am old enough to remember that problems with systemd were less technical and more political. People didn't like the way systemd developers pushed the community to adopt systemd, specially when they asked for 3rd party developers to make systemd a hard dependency. Unfortunately,people don't remember this today, and think users resisted to systemd adoption only because they didn't like systemd.
I am old enough to remember that problems with systemd were less technical and more political. People didn't like the way systemd developers pushed the community to adopt systemd, specially when they asked for 3rd party developers to make systemd a hard dependency. Unfortunately,people don't remember this today, and think users resisted to systemd adoption only because they didn't like systemd.
We are talking 10 years ago, not 1975 here. Unless everybody is 25 years old on HN...
It’s tolerated because it was forced upon people by distros. I don’t know anybody who likes it, and I would happily rip it out if it wasn’t so much work to do so.
Earlier quoted context omitted.
I use archlinux as a daily driver, but it breaks far more randomly than gentoo ever did for me. Archlinux's bugzilla is full of random breakages that happen at random system updates. Here's a random python bug that been happening, cost me a couple of hours to debug and for now I don't update python until they get around fixing it[1]. The fix? Download an older python version(not too old since that would break everyth…
The official Arch stance seems to be "You should have read the blog before updating", and I enforce that by updating maybe 3 times a year at most. I think I'm just used to the installer. I like doing everything by CLI. Ubuntu is always trying to push something odd like Snap, and I think Xubuntu is defunct. The Ubuntu installers are very opinionated on what kind of desktop they want you to have. One of these days I'll…
Earlier quoted context omitted.
...so, how does a systemd unit definition differ from a Makefile (other than using a different syntax, obviously)? What features would you need to add to UNIX make (and PID 1, for that matter) in order to be able to separate out this whole dependency management business from the other stuff PID 1 has to deal with already?
For one thing make is imperative and doesn't actually know what it's doing. Systemd is declarative. You'd need to replace all the options service files give you. Make doesn't do dependencies between unrelated projects. A makefile can't say "I want to run if X runs, but I should run before them". Make doesn't have supervision, you'd need some kind of declaratively configured poller. Systemd is also parallel, there's p…
Polling is better-addressed by having each service implement its own error handling. Restart loops are the wrong policy for most services. In the rare cases where they are actually the correct behavior, they’re trivial for the service author to implement.
Those that don’t understand make are doomed to reimplement it poorly.
Earlier quoted context omitted.
...so, how does a systemd unit definition differ from a Makefile (other than using a different syntax, obviously)? What features would you need to add to UNIX make (and PID 1, for that matter) in order to be able to separate out this whole dependency management business from the other stuff PID 1 has to deal with already?
My devuan linux desktop says something like this on each boot: INIT: version 2.88 booting Using makefile-style concurrent boot in runlevel S.
I may try it again one of these days now that the latest Devuan stable is based on Debian Bullseye.
The "why" is simple: to restore some balance in the force.
I do prefer my Linux world to be one where I still have a choice as to which init system and PID 1 my system is running.
I am old enough to remember that problems with systemd were less technical and more political. People didn't like the way systemd developers pushed the community to adopt systemd, specially when they asked for 3rd party developers to make systemd a hard dependency. Unfortunately,people don't remember this today, and think users resisted to systemd adoption only because they didn't like systemd.
Network configuration (on say, Debian) is still a pain and has a lot of different ways of accomplishing similar tasks. Anything beyond the plain vanilla singular network device that is either dhcp/static is often painful. Systemd has some sauce, there is legacy /etc/network* stuff, there are daemons which can be configured graphically… it’s still a mess. In this arena, I think systemd has failed for the last decade.…
Defining a straightforward configuration structure for that complexity is going to be insane. NetworkManager + Debian's /etc/network/interfaces (IMHO) seems to be a good fit: auto config w/ a GUI in NM in the simple case, and if the interface is listed in /etc/network/interfaces, you can do it anyway you want with Debian's system, with pre-up, up, post-up, post-down, etc scripts to your heart's content to setup whatever complexity you need.
Earlier quoted context omitted.
It’s buzzword bingo with the aim to inflate the writer’s ego and intimidate the reader. This stuff happens all the time when insecure people get to write things.
Exactly. “Idempotent” is one of the key words used as a cudgel in this way. It’s great for the bullshit artist, as to a layman the dictionary definition is completely inscrutable.
Earlier quoted context omitted.
> If you are doing something weird it can make your life a living hell. I find it much easier to reliably accomplish non-standard things with systemd unit definitions, than it used to be with the ill-defined complex set of shell scripts we had before.
This issue is a lot bigger outside of services... I think the systemd service architecture is a clear improvement over SysV. The bigger issues I run into with systemd flexibility are related to the many other aspects of it. systemd-resolved, for example, has a very "opinionated" (to be polite) set of expectations about the environment and the systemd project tends to view any complaints about it not working outside o…
But, I am 100% agreement on the whole resolvd thing. It is a complete fiasco for anything but someone's idea of a standard network.
Even the most basic things, like waiting for DNS to be up before mounting a network filesystem has to be done by writing your own units if you don't want to just try and mount and hope for the best.
Earlier quoted context omitted.
SystemD is kind of like MacOS, if you have a typical use case then it makes everything very easy. If you are doing something weird it can make your life a living hell.
Can you give some examples?
I’m sure there are many other examples.
Honestly, even after 10 years, I still have’t had a single positive interaction with it vs. traditional init. From what I’ve seen, old-school init handled (and continues to handle) the problems systemd “solved” more robustly and elegantly. I don’t get it.