51–60 of 272 posts
Earlier quoted context omitted.
Most of this comment is incorrect.
I think xenadu02 raises some valid criticisms, but I think those criticisms would have been better received if they were expressed more politely. I'd love to see a rebuttal of the specific points made as opposed to just "Most of this comment is incorrect".
The sad thing is, you do not really have a second option, yes I know some distros say they have alternatives, but SystemD becomes the "preferred" init system nearly everywhere now. I just hope Debian to get rid of SystemD and return to whatever else. I know I'm biased, just failed to find a reason to love SystemD, tried a few times.
I'm also rotating BSDs and open source solaris variants on to the home network machines. (Switching to solaris to get rid of systemd would be overkill; I switched to joyent triton for better containers and zfs...)
Earlier quoted context omitted.
Who said the unit philosophy was the be-all, end-all? Unix doesn't even believe it's own philosophy because it's too damn painful. Why does ls do sorting? Why does grep do -R recursive searching? How is that "Do one thing and do it well"? Unix is just a collection of random decisions made by various people over the years. The Unix philosophy is really more like "I've always done it that way so don't you dare change i…
"The C compilation model of separate header files is not a good design" This is probably just your lack of experience not having worked on 50+ million LOC compiling for 12 hours and not having anything else as a better option. There is a reason these things exist.
Enlighten me. And while you're at it, explain why this is better than, say, Rust's module system, where we don't need separate header files.
I feel like at some point, news aggregation sites will need moratoriums on this topic. Systemd is an architectural decision with very philosophical effects, so by its very nature be very divisive. I'm, personally, not a fan at all of systemd, but am tired of seeing these stupid arguments everywhere all the time. There are plenty of places to find competent summaries of both the technical and political arguments for a…
I don't feel they should. These are arguments I haven't heard before either and I'm glad to see more of these weird cases laid out. I run Gentoo (OpenRC) and Void (Runit) on my own systems, and although I do like both of them, I find the total lack of alternatives to the systemd ecosystem troubling. As a package maintainer, I do like being able to create rpms/deb files and only needing one standardized init script, s…
Earlier quoted context omitted.
Where do you specify laziness, failure policy etc ?
Why would I specify those in an init script? openssh has been doing The Right Thing(TM) for about two decades. Also, openssh has protocol-specific (and secure by default) configuration options around connection lifecycle, etc. that no general purpose init system should try to replicate and then blindly apply to unrelated services.
I've been greatly enjoying systemd for the ability to write services and startup jobs in languages that don't have great libraries for doing all the right things, like Python and shell, because it gives me all those Right Things as effectively a library. I don't have to manage pid file handling and daemonization and restarts on my own; systemd will do it, and will do it well and Right. (I used to do this with start-stop-daemon, and it did it poorly and only okay.) It will also get out of the way of OpenSSH, which does it well and Right, and get in the way of the dozens of services that think they're doing it well and Right but aren't.
Easy things should be easy, and hard things should be possible. systemd supports both. If that's the extent of what runit can in fact do, it only supports the former. (SysV-style init, of course, just makes easy things hard and hard things confusing, but as everyone else is saying, it's very not the standard of comparison here.)
There is something subjectively nice to me about running systemctl status and seeing a nice, clear picture of what the current state of services are on a system, being able to control the life cycle of a service including having systemd monitor and restart it, not having to deal with improperly written init scripts, etc.
Stockholm Syndrome perhaps?
Earlier quoted context omitted.
I think xenadu02 raises some valid criticisms, but I think those criticisms would have been better received if they were expressed more politely. I'd love to see a rebuttal of the specific points made as opposed to just "Most of this comment is incorrect".
Most of the statements aren't really conducive to rebuttals because they are lacking substance. But I can imagine what xenadu02 might have meant, if you like, and provide some counter arguments. Signals aren't "garbage" (whatever that means). Signals can call APIs (the set of async-signal-safe APIs). They can't call non-async-signal-safe APIs not because of threads, but because signals can interrupt a routine at any…
> So while signal handlers are perfectly workable for some of the early use cases (e.g. SIGSEGV) it seems that they were pushed beyond their competence very early, thus producing a broken design for which there have been repeated attempts at repair. While it may now be possible to write code that handles signal delivery reliably, it is still very easy to get it wrong. The replacement that we find in signalfd() promises to make event handling significantly easier and so more reliable.
Another critic makes the case that "signalfd is [also] useless" [2]:
> "UNIX[] signals are probably one of the worst parts of the UNIX API, and that’s a relatively high bar."
Signals came up recently on HN when someone remarked that not even memset() is signal-safe! [3]
All in all, working with signals correctly requires mastering a tremendous degree of complexity. Other platforms have provided simpler APIs, such as Structure Event Handling (SEH) [4].
[1] https://lwn.net/Articles/414618/
[2] article link from https://news.ycombinator.com/item?id=9564975
[3] https://news.ycombinator.com/item?id=13313563
[4] An HN comment describing how it's simpler: https://news.ycombinator.com/item?id=13323870
P.S. Please note that the views quoted above are not necessarily my views.
The problem with systemd has always been that it forces you to do everything the systemd way, and usually to use its tools. It goes against everything that has helped GNU/Linux become a great system: that it wasn't really one system. It was bits and pieces, and you could add them together however you wanted to get something you liked.
Systemd is the opposite. It is inflexible and clunky, monolithic and proprietary, binary and difficult. Everything has to be made to work with it, not vice versa. It doesn't follow any of the old conventions that made it simple to combine one tool with another. I can compare it to Windows, but I feel like that would be an insult to Windows' usability.
If this one single fact was different, everyone would love systemd, because it has plenty of useful features. But because it is designed specifically to please a single quirky user, people hate it.
Systemd ideas I'm all for but it only hints at linux lack of clean abstraction power. sysvinit was full of redundancy; apparently BSD found a way to make a thin abstraction layer to make init files clean. Bash isn't "good" at hinting proper abstractions, I rarely see talks about this, maybe gurus can see through the rain. I keep seeing a place for a tiny lambda friendly intermediate layer .. Just so you can compose p…
https://cr.yp.to/daemontools.html
Here is a bash function that retries N times:
retry() {
local n=$1
shift
for i in $(seq $n); do
"$@"
done
}
retry 5 echo hi
timeout-demo() {
timeout 0.1 $0 retry 5 echo hi
}
https://www.gnu.org/software/coreutils/manual/html_node/time...
Shell has a very forth-like quality to it, and Forth is sort of like a backwards Lisp as well (postfix rather than prefix).