Automatic respawning is a job for a process supervisor, not a process manager or initd. It's a separate duty altogether. So is resource limiting, which is probably better serviced through separate tools that wrap around syscalls.
324 karma · joined September 21, 2014
Automatic respawning is a job for a process supervisor, not a process manager or initd. It's a separate duty altogether. So is resource limiting, which is probably better serviced through separate tools that wrap around syscalls.
These things can already be accomplished through a device node manager, such as (e)udev. We just no longer handle maintaining it, because it doesn't belong here.
We've been under attack since shortly after we got covered on Phoronix. Started off with IRC bot spam, but looks like they got the wiki, as well. We're working on undoing it. Good thing ikiwiki is versioned.
It's a shame that software forks can summon such derision, but it looks like init systems are serious business. Oh well.
The same person is also spamming the #systemd channel on freenode. Pathetic display altogether.
EDIT: We're back.
In the meantime, our BitBucket repo: https://bitbucket.org/bcsd/uselessd
The end goal is to drive systemd into a direction that focuses succinctly on process management, having a portable base that can be transposed to other operating systems. Still quite some way to go, but hopefully it'll be done some day. But yeah, supplying systemd's core features for people who would like to have a conservatively developed and focused service manager that won't suddenly swallow the windowing system one day, is a key goal. Captures the gist of it.
Eventually I might transfer control to someone else and focus on my own interests. The eudev project lead has expressed some interest in us.
I'm the person who goes by The Initfinder General. Feel free to ask and be elucidated about uselessd and my general outlook on systemd/the state of Linux/Unix, if you so wish.
EDIT: Proof it's me: https://forums.darknedgy.net/viewtopic.php?pid=78186#p78186