311–320 of 357 posts
Earlier quoted context omitted.
I'd love to see a later development of a proper system manager that learns from systemd's faults and allows for compatible interfaces for transition. Much like Pipewire exposes PulseAudio interfaces but is implemented differently.
To me it's the other way around -- pipewire is the sound server equivalent of systemd. For better or for worse.
Earlier quoted context omitted.
Care to elaborate? Off the bat, your comment comes across as a cynical rant due to its high use of strong words (garbage, fuck) and lack of examples. And even if you have anecdotes, to be convincing, it would have compare something like bug density to the software projects that collectively replaces. As written, your statement is unlikely to convince anyone that isn’t yet already.
It's a pile of proof-of-concept broken pieces duct taped together into a big mess. Here's an example: Someone read that fd-passing is a thing, so now systemd listens to just about everything and spawns stuff on-demand. Now, that may seem like a good idea, if you think it up in a vaccuum and don't have experience with the real world. It's a great idea, if you're in high school. But to have it actually accepted? WTF is…
This feature benefits some people. Even if your service requires socket activation, you can still set the service to startup and you can still control it with normal command lines.
> It's a great idea, if you're in high school.
You make this accusation twice, but you give no-one any reason to believe it (unless you think "using an optional feature I don't want to use and which isn't significantly easier to use than to not use" is a reason, but most people would say that it is a good example of flexibility).
> And then restarting daemons with systemctl almost to a rule fails, and fails silently.
I have encountered an issues with using `service blah restart` on Ubuntu, which means if it isn't connected to an interactive session it doesn't work properly. I was able to fix this by switching to `systemctl restart blah`. Perhaps you're experiencing something similar? I imagine Ubuntu's service wrapper is probably taken from Debian so it could be quite widespread.
The fact that `systemctl (re)start` doesn't always give useful feedback is irritating. I am usually too bothered by something not working to have noticed when and why it gives no output about a failed service. A command should always output something on error and it should be sensitive enough to notice whether it has succeeded or failed.
> Linux too "just needs a reboot every now and then to kinda fix whatever got broken".
This is another accusation you make twice. I have been using Linux since the 90s, and I cannot agree that we have to restart Linux distros more often now than before. Can you give any examples of circumstances when you choose to reboot?
> You're asking me to be data-driven, while being fully aware that systemd isn't, right? Your argument is essentially fallacy by implying that status quo is data-driven.
Systemd might have been adopted on theoretical grounds. But that doesn't mean that an empirical objection is useless or irrelevant. If you can show that the theory doesn't match the data, or the data is worse for systemd than some alternatives due to unforeseen consequences or the difficulty of dealing with the larger spec, then this might lead to improvements to systemd or adoption of some alternative.
> At the same time I also fall into group (2), above. I don't have time to wrestle in the mud with people who don't care.
You don't fall into group (2) above. Group (2) is a subset of people who do not complain about systemd, but you are complaining about systemd. Moreover, your comment slings a good lot of mud, so it's hard to take that as a valid objection. You at least should work to clean up the mud you threw unnecessarily.
Earlier quoted context omitted.
In addition to s6 itself, the author of s6 also wrote a survey https://skarnet.org/software/s6/why.html > that provides a good large-scale view of the design space. (My gripe with how systemd does a traditional init’s job is mostly the unit and dependency types, all of which AFAICT are specified in terms of actions on state transitions, not consistency conditions on states, so for all that it has a positive boatload…
I stopped reading when they started attacking bind. Sheer ignorance. Also cathedral is good for him and his elite team but not in general? Unix has always been worse is better. You may disagree but it is the secret sauce. YAGNI for that potentially ideal system. Sadly. I like mathematically solid systems but the people with good enough systems explore the solution space much quicker.
Indeed I don’t even necessarily agree with everything said on the page I linked to (which I did reread before posting the comment), but regardless of what I think about the particular point in design space (s6) it advocates, I still consider it a good overview of the space itself and prior art in general, and that’s the only thing I claimed to offer. I do have some thoughts about init systems, but I don’t feel they’re ready to put them up for discussion here, so I haven’t.
Earlier quoted context omitted.
If it provides sufficient benefits (which systemd does), it is a no brainer.
As a technical matter, sure. As a business/ management matter, we frequently cannot do the technically obvious thing due to other constraints.
Earlier quoted context omitted.
Agree with that. It breaks catastrophically. But it's also overengineered. Like starting a daemon on first connect is "neat trick", but should never have gone beyond that. Like: oh, I want to restart this daemon, because I want it to re-run its init code (possibly with new settings), but you CAN'T, because some idiot decided that it'll only actually start when someone connects to its unix socket, so running "restart"…
> but you CAN'T, because some idiot decided that it'll only actually start when someone connects to its unix socket, so running "restart" is a no-op. FTA: > It can then boot your service on the first request, or you can do systemctl start lunchd yourself if you think that would take a while.
Sounds like you're arguing something like "yes, it's broken. But you can just reimplement everything and it won't be broken anymore".
Yes, I can also turn off "kill user processes on logout", but that doesn't make that not-broken.
Earlier quoted context omitted.
But I would also like to see data showing how often desktop users reboot (on purpose, that is, not because systemd or something says "you should reboot now" because it's shitty software that doesn't just work cross updates). Like, who even boots their computer anymore? Isn't the typical user on a laptop, and just suspends it? My workplace even had to install corp software that forces a reboot every N days (with warni…
> So to me this really looks like it applies neither to servers nor desktop. It applies to both. We need desktops to boot up fast, because you said it yourself, sometimes they just need to. And no one likes waiting around for their machines to boot. Can you imagine the volume of complaints about long boot times that would come in to large-scale distros from annoyed users? That alone makes it a high priority. And on t…
I didn't say that. Because they don't.
> And no one likes waiting around for their machines to boot.
Nobody cares, if it's once for every month or two. Which it is.
> we need servers to boot up fast
But it's not actually booted until the service is up, so it's moot.
Earlier quoted context omitted.
It's a pile of proof-of-concept broken pieces duct taped together into a big mess. Here's an example: Someone read that fd-passing is a thing, so now systemd listens to just about everything and spawns stuff on-demand. Now, that may seem like a good idea, if you think it up in a vaccuum and don't have experience with the real world. It's a great idea, if you're in high school. But to have it actually accepted? WTF is…
You can just disable the fd passing for services that don't need it. I'm not sure what your actual issue is. I haven't had to reboot any more with systemd than I did with sysvinit or openrc, or the slackware rc init, or anything else really. If you have an actual crash that is causing you problems, you should consider reporting it or submitting a patch to fix it, just like you would with any other open source that yo…
First of all this just sounds like "I don't know what your problem with systemd is, you can just choose to not use it". Second, my point is that it's an absolutely terrible idea, and should never have been done.
> I believe systemd was inspired by other established unix service managers like macOS launchd and solaris SMF. The design is definitely not perfect but I wouldn't say the history was ignored when making it.
A high school student can read up on things and then make something they, without real world experience, thinks seems like it's a good idea. And with no experience about what it takes to make software reliable.
Earlier quoted context omitted.
It's a pile of proof-of-concept broken pieces duct taped together into a big mess. Here's an example: Someone read that fd-passing is a thing, so now systemd listens to just about everything and spawns stuff on-demand. Now, that may seem like a good idea, if you think it up in a vaccuum and don't have experience with the real world. It's a great idea, if you're in high school. But to have it actually accepted? WTF is…
If you're going to rant utter nonsense, can you please do it somewhere else?
Earlier quoted context omitted.
> So to me this really looks like it applies neither to servers nor desktop. It applies to both. We need desktops to boot up fast, because you said it yourself, sometimes they just need to. And no one likes waiting around for their machines to boot. Can you imagine the volume of complaints about long boot times that would come in to large-scale distros from annoyed users? That alone makes it a high priority. And on t…
> We need desktops to boot up fast, because you said it yourself, sometimes they just need to I didn't say that. Because they don't. > And no one likes waiting around for their machines to boot. Nobody cares, if it's once for every month or two. Which it is. > we need servers to boot up fast But it's not actually booted until the service is up, so it's moot.
With per second billing, fast boot times save money and enable lower fixed capacity, further lowering cost.
Earlier quoted context omitted.
It's a pile of proof-of-concept broken pieces duct taped together into a big mess. Here's an example: Someone read that fd-passing is a thing, so now systemd listens to just about everything and spawns stuff on-demand. Now, that may seem like a good idea, if you think it up in a vaccuum and don't have experience with the real world. It's a great idea, if you're in high school. But to have it actually accepted? WTF is…
> Here's an example: Someone read that fd-passing is a thing, so now systemd listens to just about everything and spawns stuff on-demand. This feature benefits some people. Even if your service requires socket activation, you can still set the service to startup and you can still control it with normal command lines. > It's a great idea, if you're in high school. You make this accusation twice, but you give no-one an…
But it's broken by design. It's a bad idea. It's "neat", but "neat" doesn't add value.
> You make this accusation twice, but you give no-one any reason to believe it (unless you think "using an optional feature I don't want to use and which isn't significantly easier to use than to not use" is a reason, but most people would say that it is a good example of flexibility).
Not sure what you mean. Using this feature pushes orders of magnitude of complexity onto users, and greatly reduces the ability to error handle or even know the status of services.
Having a daemon listening to a socket is clearly orders of magnitude easier for end users. It means everything is in agreement. You check if the service is turned on (systemctl or whatever), you check if the process is running (ps, etc), and you check listening ports (netstat, nmap, etc...), they all agree that the service either is or isn't running. And if it's running, it's successfully run its initialization and should be usable.
We already have this experience with inetd-based services. fd-passing is reinventing the past, poorly. fd-passing actually would have made more sense back in the 90s, because spawning a new process was more expensive. Both in terms of code and CPU power that overhead doesn't actually matter anymore for the vast majority of cases.
Again, I don't know what your question is. Is it "why would I possibly want to know if a service is ready do its duties or not?"? Because if it is, I don't know what to tell you.
> Perhaps you're experiencing something similar?
I mean things like restarting nginx, and either it just plain didn't (and thus fresh TLS certificates weren't picked up), or it failed to start up again and now nobody's listening to port 80/443 at all.
> Can you give any examples of circumstances when you choose to reboot?
I've filed bugs, but don't want to doxx myself. Something more systematic is that sometimes after running apt-get upgrade it's recommended that I reboot (for non-kernel reasons). The fact that someone would even write that message is a sign that the author doesn't care.
> Systemd might have been adopted on theoretical grounds. But that doesn't mean that an empirical objection is useless or irrelevant.
I agree. But this is a very common tactic for people who just don't want to have a discussion, too. I'm sure in this case you're saying it in good faith, but you should be aware of the assymetry of asking one side to provide data when the other side has none. And the cost of collecting interpreting that data (depending on which parts of this, what, a human-year?), and the risk of systemd people dismissing that data anyway, because "yeah, I guess the data supports your point of view, but I don't like it so you can fork the repo to implement it if you want. Bye.".
So I'm not saying this appeal to data is in bad faith, but it is a bit naive.
> Group (2) is a subset of people who do not complain about systemd, but you are complaining about systemd. Moreover, your comment slings a good lot of mud, so it's hard to take that as a valid objection. You at least should work to clean up the mud you threw unnecessarily.
Best comparison is that I can complain about the corruption of politicians without inviting an argument that I myself should become one, to drain the swamp.
IOW: I don't have the time, and if nobody else cares, then even if I did then I don't see that I would succeed in a sea of people who don't care about software reliability.