|
Top-level
 and, frankly, whatever you want to say about @pid_eins, he is one of the rare software engineers who understands both the technical aspects of creating software and also the usability aspects. this is something that every other proposed service management framework lacks. it’s not necessarily a bad thing, but it is good to have a maintainer at the top that has good taste in both departments. 93 comments
 @luis_in_brief 😭:but I have to run systemctl daemon-reload after I edit a config file for the changes to take effect.  @c0dec0dec0de @luis_in_brief @ariadne auto-reload only makes sense if every possible change you could do touches a single file only. That might be fine for trivial services. But for anything even remotely more complex than hello world you might need to edit two config files, a service file or two, and you really don't want anything to load the cfg while you are just half-way done. Explicit configuration reload is a *good* thing, it allows you to schedule application of multiple changes as one  @pid_eins @c0dec0dec0de @luis_in_brief @ariadne Not only that, I also reflexively save multiple times while editing config files, often with them in unworkable intermediate states. @dysfun i’m not wrong though. i am not saying systemd is *good*, but the tooling around it feels solid. much more so than openrc, or any of the other hobbyist projects. @dysfun in general i think it is his strongest quality. he knows enough to get things going on the development side of things, but where he does his best work is in designing tools. @dysfun pulseaudio failing to route audio doesn’t mean that pavucontrol wasn’t a well designed mixer 😂  @dysfun avahi doesn’t have any UI of its own, it hooks into gtk and qt file choosers. distributions also misconfigured avahi in many cases. i can’t actually put that one on him because i’ve seen how the sausage was implemented. @ariadne it has a dbus interface. i'm not very fond of dbus either. @dysfun i mean, same? but that ship sailed well before lennart entered the picture  @leftpaddotpy @ariadne @dysfun And it was all modelled on COM by folks who thought Windows was doing things that made sense... @dalias @leftpaddotpy @dysfun well, DCOM really, which is an entirely different animal @leftpaddotpy @ariadne @dysfun There is really a clash of two *philosophies* here: One that believes software systems should be tightly coupled with every piece of software interacting with the events and data of one another, mediated through object oriented abstractions. And one that believes software should be decoupled, staying out of each other's way and exchanging data and reacting to events only through standard data formats and system interfaces. @leftpaddotpy @ariadne @dysfun The former is largely seen as "polished" and "professional looking" and "user-friendly" by techies and industry UX folks. But it also enables a lot of really user-hostile behavior. @dalias uhhhhh > software should be decoupled, staying out of each other's way and exchanging data and reacting to events only through standard data formats and system interfaces. "standard data formats". do you mean "text", for which you have a "broken handrolled C parser full of CVEs" because it's not actually structured *or* standard? or is there some magical format I have forgot about? dbus is a standard data format. the systemd-standardized interfaces are a standard, structured format. @leftpaddotpy Um, you're reading some weird ideas you had in your head into what I said...? @dalias every time I see people accusing systemd of not using the standard APIs, the so-called standard APIs in question did not exist before, and the functionality was, prior to systemd, achieved by the client software mutating things in such a way that assumes they were the only possible client (e.g. /etc/resolv.conf with VPN software, vs under systemd-resolved) I simply do not understand your argument. @leftpaddotpy The dbus protocol framing/transport is a "standardized data format". The addresses you interact with over it are *explicitly named for application software* that you're communicating with. And forget about whether it's standard or not, it's not even a data format. It's a command channel. @leftpaddotpy What I mean by "standard data formats" vs tightly coupled applications goes back to the early Windows idea of "inserting a paintbrush object" into your Word document rather than "inserting an image file in BMP format". Or the early Mac idea of resource forks identifying an "owning application" for a file rather than the data format of the file. @ariadne @dysfun hm. Somehow my perception is very different here. The time I've sunk into trying to figure out why systemd is (or is not) doing something while wrangling service files is… significant. And pretty much all of my bubble shares this view: it's great while it works, but as soon as something goes wrong you're left digging for scraps of rare helpful output and trying to divine from manpages what is going on. The tools are /horrible/ at telling you /why/ things are as they are. @dysfun @equinox we have had conversations with him over the years and he has largely come around to seeing our thinking on a number of issues, which led to pmOS feeling like they could pull the trigger. i worry more about openrc having basically no maintenance and the code being a minefield of potential CVEs than dealing with lennart on a bad day. i can’t stress this enough. one of the guiding design principles in alpine is that if you have to read a manpage to perform a basic operation as a user, we have already failed. the competition to systemd in service lifecycle management is largely a minefield of tools with cryptic command line switches and other potholes. the tools do not feel good to use. we want a service management system that feels as good to use as apk. there are of course, valid criticisms of systemd. the fact that so much userspace surface is contained in a single project is unpleasant from a technical and governance POV. however, systemd itself is highly modular. the core service management framework is only a few megabytes on disk, which is comparable to openrc. so the people who complain about bloat are likely just not using a properly packaged form of systemd…  @ariadne modularity of some chunks of code is kind of moot when such fundamental parts of the kernel interface (eg. udev) no longer work standalone.  @ariadne @spacehobo but systemd doesn’t actually do that. its a monorepo, but it generates tons of binaries. @ariadne Yeah, I was hoping to wave hands a little wider than I did with the word "runtime", really. @ska @ariadne OK, I did not expect to read that today: that sd_notify() is "over-engineered" and "bloated". It's *literally* a frickin env-var-like text string in a datagram to an AF_UNIX socket whose path is passed in an env var. I mean, I can explain the protocol this in a single (one!) sentence. If that's "bloated", then I think you are smoking some really really really good dope, man. No shame in that, but maybe don't comment on the Internet when you do ;-) @ska i don’t think your sd_notify example holds. a child supervisor could hoist the socket along to its parent to solve this problem using SCM_RIGHTS. > This assumption means that the only way to implement readiness notification management in systemd is to have a central supervisor for all the services, which is the exact opposite of modularity. Just set NOTIFY_SOCKET to the socket implementing the trivial protocol, which can be named at random? There is no reason this protocol is at all incompatible with multiple decentralized managers? You just run a socket on each? I can't understand the problem here. @ariadne as a long-time systemd hater I tried out Void, which is on runit, and discovered to my displeasure that the Old Ways are actually super annoying and systemctl is actually a very wieldy way to manage services… but there’s also part of me that appreciated having a system where you could quickly figure out how to enable or disable a service by inspecting its peers in the filesystem. I think systemd is equally guilty of needing a manpage check – I’ve had to google how to read logs so much    @ariadne Lennart is one of the kindest people I've ever met. And this is when he'd have all the rights in the world to be the exact opposite, yet he does not. |
Gregory's Server
@ariadne @pid_eins More than anything else, this is the thing I just don't understand about the nostalgia for the Old Ways. Gigantic-pile-o-shell was just ... *terrible* from a usability (not to mention maintainability and debuggability) perspective.