Wayland is being treated like PulseAudio and systemd before. So, it will probably win its battle, thanks $DEITY.
PulseAudio did have some growing pains, though. I don't remember them exactly, but I remember having to tinker way too much to get apps to work together/correctly between ALSA and PulseAudio, etc. I still have a finicky laptop that REFUSES to do audio over HDMI unless I boot the machine with the HDMI cable plugged in already.
No real point, here. Just rambling.
I mostly agree, although I prefer OpenRC personally. I was bit by
[* ] Stopping service 1:30 remaining
systemctl edit service-name
[Service]
TimeoutStopSec=XX
I mean Slackware used to send a SIGTERM to all processes, wait two seconds, and send a SIGKILL. Why would anyone need more? It's the Unix way (except it isn't).
If you disagree with the default wait time then you disagree with the default wait time. So what.
Summarily killing processes with a SIGKILL should really be a last resort because it can very easily corrupt data.
If you have processes which just hang for ages during shutdown, there is probably something wrong with your system (or the process's code) which might warrant further investigation.
I kinda wish "proper shutdown" was never invented at all. That would've motivated so many developers to care about reliability much more :P
I'm talking more along the lines of ZFS – I can always pull the plug without worrying about FS consistency, because the FS always goes between valid, consistent states atomically.
The problem is a thorough lack of semantics on file systems. It's the wild west.
ACID was a good start for databses, but even that is pretty vendor specific in the specifis... and nobody truly understands the basics of it anyway.
It's a difficult problem.
[0] Well, not exactly, but you get the idea.
It's just another init system to me. I don't really care enough about it to get upset and complain that I had to read some documentation and edit a text file to change its behavior.
The other comments already explained how to change the timeout per-unit, but I wonder how would you want a “perfect” init system to handle this?
Hang forever until the process dies without any message (as far as I know this is how legacy shell-script-based inits would handle it)?
Kill the process immediately and risk data loss?
Behave as-is but with a lower default delay?
The thing is, “with enough users someone will depend on both the public and private parts of your APIs” is true (and I am sure I butchered up this quote as well)
I regularly have to open pavucontrol to fix basic things like "where output audio streams are routed to", fight with audio frequency rates, etc. On new embedded designs, PA is often the bane of my existance because of the insane heuristics it runs to figure out audio policies and mixer/routing behaviors. Even the major desktop environments have trouble trying to integrate with the blasted thing.
PA is still hot garbage, straight from upstream source.
If you think that the window manager was modular component you can basically pretend that wlroots is X and the compositor is the window manager. It is just as modular with that logic except more efficient and capable.
Being able to dump screenshots or process them in any other way, also again with bash scripts, is very modular
Being able to debug parameters of X windows, etc...
In the wayland model, these previously modular components that communicated through process boundaries to cobble together those policies that make a desktop are typically subsumed into one process called the compositor. Look and feel is still the domain of the widget set, but window policy is not.
There are other processes involved though where the compositor and the client do talk the Wayland protocol via IPC, such that the compositor hands off various responsibilities to external processes.
As far as I understand, X11 ended up with the window manager architecture pretty much by accident; initially, window managers didn't even exist.
It doesn't do output configuration, input management, application window drawing, font rendering, or remoting, all of which X did itself (although modern application rarely made use of that part of X). Those things are delegated to the kernel or to application libraries.