Distributors ponder a systemd change

We've had ancient unix plumbing that was really starting to show it's age and while there were some attempts to bring contemporary code into the whole lower layer between the kernel and userland (and system startup), it was not really a coordinated push towards something new. systemd entered that vacuum and pushed hard, solved some problems, made some things convenient to do and won market share with this approach.

The whole problem is that systemd is the php/mysql equivalent of init systems combined with a tendency to borg more and more components into it's sphere of influence. Sure, plently of people use php and mysql too and I don't mean to ignite old flamewars but it's still important to realise that people use software like that _despite_ their technological shortcomings, not because of their technological merits. PHP and MySQL both got bootstrapped into widespread use because they entered a market vacuum, were widely available, easy to start using and were heavily geared towards "keep going" no matter what. The fact that they belong to the "gentleman's C" or "barely adequate" level of software didn't really matter and still doesn't to some extent.

On the macro level I guess it doesn't matter* that much that systemd is making questionable design decisions, it's something that distributions and developers can sort of work around and mitigate for now, people can keep passing --without-stupid-decision-x and their ilk like with OpenSSL and gcc to some extent. What systemd is, is a lost opportunity / opportunity cost. It's not that it worsened the status quo much, it's that we're not building something that's clearly superior to both ancient unix plumbing and systemd, that would actually matter on the large scale and improve things.

*with the caveat that as systemd keeps borging stuff with a willingness to force change on software orthogonal to it and increasing the monolithic complexity, things might start breaking pretty badly

Lennart Poettering is I think the perfect example of someone just smart enough to dig himself into a deep well and with surefire convictions making him incapable of stopping. This current change about killing processes on logout cannot be reasonably justified from a security perspective, killing processes on logout doesn't make things more secure at all. That's a nonexistent security barrier even to the stupidest malicious actor. The fact is that if a user has access to a system, it means control over a huge range of things on that system regardless of whether that user is currently logged in or not. The security barrier is at the point when a user gets deleted, then it makes sense to kill their processes and audit as many resources as the user had access to.

Security is just an excuse in this case, misbehaving gnome processes that do not handle sighup are the real reason for this change and this change is the direct equivalent of MySQL silently inserting '00-00-00 00:00:00' as a date on invalid data, an attempt to brush problems under the carpet where it inevitably leads to more problems, instead of fixing it by rejecting that kind of thing at the source of the problem.