Re: Four people decided the fate of debian with systemd. Bad faith likely
Andrei POPESCU writes:
> > 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 :(
With "under the hood" you mean the assembler code?
I did the configuration using the documentation and maybe a couple of
suggestion from my wife...
There was nothing mad.
> > 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.
"proving your point"? Noooo, mine is a *very customized* machine, you
can't do such a customization with standard issue stuff :) :) :) :).
Maybe mine are a bit old-fashoned solutions, they are running this way
since several years now.
> This stuff should Just Work (tm).
...And the magic money gnomes bring the montly wages :) :) :)
Systemd can help a bit in making a little easier to have tools that
satisfy the (not so) basic need "to have this device mounted here if
it is plugged, otherwise go ahead with the bootstrap" for the
completely tech-unsavy user, but you can achieve this with system V
init. If you want to do it.
> we (and by this I mean mostly debian-user subscribers) are tinkerers,
> otherwise we wouldn't be here.
WARNING! If I got right your words, this is a damn narrow-sighted
point of view. If you stop a moment and and think, you may see how
many user of Debian GNU/Linux may exists that do not access this
mailing list. Or do not access any.
> But, how am I going to do that for my
> father's laptop, which I *might* be able to access remotely?
Excuse me, could you re-state this sentence. I am unable to understand
the point, sorry that is due my poor English skills.
Anywaty, if you have no access to a machine it's hard to work on it.
But I was sysadmin in other's (spare|lost) time :), as I might have
said before [and as my signature says in Italian]. I had a couple of
rack under my controls, and the only times I had to move (3 hrs by
high speed train) was when there were cables to remove and screws to
unscrew...
> > > 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.
Sorry, no, or I could equally say "I want an Aston Martin parked in
the company yard. Now and anything else is like the tail wagging the
dog".
We agree that there are "some steps involved" between "wanting the
Astong Martin" and getting one.
The same is for restarting a service (provided by a daemon).
If you want a daemon to restart you either have a daemon that can
completely resets itself upon receiving, say, SIGHUP or you need to
terminate the previous instance and start a new one.
And when you terminate a program you want to restart, you have to wait
for that program to be terminated to be sure all resources are
released.
And in this systemd has no more power than a script. It has to issue
the stopping signal, wait for the process to die and let free the
resources it used, and finally start a new one.
Code it with shell, code it with C, you have to code the instructions.
> Rogue daemons,
Could you introduce me some?
Don't take this as a provocation. I know of daemons that do a "fire
and forget" spawn of a process to serve a single request, then the
process dies.
And, AFAIK, if a process is not son of some other process then is son
of init by 'adoption'.
But I know I run a subset of Debian programs, so there are program I
never run.
> > 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)
The use of explicit dependencies is something really needed. Even if
you do not have to handle all the possible scripts in a distribution -
(that is really complex task).
The faster reboot will please pc-users.
Have to scan all custom network-referencing scripts and the firewall
(debian stable is wonderful for this task!) is something that will
not please the sysadmin.
> - systemd is the best we've got *at the moment*
My opinion that the migration was too swift. I am almost sure that
a less "disruptive" way was possible provided some more time.
systemd will be not as evil as I feared when I was first pointed to
some random document. It could add even some good in the long run. But
this too early migration will give some troubles to someone, I am in
this set.
--
/\ ___ 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: