User: Password:
|
|
Subscribe / Log in / New account

Changes coming for systemd and control groups

Changes coming for systemd and control groups

Posted Jul 5, 2013 3:14 UTC (Fri) by zblaxell (subscriber, #26385)
In reply to: Changes coming for systemd and control groups by Cyberax
Parent article: Changes coming for systemd and control groups

Wait, did we switch topics to the boot process now? (as opposed to shutdown/reboot)

I have no complaints about the way systemd starts processes. The insanity starts when it's time to keep processes alive or reboot the system.

If we are still talking about reboot, it sounds like your solution to the problem of having buggy software in a critical code path is to add even more software in the critical path to supervise the buggy software and contain the impact of known bugs without fixing them. Presumably you also run this in some sort of nested container so that if systemd is buggy, some higher level of supervision (maybe another systemd?) can detect the problem and execute even more code in response. That layer could be buggy too, so it's nested supervisor software all the way down? Just the first level (the one with the initial bug) sounds insane to me, and every level of recursion squares the insanity.

"Yo dawg, I heard you like software, so I put some software on your software so you can run code to run your code..."

My approach is to look at the unnecessary code, and realize that even if that code was utterly perfect, it would not do anything more useful than no code at all, but would use more time, space, and power to achieve the null result. The sane thing to do is identify such code and simply remove it.


(Log in to post comments)

Changes coming for systemd and control groups

Posted Jul 5, 2013 3:30 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

> Wait, did we switch topics to the boot process now? (as opposed to shutdown/reboot)
It doesn't matter.

>If we are still talking about reboot, it sounds like your solution to the problem of having buggy software in a critical code path is to add even more software in the critical path to supervise the buggy software and contain the impact of known bugs without fixing them.
Yup. My solution is to put a fairly SMALL amount of carefully tested code that can cope with whatever crap is thrown at it.

Your solution is to build a house of cards. Carefully checking each card, because we know that all bugs are easy to spot and fix.


Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds