Bug#727708: call for votes on default Linux init system for jessie
(I was informed, that my posts are not welcome anymore here. So,
there is last one for all.)
On Thu, Jan 30, 2014 at 12:05:19PM -0700, Bdale Garbee wrote:
> Sergey B Kirpichev <skirpichev@gmail.com> writes:
> > I just wonder why nobody from tect-ctte take care about the exact
> > specification of that "bare minimum" (or, in other words, what exactly
> > is wrong with sysvinit).
>
> In a sense, we all have done this, even if you don't see it explicitly
> written in just this way.
Sorry. Maybe it's clear from the thread for others, that this
specification is somewhere in minds of all tech-ctte members...
But I doubt if it's so, as I was kindly pointed out to
https://wiki.debian.org/Debate/initsystem/systemd#sysvinit_.2B-_insserv
Is this all (what we want to fix in sysvinit/what we want to have
in the modern init)?
And that wasn't clear for others, otherwise I can't explain, for example,
the questions why OpenRC was silently discarded from reviews.
> The thing that may not be obvious is that this line doesn't stand still,
> it is constantly moving as more people develop more free software that
> does newer and better things and in the process builds new dependencies.
Old init was working for years. Are we only buy something
that satisfy the new dependencies (for the Gnome) or a new
init, that would work for comparable time?
On Thu, Jan 30, 2014 at 05:16:46PM -0800, Keith Packard wrote:
> In effect, X takes the Debian position that patches which improve
> interoperabilty with a specific init system should be integrated.
Seems to be sane and reasonable position. I wonder why Gnome
people can't follow this.
>> Where is the list of problems for sysvinit we intend to solve?
> For X, the problem is running X as a user other than root
(There are sysvinit-enabled setups even without X...)
On Fri, Jan 31, 2014 at 09:38:45AM +0100, Josselin Mouette wrote:
> > > https://wiki.debian.org/Debate/initsystem/systemd#sysvinit_.2B-_insserv
> Since you forgot to paste the first sentence, let me add it here.
>
> “Sysvinit was never designed to cope with the dynamic/event-based
> architecture of the current Linux kernel. The only reason why we still
> use it today is the cost of a migration.”
I'm not forgot, because it's not the only reason - please
see the mentioned example.
> Anyone who knows how Linux works doesn’t consider
> sysvinit a viable choice today.
I'm sure Google sysadmins know how Linux works, still
they consider sysvinit to be a viable (and preferred) choice.
Reply to: