[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Four people decided the fate of debian with systemd. Bad faith likely



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?

 > > 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.

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.

 > 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.

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.

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.

-- 
 /\           ___                                    Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_____               African word
  //--\| | \|  |   Integralista GNUslamico            meaning "I can
\/                 coltivatore diretto di software       not install
     già sistemista a tempo (altrui) perso...                Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO


Reply to: