Re: Arguments for tech-ctte (Was: Proposal: let’s have a GR about the init system)
Hi,
I really didn't want to write again in this thread (we did write too
much already, and the wiki should be the only medium to write about this
now...), though I can't just let John Paul Adrian Glaubitz write false
statements this way, and the wiki isn't a good medium for debunking
things that can be read below (I tried, it just doesn't fit).
On 11/08/2013 11:30 PM, John Paul Adrian Glaubitz wrote:
>> * If OpenRC's development continues in good direction, Debian could
>> switch to OpenRC
>
> The word here is "if". It's not going to happen.
It's already happening. OpenRC development very is active. Join #openrc
on Freenode and chat with upstream, then you'll see that they are
actively working on it, and well. The constant point release is another
proof. The git repo as well.
I've also worked on it on the Debian side, and upstream has been very
responsive. Please don't write this kind of things: you clearly don't
know what you are talking about here.
Or probably this was about "good direction" and related to Gentoo bug
#391945? Well, in this case, see below...
> OpenRC has fundamental
> issues which haven't been resolved for years now:
>
>> https://bugs.gentoo.org/show_bug.cgi?id=391945
>
> I don't think this is a viable alternative to anything.
The bug which you are referring to only happens in very few edge cases.
A lot of efforts has been put into this problem, and I don't think it
can be held as an argument against OpenRC anymore.
> We can't work with vaporware, we need software that actually works.
Please quit using this kind of wording. Here's the wikipedia definition:
"Vaporware is a term in the computer industry that describes a product,
typically computer hardware or software, that is announced to the
general public but is never actually released nor officially cancelled."
OpenRC is *not* a vaporware, it is available upstream from Gentoo, and
released often. And from the Git on Alioth, and it works rather well.
Because it failed to pass the NEW queue once (for a valid reason)
doesn't mean it's vaporware.
>> * If our shell scripts are a mess, then we should clean up the mess,
>> not trying to escape it by changing whole init system; more precisely,
>> we should correct mistakes we made in past, such as not enough
>> abstraction
>
> And who is going to do it? Are you?
If you believe that people are going to switch to systemd and write
stuff for it if we choose it, why do you think the same thing will not
happen with OpenRC if that's the choice? This makes absolutely no sense.
> People constantly stating that systems like OpenRC and sysvinit
> are actually viable alternatives if someone improved them without
> actually stepping forward themselves leaves me up to the impression
> that those people actually don't have interests in pushing sysvinit
> or OpenRC but just blocking the adoption of systemd or upstart.
Well, there's not only this kind of people, some did stepping forward,
while some just did nothing. The same thing could be said by replacing
OpenRC with systemd and systemd with OpenRC, and in fact, with any kind
of software the same could be truth. This is not a valid argumentation.
Furthermore, what you wrote above shows that you haven't investigated
much about OpenRC when writing these words.
By the way, I don't think people are pushing an agenda just for
"blocking the adoption of systemd or upstart". What's blocking it, IMO,
is that none support our ports. If they were, there wouldn't be such a
controversy. And in some ways, upstream for systemd is hurting its
adoption even more than anyone by stating that no ports patch will be
accepted upstream.
If there was any kind of ongoing effort for porting upstart or systemd
to our ports, I wouldn't do anything on OpenRC for Debian myself.
>> If sysvinit is in accord with UNIX philosophy, and as they say it is,
>> than I don't see why (1) and (2) would not be possible, too, and with
>> not to much effort.
>
> No one cares about the "Unix philosophy" (TM)
A lot of people don't like that systemd is doing too many things and
that its components are depending on each other (that's not *my* biggest
critic though, but it seems it is for some). What's being argued here is
that systemd contains unnecessarily complexity in its current design
(and that features could be implemented without this complexity). This
is what the "Unix philosophy" (TM) is about...
Also, please don't talk for everyone using "no one cares". You are *not*
everyone. You did this in the past, and that's a very annoying kind of
wording habit that you have here, and which IMO you should quit.
Thomas
Reply to: