* John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de> [121129 21:14]:
> On Thu, Nov 29, 2012 at 08:22:41PM +0100, Bernhard R. Link wrote:
> > As our world has not
> > yet seen bug-free software handling every single situation the authors
> > did not think about properly, the expectation of what happens if one
> > runs into a not-yet fixed bug is an important issue for many people.
>
> Absolutely. But again, this is true for any software and this is
> *especially* true for old designs which couldn't cover certain setups
> which simply didn't exist back then.
But you have to understand that you put something that only does
promises against something that exists. Something that exists means
that people have experiences with it, now how it behaves, know how
to debug it and now how to make it work again when it breaks.
On the other side is systemd which has not yet been available in
a single Debian release and could not yet prove itself anywhere.
So if it would be proposed as some more init system to support
or a cool new stuff to experiment with it, you would not get that
much emotional reactions.
But as people demanded making it the only available system before
it could prove itself and while all most people know is that it
is quite a different design which wants to solve all the problems
at the same time (which often enough means it creates more problems
than it solves) and that it has ties which other projects people
have had no good experiences with (for enough people pulse-audio
is a synonym of "my sound is not working") you should have a
different reaction than ridiculing people not wanting to bet
their future on it.
> You know the famous quote: "640 kB ought to be enough!"
But I also know which happened to the 80286, which offered
quite a lot more memory and many nice things like fine
grained memory proection: It only looked nice on the paper
but (with some noble exceptions) was just not worth the hassle,
so that people prefered to stay with a 1 MB limit for many
years to come.
> Yes, I see your point. But again, what I said before, how many people
> are actually digging into such low-level code? Someone who is jumping
> into kernel or plumberland development always has to have a certain
> background knowledge. It requires more skills and experience as
> opposed to writing desktop applications or smart phone apps.
This is exactly the mindset that scares people away from systemd.
An application that does not behave is no big problem. One can easily
ditch it and replace it withanother. One has all the bells and whistles
of your full desktop available while you debug it. It's all quite well
understood.
If your init system does not work -- and one day it will not work,
there is no way that can be avoided, there is no perfect bug-free
software out there and especially when the task is to cope with
all possible hardware and their little quirks and timing problems,
all the different combinations of services and daemons out there
and so on -- you are set back much more.
So if you end up in a situation like that, what do you do as user?
Some will say "oh, it does not work. Let's try to reinstall the machine
and if that does not help let's try another distribution. Perhaps the
next release in two years will work. Or perhaps what I wanted to do
is not that important, so I will just not do that".
But for many people that would not be a solution but the absolute
nightmare. Being at the mercy of the computer; not being able to decide
what your machine does and what not; being totally powerless and
dependent on whether someone has decided that what you want to do
makes sense or not.
So being a more complex thing means it must be easier. Easier to
understand what it does. Easier to understand why something does
not work. Easier to fix it once it breaks.
> But do you really think that we should keep every part of the system
> brain-dead simple that everyone understands at the cost of reliablity
> and performance?
Do you really not understand why people think that?
And what does reliability mean if it can stop working and I can do
nothing against that at all?
> I see your argument about keeping stuff simple, but again, if you want
> to be able to solve more complex tasks with your computer, the
> software on it itself has to become more complex.
Strangely the complexity of the solution has seldom been related
to the complexity of the problem and always been the opposite of
reliablity in the past. So this is merely a false assertion.
> > Claiming that it will work for everyone and that
> > anyone not being able to name a problem existing now has no arguments
> > does not help.
>
> Do System V Init or Upstart work in EVERY single use case?
Actually, all my experiences with upstart has been when it does not
work. And then it was always a pain to work with. So in my experience
System V Init is quite superior to Upstart.
And the big advantage of System V Init is that everyone can diagnose
and fix it. Everyone knows how to add some echo lines to find out where
something is happening. Having the logic available in some easy
well-known and very extensible syntax means I could easily adopt it
and make it fit my needs even more I understood what most of this stuff
it. And with all the nice properties descriptive systems have and as
much as I love them, nothing beats discoveribility, debugablity and
extendiblity of imperative programming.
I do not claim that one could not write something far better than System
V Init. But if your answer to question "how do I fix my system if it
fails" is "You do not need to fix it. It will work and you would
not understand the real problem anyway.", then you are not even trying
to be better than System V Init.
> Do you know
> that systemd actually works much better with systems which have high
> load or are shared among many users (because it allows ressource
> control by using cgroups).
Let's assume for the sake of argument that this is true. Why does it
matter? Why should I care more about some corner cases than about
being able to use it?
> It is the old
> System V Init which actually covers only a very limited use case while
> systemd offers a much more flexible design, ranging from embedded
> stuff up to very big machines.
What is interesting for people is that *they* can get *their*
problems solved. Your offer is something like "I'll write something
for you that can do everything. Just trust me to do right what
everyone before at failed. You no longer need a solution you
can understand because my solution is complete".
Does it really understand you if people react with "Thanks, but no
thanks?"
> the stance to reject any modern developments.
I strongly recommend you stop this name calling. If you do
not have any arguments left to speak for you, then insulting
the other side will not help you to convince anyone.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121129213244.ga17...@client.brlink.eu
