On 03/28/2013 12:28 AM, Grant Edwards wrote: > On 2013-03-27, Michael Mol wrote: > >> The case for systemd is twofold: >> >> 1) Boot-to-desktop session management by one tool. > > Ah, the old "universal generic tool" approach. I've seen a lot of > money and time poured into black-hole projects with names containing > words like universal and generic, so I don't really like the sound of > that. [Is that the right response for somebody who started using V7 > Unix on a PDP11?] It has theoretical advantages. Avoiding an impedance mismatch makes turn-key systems that much easier. (I expect that to apply to embedded systems like phones and consumer network gear, but we'll see how it plays out. RAM is cheap, and getting cheaper...I just configured a Netgear router with 128MB of RAM...) > >> (The same thing that launches your cron daemon is what launches >> your favorite apps when you log in.) > > The only app that runs when I log in is bash. Then I usually start > XFCE from the command line -- but not always. > >> 2) Reduce the amount of CPU and RAM consumed when you're talking >> about booting tens of thousands of instances simultaneously across >> your entire infrastructure, or when your server instance might be >> spun up and down six times over the course of a single day. > > It sounds like systemd really isn't intended for the likes of me. Indeed. > >>> Are there people who reboot their machines every few minutes and >>> therefore need to shave a few seconds off their boot time? >> >> On-demand server contexts, yes. > > Thanks for the explanation -- I never would have guessed that's how > the whole cloud thing worked. "Private clouds" work the same way. As business penetration of cloud services grow, I expect we'll see backlash as major outages occur. Imagine if cyberbunker had attacked Google rather than Spamhaus earlier this week. The scale of that attack reached the upper limit of what the Internet's infrastructure is capable of carrying...nobody, not even companies with dozens of data centers in a distributed architecture, can ultimately bear that. Organizations which have grown comfortable in an age of reliable Internet access and cheap cloud services are going to discover they still have operational needs that must go on even without network access.