ANTINEWS is the best kind of NEWS. And you don't just lose things, come on. Our recent support for running a system instance of systemd/uselessd without taking over init (as early and rudimentary as it still may be) is a good thing. Cross-libc is another. A couple of things from main.c were refactored into independent tools.
This is still a giant WIP and it's quite experimental. We make this perfectly clear in the wiki that it's not ready for system integration or daily use, and there's still a long way to go (including some more radical ideas) before we ever think of making a stable release.
uselessd is about sticking to processes. Did we not make that clear? If you want a dedicated supervisor, you can use something explicitly designed for such a purpose, like monit or supervisord, instead of using systemd's mixed functionality. Device activation can still be accomplished through (e)udev. We're device node manager-agnostic. We made this clear.
No, you're not screwed. I think you completely ignored the fact that we intend on being portable. This is still early, again, but nonetheless we do compile on FreeBSD and Debian GNU/Hurd and some of the tools (like systemd-delta) actually run properly.
To be honest, we haven't tested the systemd-fsck unit. We mostly removed the binary due to being something that used libudev and looked like it belonged to a shell script more than anything. You can still force fscks through other means (tune2fs for ext2/3/4, etc.) We'll be sorting this out.
It sounds like this project offends your personal ideological sensibilities, as you totally misunderstand its purpose and fail to realize it's a WIP and unstable.
By the way, I liked the jab about choice. I wish we all voted for the same political party, too.
> If you want a dedicated supervisor, you can use something explicitly designed for such a purpose, like monit or supervisord, instead of using systemd's mixed functionality.
Without being pid 1, that dedicated supervisor needs supervision. Now you have duplicated functionality.
At the same time, said supervisor runs into all kinds of extra problems to ensure proper cleanup of misbehaving services. Supervisord for example is a perfect example of a process monitor is easy to make lose track of the services it's supposed to monitor (I'm not trusting it again). Systemd's use of cgroups for this is for good reason: it's a hard problem to sort out.
You may end up with something usable, but a lot of the Systemd decisions are the ways they are because the alternatives were severely broken. And yes, that includes supervisord and monit.
E.g. here's an example from the Monit website:
check process apache with pidfile /var/run/httpd.pid
start program = "/etc/init.d/apache2 start"
stop program = "/etc/init.d/apache2 stop"
This seems innocent enough. Certainly it's better than "just" plain old SysV init. But it is still fundamentally broken.
I've lost count of the number of times the Apache init scripts fails to bring Apache reliably up or down, for a variety of reasons, and the assumption that the pid-file will actually contain the pid of Apache or an invalid pid is fundamentally broken (the number of times I've found the pid-space has rolled over quickly enough to cause problems? Not huge, but far from zero), as is the assumption that there won't be other Apache processes in various unpleasant states whose pid is not in the pid file, but which will prevent a restart.
The problem is that Monit is fairly representative for process managers in this respect, most of which makes the (broken) assumption that the init scripts start, stop and restart actions will work reliably, and/or that the pid file contains sane content, and/or that you have a reliable way to kill a process based on holding onto a pid. I've yet to encounter a system where any of those assumptions are true, though you may need to scale up a bit before you start seeing enough of those failures to care.
So the suggestion of using something like monit or supervisord without addressing the amount of functionality you lose if you do makes me question if you understand the purpose of the pieces you are tearing out and/or whether you have put any thought into how users can regain that functionality without ending up making the same tradeoffs systemd does after all.
I'm all for getting something more modular than systemd, but ultimately I think few people will be well served by giving up on the substantial improvements systemd is bringing.
You can run uselessd with or without being PID1. The two modes have different implications, obviously. The latter choice will mean a separation of system manager and service manager. cgroupfs monitoring works properly in both cases.
PID files and SysV initscripts are broken. We're well aware and this has been common knowledge for a long time. What I meant was that you can still get more potential from a dedicated program that tries to focus and solve cases in one specific areas. Making a distinction between the init part and the manager/supervisor part is one of our longer term goals with uselessd, beginning with version 5. It's a trade-off.
We understand what we're doing, and we do not deny the presence of warts. When we announce that we're stable and ready for system integration, then we can really talk. As it stands now, this is all preliminary pondering.
This is still a giant WIP and it's quite experimental. We make this perfectly clear in the wiki that it's not ready for system integration or daily use, and there's still a long way to go (including some more radical ideas) before we ever think of making a stable release.
uselessd is about sticking to processes. Did we not make that clear? If you want a dedicated supervisor, you can use something explicitly designed for such a purpose, like monit or supervisord, instead of using systemd's mixed functionality. Device activation can still be accomplished through (e)udev. We're device node manager-agnostic. We made this clear.
No, you're not screwed. I think you completely ignored the fact that we intend on being portable. This is still early, again, but nonetheless we do compile on FreeBSD and Debian GNU/Hurd and some of the tools (like systemd-delta) actually run properly.
To be honest, we haven't tested the systemd-fsck unit. We mostly removed the binary due to being something that used libudev and looked like it belonged to a shell script more than anything. You can still force fscks through other means (tune2fs for ext2/3/4, etc.) We'll be sorting this out.
It sounds like this project offends your personal ideological sensibilities, as you totally misunderstand its purpose and fail to realize it's a WIP and unstable.
By the way, I liked the jab about choice. I wish we all voted for the same political party, too.