FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 07-05-2010, 03:23 AM
Mike Frysinger
 
Default The future of sys-apps/openrc in Gentoo

On Sunday, July 04, 2010 21:03:41 Olivier Crête wrote:
> On Sun, 2010-07-04 at 18:15 -0400, Mike Frysinger wrote:
> > which is trivial to fix and anyone with commit privs could have done. it
> > certainly doesnt warrant a paniced "the sky is falling" message.
>
> I think this is a great occasion to dump our stupid custom crap and
> switch to SystemD, PolicyKit, NetworkManager, etc. Anyone with half a
> brain already dropped our stuff. And the lack of use of modern tools is
> the reason I don't use Gentoo on my work computer anymore.

no one ever really carried Gentoo init.d scripts except for projects that were
doing their development in Gentoo, so there really is no change here.

as for the other init packages, you're certainly free to use whatever you want
on your system. as for the rest, openrc doesnt conflict with PolicyKit or
NetworkManager or anything else, nor does it prevent you from using those
services at all. so statements carrying such implications are mere FUD.
-mike
 
Old 07-05-2010, 03:32 AM
Nirbheek Chauhan
 
Default The future of sys-apps/openrc in Gentoo

On Mon, Jul 5, 2010 at 7:53 AM, Richard Freeman <rich0@gentoo.org> wrote:
> On 07/04/2010 04:09 PM, Jory A. Pratt wrote:
>>
>> For those of you not on the #gentoo-dev channel, I just announced I am
>> gonna be looking at the openrc code and fixing the bugs and working to
>> continue the development. Anyone that is interested in helping please
>> feel free to contact me off list to discuss how we will handle getting
>> openrc back on track.
>>
>
> Well, openrc isn't any worse than baselayout-1 for upstream support.
> However, I do agree that we should strongly try to standardize on something
> that is more cross-platform if possible.
>
> I'd rather not push to make openrc stable (which means lots of migration for
> users), only to then move to something else anyway. *Why have two migrations
> when you can just have one?
>

The reason why people want to do an openrc migration right now is
because we don't know when we'll find something else to move to; make
it work with gentoo, make it work for everyone, iron out all the bugs,
and push it to stable. In all probability, and looking at our past
experience with pushing openrc to stable, it *will* take years. It's
too much work to maintain both baselayout-1 *and* openrc *and* find
something else to move to. It's best to move to openrc (which has
numerous benefits over baselayout-1, and has a maintainer now), and
then see what we can do.


--
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team
 
Old 07-05-2010, 04:13 AM
Nirbheek Chauhan
 
Default The future of sys-apps/openrc in Gentoo

2010/7/5 Olivier Crête <tester@gentoo.org>:
> On Sun, 2010-07-04 at 18:15 -0400, Mike Frysinger wrote:
>> which is trivial to fix and anyone with commit privs could have done. *it
>> certainly doesnt warrant a paniced "the sky is falling" message.
>
> I think this is a great occasion to dump our stupid custom crap and
> switch to SystemD, PolicyKit, NetworkManager, etc. Anyone with half a
> brain already dropped our stuff. And the lack of use of modern tools is
> the reason I don't use Gentoo on my work computer anymore.
>

What you are saying makes sense for desktop users since they will
likely already have consolekit/policykit/nm-applet installed, and
hence using NetworkManager for all network management makes sense.
However, this makes very little sense for people who install gentoo on
servers. Requiring these things of them would be a disservice on our
part (we're not fedora/ubuntu). And there is the issue that
NetworkManager (aka NM) does not have any command line tools to
control it (bring individual interfaces on/off, etc). cnetworkmanager
exists, but it's third-party application, and I don't think it's that
widely used/tested.

From what I can see, we have three options:
(a) Make our existing openrc network code + openrc configuration files
work with systemd, and move to systemd by default
(b) Make systemd work with openrc+NM configuration files[1], make NM
work w/o PK/CK[2], add command line tools to NM, and move to systemd
by default.
(c) Support systemd as an alternative init system for use by desktop users.

I'd go with (c), personally, but if enough people are interested, they
can pursue any of these options.


1. There's an ongoing GSoC project in Gentoo to make NM work with
openrc's configuration files. It is proceeding quite successfully
thanks to the excellent work of Mu Qiao.
2, PK == polkit, CK == consolekit

--
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team
 
Old 07-05-2010, 07:29 AM
Patrick Lauer
 
Default The future of sys-apps/openrc in Gentoo

On 07/05/10 03:03, Olivier Crête wrote:
> On Sun, 2010-07-04 at 18:15 -0400, Mike Frysinger wrote:
>> which is trivial to fix and anyone with commit privs could have done. it
>> certainly doesnt warrant a paniced "the sky is falling" message.
>
> I think this is a great occasion to dump our stupid custom crap and
> switch to SystemD, PolicyKit, NetworkManager, etc.
Err what. So instead of using our well-known and rather robust crap you
want to use other people's more shiny untested crap?

I still haven't seen any compelling reason for systemd apart from a
fuzzy "it's faster" (which openrc already satisfies). Policykit is one
of those things that are a serious pain to get working (hello XML!) and
NetworkManager ... oh dear, you can't be serious. Debugging that beast
made me realize how bad things can get. Let's just say that I'd like to
switch upstream to state 9 for reason 6 a few times until they say
"Warning: Error successfully happened!" or something like that.



> Anyone with half a
> brain already dropped our stuff. And the lack of use of modern tools is
> the reason I don't use Gentoo on my work computer anymore.
>
"Modern tools" ? OpenRC is the fastest and most reliable init system
I've seen in quite some time. It even has the most awesome feature that
"stop" stops services! (Which some other distros still don't manage
reliably)
Add human-readable config files and no silly dependencies to the list
and you have an awesome tool. No idea why you don't like having nice
features ...
 
Old 07-05-2010, 08:57 AM
Duncan
 
Default The future of sys-apps/openrc in Gentoo

Nirbheek Chauhan posted on Mon, 05 Jul 2010 09:02:19 +0530 as excerpted:

> On Mon, Jul 5, 2010 at 7:53 AM, Richard Freeman <rich0@gentoo.org>
> wrote:
>> On 07/04/2010 04:09 PM, Jory A. Pratt wrote:
>>>
>>> For those of you not on the #gentoo-dev channel, I just announced I am
>>> gonna be looking at the openrc code and fixing the bugs and working to
>>> continue the development. Anyone that is interested in helping please
>>> feel free to contact me off list to discuss how we will handle getting
>>> openrc back on track.

Very cool. =:^)

If you/we're moving OpenRC development back in-house, a couple of the
problems with OpenRC as it was, pretty much cease to exist any more.

The problems with OpenRC first trace back to, from what I can see, a
disagreement some years ago, now -- which also played a non-minor role in
Roy leaving Gentoo, as well. Roy's idea was to take Gentoo toward POSIX
shell compatibility, both init-system-wise and package-system-wise. Over-
all, that went over like a lead balloon, a number of devs (including
several core toolchain, etc, devs, and council members) /liked/ the bash
extensions Gentoo relies on, and our package system remains solidly bash
dependent today, both by policy and in practice.

But Roy was the baselayout (then including what's now openrc as well)
maintainer, and he went ahead with his plans there, splitting baselayout
into the Gentoo specific baselayout, and the init system itself, which was
intended to be POSIX shell compliant and distribution and *nix system
independent, as well as implementing core parts of it as native
executables, thus speeding it up dramatically from the formerly almost
entirely shell scripted implementation.

In large part (at least from the view from here as a user of the new
system) it was due to the goals of POSIX shell compatibility and
distribution agnosticism that delayed and drew out OpenRC development and
stabilization so much, the reason why every time it seemed about ready to
go stable, along would come new versions with dramatic changes, dropping
more bashisms/gentooisms, or fixing bugs in the implementation triggered
by the last round of drops. Had the only or primary goal been simply the
split and the switch to the native code core, many of the changes, for
instance to the network subsystem, wouldn't have been necessary, and the
more parallel reliable and faster native code system would have been able
to stabilize far sooner.

But it would seem that whatever other distributions or BSDs he had hoped
to get using OpenRC went with something else, instead, and as Gentoo has
continued down the GNU/bash based system route, his interests and those of
Gentoo have continued to diverge as well, so the OpenRC project has
apparently become a dead-end as far as his interest is concerned, and he's
abandoning it.

Too bad for what could have been for OpenRC, but bringing it back in-house
does solve the two biggest problems Gentoo was having with it, all the
unnecessary (from a Gentoo perspective) changes removing bashisms and
gentooisms, and the fast rate of incompatible change, leaving Gentoo
without a practical base for stabilizing anything.

>> Well, openrc isn't any worse than baselayout-1 for upstream support.
>> However, I do agree that we should strongly try to standardize on
>> something that is more cross-platform if possible.
>>
>> I'd rather not push to make openrc stable (which means lots of
>> migration for users), only to then move to something else anyway. *Why
>> have two migrations when you can just have one?
>>
> The reason why people want to do an openrc migration right now is
> because we don't know when we'll find something else to move to; make it
> work with gentoo, make it work for everyone, iron out all the bugs, and
> push it to stable. In all probability, and looking at our past
> experience with pushing openrc to stable, it *will* take years. It's too
> much work to maintain both baselayout-1 *and* openrc *and* find
> something else to move to. It's best to move to openrc (which has
> numerous benefits over baselayout-1, and has a maintainer now), and then
> see what we can do.

Well, given the above and assuming Gentoo could settle on a reasonably
mature replacement within a reasonably short period (say 4-6 months), it's
possible adopting and stabilizing that replacement wouldn't take the years
and years that OpenRC has. Presumably, whatever we were to settle on
would already know where it was going, and wouldn't be doing the
change-horses-in-mid-stream thing that OpenRC was pulling, killing the
bashims, etc, at the same time.

But those are some big assumptions. I've gotten the impression that the
projects making the big waves aren't all that mature, and while they
hopefully aren't changing horses in mid-stream like OpenRC was doing, so
the development shouldn't be as painful in that regard, they still have
some serious growing to do before they're to the point where OpenRC is,
today.

Really, even if Gentoo does ultimately switch to something else, we do
need to get stable on something a bit more modern than the baselayout-1
we're stuck with ATM, and OpenRC is pretty close to there, particularly
since we're bringing it back in-house now, and it'll take some time for
our new maintainer to get up to speed on it, so the only right away
changes are likely to be what's necessary to fix the remaining bugs and
stabilize what we have -- we're not trying to hit a fast changing target,
as we were before, and there's nothing to trigger any more of those
incompatible changes simply for POSIX compatibility or the like, since
Gentoo depending on bash is a settled question at this point.

So really, openrc-for-stable it really needs to be, at this point. Once
that's for sure a settled question, /then/ we can debate whether Gentoo
should try to switch to something more standardized, and what that might
be if so, longer term. But what's very likely to be another two years
minimum, with no real upper bound at all at this point, on baselayout-1,
for stable users, while Gentoo dumps an OpenRC that's very close to stable
at this point, to chase after what could well be "the wind" for another
two years or more, possibly to realize that's simply not going to work for
Gentoo either, or if we force it, it'll be at the expense of serious
feature regression, just isn't a good idea, and there's no way to /make/
it a good idea.

So let's stabilize OpenRC and be done with it, and /then/ we can debate
where we want to go from there.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
 
Old 07-05-2010, 01:03 PM
"Anthony G. Basile"
 
Default The future of sys-apps/openrc in Gentoo

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/04/10 23:32, Nirbheek Chauhan wrote:
> On Mon, Jul 5, 2010 at 7:53 AM, Richard Freeman <rich0@gentoo.org> wrote:
>> On 07/04/2010 04:09 PM, Jory A. Pratt wrote:
>>>
>>> For those of you not on the #gentoo-dev channel, I just announced I am
>>> gonna be looking at the openrc code and fixing the bugs and working to
>>> continue the development. Anyone that is interested in helping please
>>> feel free to contact me off list to discuss how we will handle getting
>>> openrc back on track.
>>>
>>
>> Well, openrc isn't any worse than baselayout-1 for upstream support.
>> However, I do agree that we should strongly try to standardize on
something
>> that is more cross-platform if possible.
>>
>> I'd rather not push to make openrc stable (which means lots of
migration for
>> users), only to then move to something else anyway. Why have two
migrations
>> when you can just have one?
>>
>
> The reason why people want to do an openrc migration right now is
> because we don't know when we'll find something else to move to; make
> it work with gentoo, make it work for everyone, iron out all the bugs,
> and push it to stable. In all probability, and looking at our past
> experience with pushing openrc to stable, it *will* take years. It's
> too much work to maintain both baselayout-1 *and* openrc *and* find
> something else to move to. It's best to move to openrc (which has
> numerous benefits over baselayout-1, and has a maintainer now), and
> then see what we can do.
>

That's true, but there's also the fact that openrc has merits which
make it an attractive choice --- it is not just that we're stuck with
it. We've all used other init systems. I like openrc best. Its
excellent for servers and compatible with all the goodies people want
on desktops. It is one of the features that attracted me to Gentoo.
I'm going to be helping Jory and Patrick with this one. If people
feel strongly that we need another init system, it would be
interesting to have Gentoo compatible with others (although this
sounds like quagmire). However, I wouldn't want to see openrc go.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwx2AUACgkQl5yvQNBFVTWmrwCbBdgx7H0KF9 ugoO7Rwe9yOJTW
2TwAnRDnABYPAUyT2cH0i4rsyPQ8MsiY
=+yG6
-----END PGP SIGNATURE-----
 
Old 07-05-2010, 04:11 PM
Enrico Weigelt
 
Default The future of sys-apps/openrc in Gentoo

* Brian Harring <ferringb@gmail.com> schrieb:

> Requiring policykit, let alone networkmanager and dbus as a default is
> not something I'd personally agree with as a sane choice. If you're
> trying to build *just* a desktop distro, sure, it's sane. We're not
> however, thus invalidating those options from where I'm sitting.

ACK. I'd never put any system into production which requires dbus,
no change.

Maybe I'll find some time to rewrite systemd w/ dbus.
The overall concepts seem very promising to me - quite the same
direction I'm planning to go into.


cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
 
Old 07-05-2010, 04:13 PM
Enrico Weigelt
 
Default The future of sys-apps/openrc in Gentoo

* Nirbheek Chauhan <nirbheek@gentoo.org> schrieb:

> What you are saying makes sense for desktop users since they will
> likely already have consolekit/policykit/nm-applet installed, and
> hence using NetworkManager for all network management makes sense.

Actually, I've got several Gentoo-based desktop systems, none of
them uses any these packages.

> From what I can see, we have three options:
> (a) Make our existing openrc network code + openrc configuration files
> work with systemd, and move to systemd by default
> (b) Make systemd work with openrc+NM configuration files[1], make NM
> work w/o PK/CK[2], add command line tools to NM, and move to systemd
> by default.
> (c) Support systemd as an alternative init system for use by desktop users.

(d) Fix systemd to get rid of dependencies to dbus, etc.


cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
 
Old 07-07-2010, 12:56 AM
Doug Goldstein
 
Default The future of sys-apps/openrc in Gentoo

On Mon, Jul 5, 2010 at 11:13 AM, Enrico Weigelt <weigelt@metux.de> wrote:
> * Nirbheek Chauhan <nirbheek@gentoo.org> schrieb:
>
>> What you are saying makes sense for desktop users since they will
>> likely already have consolekit/policykit/nm-applet installed, and
>> hence using NetworkManager for all network management makes sense.
>
> Actually, I've got several Gentoo-based desktop systems, none of
> them uses any these packages.
>
>> From what I can see, we have three options:
>> (a) Make our existing openrc network code + openrc configuration files
>> work with systemd, and move to systemd by default
>> (b) Make systemd work with openrc+NM configuration files[1], make NM
>> work w/o PK/CK[2], add command line tools to NM, and move to systemd
>> by default.
>> (c) Support systemd as an alternative init system for use by desktop users.
>
> *(d) Fix systemd to get rid of dependencies to dbus, etc.
>
>

(e) Get our network scripts compatible with netcf [1], which is the
way of the future for letting applications modify the network
configuration of the system.

[1] https://fedorahosted.org/netcf/


--
Doug Goldstein
 
Old 08-23-2010, 02:17 PM
Jon Portnoy
 
Default The future of sys-apps/openrc in Gentoo

On Sun, Jul 04, 2010 at 09:03:41PM -0400, Olivier Cr?te wrote:
> On Sun, 2010-07-04 at 18:15 -0400, Mike Frysinger wrote:
> > which is trivial to fix and anyone with commit privs could have done. it
> > certainly doesnt warrant a paniced "the sky is falling" message.
>
> I think this is a great occasion to dump our stupid custom crap and
> switch to SystemD, PolicyKit, NetworkManager, etc. Anyone with half a
> brain already dropped our stuff. And the lack of use of modern tools is
> the reason I don't use Gentoo on my work computer anymore.
>


I wasn't looking to run Ubuntu, but thanks anyway 8)
 

Thread Tools




All times are GMT. The time now is 03:17 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org