Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

On some level I agree with you, but if you look at the things that Apple is able to do with OS X and timer coalescing [1], that central point of coordination becomes critical. You need a mechanism for starting and stopping all things, not just daemons, that plays by a specific, defined set of rules so you don't have multiple processes trying to do the same thing.

On another level, I feel the "unix philosophy" of having a lot of interchangeable modules taking care of small, simple tasks hurt it: each level of abstraction has a performance hit, and having to support multiple components in a modular way makes change management a nightmare. There's something to be said for the elegance of tightly integrated components: you can make assumptions that you couldn't otherwise make in a more modular system. I can see how it would be a problem if systemd were proprietary, but it's open source.

[1] http://www.apple.com/osx/advanced-technologies/



You are right that loose coupling carries a performance hit. Certainly, if your only goal is to increase the boot speed of a desktop Linux box, then systemd makes a lot of sense. That said, there are many other goals and many other kinds of boxes, which, among other reasons, is why the tide is turning against systemd.


"Performance" can many different things, all of which are useful in different contexts. It could be lower power consumption, faster thread performance, more I/O, lots of things.


agree. So far, the only 'performance' case that I've seen made for systemd is in desktop system bootup time. Certainly it won't make my threads go faster or cause significantly lower power consumption, or give me 'more I/O'.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: