On Lu, 03 mar 14, 10:40:52, Gian Uberto Lauri wrote: > Andrei POPESCU writes: > > On Du, 02 mar 14, 18:09:46, ghaverla wrote: > > > > > > Systemd seems to have 2 proponents, people interested in fast booting, > > > and people interested in servers. The intersection of those two groups > > > is almost the NULL set. I think the answer to faster booting is > > > hibernation, and people have been playing with that for many years as > > > near as I can tell. To the people running servers who want faster > > > booting, I would suggest that they not turn the things off. > > > > Hibernation has it's own set of problems, especially as RAM sizes go up. > > I am interested in this issue. Could you tell some more about this? Depending on RAM size and what you were running at the time you set your computer to hibernate it may just take longer to resume (i.e. read the stuff from slow storage) than to cold boot. This may have been solved in the meantime (compression, optimisations, whatever), because I'm running sid hibernate is not really useful for me. > > > It isn't change is evil, the saying is if it isn't broken, don't fix it. > > > > But things *are* broken. Any computer with more than 1 (one) storage > > device (not hot pluggable please) and 1 (one) wired network connection > > (IPv4, not IPv6) with a static configuration and all other devices > > connected at boot needs more than sysvinit + sysv-rc can handle sanely. > > I completely disagree. I had quite a nicely complex storage server > with trunking and multipath things on, and it was sane and clean. Until one looks under the hood :( > What was a bit 'magic' was iSCSI, but I doubt it was due init! > > On my laptop-used-as-a-desktop, I solved any problem quite sanely, > even if it involved skills, skills that I borrowed from my wife (who > "has any AIX certification IBM provided an exam for" :) :) :) :)): > > - my external, always plugged, HD is automatically mounted with LVM > provided I see its id in lsusb output. > > - usb keys have their label. > > This is extremely sane. It is also a bit for tech savy not for end > users. Which basically proves my point. This stuff should Just Work (tm). Yes, we (and by this I mean mostly debian-user subscribers) are tinkerers, otherwise we wouldn't be here. But, how am I going to do that for my father's laptop, which I *might* be able to access remotely? > > If you don't believe me just do > > > > grep sleep /etc/init.d/* > > You should do a step further. Go and watch what each one does. > > The large majority of sleeps is used in restarting a daemon > (/etc/init.d/some-devil restart), to wait that the kill has succeeded > before restarting the daemon itself. This is a joke right? If I tell a daemon to restart I want it restarted. Now. Anything else is like the tail wagging the dog. > A DBUS system could indeed make things cleaner (I wolud like to know > the cost). > > But restart is never invoked by init in bootstrap or shutdown. > > Therefore I really can't see the issue with the use for sleep. True, > with messages that could be cleaner... > > Maybe. Easy example: write an event driven POP client and compare the > code with some other doing sleeps :). > > > And let's not forget about: remote shares, remote storage, encrypted > > storage, local hot-plugged devices (not limited to storage), dynamic > > network configuration (especially with IPv6), etc. > > Except storage, the other stuff is "personal pc stuff". What is good > on a personal pc may not be good on a server - and vice versa. They > look the same (for low end servers), but they are not. Rogue daemons, duplicated code (for the forking), etc. And no, "this could be done with (x)inetd/daemontools/whatever" is not an answer, because it hasn't been done. > And while 20 years ago I could have been on the "go systemd go" side, > today I still think that there are things that could have done better > with less problems given to the "server running" guys with no cost > given to "pc running" guys except waiting a bit more. Don't get me wrong, I'm not advocating systemd. I've followed the -ctte debate quite closely and my own conclusions are: - sysv-rc and all the initscripts are a nightmare to maintain (and have been for quite a while) - systemd is the best we've got *at the moment* - OpenRC *could* be a great alternative If I had the skills I would be helping out with OpenRC development/integration/etc. I plan to test it as soon as some mechanism as simple as 'apt-get install openrc and set init=whatever' is available and documented. Right now I would have to remove sysv-rc, which I'm not prepared to do, even though I've been running with 'init=/bin/systemd' for quite a while. I believe the fact that the upstart maintainers did not include such an easy mechanism from the beginning (2006 in experimental and 2009 in unstable and testing) has contributed a lot to upstart having such low adoption in Debian and eventually led to systemd (in Debian only since 2012) taking over. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt
Attachment:
signature.asc
Description: Digital signature