[gentoo-dev] Questions about SystemD and OpenRC

[gentoo-dev] Questions about SystemD and OpenRC

[Sylvain Alain]

[-- Attachment #1: Type: text/plain, Size: 931 bytes --]

Hi everyone, for a couple of months now, I see on the list some of
activities about OpenRC been ported to FreeBSD or OpenRC to Debian and
other stuff related to SystemD.

I have some basic questions about all that :

1. The SystemD and Udev projetcs are merged now, so what is the impact on
the Gentoo on a short term period ?

2. I saw on some lists that Gnome/Kde and Xfce plan to use some SystemD
API, so does it means that we will need to install SystemD aside of OpenRC
?

3. In a long term vision, can OpenRC still exist on a Gentoo box(OpenRC
might be able to boot the box then give the control to SystemD/Udev for the
rest of the boot process)  or we will need to migrate to SystemD to be able
to use Gnome/Kde or Xfce ?

4. Finally, is there any reason why Gnome/Kde/Xfce wants to add deps
related to SystemD ? I don't understand why these desktops want to depend
on a specific Sysint....

Thanks !

Sylvain aka d2_racing

[-- Attachment #2: Type: text/html, Size: 993 bytes --]

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Rich Freeman]

On Tue, Aug 7, 2012 at 8:47 AM, Sylvain Alain <d2racing911@gmail.com> wrote:
> Hi everyone, for a couple of months now, I see on the list some of
> activities about OpenRC been ported to FreeBSD or OpenRC to Debian and other
> stuff related to SystemD.
>

You and half the world.  Most of the issues you raise are much bigger
than Gentoo and are taking the whole linux world by storm.

> I have some basic questions about all that :
>
> 1. The SystemD and Udev projetcs are merged now, so what is the impact on
> the Gentoo on a short term period ?

In the short term nothing, although systemd has half-decent support
now, the default remains openrc and there are no plans to change that.

>
> 2. I saw on some lists that Gnome/Kde and Xfce plan to use some SystemD API,
> so does it means that we will need to install SystemD aside of OpenRC ?
>

Now, no.  In the future - nobody really knows for sure, but it seems
likely that at least in some cases not only will you need to install
it, but you'll need to run it also.

I'd heard only Gnome was moving in this direction, but perhaps other
projects are as well.  I'd be surprised if Xfce moves in this
direction - they've always been about being minimal.

> 3. In a long term vision, can OpenRC still exist on a Gentoo box(OpenRC
> might be able to boot the box then give the control to SystemD/Udev for the
> rest of the boot process)  or we will need to migrate to SystemD to be able
> to use Gnome/Kde or Xfce ?
>

If you do need systemd for gnome/etc then most likely you'll just want
to use it across the board.  Trying to run some kind of a hybrid seems
like the worst of both worlds.

> 4. Finally, is there any reason why Gnome/Kde/Xfce wants to add deps related
> to SystemD ? I don't understand why these desktops want to depend on a
> specific Sysint....

You'd have to talk to them, but I believe their goal is to go for more
of a vertically-integrated experience (which fits more with Gnome or
KDE than Xfce, but again the last I'd heard only Gnome was going in
this direction so far).  Ubuntu is doing similar things with
Unity/Upstart.

I don't know everything that the integration will support, but I can
imagine they're interested in things like better WiFi and network
roaming support (re-set your network, re-configure your firewall
settings, update the UI, etc), better behavior during
suspend/resume/etc, handling of things like bluetooth, and so on.  I
don't run linux on a laptop unless you count my Chromebook so I can't
really vouch for what the current experience is like or what needs
improvement.

I've tried to stick to the facts here, at least as far as I'm aware of
them.  I don't think we need another 50-post thread on The Unix
Way(TM) and whether it is a good or bad thing.  These developments are
going to be a challenge for distros like Gentoo or Debian that aim to
be general/meta distributions.  It used to be that you could swap out
major components and all the APIs/interfaces still worked.  In the
future it might be much harder to run Gnome on Gentoo on an OSX
kernel, etc.  However, all of this is a bit speculative and it is hard
to say how things will actually turn out.

Rich

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Peter Stuge]

Rich Freeman wrote:
> In the future it might be much harder to run Gnome on Gentoo on an OSX
> kernel, etc.

Yes, but if the upstream that is Gnome decides to start depending on
systemd features then that's their decision, and the place to discuss
if it's good or bad (more important, the place to change it!) would
be within the Gnome project.

I guess Gentoo will always continue to offer the best of upstream.

OTOH, if upstream goes and make some change that means a regression
for Gentoo users, then they deserve bug report floods from their users! :)


//Peter

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Rich Freeman]

On Tue, Aug 7, 2012 at 10:11 AM, Peter Stuge <peter@stuge.se> wrote:
> Yes, but if the upstream that is Gnome decides to start depending on
> systemd features then that's their decision, and the place to discuss
> if it's good or bad (more important, the place to change it!) would
> be within the Gnome project.

More or less, but again my goal was not to start another discussion -
just to inform.  Anybody inclined to comment on whether this is good
or bad should go look at the list archives and see if any of the 400
messages in the last month already covered their points.

>
> I guess Gentoo will always continue to offer the best of upstream.

I don't think Gentoo has to limit itself to what upstream supports (I
don't think anybody would look at Prefix and say that this was what
any upstream had in mind).  However, the bottom line is that to do
something exotic takes effort, so nothing will happen unless somebody
makes it happen.

>
> OTOH, if upstream goes and make some change that means a regression
> for Gentoo users, then they deserve bug report floods from their users! :)

Perhaps, but don't count on it going anywhere.  With Gnome 3 they must
already have pretty thick skin.  I suspect upstream would say that if
you want a smooth desktop experience you shouldn't be running Gentoo.
To some degree they probably even have a valid point.  Gentoo is about
more than a just-works desktop so I think the best we'll be able to
offer is a "reasonable" experience.  If things get really integrated
you might see some Sabayon-like forks favoring particular DEs/etc, and
as long as those forks contribute to our main tree I think that is
good for all of us.

Rich

Re: [gentoo-dev] Gentoo vs. upstream

[Peter Stuge]

Rich Freeman wrote:
> I suspect upstream would say that if you want a smooth desktop
> experience you shouldn't be running Gentoo. To some degree they
> probably even have a valid point.

Yes and no.. I think it will always be possible to use Gentoo to
create as smooth a desktop experience as any distro provides, but
it will certainly require knowing every single detail of what makes
that desktop experience possible.


> Gentoo is about more than a just-works desktop

Yes! <3


> so I think the best we'll be able to offer is a "reasonable"
> experience.

One doesn't have to exclude the other, but users will have to know
how things work, in order to use Gentoo to get things the way they
want them. Just like it has always been.


> If things get really integrated you might see some Sabayon-like
> forks favoring particular DEs/etc, and as long as those forks
> contribute to our main tree I think that is good for all of us.

I agree completely!


//Peter

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Sylvain Alain]

[-- Attachment #1: Type: text/plain, Size: 2101 bytes --]

The KDE team seems to work on that too :
http://lists.kde.org/?l=kde-core-devel&m=134052539215508&w=2

Now I understand why some devs are working hard to make Mdev working with
OpenRC.

They want to replace Udev/SystemD with Mdev/OpenRC and solve this situation.

Sylvain aka d2_racing

2012/8/7 Rich Freeman <rich0@gentoo.org>

> On Tue, Aug 7, 2012 at 10:11 AM, Peter Stuge <peter@stuge.se> wrote:
> > Yes, but if the upstream that is Gnome decides to start depending on
> > systemd features then that's their decision, and the place to discuss
> > if it's good or bad (more important, the place to change it!) would
> > be within the Gnome project.
>
> More or less, but again my goal was not to start another discussion -
> just to inform.  Anybody inclined to comment on whether this is good
> or bad should go look at the list archives and see if any of the 400
> messages in the last month already covered their points.
>
> >
> > I guess Gentoo will always continue to offer the best of upstream.
>
> I don't think Gentoo has to limit itself to what upstream supports (I
> don't think anybody would look at Prefix and say that this was what
> any upstream had in mind).  However, the bottom line is that to do
> something exotic takes effort, so nothing will happen unless somebody
> makes it happen.
>
> >
> > OTOH, if upstream goes and make some change that means a regression
> > for Gentoo users, then they deserve bug report floods from their users!
> :)
>
> Perhaps, but don't count on it going anywhere.  With Gnome 3 they must
> already have pretty thick skin.  I suspect upstream would say that if
> you want a smooth desktop experience you shouldn't be running Gentoo.
> To some degree they probably even have a valid point.  Gentoo is about
> more than a just-works desktop so I think the best we'll be able to
> offer is a "reasonable" experience.  If things get really integrated
> you might see some Sabayon-like forks favoring particular DEs/etc, and
> as long as those forks contribute to our main tree I think that is
> good for all of us.
>
> Rich
>
>


-- 
Salut
alp
Sylvain

[-- Attachment #2: Type: text/html, Size: 2840 bytes --]

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2744 bytes --]

On Tue, 7 Aug 2012 11:33:59 -0400
Sylvain Alain <d2racing911@gmail.com> wrote:

> The KDE team seems to work on that too :
> http://lists.kde.org/?l=kde-core-devel&m=134052539215508&w=2

it's actually worth it.
more user-spread FUD or however you like to call it on the topic than
I'm not sure if *devs* are actually working on that. I believe there's
 
> Now I understand why some devs are working hard to make Mdev working
> with OpenRC.

different, you could as well disable USE=udev and use regular udev.
equivalent to KDE/GNOME/whatever without anything? And if it's no
But you are aware that KDE/GNOME/whatever+mdev would be practically

> They want to replace Udev/SystemD with Mdev/OpenRC and solve this
> situation.
> 
> Sylvain aka d2_racing
> 
> 2012/8/7 Rich Freeman <rich0@gentoo.org>
> 
> > On Tue, Aug 7, 2012 at 10:11 AM, Peter Stuge <peter@stuge.se> wrote:
> > > Yes, but if the upstream that is Gnome decides to start depending
> > > on systemd features then that's their decision, and the place to
> > > discuss if it's good or bad (more important, the place to change
> > > it!) would be within the Gnome project.
> >
> > More or less, but again my goal was not to start another discussion
> > - just to inform.  Anybody inclined to comment on whether this is
> > good or bad should go look at the list archives and see if any of
> > the 400 messages in the last month already covered their points.
> >
> > >
> > > I guess Gentoo will always continue to offer the best of upstream.
> >
> > I don't think Gentoo has to limit itself to what upstream supports
> > (I don't think anybody would look at Prefix and say that this was
> > what any upstream had in mind).  However, the bottom line is that
> > to do something exotic takes effort, so nothing will happen unless
> > somebody makes it happen.
> >
> > >
> > > OTOH, if upstream goes and make some change that means a
> > > regression for Gentoo users, then they deserve bug report floods
> > > from their users!
> > :)
> >
> > Perhaps, but don't count on it going anywhere.  With Gnome 3 they
> > must already have pretty thick skin.  I suspect upstream would say
> > that if you want a smooth desktop experience you shouldn't be
> > running Gentoo. To some degree they probably even have a valid
> > point.  Gentoo is about more than a just-works desktop so I think
> > the best we'll be able to offer is a "reasonable" experience.  If
> > things get really integrated you might see some Sabayon-like forks
> > favoring particular DEs/etc, and as long as those forks contribute
> > to our main tree I think that is good for all of us.
> >
> > Rich
> >
> >
> 
> 



-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Michael Mol]

On Tue, Aug 7, 2012 at 12:29 PM, Michał Górny <mgorny@gentoo.org> wrote:
> On Tue, 7 Aug 2012 11:33:59 -0400
> Sylvain Alain <d2racing911@gmail.com> wrote:
>
>> The KDE team seems to work on that too :
>> http://lists.kde.org/?l=kde-core-devel&m=134052539215508&w=2
>
> it's actually worth it.
> more user-spread FUD or however you like to call it on the topic than
> I'm not sure if *devs* are actually working on that. I believe there's

Perhaps not official Gentoo devs, but users taking development
initiative to solve a problem in userland. I'm not an official Gentoo
dev, either, but I think it'd be a very bad idea to discourage or
ridicule such initiative. Someone putting in that much effort in light
of all the information already available isn't something that should
be taken lightly!

>
>> Now I understand why some devs are working hard to make Mdev working
>> with OpenRC.
>

> different, you could as well disable USE=udev and use regular udev.

> equivalent to KDE/GNOME/whatever without anything? And if it's no

> But you are aware that KDE/GNOME/whatever+mdev would be practically

(My reason for replying...looks like a few chunks of text got lost here.)

[snip]


-- 
:wq

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2074 bytes --]

On Tue, 7 Aug 2012 13:31:32 -0400
Michael Mol <mikemol@gmail.com> wrote:

> On Tue, Aug 7, 2012 at 12:29 PM, Michał Górny <mgorny@gentoo.org>
> wrote:
> > On Tue, 7 Aug 2012 11:33:59 -0400
> > Sylvain Alain <d2racing911@gmail.com> wrote:
> >
> >> The KDE team seems to work on that too :
> >> http://lists.kde.org/?l=kde-core-devel&m=134052539215508&w=2
> >
> > it's actually worth it.
> > more user-spread FUD or however you like to call it on the topic
> > than I'm not sure if *devs* are actually working on that. I believe
> > there's
> 
> Perhaps not official Gentoo devs, but users taking development
> initiative to solve a problem in userland. I'm not an official Gentoo
> dev, either, but I think it'd be a very bad idea to discourage or
> ridicule such initiative. Someone putting in that much effort in light
> of all the information already available isn't something that should
> be taken lightly!

I don't want to offend anyone but let's be honest: people start many
initiatives, and they are not always right, no matter how many effort
is put. I don't want to discourage it but sometimes I dislike
the importunity accompanying it.

Users are free to do whatever they want as long as it doesn't harm
the rest of users. And I'm afraid that too much enthusiasm over mdev
will actually cause a number of users to end up being disappointed
that one or another magic requiring udev no longer works.

> 
> >
> >> Now I understand why some devs are working hard to make Mdev
> >> working with OpenRC.
> >
> 
> > different, you could as well disable USE=udev and use regular udev.
> 
> > equivalent to KDE/GNOME/whatever without anything? And if it's no
> 
> > But you are aware that KDE/GNOME/whatever+mdev would be practically
> 
> (My reason for replying...looks like a few chunks of text got lost
> here.)

Sorry for the confusion caused to you and the others. You need to read
it bottom-to-top. I reversed the line order for Sylvain who seems to
prefer reading that way. 

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Dale]

Michał Górny wrote:
> On Tue, 7 Aug 2012 13:31:32 -0400
> Michael Mol <mikemol@gmail.com> wrote:
>
>> On Tue, Aug 7, 2012 at 12:29 PM, Michał Górny <mgorny@gentoo.org>
>> wrote:
>>> On Tue, 7 Aug 2012 11:33:59 -0400
>>> Sylvain Alain <d2racing911@gmail.com> wrote:
>>>
>>>> The KDE team seems to work on that too :
>>>> http://lists.kde.org/?l=kde-core-devel&m=134052539215508&w=2
>>> it's actually worth it.
>>> more user-spread FUD or however you like to call it on the topic
>>> than I'm not sure if *devs* are actually working on that. I believe
>>> there's
>> Perhaps not official Gentoo devs, but users taking development
>> initiative to solve a problem in userland. I'm not an official Gentoo
>> dev, either, but I think it'd be a very bad idea to discourage or
>> ridicule such initiative. Someone putting in that much effort in light
>> of all the information already available isn't something that should
>> be taken lightly!
> I don't want to offend anyone but let's be honest: people start many
> initiatives, and they are not always right, no matter how many effort
> is put. I don't want to discourage it but sometimes I dislike
> the importunity accompanying it.
>
> Users are free to do whatever they want as long as it doesn't harm
> the rest of users. And I'm afraid that too much enthusiasm over mdev
> will actually cause a number of users to end up being disappointed
> that one or another magic requiring udev no longer works.

User perspective follows:

What I don't like about the way Walter, mdev, is being treated is this. 
People say that if you don't like the way udev is going, WRITE CODE.  If
you are not going to write code, don't complain about udev.  Then
Walter, I think I got the name right, comes along and comes up with a
alternative for udev that seems to work well for the people using it. 
Then people complain because he is actually stepping up and WRITING
CODE.  Well, it seems a person can't win on this. 

Some, no names mentioned, need to make up their minds.  Either listen
when people don't like the way things are going or let people write code
to have a alternative to whatever people are not liking and don't
complain because people are stepping up and doing something about it,
for example, writing code.

As to mdev not being as feature rich as udev, well, some people don't
need the features udev has and I don't think anyone is saying mdev is
the same as udev.  It even says on the wiki that there are some
situations where it should not even be tried because it is known to not
work.  Given that, if a person tries to use mdev to replace udev in a
situation where it is known not to work, then they should read more
closely.  It's not Walters fault, it's the person in the chair. 

Now, since Walter didn't like the way things are going, can he write
code and be left in peace to do so?  Maybe have a little bit of support
while he is doing it? 

Dale

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Rich Freeman]

On Tue, Aug 7, 2012 at 5:36 PM, Dale <rdalek1967@gmail.com> wrote:
> Now, since Walter didn't like the way things are going, can he write
> code and be left in peace to do so?  Maybe have a little bit of support
> while he is doing it?

++

I can't say I think that preferring mdev over an initramfs is a good
choice, but I can say that I prefer that people have the choice to
make in the first place.  Nobody can expect anybody to maintain
something for them, but if some are willing to step up and give Gentoo
a bit of a broader perspective that is what we're all about.  Where
else are you going to find a linux distro that can run a fair bit of
their repository on Interix of all things?

We all get grumpy from time to time, but I've learned that if you're
going to speak up it is best if you're doing so to offer something
better, and not just to gripe.  My hat is always off to those who
write code, and the community around Gentoo that has allowed us to
choose whether to run it.  Systemd, Dracut, Wayland, and more - bring
it on, and if my writing an odd init script/unit/whatever for a
package I maintain makes it possible to do something genuinely new
with Gentoo, then file all the bugs you want.  :)

Rich

[gentoo-dev] Re: Questions about SystemD and OpenRC

[Duncan]

Dale posted on Tue, 07 Aug 2012 16:36:30 -0500 as excerpted:

> What I don't like about the way Walter, mdev, is being treated is this.
> People say that if you don't like the way udev is going, WRITE CODE.  If
> you are not going to write code, don't complain about udev.  Then
> Walter, I think I got the name right, comes along and comes up with a
> alternative for udev that seems to work well for the people using it.
> Then people complain because he is actually stepping up and WRITING
> CODE.  Well, it seems a person can't win on this.

FWIW, while this isn't (currently at least) a solution I'd use, I 
certainly respect the man both for coming up with a solution to his own 
problems, and more importantly, for sharing it with others. =:^)

The more so here, since as he's stated (and much like me), he's 
reasonable with scripting, etc, but doesn't claim to be a C/C++ coder.

I believe there's quite a few list readers who have a similar respect for 
his efforts.  Just because it's not something they'd use personally, 
doesn't mean they don't respect the idea.

I believe at least some of the push-back isn't out of disrespect per se, 
or even saying it shouldn't be done, it's more a skepticism many within 
the FLOSS community develop over time, having seen all sorts of projects 
begun, but few of them actually survive more than a few months, 
continuing to be maintained and updated over years.  Just take a look at 
sourceforge or github or the like, for the number of half-or quarter-
finished projects...

FLOSS projects are similar to business startups in that regard.  
Something like 80% don't survive a year or ever become even close to self-
sufficient, but if they do... they're generally around for five.  (Tho a 
difference with FLOSS is that in 5-10 years, the /need/ for the project 
has often disappeared as well, at least as originally envisioned.  By 
that point many projects that actually survived their first year and got 
a userbase, have either evolved far enough from the original idea that 
they're hardly recognizable, or have simply disappeared as no longer 
necessary or useful.  By contrast, a business life cycle, once it gets 
beyond that first year, tends to be rather longer...

So I think a lot of it is more a "nice idea, we'll see if it sticks 
around", more than a disrespect for it or the person behind it, per se.  
If it's still around and actually useful in a couple years, I expect 
you'll see a lot more overt respect that simply isn't evident, now.

-- 
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

Re: [gentoo-dev] Re: Questions about SystemD and OpenRC

[Peter Stuge]

Duncan wrote:
> I believe there's quite a few list readers who have a similar respect
> for his efforts.

I believe so too!

I think it's a great effort. It may not fit my use cases, but I don't
care about that - even if it is *only* Walter scratching his own itch
I agree that it's important to show some love for the work. It
doesn't matter right now if the itch will go away or if mdev will
rule the Linux desktop one day. It's ongoing work and I think it's
important not to dismiss it.


//Peter

[gentoo-dev] Re: Questions about SystemD and OpenRC

[Duncan]

Michał Górny posted on Tue, 07 Aug 2012 22:13:21 +0200 as excerpted:

> Sorry for the confusion caused to you and the others. You need to read
> it bottom-to-top. I reversed the line order for Sylvain who seems to
> prefer reading that way.

LOL!  THAT's what it was!  Along the same lines...

...senil emas eht gnolA  !saw ti tahw s'TAHT  !LOL

http://www.textreverse.com/

(While the link I had saved was stale it did mean I still remembered 
enough about it to plug the idea into google and successfully find it. 
Link updated.  =:^)

-- 
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

Re: [gentoo-dev] Re: Questions about SystemD and OpenRC

[Kent Fredric]

On 8 August 2012 22:55, Duncan <1i5t5.duncan@cox.net> wrote:
> LOL!  THAT's what it was!  Along the same lines...
>
> ...senil emas eht gnolA  !saw ti tahw s'TAHT  !LOL
>
> http://www.textreverse.com/
>
> (While the link I had saved was stale it did mean I still remembered
> enough about it to plug the idea into google and successfully find it.
> Link updated.  =:^)

https://duckduckgo.com/?q=reverse+hgual%20doog%20a%20ekil%20sdnuos%20taht

Google not required ;D

(Also, that textreverse.com link was really slow to load )

-- 
Kent

Re: [gentoo-dev] Re: Questions about SystemD and OpenRC

[Peter Stuge]

Kent Fredric wrote:
> > (While the link I had saved was stale it did mean I still remembered
> > enough about it to plug the idea into google and successfully find it.
> > Link updated.  =:^)
> 
> https://duckduckgo.com/?q=reverse+hgual%20doog%20a%20ekil%20sdnuos%20taht
> 
> Google not required ;D

Internet not required:

$ rev <<< foobar
raboof
$ tac <<< 'line1
> line2'
line2
line1
$ 


//Peter

[gentoo-dev] Re: Questions about SystemD and OpenRC

[Duncan]

Peter Stuge posted on Wed, 08 Aug 2012 13:22:54 +0200 as excerpted:

> Internet not required:
> 
> $ rev <<< foobar
> raboof
> $ tac [...]

Thanks.

I'd read about those before (at least tac), but they aren't links (stale 
or not), so I'd forgotten them...

Hmm... links to the manpages might solve that! =:^)

http://ss64.com/bash/tac.html

http://ss64.com/bash/rev.html

-- 
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

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Jason A. Donenfeld]

On Tue, Aug 7, 2012 at 3:17 PM, Rich Freeman <rich0@gentoo.org> wrote:

> You'd have to talk to them, but I believe their goal is to go for more
> of a vertically-integrated experience (which fits more with Gnome or
> KDE than Xfce, but again the last I'd heard only Gnome was going in
> this direction so far).  Ubuntu is doing similar things with
> Unity/Upstart.

It's worth noting that KDE is actually becoming more independent, as
KDE Frameworks 5 is going to focus on having smaller separate reusable
components, with fewer monolithic dependencies.

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Olivier Crête]

[-- Attachment #1: Type: text/plain, Size: 2455 bytes --]

Hi,

Let's cut the FUD.

On Tue, 2012-08-07 at 08:47 -0400, Sylvain Alain wrote:
> 1. The SystemD and Udev projetcs are merged now, so what is the impact
> on the Gentoo on a short term period ?

Only the build system is merged, they're still separate binaries.

> 2. I saw on some lists that Gnome/Kde and Xfce plan to use some
> SystemD API, so does it means that we will need to install SystemD
> aside of OpenRC ? 


The APIs that GNOME is using from systemd are simple, well designed and
well documented D-Bus APIs [1][2][3]. They are implemented by simple
binaries separate from the core systemd. Legacy init systems can just
re-use them as-is.

Also, systemd includes logind, which replaces ConsoleKit with a much
better design.

> 4. Finally, is there any reason why Gnome/Kde/Xfce wants to add deps
related to SystemD ? I don't understand why these desktops want to
depend on a specific Sysint....

Old versions of GNOME (and KDE, XFCE, etc) had to have distro-specific
code for a bunch of things, such as changing the timezone, the system
locale or the hostname. Because these things are in separate places in
every distribution for historical reason. So every desktop had to
re-implement these things for every distribution, making a lot of
duplicated code. The goal is to have a single set of tools using a
common D-Bus API that you only have to implement once per distribution
and that every desktop can use.

> 3. In a long term vision, can OpenRC still exist on a Gentoo
> box(OpenRC might be able to boot the box then give the control to
> SystemD/Udev for the rest of the boot process)  or we will need to
> migrate to SystemD to be able to use Gnome/Kde or Xfce ?

I expect that in the not so long term, systemd will become an essential
user-space component of desktop Linux, just like crond, syslog, dbus,
udev or glibc. Sharing that code just makes sense, that allows
distributions to focus on their strength instead of having to maintain a
nightmare of shell scripts. Sure you can do a Android and write your own
crappier version, but that doesn't gain you anything.

Refs:
[1] http://www.freedesktop.org/wiki/Software/systemd/hostnamed
[2] http://www.freedesktop.org/wiki/Software/systemd/timedated
[3] http://www.freedesktop.org/wiki/Software/systemd/localed
[4] http://www.freedesktop.org/wiki/Software/systemd/logind

-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Luca Barbato]

On 08/07/2012 09:00 PM, Olivier Crête wrote:
> I expect that in the not so long term, systemd will become an essential
> user-space component of desktop Linux, just like crond, syslog, dbus,
> udev or glibc. Sharing that code just makes sense, that allows

As in completely optional and easily replaceable? That would be a nice
improvement over the current "use it or die" attitude.

> distributions to focus on their strength instead of having to maintain a
> nightmare of shell scripts. Sure you can do a Android and write your own
> crappier version, but that doesn't gain you anything.

Repeat after me: having your first process require anything more than
libc is stupid and dangerous.

Once that concept gets accepted then we could discuss about why
reinventing shellscript may not be that sound and other less glaring,
horrid and appalling design choices.

Most ideas behind systemd are interesting, their current implementation
is sometimes completely wrong and given the experience with pulseaudio
we all know that they won't change even if you provide code for it.

Obviously it is always fun seeing people first say "accept it or fork
it", then "do not keep your fork you are wasting time" once somebody
starts forking and/or working for an alternative.


lu

Re: [gentoo-dev] pid 1 design

[Peter Stuge]

Luca Barbato wrote:
> Repeat after me: having your first process require anything more
> than libc is stupid and dangerous.

Why do you say?

And why is libc different from other libraries, say libuuid or
libext2fs? I mean: Why allow pid 1 to require libc, it could
just be statically linked.


//Peter

Re: [gentoo-dev] pid 1 design

[Rich Freeman]

On Thu, Aug 9, 2012 at 10:02 AM, Peter Stuge <peter@stuge.se> wrote:
> Luca Barbato wrote:
>> Repeat after me: having your first process require anything more
>> than libc is stupid and dangerous.
>
> Why do you say?
>
> And why is libc different from other libraries, say libuuid or
> libext2fs? I mean: Why allow pid 1 to require libc, it could
> just be statically linked.

So, while I've had only positive (but limited) experiences with
systemd, I can understand the fundamental design concern with having a
complex process running as pid 1.  If init dies, the kernel panics
(just boot your system with init=/bin/bash and type exit to see).

So, a simple init that is less likely to die is a good thing.

That said, init NEEDS to be able to communicate with other processes
if you don't want it to keep propping things up when you're trying to
shut the system down.  This is usually done via signals (init can trap
them all at least on linux), but I believe there are other mechanisms
that have been used in traditional init implementations.  It seems
like the big changes to systemd/etc are to allow it to communicate via
dbus.

I'm not sure why having systemd be a monolithic PID=1 solution was
chosen - that is probably a better topic for their lists.  Maybe a
more resilient solution would be to have an init as PID=1 that does
nothing but launch systemd and keep it propped up until it gets a
signal from systemd.  However, that could have issues I'm just not
thinking of.  That could be accomplished just by running the
traditional init and having a runlevel with just systemd in it, aside
from any issues not being PID 1 creates for systemd.

Rich

Re: [gentoo-dev] pid 1 design

[Wyatt Epp]

On Thu, Aug 9, 2012 at 11:25 AM, Rich Freeman <rich0@gentoo.org> wrote:
> ...have an init as PID=1 that does
> nothing but launch systemd and keep it propped up until it gets a
> signal from systemd.  However, that could have issues I'm just not
> thinking of.

I'm not the maintainer, but this method does seem to work pretty well
for OpenRC and our old friend baselayout-1 (so, the last decade or so,
as I understand it).

Re: [gentoo-dev] pid 1 design

[Rich Freeman]

On Thu, Aug 9, 2012 at 12:00 PM, Wyatt Epp <wyatt.epp@gmail.com> wrote:
> On Thu, Aug 9, 2012 at 11:25 AM, Rich Freeman <rich0@gentoo.org> wrote:
>> ...have an init as PID=1 that does
>> nothing but launch systemd and keep it propped up until it gets a
>> signal from systemd.  However, that could have issues I'm just not
>> thinking of.
>
> I'm not the maintainer, but this method does seem to work pretty well
> for OpenRC and our old friend baselayout-1 (so, the last decade or so,
> as I understand it).

Yes, but OpenRC basically just launches processes and considers itself
done with them.  Systemd is a bit more like a shepherd, looking after
things for their entire lifecycle.  When you use openrc to stop a
process it just runs a script which is responsible for cleaning up.
If you stop a systemd service it can try nicely first, but if any
descendant of the service is left running it will be cleaned up with a
vengeance.  If a process is supposed to be running and stops, systemd
can restart it (which makes it more like init - which restarts
anything in inittab if it dies).

Systemd isn't a like-for-like replacement for traditional inits.  It
aims to be much more, so this is a bit of an apples-to-oranges
comparison.  Again, I'm not sure that it HAS to work the way it does,
but I wouldn't dismiss their design simply because it is different.
Also again, if curious I'd probably ask on their own list, assuming it
hasn't already been answered there.

Rich

Re: [gentoo-dev] pid 1 design

[Peter Stuge]

Rich Freeman wrote:
> Systemd is a bit more like a shepherd, looking after things for
> their entire lifecycle.

This is a big part of why it is so useful.

I threw out init scripts because it was retarded to not monitor
long-running processes on servers.

Those processes shouldn't fail, but sometimes they do anyway.

sysvinit does the monitoring already and I wanted to write my own
monitoring solution sometime in the 90s, until I found daemontools
which did exactly what I wanted to do, and in a way quite similar
to how I would have implemented it. Win. \o/


> Systemd isn't a like-for-like replacement for traditional inits.
> It aims to be much more, so this is a bit of an apples-to-oranges
> comparison.

Yes, it is much more, which is a very nice thing on the systems
it supports. I believe systemd is not usuable at all outside Linux
and will not likely ever be, so for prefix there will anyway always
be systemd alternatives in Gentoo! And on those systems the service
files should never be installed.


> Again, I'm not sure that it HAS to work the way it does

I would say that it does, because it is required in order to
accomplish what systemd wants to deliver.


//Peter

Re: [gentoo-dev] pid 1 design

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2364 bytes --]

On Thu, 9 Aug 2012 22:27:37 +0200
Peter Stuge <peter@stuge.se> wrote:

> Rich Freeman wrote:
> > Systemd is a bit more like a shepherd, looking after things for
> > their entire lifecycle.
> 
> This is a big part of why it is so useful.
> 
> I threw out init scripts because it was retarded to not monitor
> long-running processes on servers.
> 
> Those processes shouldn't fail, but sometimes they do anyway.
> 
> sysvinit does the monitoring already and I wanted to write my own
> monitoring solution sometime in the 90s, until I found daemontools
> which did exactly what I wanted to do, and in a way quite similar
> to how I would have implemented it. Win. \o/

I still remember using djbdns for a while. I especially threw away
the daemontools part of it and wrote openrc scripts to not have 20
additional processes to run a tiny DNS server.

> > Systemd isn't a like-for-like replacement for traditional inits.
> > It aims to be much more, so this is a bit of an apples-to-oranges
> > comparison.
> 
> Yes, it is much more, which is a very nice thing on the systems
> it supports. I believe systemd is not usuable at all outside Linux
> and will not likely ever be, so for prefix there will anyway always
> be systemd alternatives in Gentoo! And on those systems the service
> files should never be installed.

Considering that systemd unit files are sometimes shipped with upstream
packages, and often they are practically equivalent to openrc init
scripts, I'd rather see openrc supporting that file format
as an extension and using it instead of duplicating the same thing
in init.d scripts.

And yes, that means that people masking service files shoot themselves
in the foot.

Also, if I had more time (or support), I'd probably start working
on a systemd-compatible init system with a more portable design.

> > Again, I'm not sure that it HAS to work the way it does
> 
> I would say that it does, because it is required in order to
> accomplish what systemd wants to deliver.

Not necessarily. You can move many 'extra' systemd features outside of
PID 1. For example, unit dependency trees are complex by definition
and practically not necessary for PID 1.

In other words, it could be designed to move more complex (and thus
risky) tasks outside of PID 1.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] pid 1 design

[Michael Mol]

On Thu, Aug 9, 2012 at 4:37 PM, Michał Górny <mgorny@gentoo.org> wrote:
> On Thu, 9 Aug 2012 22:27:37 +0200
> Peter Stuge <peter@stuge.se> wrote:
>
>> Rich Freeman wrote:

[snip]

>> > Systemd isn't a like-for-like replacement for traditional inits.
>> > It aims to be much more, so this is a bit of an apples-to-oranges
>> > comparison.
>>
>> Yes, it is much more, which is a very nice thing on the systems
>> it supports. I believe systemd is not usuable at all outside Linux
>> and will not likely ever be, so for prefix there will anyway always
>> be systemd alternatives in Gentoo! And on those systems the service
>> files should never be installed.
>
> Considering that systemd unit files are sometimes shipped with upstream
> packages, and often they are practically equivalent to openrc init
> scripts, I'd rather see openrc supporting that file format
> as an extension and using it instead of duplicating the same thing
> in init.d scripts.
>
> And yes, that means that people masking service files shoot themselves
> in the foot.
>
> Also, if I had more time (or support), I'd probably start working
> on a systemd-compatible init system with a more portable design.

I would find this very interesting. I doubt I could find time for much
active contribution, unfortunately, but I'd help where I could.

>
>> > Again, I'm not sure that it HAS to work the way it does
>>
>> I would say that it does, because it is required in order to
>> accomplish what systemd wants to deliver.
>
> Not necessarily. You can move many 'extra' systemd features outside of
> PID 1. For example, unit dependency trees are complex by definition
> and practically not necessary for PID 1.
>
> In other words, it could be designed to move more complex (and thus
> risky) tasks outside of PID 1.

+1

-- 
:wq

Re: [gentoo-dev] pid 1 design

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2079 bytes --]

On Thu, 9 Aug 2012 16:45:28 -0400
Michael Mol <mikemol@gmail.com> wrote:

> On Thu, Aug 9, 2012 at 4:37 PM, Michał Górny <mgorny@gentoo.org>
> wrote:
> > On Thu, 9 Aug 2012 22:27:37 +0200
> > Peter Stuge <peter@stuge.se> wrote:
> >
> >> Rich Freeman wrote:
> 
> [snip]
> 
> >> > Systemd isn't a like-for-like replacement for traditional inits.
> >> > It aims to be much more, so this is a bit of an apples-to-oranges
> >> > comparison.
> >>
> >> Yes, it is much more, which is a very nice thing on the systems
> >> it supports. I believe systemd is not usuable at all outside Linux
> >> and will not likely ever be, so for prefix there will anyway always
> >> be systemd alternatives in Gentoo! And on those systems the service
> >> files should never be installed.
> >
> > Considering that systemd unit files are sometimes shipped with
> > upstream packages, and often they are practically equivalent to
> > openrc init scripts, I'd rather see openrc supporting that file
> > format as an extension and using it instead of duplicating the same
> > thing in init.d scripts.
> >
> > And yes, that means that people masking service files shoot
> > themselves in the foot.
> >
> > Also, if I had more time (or support), I'd probably start working
> > on a systemd-compatible init system with a more portable design.
> 
> I would find this very interesting. I doubt I could find time for much
> active contribution, unfortunately, but I'd help where I could.

Well, the sad thing is that I don't really have much expertise in this
area. I like the philosophy of designing many smalls things which just
work well together, so I would probably start that by reinventing some
helper tools.

It would be most helpful to get some aid from OpenRC team. I believe
that some common-use tools written for the project could be used
and tested in OpenRC first. And that way, slowly a new init system
could enter the world.

Sadly, it would be strictly bound to file formats and names set by
systemd team.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] pid 1 design

[heroxbd]

[-- Attachment #1: Type: text/plain, Size: 680 bytes --]

Michał Górny <mgorny@gentoo.org> writes:

> Considering that systemd unit files are sometimes shipped with upstream
> packages, and often they are practically equivalent to openrc init
> scripts, I'd rather see openrc supporting that file format
> as an extension and using it instead of duplicating the same thing
> in init.d scripts.

I bet this resonate with many minds out here. I am also planning to make
a draft implementation.

> And yes, that means that people masking service files shoot themselves
> in the foot.
>
> Also, if I had more time (or support), I'd probably start working
> on a systemd-compatible init system with a more portable design.


[-- Attachment #2: Type: application/pgp-signature, Size: 489 bytes --]

Re: [gentoo-dev] pid 1 design

[Luca Barbato]

On 08/09/2012 04:02 PM, Peter Stuge wrote:
> Luca Barbato wrote:
>> Repeat after me: having your first process require anything more
>> than libc is stupid and dangerous.
> 
> Why do you say?

Because libc supposedly should be stable, other libraries are a bit more
prone to radical changes and other annoyances. You wouldn't like to
reboot your system if you replace/update dbus or glib, do you?

> And why is libc different from other libraries, say libuuid or
> libext2fs? I mean: Why allow pid 1 to require libc, it could
> just be statically linked.

Actually statically linked initial process would be another reason why
you'd like to NOT use large libraries and in large number.

Obviously if you are thinking about desktop and not system in which
replacing kernels should be done w/out downtime (qnx and some linux
patches let you do that) it isn't a huge concern.

Yet I'm not used to have to reboot after issuing emerge -u world and
most of the times I don't have even to restart X...

lu

Re: [gentoo-dev] pid 1 design

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 282 bytes --]

On Thu, Aug 09, 2012 at 05:59:39PM +0200, Luca Barbato wrote:
> Yet I'm not used to have to reboot after issuing emerge -u world and
> most of the times I don't have even to restart X...

What if sysvinit is updated as part of that emerge -u world? Don't you
reboot then?

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] pid 1 design

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 344 bytes --]

Ok folks, I hit the wrong key; this was meant to go to the list.

On Thu, Aug 09, 2012 at 05:59:39PM +0200, Luca Barbato wrote:
> Yet I'm not used to have to reboot after issuing emerge -u world and
> most of the times I don't have even to restart X...

What if sysvinit is updated during that emerge -u world? Don't you
reboot then?

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] pid 1 design

[Christopher Head]

On Thu, 9 Aug 2012 12:30:54 -0500
William Hubbs <williamh@gentoo.org> wrote:

> Ok folks, I hit the wrong key; this was meant to go to the list.
> 
> On Thu, Aug 09, 2012 at 05:59:39PM +0200, Luca Barbato wrote:
> > Yet I'm not used to have to reboot after issuing emerge -u world and
> > most of the times I don't have even to restart X...
> 
> What if sysvinit is updated during that emerge -u world? Don't you
> reboot then?
> 
> William
> 

# telinit U

(also works for libc replacement, and it’s actually done automatically
by the sysvinit ebuild)

Chris

[gentoo-dev] Re: pid 1 design

[Duncan]

Luca Barbato posted on Thu, 09 Aug 2012 17:59:39 +0200 as excerpted:

> Yet I'm not used to have to reboot after issuing emerge -u world and
> most of the times I don't have even to restart X...

I suppose if you just use emerge -u @world, are running stable, and 
possibly don't care about services using old-version libs...

If you're running ~arch, prefer emerge -NuD @world, and do a lib_users or 
the like after updates, at least here, I've found it's often easier to 
simply reboot, than to restart X/KDE and half a dozen services, even if I 
could in theory avoid the full reboot.

That -D makes a big difference, tho, and -N of course compounds it.  
Between that and the more frequent updates on ~arch...

But of course I'm usually running a live-git kernel too, so that just 
gives me even more excuse to do a git pull and a kernel rebuild before 
the reboot too, so as to get the new kernel as well. =:^)

-- 
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

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Olivier Crête]

[-- Attachment #1: Type: text/plain, Size: 1351 bytes --]

On Thu, 2012-08-09 at 10:42 +0200, Luca Barbato wrote:
> On 08/07/2012 09:00 PM, Olivier Crête wrote:
> > I expect that in the not so long term, systemd will become an essential
> > user-space component of desktop Linux, just like crond, syslog, dbus,
> > udev or glibc. Sharing that code just makes sense, that allows
> 
> As in completely optional and easily replaceable? That would be a nice
> improvement over the current "use it or die" attitude.

Sure, you can use bionic and use a shell script as your PID 1. But no
one would do that as part of a desktop/server computer.

> Repeat after me: having your first process require anything more than
> libc is stupid and dangerous.

It's lucky that systemd only requires libc, libc-like libraries
(libselinux, libcap, libaudit, librt, etc) and it's own libraries (ie,
maintained by the systemd team) then?

> Most ideas behind systemd are interesting, their current implementation
> is sometimes completely wrong and given the experience with pulseaudio
> we all know that they won't change even if you provide code for it.

This is bullshit, if you have good reasoned arguments, Lennart is a very
reasonable guy, but if you just say "your ideas are shit, you code is
terrible", then yes, he'll just ignore you.

-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Questions about SystemD and OpenRC

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1171 bytes --]

On Thu, Aug 09, 2012 at 11:12:46AM -0700, Olivier Crête wrote:
> > Most ideas behind systemd are interesting, their current implementation
> > is sometimes completely wrong and given the experience with pulseaudio
> > we all know that they won't change even if you provide code for it.
> 
> This is bullshit, if you have good reasoned arguments, Lennart is a very
> reasonable guy, but if you just say "your ideas are shit, you code is
> terrible", then yes, he'll just ignore you.

Sorry to call you on this one, but that is not the experience I had.

I proposed adding configure switches to their build system to accomodate
source base distros, such as gentoo, who at times want to use udev
without systemd. I even went out of the way to make sure that I didn't
change their default settings.

Look at a thread on their ml called minimal builds along with their wiki
page on minimal builds for Lennart's answer. He even went so far as to
say that our package managers are broken, and there was absolutely no
negotiating this point. We are wrong as far as he is concerned.

William

[1] http://freedesktop.org/wiki/Software/systemd/MinimalBuilds

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Olivier Crête]

[-- Attachment #1: Type: text/plain, Size: 1553 bytes --]

On Thu, 2012-08-09 at 13:31 -0500, William Hubbs wrote:
> On Thu, Aug 09, 2012 at 11:12:46AM -0700, Olivier Crête wrote:
> > > Most ideas behind systemd are interesting, their current implementation
> > > is sometimes completely wrong and given the experience with pulseaudio
> > > we all know that they won't change even if you provide code for it.
> > 
> > This is bullshit, if you have good reasoned arguments, Lennart is a very
> > reasonable guy, but if you just say "your ideas are shit, you code is
> > terrible", then yes, he'll just ignore you.
> 
> Sorry to call you on this one, but that is not the experience I had.
> 
> I proposed adding configure switches to their build system to accomodate
> source base distros, such as gentoo, who at times want to use udev
> without systemd. I even went out of the way to make sure that I didn't
> change their default settings.
> 
> Look at a thread on their ml called minimal builds along with their wiki
> page on minimal builds for Lennart's answer. He even went so far as to
> say that our package managers are broken, and there was absolutely no
> negotiating this point. We are wrong as far as he is concerned.

He has a perfectly reasonable argument that build time is really not
something you should be optimising for. Build systems easily become
overcomplicated if you try to make everyone happy, you do have to make
choices. Anyway, I'm not sure how that's related to the quality or
design of systemd.

-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Rich Freeman]

On Thu, Aug 9, 2012 at 2:41 PM, Olivier Crête <tester@gentoo.org> wrote:
> He has a perfectly reasonable argument that build time is really not
> something you should be optimising for. Build systems easily become
> overcomplicated if you try to make everyone happy, you do have to make
> choices. Anyway, I'm not sure how that's related to the quality or
> design of systemd.

Well, much as I don't like it, build systems not being adequate for
Gentoo is not exactly a new thing.  I maintain a package that embeds
its version in the about/etc boxes by pulling data out of git, which
doesn't exactly work well when I try to install it from a tarball (and
their branch for building outside of git has a bug and dies).  Oddly
enough upstream combines this without tagging releases.  So, I patch
it, and fork it to github where I can tag my branches and prep
tarballs.  And I occasionally pester upstream to accept my patches.
But, such things are not that unusual.

Rich

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Canek Peláez Valdés]

On Thu, Aug 9, 2012 at 1:31 PM, William Hubbs <williamh@gentoo.org> wrote:
> On Thu, Aug 09, 2012 at 11:12:46AM -0700, Olivier Crête wrote:
>> > Most ideas behind systemd are interesting, their current implementation
>> > is sometimes completely wrong and given the experience with pulseaudio
>> > we all know that they won't change even if you provide code for it.
>>
>> This is bullshit, if you have good reasoned arguments, Lennart is a very
>> reasonable guy, but if you just say "your ideas are shit, you code is
>> terrible", then yes, he'll just ignore you.
>
> Sorry to call you on this one, but that is not the experience I had.
>
> I proposed adding configure switches to their build system to accomodate
> source base distros, such as gentoo, who at times want to use udev
> without systemd. I even went out of the way to make sure that I didn't
> change their default settings.
>
> Look at a thread on their ml called minimal builds along with their wiki
> page on minimal builds for Lennart's answer. He even went so far as to
> say that our package managers are broken, and there was absolutely no
> negotiating this point. We are wrong as far as he is concerned.

By the same reasoning, Linus is even a bigger asshole. In the kernel
they flatly refuse to merge code from a LOT of people; that's their
job in the end.

I read the thread where you proposed the changes to systemd's build
system. I wish it was accepted, but I also understand why they didn't.
As I said in other threads, they really don't care for source based
distros; and that sucks for Gentoo (and every other source based
distro), but it's their call. And it certainly helps them to keep the
build system simple, assuming that it would be used only by packagers
for binary distros.

That doesn't say anything about the design of systemd, which is why I
use it; not because of the build system.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 464 bytes --]

On Thu, 9 Aug 2012 13:53:34 -0500
Canek Peláez Valdés <caneko@gmail.com> wrote:
> That doesn't say anything about the design of systemd, which is why I
> use it; not because of the build system.

Actually, it's fairly representative of the design of systemd too: it
forces you into a particular monolithic, vertically integrated, tightly
coupled way of doing things, and if you try to deviate from that way,
then you're stuffed.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Canek Peláez Valdés]

On Thu, Aug 9, 2012 at 1:57 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Thu, 9 Aug 2012 13:53:34 -0500
> Canek Peláez Valdés <caneko@gmail.com> wrote:
>> That doesn't say anything about the design of systemd, which is why I
>> use it; not because of the build system.
>
> Actually, it's fairly representative of the design of systemd too: it
> forces you into a particular monolithic, vertically integrated, tightly
> coupled way of doing things, and if you try to deviate from that way,
> then you're stuffed.

I agree with Greg Kroah-Hartman: I actually like (and want) a
"vertically integrated, tightly coupled way of doing things". And of
course people who *don't* want that don't have to use it; just don't
expect support from the people writing the code for a "vertically
integrated, tightly coupled" OS, and don't complain when they reject
your contributions when they go against their goals.

Or in other words, if you don't want a vertically integrated, tightly
coupled system, then use mdev, or Luca's fork of udev; if enough
people really want that, they will thrive.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Rich Freeman]

On Thu, Aug 9, 2012 at 3:24 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>
> I agree with Greg Kroah-Hartman: I actually like (and want) a
> "vertically integrated, tightly coupled way of doing things".

Well, if you completely agreed with him you wouldn't be running Gentoo
(or Debian, or other general-purpose distros).  He advocates that
ordinary users should use more purpose-driven distros, where all of
this stuff is less of an issue.

He does make a valid point - I'd never argue that a linux noob should
start with Gentoo.  However, obviously I think Gentoo has its place,
and the world would be poorer without it.

Rich

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Canek Peláez Valdés]

On Thu, Aug 9, 2012 at 2:47 PM, Rich Freeman <rich0@gentoo.org> wrote:
> On Thu, Aug 9, 2012 at 3:24 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>
>> I agree with Greg Kroah-Hartman: I actually like (and want) a
>> "vertically integrated, tightly coupled way of doing things".
>
> Well, if you completely agreed with him you wouldn't be running Gentoo
> (or Debian, or other general-purpose distros).  He advocates that
> ordinary users should use more purpose-driven distros, where all of
> this stuff is less of an issue.
>
> He does make a valid point - I'd never argue that a linux noob should
> start with Gentoo.  However, obviously I think Gentoo has its place,
> and the world would be poorer without it.

I don't understand you. Greg is a Gentoo developer; he would never
propose for Gentoo to disappear.

I don't consider myself (nor any other Gentoo user) an ordinary user;
Gentoo is for power users, I believe. That is orthogonal to get a
vertically integrated, tightly coupled system, and the advantages of
it are independent of how easy to use is the system. The primary
advantage (from my point of view) is that we get a unique, robust
stack from kernel to userspace, where we don't need to worry about 20
different implementations of the same functionality.

I think that's what Greg was talking about, and I agree with that.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Rich Freeman]

On Thu, Aug 9, 2012 at 4:58 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>
> I don't understand you. Greg is a Gentoo developer; he would never
> propose for Gentoo to disappear.

I wasn't suggesting he was saying it should disappear.  I think his
point was that distros like Gentoo shouldn't be the first place people
go.  I'm not sure I fully agree with that, but on the other hand I
don't expect us to be having Ubuntu marketshare anytime soon either.
He can of course comment here, but he made his comments publicly on
Google+:

https://plus.google.com/111049168280159033135/posts/V2t57Efkf1s

> I just don't think it can be done well, sorry, which is why I strongly
> recommend tightly-coupled distros for desktops for anyone (like Fedora or
> openSUSE or Ubuntu), and Debian or Gentoo only for servers or embedded systems
> where you know exactly what you are putting together, and why you are doing it
> that way.

Rich

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Greg KH]

On Thu, Aug 09, 2012 at 03:47:19PM -0400, Rich Freeman wrote:
> On Thu, Aug 9, 2012 at 3:24 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> >
> > I agree with Greg Kroah-Hartman: I actually like (and want) a
> > "vertically integrated, tightly coupled way of doing things".
> 
> Well, if you completely agreed with him you wouldn't be running Gentoo
> (or Debian, or other general-purpose distros).  He advocates that
> ordinary users should use more purpose-driven distros, where all of
> this stuff is less of an issue.

That is not what I said, or mean at all.

Given that I'm a Gentoo developer, and have been for a very long time, I
find it very strange that you would think otherwise.

greg k-h

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Rich Freeman]

On Mon, Aug 13, 2012 at 11:24 PM, Greg KH <gregkh@gentoo.org> wrote:
> On Thu, Aug 09, 2012 at 03:47:19PM -0400, Rich Freeman wrote:
>> On Thu, Aug 9, 2012 at 3:24 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>> >
>> > I agree with Greg Kroah-Hartman: I actually like (and want) a
>> > "vertically integrated, tightly coupled way of doing things".
>>
>> Well, if you completely agreed with him you wouldn't be running Gentoo
>> (or Debian, or other general-purpose distros).  He advocates that
>> ordinary users should use more purpose-driven distros, where all of
>> this stuff is less of an issue.
>
> That is not what I said, or mean at all.
>
> Given that I'm a Gentoo developer, and have been for a very long time, I
> find it very strange that you would think otherwise.

I did clarify my post in a reply, linking to your post and of course
stating that you could clarify.  Your words were:   "I just don't
think it can be done well, sorry, which is why I strongly recommend
tightly-coupled distros for desktops for anyone (like Fedora or
openSUSE or Ubuntu), and Debian or Gentoo only for servers or embedded
systems where you know exactly what you are putting together, and why
you are doing it that way."

I'm not a big fan of putting words in mouths, so if I misread that
than I apologize.  In any case, I can't really argue much with that
statement as-is, although I'd probably carve out an additional
exception for enthusiasts or those who otherwise like to tinker under
the hood.

If you want strong vertical integration, you probably will never get
as much of it with Gentoo as you might get with a tightly-coupled
distro.

Rich

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Canek Peláez Valdés]

On Tue, Aug 14, 2012 at 5:31 AM, Rich Freeman <rich0@gentoo.org> wrote:
> On Mon, Aug 13, 2012 at 11:24 PM, Greg KH <gregkh@gentoo.org> wrote:
>> On Thu, Aug 09, 2012 at 03:47:19PM -0400, Rich Freeman wrote:
>>> On Thu, Aug 9, 2012 at 3:24 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>> >
>>> > I agree with Greg Kroah-Hartman: I actually like (and want) a
>>> > "vertically integrated, tightly coupled way of doing things".
>>>
>>> Well, if you completely agreed with him you wouldn't be running Gentoo
>>> (or Debian, or other general-purpose distros).  He advocates that
>>> ordinary users should use more purpose-driven distros, where all of
>>> this stuff is less of an issue.
>>
>> That is not what I said, or mean at all.
>>
>> Given that I'm a Gentoo developer, and have been for a very long time, I
>> find it very strange that you would think otherwise.
>
> I did clarify my post in a reply, linking to your post and of course
> stating that you could clarify.  Your words were:   "I just don't
> think it can be done well, sorry, which is why I strongly recommend
> tightly-coupled distros for desktops for anyone (like Fedora or
> openSUSE or Ubuntu), and Debian or Gentoo only for servers or embedded
> systems where you know exactly what you are putting together, and why
> you are doing it that way."
>
> I'm not a big fan of putting words in mouths, so if I misread that
> than I apologize.  In any case, I can't really argue much with that
> statement as-is, although I'd probably carve out an additional
> exception for enthusiasts or those who otherwise like to tinker under
> the hood.
>
> If you want strong vertical integration, you probably will never get
> as much of it with Gentoo as you might get with a tightly-coupled
> distro.

You can get as much vertical integration with Gentoo as with any other
distro. The problem (and I think this is the point Greg is trying to
make) is that it will be harder (not impossible, just harder) if most
of Gentoo developers really believe that every single possible
combination of hardware, software, init systems, and even OS kernels
should be supported.

I myself believe that any Gentoo dev should support whatever the hell
s/he wants to; I'm just interested in that if some of us want vertical
integration, it should be easier to get. Right now every single Gentoo
install from the official tree has OpenRC installed, because is pulled
in by baselayout, and OpenRC also pulls sysvinit. And I'm not talking
about some text files (even if they are executables) in /etc/init.d;
I'm talking about executable binaries and libraries in every Gentoo
install, even if the user has systemd, and they don't use
OpenRC/sysvinit at all. Not to mention that they need to compile both
packages if they ever upgrade (which doesn't happen that much, I
agree).

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Peter Stuge]

Canek Peláez Valdés wrote:
> You can get as much vertical integration with Gentoo as with any other
> distro. The problem (and I think this is the point Greg is trying to
> make) is that it will be harder (not impossible, just harder) if most
> of Gentoo developers really believe that every single possible
> combination of hardware, software, init systems, and even OS kernels
> should be supported.

And even if it isn't harder, the main point for *many* competent
users is that they have to do it themselves.

Many extremely skilled peers of mine simply do not want to.

They tried to do it, just not on Gentoo, and they have been burnt so
badly by whatever distribution they tried that they basically swear
off Linux completely for lack of time messing around, and just buy
fruit computers.

I have always appreciated the ability to customize, and I want to do
it. The framework for customization that is Gentoo easily surpasses
everything else that I have seen, and that's thanks to all the
developers.

But it means nothing for someone who wants to open a box, switch on
the power, and go online to $socialmediasite or $emailprovider.


//Peter

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Luca Barbato]

On 08/14/2012 09:14 PM, Peter Stuge wrote:
> But it means nothing for someone who wants to open a box, switch on
> the power, and go online to $socialmediasite or $emailprovider.

Sabayon does a decent job for them.

lu

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Rich Freeman]

On Tue, Aug 14, 2012 at 2:12 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> You can get as much vertical integration with Gentoo as with any other
> distro. The problem (and I think this is the point Greg is trying to
> make) is that it will be harder (not impossible, just harder) if most
> of Gentoo developers really believe that every single possible
> combination of hardware, software, init systems, and even OS kernels
> should be supported.

It isn't impossible for Gentoo to build a moon lander or for the
Foundation to buy the entire planet - just hard.  However, in practice
things that require resources we don't have simply won't happen.

Right now having decent KDE and Gnome support with all the bells and
whistles that works fine on FreeBSD as well as Linux isn't that hard,
because this trend towards vertical integration is just getting
started.  Running that on OSX under Prefix is already pretty painful
(not sure if anybody has actually pulled it off - I'm sure it is
possible).

It will likely get harder, which means in practice what we'll probably
have is a reasonable compromise which will never be quite as polished
in any one direction as it could be, unless the end user does the
polishing.

RE you concerns about OpenRC being in @system.  Personally I'm a fan
of getting rid of @system entirely except as something used to build
install CDs or having some sets for convenience in building systems.
It only exists for a few reasons that I can think of:
1.  Devs don't want to have ebuilds that capture dependencies on every
little thing.  A few well-chosen virtuals like "shell utilities" or
whatever might help with this.
2.  Things like Prefix rely on the system not installing local copies
of libraries in the core system it needs to link to.  Careful use of
package.provided in profiles might address this.
3.  We'd need many more virtuals to handle situations like FreeBSD
where people don't what GNU on their systems.  Right now if they are
system packages they just define system appropriately and ebuilds
don't directly pull in the GNU stuff anyway.

I'm sure there could be others.  Keep in mind that systemd is still
pretty new and largely out-of-the-blue so it will take time for Gentoo
to adjust to it.  Right now OpenRC might install executables, but
nothing should be actually running them - this is just wasted
compilation time which isn't a bad interim state to be in.  If
virtualizing udev is causing controversy just wait until somebody
actually makes a push to remove OpenRC from @system...

Rich

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1299 bytes --]

On Wed, 15 Aug 2012 06:27:41 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> 1.  Devs don't want to have ebuilds that capture dependencies on every
> little thing.  A few well-chosen virtuals like "shell utilities" or
> whatever might help with this.

Just note that PMS specifies a few requirements about those utilities
as well. I'm not sure if we want ebuilds explicitly DEPEND-ing on
things which are required by PMS.

In any case, virtual/posix-system would be nice to have.

> 2.  Things like Prefix rely on the system not installing local copies
> of libraries in the core system it needs to link to.  Careful use of
> package.provided in profiles might address this.

We could also make virtuals not pull in anything on Prefix in those
cases.

> 3.  We'd need many more virtuals to handle situations like FreeBSD
> where people don't what GNU on their systems.  Right now if they are
> system packages they just define system appropriately and ebuilds
> don't directly pull in the GNU stuff anyway.

I doubt that's a problem. We've got a lot of virtuals and adding new
ones shouldn't be a problem. I'd dare say it's better to add more
virtuals than introducing USEflags to existing ones -- it requires less
work from users.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 583 bytes --]

On 15-08-2012 12:58:32 +0200, Michał Górny wrote:
> Rich Freeman <rich0@gentoo.org> wrote:
> > 2.  Things like Prefix rely on the system not installing local copies
> > of libraries in the core system it needs to link to.  Careful use of
> > package.provided in profiles might address this.

Huh?  Not sure I understand this, but it suggests something which isn't
true for Prefix to me.

> We could also make virtuals not pull in anything on Prefix in those
> cases.

Things like virtual/os-headers already do so.


-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Rich Freeman]

On Wed, Aug 15, 2012 at 7:07 AM, Fabian Groffen <grobian@gentoo.org> wrote:
> On 15-08-2012 12:58:32 +0200, Michał Górny wrote:
>> Rich Freeman <rich0@gentoo.org> wrote:
>> > 2.  Things like Prefix rely on the system not installing local copies
>> > of libraries in the core system it needs to link to.  Careful use of
>> > package.provided in profiles might address this.
>
> Huh?  Not sure I understand this, but it suggests something which isn't
> true for Prefix to me.

Do you want every other package in the tree depending on glibc, and
therefore trying to pull it in on a prefix system?  (For those
unaware, prefix depends on a non-Gentoo glibc for the system call
interface.)  There are probably a few ways you could do it, but if you
got rid of the implicit @system dependency then you'd need to handle
situations where @system is something non-traditional and ebuilds are
likely to do it wrong.

Agree with mgorny's suggestion that anything required by PMS could be
pulled in by the package manager, perhaps in an EAPI-dependent
fashion.

Oh, @system has another use I didn't mention - getting rid of some
chicken-and-egg issues during the initial install.  That can be
addressed by providing pre-built stage1/2/3s, having package sets and
scripts for their building, and so on.  Maybe make world a world.d
directory with Gentoo providing a starter file and users modifying
their own addition, but being free to remove items and depcleaning
them.  Or provide a syntax for world to remove packages pulled in by a
distro-provided world, etc.  Many elements of this would benefit from
public comment obviously should we choose to go along this road.

Rich

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]

On 15-08-2012 07:32:45 -0400, Rich Freeman wrote:
> On Wed, Aug 15, 2012 at 7:07 AM, Fabian Groffen <grobian@gentoo.org> wrote:
> > On 15-08-2012 12:58:32 +0200, Michał Górny wrote:
> >> Rich Freeman <rich0@gentoo.org> wrote:
> >> > 2.  Things like Prefix rely on the system not installing local copies
> >> > of libraries in the core system it needs to link to.  Careful use of
> >> > package.provided in profiles might address this.
> >
> > Huh?  Not sure I understand this, but it suggests something which isn't
> > true for Prefix to me.
> 
> Do you want every other package in the tree depending on glibc, and
> therefore trying to pull it in on a prefix system?  (For those
> unaware, prefix depends on a non-Gentoo glibc for the system call
> interface.)

Correction: Prefix uses a possibly non-Gentoo, host-provided libc, not
necessarily GNU libc of an unknown version.

There are only a few packages I've seen that depend on a certain
(min/max) version of glibc, and when in use for Prefix, mostly use
  "!prefix? ( elibc_glibc? ( ...) )"
stuff at the moment.


-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Rich Freeman]

On Wed, Aug 15, 2012 at 7:41 AM, Fabian Groffen <grobian@gentoo.org> wrote:
> There are only a few packages I've seen that depend on a certain
> (min/max) version of glibc, and when in use for Prefix, mostly use
>   "!prefix? ( elibc_glibc? ( ...) )"
> stuff at the moment.

Half the packages in portage link to libc, though they don't actually
declare this dependency due to the policy of not declaring policies in
@system.  If you got rid of @system then they'd need to declare them.

However, use of virtuals or package.provided would address this issue
- I was just pointing it out.

Rich

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 650 bytes --]

On 15-08-2012 07:50:42 -0400, Rich Freeman wrote:
> On Wed, Aug 15, 2012 at 7:41 AM, Fabian Groffen <grobian@gentoo.org> wrote:
> > There are only a few packages I've seen that depend on a certain
> > (min/max) version of glibc, and when in use for Prefix, mostly use
> >   "!prefix? ( elibc_glibc? ( ...) )"
> > stuff at the moment.
> 
> Half the packages in portage link to libc, though they don't actually
> declare this dependency due to the policy of not declaring policies in
> @system.  If you got rid of @system then they'd need to declare them.

Yeah, so just don't do that.


-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Rich Freeman]

On Wed, Aug 15, 2012 at 8:01 AM, Fabian Groffen <grobian@gentoo.org> wrote:
> On 15-08-2012 07:50:42 -0400, Rich Freeman wrote:
>> On Wed, Aug 15, 2012 at 7:41 AM, Fabian Groffen <grobian@gentoo.org> wrote:
>> > There are only a few packages I've seen that depend on a certain
>> > (min/max) version of glibc, and when in use for Prefix, mostly use
>> >   "!prefix? ( elibc_glibc? ( ...) )"
>> > stuff at the moment.
>>
>> Half the packages in portage link to libc, though they don't actually
>> declare this dependency due to the policy of not declaring policies in
>> @system.  If you got rid of @system then they'd need to declare them.
>
> Yeah, so just don't do that.

In that case then just ignore that whole section of my post.  :)
Personally I consider the existence of @system a bit of a hack - like
the big kernel lock.  It works OK, but here and there we run into
issues with it.

Williamh pointed out that the plan for now is to virtualize
openrc/systemd, which certainly is a solution to that problem.  Being
an evolutionary vs revolutionary solution it is probably the better
next step.  In fact, if you kept making many steps like that one
before long @system would become mostly a big collection of virtuals
anyway, and at that point its only reason for being would be as an
arbitrary list of packages that ebuild maintainers shouldn't add as
dependencies, at which point you could start stripping it away.

That isn't unlike what was done to get rid of the big kernel lock -
just remove it one instance at a time...

Rich

Re: [gentoo-dev] remove system set?

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 2244 bytes --]

On 15-08-2012 09:43:37 -0400, Rich Freeman wrote:
> In that case then just ignore that whole section of my post.  :)
> Personally I consider the existence of @system a bit of a hack - like
> the big kernel lock.  It works OK, but here and there we run into
> issues with it.
> 
> Williamh pointed out that the plan for now is to virtualize
> openrc/systemd, which certainly is a solution to that problem.  Being
> an evolutionary vs revolutionary solution it is probably the better
> next step.  In fact, if you kept making many steps like that one
> before long @system would become mostly a big collection of virtuals
> anyway, and at that point its only reason for being would be as an
> arbitrary list of packages that ebuild maintainers shouldn't add as
> dependencies, at which point you could start stripping it away.
> 
> That isn't unlike what was done to get rid of the big kernel lock -
> just remove it one instance at a time...

I see it more as the set of packages I need to have on my system/Prefix,
to have Portage and its ebuilds working happily and me being able to do
basic stuff.  One can debate whether ssh belongs to that set.  For a
non-Prefix (regular Gentoo?) system it's sort of essential, for a Prefix
system, it's quite handy to have an ssh that actually works.

Nevertheless, the system set, is a vital part of bootstrapping e.g. a
Prefix setup.  The whole route leading up to the situation of having the
full set installed consists of numerous --nodeps emerges carefully put
in an order where one can get away with the errors one receives due to
missing stuff.

From that angle, if you wouldd remove the system set, would you add its
contents to the Portage ebuild?  Portage itself doesn't need a compiler
or might not need gawk, but whatever it runs (ebuilds) often need so.

Adding libc, a compiler, linker, shell, etc. to almost any every ebuild
looks pretty much useless to me.  Adding deps for all regular tools an
ebuild uses (bash, sed, awk, cut, wc, ...) seems like error-prone and
pretty much useless to me as well.  So, there is the system set which
just is the central place where those packages are recorded.


-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] remove system set?

[Rich Freeman]

On Wed, Aug 15, 2012 at 10:04 AM, Fabian Groffen <grobian@gentoo.org> wrote:
>
> From that angle, if you wouldd remove the system set, would you add its
> contents to the Portage ebuild?  Portage itself doesn't need a compiler
> or might not need gawk, but whatever it runs (ebuilds) often need so.

Nope - I'd add them to every ebuild, and only where needed.  That's
the whole point.

>
> Adding libc, a compiler, linker, shell, etc. to almost any every ebuild
> looks pretty much useless to me.  Adding deps for all regular tools an
> ebuild uses (bash, sed, awk, cut, wc, ...) seems like error-prone and
> pretty much useless to me as well.  So, there is the system set which
> just is the central place where those packages are recorded.

It is only useful for situations where people want to do something
unusual.  Some would argue that this is the only situation where
Gentoo is useful.  If I wanted a system just like everybody else's I
guess I'd run Ubuntu, if not Windows or OSX.

In any case, I do agree that getting there is associated with pain.  I
just like to think that getting there "someday" would be nice.  I know
that a systematic effort exists in mathematics to try to reduce all of
math to a minimum set of axioms and have everything else be formally
derived.  I consider that a thing of beauty, even if I don't care to
read the two volumes necessary to get to 1+1=2.

Rich

Re: [gentoo-dev] remove system set?

[Doug Goldstein]

On Thu, Aug 16, 2012 at 7:05 AM, Rich Freeman <rich0@gentoo.org> wrote:
> On Wed, Aug 15, 2012 at 10:04 AM, Fabian Groffen <grobian@gentoo.org> wrote:
>>
>> From that angle, if you wouldd remove the system set, would you add its
>> contents to the Portage ebuild?  Portage itself doesn't need a compiler
>> or might not need gawk, but whatever it runs (ebuilds) often need so.
>
> Nope - I'd add them to every ebuild, and only where needed.  That's
> the whole point.
>
>>
>> Adding libc, a compiler, linker, shell, etc. to almost any every ebuild
>> looks pretty much useless to me.  Adding deps for all regular tools an
>> ebuild uses (bash, sed, awk, cut, wc, ...) seems like error-prone and
>> pretty much useless to me as well.  So, there is the system set which
>> just is the central place where those packages are recorded.
>
> It is only useful for situations where people want to do something
> unusual.  Some would argue that this is the only situation where
> Gentoo is useful.  If I wanted a system just like everybody else's I
> guess I'd run Ubuntu, if not Windows or OSX.
>
> In any case, I do agree that getting there is associated with pain.  I
> just like to think that getting there "someday" would be nice.  I know
> that a systematic effort exists in mathematics to try to reduce all of
> math to a minimum set of axioms and have everything else be formally
> derived.  I consider that a thing of beauty, even if I don't care to
> read the two volumes necessary to get to 1+1=2.
>
> Rich
>

The other point of the system set is to get rid of the chicken and egg
problem. For example, virtually every package in the system set ships
as a tar, including tar itself. All the compression utilities ship as
tars, which need to be installed to build tar (think -z, -j, -J). You
need a standard C library to run virtually everything including tar,
which you need to extract your standard C sources. The list goes on.


-- 
Doug Goldstein

Re: [gentoo-dev] remove system set?

[Michael Mol]

On Thu, Aug 16, 2012 at 11:13 PM, Doug Goldstein <cardoe@gentoo.org> wrote:
> On Thu, Aug 16, 2012 at 7:05 AM, Rich Freeman <rich0@gentoo.org> wrote:

[snip]

>>
>> It is only useful for situations where people want to do something
>> unusual.  Some would argue that this is the only situation where
>> Gentoo is useful.  If I wanted a system just like everybody else's I
>> guess I'd run Ubuntu, if not Windows or OSX.
>>
>> In any case, I do agree that getting there is associated with pain.  I
>> just like to think that getting there "someday" would be nice.  I know
>> that a systematic effort exists in mathematics to try to reduce all of
>> math to a minimum set of axioms and have everything else be formally
>> derived.  I consider that a thing of beauty, even if I don't care to
>> read the two volumes necessary to get to 1+1=2.
>>
>> Rich
>>
>
> The other point of the system set is to get rid of the chicken and egg
> problem. For example, virtually every package in the system set ships
> as a tar, including tar itself. All the compression utilities ship as
> tars, which need to be installed to build tar (think -z, -j, -J). You
> need a standard C library to run virtually everything including tar,
> which you need to extract your standard C sources. The list goes on.

Bootstrapping is an inherently curious problem. Most systems are built
upon the systems they themselves build, but getting to that
self-hosting state always requires some unclean solution. (E.g. the
first C compiler couldn't have been written in C. The first x86
assembler wouldn't have been written in x86 assembler. Etc.)

Ideally, you'd want as narrow a bootstrapping channel as possible.
Assuming things start off statically linked, what's the sequence for
going from an empty chroot to stage 1, 2, 3...? What are the starting
conditions?


-- 
:wq

Re: [gentoo-dev] remove system set?

[Gregory M. Turner]

On 8/16/2012 8:26 PM, Michael Mol wrote:

> Ideally, you'd want as narrow a bootstrapping channel as possible.

I guess I tend to think that, too, and I'm pretty sure it's correct. But 
I don't normally think about why, and since you've prompted me to do so, 
perhaps it's a good moment to interject the fairly obvious, but 
amusingly contrary notion that there is too much of a good thing to be 
had in this dimension.

I suppose the main reason to want a minimal pre-bootstrap tool-chain is 
to maximize repeatability, minimize platform quirks, maximize 
time-stability in the face of changing code bases, and so forth.

Plus... you know... it's a lot more likely to make somebody say "Wow!" 
the "narrow" way.  Which maybe sounds like I'm poking fun, but I do 
actually think there's some intrinsic value in that.

However, there /are/ also reasons to make the bootstrap-er machine more 
fat and complex.  Most of them boiling down to there only being so much 
time in a day.

Otherwise we would boot-strap from stage -10, consisting only of a sed 
script and some architecture files to generate crude asm lexers ....
:)

-gmt

Re: [gentoo-dev] remove system set?

[Zac Medico]

On 08/16/2012 08:26 PM, Michael Mol wrote:
> Ideally, you'd want as narrow a bootstrapping channel as possible.
> Assuming things start off statically linked, what's the sequence for
> going from an empty chroot to stage 1, 2, 3...? What are the starting
> conditions?

We use sys-apps/catalyst, which builds stage1 in a new $ROOT by simply
extracting a seed stage3 and calling $PORTDIR/scripts/booststrap.sh. The
stage1 is pretty minimal, but it's enough to generate a new stage3 by
simply calling emerge -e @system (you can skip stage2 step entirely).
The stage2 step is just used to rebuild some essential packages for a
more specialized CHOST, so it's only needed when your stage1 has a
generic CHOST and you want to build a stage3 with a more specialized CHOST.
-- 
Thanks,
Zac

Re: [gentoo-dev] remove system set?

[Rich Freeman]

On Thu, Aug 16, 2012 at 11:26 PM, Michael Mol <mikemol@gmail.com> wrote:
> Bootstrapping is an inherently curious problem. Most systems are built
> upon the systems they themselves build, but getting to that
> self-hosting state always requires some unclean solution.

Yup, I never viewed getting rid of @system as a solution to the
bootstrapping problem.  You could even have an @stage3 set for
convenience, or a meta-virtual to create one, using a fully
functioning Gentoo system.  I also wasn't suggesting we have empty
stage3s or anything like that.  By all means supply a default
collection of packages, and feel free to include openssh in that
collection.  However, those default packages would be nothing more
than a starting point and users could uninstall them at will.  Perhaps
portage would have some set it would offer a warning before
uninstalling (either a hardcoded list like @system, or use logic like
any dep of portage or gcc).

Rich

Re: [gentoo-dev] remove system set?

[Michael Mol]

On Fri, Aug 17, 2012 at 9:03 PM, Rich Freeman <rich0@gentoo.org> wrote:
> On Thu, Aug 16, 2012 at 11:26 PM, Michael Mol <mikemol@gmail.com> wrote:
>> Bootstrapping is an inherently curious problem. Most systems are built
>> upon the systems they themselves build, but getting to that
>> self-hosting state always requires some unclean solution.
>
> Yup, I never viewed getting rid of @system as a solution to the
> bootstrapping problem.  You could even have an @stage3 set for
> convenience, or a meta-virtual to create one, using a fully
> functioning Gentoo system.  I also wasn't suggesting we have empty
> stage3s or anything like that.  By all means supply a default
> collection of packages, and feel free to include openssh in that
> collection.  However, those default packages would be nothing more
> than a starting point and users could uninstall them at will.  Perhaps
> portage would have some set it would offer a warning before
> uninstalling (either a hardcoded list like @system, or use logic like
> any dep of portage or gcc).

Sure, this makes perfect sense to me. It does depend on having
dependency logic fully expressed, and not dependent on @system as an
inherent dependency. But that's something that ought to be a long-term
goal, not a short-term goal, just based on the amount of work required
to get there, and possibly the work required to maintain it.

Incidentally, I'm pretty sure portage already does offer a warning
when you might unmerge a package that's in @system; on a fresh
install, the first --depclean will try to remove nano, and portage
warns the user.

-- 
:wq

Re: [gentoo-dev] Questions about SystemD and OpenRC

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1754 bytes --]

On Wed, Aug 15, 2012 at 06:27:41AM -0400, Rich Freeman wrote:
> RE you concerns about OpenRC being in @system.  Personally I'm a fan
> of getting rid of @system entirely except as something used to build
> install CDs or having some sets for convenience in building systems.
> It only exists for a few reasons that I can think of:
> 1.  Devs don't want to have ebuilds that capture dependencies on every
> little thing.  A few well-chosen virtuals like "shell utilities" or
> whatever might help with this.
> 2.  Things like Prefix rely on the system not installing local copies
> of libraries in the core system it needs to link to.  Careful use of
> package.provided in profiles might address this.
> 3.  We'd need many more virtuals to handle situations like FreeBSD
> where people don't what GNU on their systems.  Right now if they are
> system packages they just define system appropriately and ebuilds
> don't directly pull in the GNU stuff anyway.
> 
> I'm sure there could be others.  Keep in mind that systemd is still
> pretty new and largely out-of-the-blue so it will take time for Gentoo
> to adjust to it.  Right now OpenRC might install executables, but
> nothing should be actually running them - this is just wasted
> compilation time which isn't a bad interim state to be in.  If
> virtualizing udev is causing controversy just wait until somebody
> actually makes a push to remove OpenRC from @system...

This isn't in the plans. OpenRC gets installed everywhere right now,
because it is a pdepend of baselayout. The plan is actually to tie it to
a virtual which will be added to @system; I just haven't gotten around
to doing this yet. [1]

William

[1] https://bugs.gentoo.org/show_bug.cgi?id=409385

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: Questions about SystemD and OpenRC

[Duncan]

Rich Freeman posted on Wed, 15 Aug 2012 06:27:41 -0400 as excerpted:

> Right now having decent KDE and Gnome support with all the bells and
> whistles[...] isn't that hard, [It] will likely get harder, which means
> in practice what we'll probably have is a reasonable compromise which
> will never be quite as polished in any one direction as it could be,
> unless the end user does the polishing.

Well stated.

> RE you concerns about OpenRC being in @system.  Personally I'm a fan of
> getting rid of @system entirely except as something used to build
> install CDs or having some sets for convenience in building systems. It
> only exists for a few reasons that I can think of:
> 1.  Devs don't want to have ebuilds that capture dependencies on every
> little thing.  A few well-chosen virtuals like "shell utilities" or
> whatever might help with this.
> 2.  Things like Prefix rely on the system not installing local copies of
> libraries in the core system it needs to link to.  Careful use of
> package.provided in profiles might address this.
> 3.  We'd need many more virtuals to handle situations like FreeBSD where
> people don't what GNU on their systems.  Right now if they are system
> packages they just define system appropriately and ebuilds don't
> directly pull in the GNU stuff anyway.

AFAIK, @system also helps resolve a few nasty circular dependencies.  In 
fact, I believe that's it's primary purpose.  As such I'm not sure it's 
practical (as opposed to possible, cost/benefit simply makes it 
impractical) to entirely get rid of, but it does occur to me that sets 
would be an interesting way to go.  Define a few sets that together 
compose @system as we have it today, and basically package.provide them 
during the bootstrap phase.

AFAIK the original stage tarball also contains a minimal installed tree, 
for similar reasons.  I'm not actually sure how they interact.  That'd be 
releng/arch/catalyst territory.

-- 
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

Re: [gentoo-dev] Re: Questions about SystemD and OpenRC

[Michael Mol]

On Wed, Aug 15, 2012 at 2:21 PM, Duncan <1i5t5.duncan@cox.net> wrote:
>
> Rich Freeman posted on Wed, 15 Aug 2012 06:27:41 -0400 as excerpted:
>
> > Right now having decent KDE and Gnome support with all the bells and
> > whistles[...] isn't that hard, [It] will likely get harder, which means
> > in practice what we'll probably have is a reasonable compromise which
> > will never be quite as polished in any one direction as it could be,
> > unless the end user does the polishing.
>
> Well stated.
>
> > RE you concerns about OpenRC being in @system.  Personally I'm a fan of
> > getting rid of @system entirely except as something used to build
> > install CDs or having some sets for convenience in building systems. It
> > only exists for a few reasons that I can think of:
> > 1.  Devs don't want to have ebuilds that capture dependencies on every
> > little thing.  A few well-chosen virtuals like "shell utilities" or
> > whatever might help with this.
> > 2.  Things like Prefix rely on the system not installing local copies of
> > libraries in the core system it needs to link to.  Careful use of
> > package.provided in profiles might address this.
> > 3.  We'd need many more virtuals to handle situations like FreeBSD where
> > people don't what GNU on their systems.  Right now if they are system
> > packages they just define system appropriately and ebuilds don't
> > directly pull in the GNU stuff anyway.
>
> AFAIK, @system also helps resolve a few nasty circular dependencies.  In
> fact, I believe that's it's primary purpose.  As such I'm not sure it's
> practical (as opposed to possible, cost/benefit simply makes it
> impractical) to entirely get rid of, but it does occur to me that sets
> would be an interesting way to go.  Define a few sets that together
> compose @system as we have it today, and basically package.provide them
> during the bootstrap phase.
>
> AFAIK the original stage tarball also contains a minimal installed tree,
> for similar reasons.  I'm not actually sure how they interact.  That'd be
> releng/arch/catalyst territory.

Just piping up here, as this relates to an idea that's been
percolating through my mind for a couple weeks.

I've occasionally noticed portage tell me about circular dependencies,
where the most straight forward resolution is to emerge some package
in the loop twice. The first time, with a USE flag disabled (avahi and
gtk are the usual suspects), and the second time with the USE flag
enabled.

In circumstances where it's necessary to do something like that to
reach a final desired system state, I'm not sure I see any problem
with portage automatically doing the two-stage emerge.

It also sounds like something like that could be a benefit to shrinking @system.

As far as things such as libc, where many, many packages require their
use, I don't personally see a problem with recommending that ebuilds
depend on them. My only other notable experience for Linux
distributions is Debian/Ubuntu, and a quick glance shows 16,389
packages expressing explicit dependencies on libc6 in Ubuntu 12.04.

--
:wq

Re: [gentoo-dev] Re: Questions about SystemD and OpenRC

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 718 bytes --]

On Wed, 15 Aug 2012 15:18:24 -0400
Michael Mol <mikemol@gmail.com> wrote:
> I've occasionally noticed portage tell me about circular dependencies,
> where the most straight forward resolution is to emerge some package
> in the loop twice. The first time, with a USE flag disabled (avahi and
> gtk are the usual suspects), and the second time with the USE flag
> enabled.
> 
> In circumstances where it's necessary to do something like that to
> reach a final desired system state, I'm not sure I see any problem
> with portage automatically doing the two-stage emerge.

That's going to be rather horrible when your package mangler
"temporarily" turns off acl or turns on build...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Questions about SystemD and OpenRC

[Michael Mol]

On Wed, Aug 15, 2012 at 3:26 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Wed, 15 Aug 2012 15:18:24 -0400
> Michael Mol <mikemol@gmail.com> wrote:
>> I've occasionally noticed portage tell me about circular dependencies,
>> where the most straight forward resolution is to emerge some package
>> in the loop twice. The first time, with a USE flag disabled (avahi and
>> gtk are the usual suspects), and the second time with the USE flag
>> enabled.
>>
>> In circumstances where it's necessary to do something like that to
>> reach a final desired system state, I'm not sure I see any problem
>> with portage automatically doing the two-stage emerge.
>
> That's going to be rather horrible when your package mangler
> "temporarily" turns off acl or turns on build...

Fair observation; there would need to be a way either weight benign or
dangerous USE/package flags, and search paths with weights outside of
a 'safe' range would be discarded.

A mechanism like that also offers a means of finding and favoring
cheap rebuilds over expensive ones; rebuilding gcc an extra time ought
to be disfavored over rebuilding, say, sudo.

-- 
:wq

Re: [gentoo-dev] Re: Questions about SystemD and OpenRC

[Rich Freeman]

On Wed, Aug 15, 2012 at 3:18 PM, Michael Mol <mikemol@gmail.com> wrote:
> It also sounds like something like that could be a benefit to shrinking @system.
>

I think the solution to the circular dependency issue isn't to make
Portage able to completely bootstrap the whole system, but rather just
to make it capable of coping with the issues and knowing when to raise
an alarm.

Gentoo will always involve extracting a tarball/etc for the initial
installation since you always need SOMETHING to start with.  You can't
even chroot into your install directory without a shell being there,
and typing "emerge" won't go so well if portage isn't actually
installed.

So, continue to build stages like we do right now - no doubt with
hard-coding and such to get around the dependencies.

As far as objections to listing gcc and such in every ebuild go, why
not?  We list all kinds of routine stuff in hundreds of ebuilds so
that we can install systems without them.  Why not just have a
toolchain virtual or something?

And since ssh was brought up - this is what happens with hacks like
this.  When you combine the "default install" with the "minimum deps
for everything" list you end up with an ssh you can't get rid of
without the package.provided hack (which really should be used for
stuff that is, well, provided).

It would be nice if people who want to build a server with Gentoo but
then reduce it to only true RDEPENDS could do so.  Obviously they'd
have to use binary packages to continue to maintain it (and even then
they'd need to keep portage on it), or they'd have to build another
one.  Actually, the trend in general is towards disposable servers
anyway so generating an entire new server every time one thing changes
is probably a desirable thing, since you probably want to be able to
do it every time you add a server anyway.

Rich

Re: [gentoo-dev] Re: Questions about SystemD and OpenRC

[Zac Medico]

On 08/16/2012 04:59 AM, Rich Freeman wrote:
> And since ssh was brought up - this is what happens with hacks like
> this.  When you combine the "default install" with the "minimum deps
> for everything" list you end up with an ssh you can't get rid of
> without the package.provided hack (which really should be used for
> stuff that is, well, provided).

FWIW, instead of using package.provided, you can negate "*virtual/ssh"
like this:

  mkdir -p /etc/portage/profile
  echo "-*virtual/ssh" >> /etc/portage/profile/packages

-- 
Thanks,
Zac

Re: [gentoo-dev] Re: Questions about SystemD and OpenRC

[Gregory M. Turner]

On 8/16/2012 4:59 AM, Rich Freeman wrote:
> On Wed, Aug 15, 2012 at 3:18 PM, Michael Mol <mikemol@gmail.com> wrote:
>> It also sounds like something like that could be a benefit to shrinking @system.
>>
>
> I think the solution to the circular dependency issue isn't to make
> Portage able to completely bootstrap the whole system, but rather just
> to make it capable of coping with the issues and knowing when to raise
> an alarm.
>
> Gentoo will always involve extracting a tarball/etc for the initial
> installation since you always need SOMETHING to start with.  You can't
> even chroot into your install directory without a shell being there,
> and typing "emerge" won't go so well if portage isn't actually
> installed.
>
> So, continue to build stages like we do right now - no doubt with
> hard-coding and such to get around the dependencies.
>
> As far as objections to listing gcc and such in every ebuild go, why
> not?  We list all kinds of routine stuff in hundreds of ebuilds so
> that we can install systems without them.  Why not just have a
> toolchain virtual or something?
>
> And since ssh was brought up - this is what happens with hacks like
> this.  When you combine the "default install" with the "minimum deps
> for everything" list you end up with an ssh you can't get rid of
> without the package.provided hack (which really should be used for
> stuff that is, well, provided).
>
> It would be nice if people who want to build a server with Gentoo but
> then reduce it to only true RDEPENDS could do so.  Obviously they'd
> have to use binary packages to continue to maintain it (and even then
> they'd need to keep portage on it), or they'd have to build another
> one.  Actually, the trend in general is towards disposable servers
> anyway so generating an entire new server every time one thing changes
> is probably a desirable thing, since you probably want to be able to
> do it every time you add a server anyway.

tldr: I like, approve and otherwise +1 the idea of somehow paring down 
or eliminating @system but I think it's going to be fairly challenging, 
so more discussion on this topic is warranted in my humble non-developer 
opinion :)

-- 

I really like everything you have to say here.  Unfortunately, 
assumptions of toolchain availability have gotten into the DNA of Gentoo 
in ways that make it nontrivial -- although probably not rocket science, 
either -- to implement these ideas.

I'd say it's the kind of thing where somebody needs to do the work.  I 
think there is demand for this, but when it comes down to brass tacks, 
people who really need features like this can just write a script to 
push some tarballs or files around in a way that's "good enough" for 
their purposes.  What is the cost/bene for a single sys-admin to do all 
the work and politics of making this change?

However, staying with the cost/bene theme, we have here a kind of 
externality, as they say in economics, (which is a fancy way, I guess, 
of saying a bad decision or a raw deal), because, in the aggregate, I 
think it's pretty clear that the cost/bene favors doing that work.

To be clear, I don't have religion about getting rid of @system, per-se, 
but I do have religion about the stuff Larry the Cow told me when I 
first visited the Gentoo homepage in 2001, or whenever, which was, 
basically, that the software I was using had a bunch of frobs that I 
couldn't touch, because I was running an rpm- or .deb-based system, and 
that Gentoo was going to let me frob them.

It's not a total disaster, even now -- a determined sysadmin can 
absolutely do this right now with features like prefix, ROOT, binpkg and 
so forth.... but /really/ fixing this, so that non-standard/minimal 
setups "just work", would allow Gentoo to effectively address a whole 
bunch of really practical, real-world use-cases -- use-cases Gentoo is 
in many aspects uniquely suited to address, due to Larry the Cow's 
brilliant insights -- yet, by-and-large, due to precisely this @system 
thing and the package-management decisions that have stemmed from it, 
for which Gentoo has become unsuitable or impractical.

Specifically, I'm talking, here, about managed LAMP servers, big-data 
clusters, and embedded.

I suppose I'm not doing much to fix it by ranting and raving like this 
however.  So see first paragraph :)

-gmt

Re: [gentoo-dev] Re: Questions about SystemD and OpenRC

[Michael Mol]

On Thu, Aug 16, 2012 at 3:51 PM, Gregory M. Turner <gmt@malth.us> wrote:
> On 8/16/2012 4:59 AM, Rich Freeman wrote:
>>
[snip]

>
>
> tldr: I like, approve and otherwise +1 the idea of somehow paring down or
> eliminating @system but I think it's going to be fairly challenging, so more
> discussion on this topic is warranted in my humble non-developer opinion :)
>
> --
>
> I really like everything you have to say here.  Unfortunately, assumptions
> of toolchain availability have gotten into the DNA of Gentoo in ways that
> make it nontrivial -- although probably not rocket science, either -- to
> implement these ideas.

The limited-visibility build feature discussed a week or so ago would
go a long way in detecting unexpressed build dependencies.

-- 
:wq

Re: [gentoo-dev] Re: Questions about SystemD and OpenRC

[Rich Freeman]

On Thu, Aug 16, 2012 at 4:05 PM, Michael Mol <mikemol@gmail.com> wrote:
> The limited-visibility build feature discussed a week or so ago would
> go a long way in detecting unexpressed build dependencies.

I can't say that is a coincidence, but my intent would be to include
@system as implicit dependencies, at least until we change that policy
(though the morbidly curious could use that as a test in a tinderbox
to find packages in @system that are good candidates for removal).

I haven't gotten to test it, but after studying sandbox it shouldn't
be hard to just hack together a manual test by removing read access to
root from the config files and adding in a bazillion files. That
should at least let me profile performance/etc.  I'm not convinced
that there isn't room for improvement, but if it works well as-is then
automating this shouldn't be hard at all.  If portage has the
dependency tree in RAM then you just need to dump all the edb listings
for those packages plus @system and feed those into sandbox.  That
just requires reading a bunch of text files and no searching, so it
should be pretty quick. As far as I can tell the relevant calls to
check for read access are already being made in sandbox already, and
obviously they aren't taking forever.  We just have to see if the
search gets slow if the access list has tens of thousands of entries
(if it does, that is just a simple matter of optimization, but being
in-RAM I can't see how tens of thousands of entries is going to slow
down a modern CPU even if it is just an unsorted list).

Rich

Re: [gentoo-dev] Re: Questions about SystemD and OpenRC

[Michael Mol]

On Thu, Aug 16, 2012 at 9:26 PM, Rich Freeman <rich0@gentoo.org> wrote:
> On Thu, Aug 16, 2012 at 4:05 PM, Michael Mol <mikemol@gmail.com> wrote:
>> The limited-visibility build feature discussed a week or so ago would
>> go a long way in detecting unexpressed build dependencies.
>
> I can't say that is a coincidence, but my intent would be to include
> @system as implicit dependencies, at least until we change that policy
> (though the morbidly curious could use that as a test in a tinderbox
> to find packages in @system that are good candidates for removal).
>
> I haven't gotten to test it, but after studying sandbox it shouldn't
> be hard to just hack together a manual test by removing read access to
> root from the config files and adding in a bazillion files. That
> should at least let me profile performance/etc.  I'm not convinced
> that there isn't room for improvement, but if it works well as-is then
> automating this shouldn't be hard at all.  If portage has the
> dependency tree in RAM then you just need to dump all the edb listings
> for those packages plus @system and feed those into sandbox.  That
> just requires reading a bunch of text files and no searching, so it
> should be pretty quick. As far as I can tell the relevant calls to
> check for read access are already being made in sandbox already, and
> obviously they aren't taking forever.  We just have to see if the
> search gets slow if the access list has tens of thousands of entries
> (if it does, that is just a simple matter of optimization, but being
> in-RAM I can't see how tens of thousands of entries is going to slow
> down a modern CPU even if it is just an unsorted list).

Yeah, I presumed you'd have @system as a set of implicit dependencies.
The obvious approaches would be to either temporarily remove a package
from @system, tell the portage to ignore a package while doing limited
visibility, or copy @system to a different, temporary set and remove
things piecemeal from there.

That last might make the most sense. "--implicit-dependencies ---
defaults to @system. Additional instances append to the set of
implicit dependencies. Use, e.g. -${ATOM} or -@system to override
default include."

-- 
:wq

Re: [gentoo-dev] Re: Questions about SystemD and OpenRC

[Gregory M. Turner]

[-- Attachment #1: Type: text/plain, Size: 4054 bytes --]

On 8/16/2012 6:26 PM, Rich Freeman wrote:
> On Thu, Aug 16, 2012 at 4:05 PM, Michael Mol <mikemol@gmail.com> wrote:
>> The limited-visibility build feature discussed a week or so ago would
>> go a long way in detecting unexpressed build dependencies.

[snip]

> If portage has the
> dependency tree in RAM then you just need to dump all the edb listings
> for those packages plus @system and feed those into sandbox.

> That just requires reading a bunch of text files and no searching, so it
> should be pretty quick.

Portage could hypothetically compile such a list while it crawls the 
package dependency tree, but I suspect the cost will not be small as you 
predict.

> As far as I can tell the relevant calls to
> check for read access are already being made in sandbox already, and
> obviously they aren't taking forever.  We just have to see if the
> search gets slow if the access list has tens of thousands of entries
> (if it does, that is just a simple matter of optimization, but being
> in-RAM I can't see how tens of thousands of entries is going to slow
> down a modern CPU even if it is just an unsorted list).

I appreciate your optimism but I think you're underestimating the cost. 
  Can't speak for others, but my portage db's churn too much for comfort 
as is.  Once we start multiplying per-package-dependency iteration by 
the files-per-package iteration, that's going to be O(a-shit-load).

Of course, where there's a will there's a way.  I'd be surprised if some 
kind of delayed-evaluation + caching scheme wouldn't suffice, or, 
barring that, perhaps it's time to create an indexed-database-based 
drop-in replacement for the current portage db code.

I've enclosed some scripts you may find helpful in looking at the 
numbers.  They are kind-of kludgey (originally intended for 
in-house-only use and modified for present purposes) but may help shed 
some light, if they aren't too buggy, that is...

"dumpworld" slices and dices "emerge -ep" output to provide a list of 
atoms in the complete dependency tree of a given list of atoms (add 
'@system' to get the complete tree, dumpworld won't do so).

"dumpfiles" operates only on packages installed in the local system 
(non-installed atoms are silently dropped), and requires/assumes that 
'emerge -ep world' would not change anything if it is to give accurate 
information.  It takes a list of atoms, transforms them into the 
complete lists of atoms in their dependency tree via dumpworld, merges 
the lists together, and finds the number of files associated with each 
atom in portage.  Any collisions will be counted twice, since it doesn't 
keep track.  It also doesn't add '@system' unless you do.  By default it 
emits:

  o A list of package atoms and the files owned by each atom (stderr)
  o total atoms and files
  o average filename length

What is, perhaps, more discouraging than the numbers it reports is how 
long it takes to run (note: although I suspect an optimized python 
implementation could be made to do this faster by a moderate constant 
factor, I'm not sure if the big-oh performance characteristics can be 
significantly improved without database structure changes like the ones 
mentioned above).

My disturbingly bloated and slow workstation gives these answers (note: 
here it's even slower because it's running in an emulator):

greg@fedora64vmw ~ $ time bash -c 'dumpfiles @system 2>/dev/null'
TOTAL: 402967 files (in 816 ebuilds, average path length: 66)


real    15m33.719s
user    13m18.909s
sys     2m8.436s
greg@fedora64vmw ~ $ time bash -c 'dumpfiles chromium 2>/dev/null'
TOTAL: 401300 files (in 807 ebuilds, average path length: 66)


real    15m28.900s
user    13m15.126s
sys     2m8.088s

My workstation is surely an "outlier" as I have a lot of dependencies 
and files due to multilib, split-debug, and USE+=$( a lot ).  It's also 
got slow hardware Raid6 and the emulator only gives it 2G of ram to work 
with.  But I'm a real portage user; I'm sure there's other ones out 
there, if not many, with similar constraints.

-gmt

[-- Attachment #2: dumpfiles --]
[-- Type: text/plain, Size: 2108 bytes --]

#!/bin/bash

if [[ x$(qlist -IC app-portage/portage-utils)x == xx || \
	x$(qlist -IC app-portage/gentoolkit)x == xx ]] ; then
	echo "This utility requires both app-portage/portage-utils" >&2
	echo "and app-portage/gentoolkit.  Emerge them both and try again." >&2
	exit 1
fi

declare -a arguments atoms

arguments=( )
atoms=( )

verbose=yes
redic=no

for arg in "$@" ; do
	case $arg in
		-q|--quiet) verbose=no ;;
		-r|--redic) redic=yes ;; 
		 *) arguments=( "${arguments[@]}" "$arg" ) ;;
	esac
done

[[ ${#arguments[*]} == 0 ]] && arguments=( '@world' )

for arg in "${arguments[@]}" ; do
	if [[ ${arg} == @* ]] ; then
		newatoms=( "${arg}" )
	else
		newatoms=( "$( qlist -eICv "${arg}" | sed 's/^/=/' )" )
	fi
	newatoms=( $( dumpworld "${newatoms[@]}" ) )
	result=$?
	[[ ${result} != 0 ]] && { echo "dumpworld failed, giving up." >&2 ; exit ${result} ; }
	atoms=( "${atoms[@]}" "${newatoms[@]}" )
done

# OK, we have all the packages -- remove dups, there could be a bunch.
atoms=( $( for atom in "${atoms[@]}" ; do echo "${atom}" ; done | sort -u ) )
		
[[ ${verbose} == yes ]] && \
	echo "Checking for files depended upon by the specified atom(s):" >&2 && \
	echo >&2

total=0
totalfilechars=0
for atom in "${atoms[@]}" ; do
	# turns out equery filse includes certain files (/usr/lib/debug... but why?)
	# that qlist excludes so ... we'd might as well get all the bad news possible
	files=$( equery -Cq files "${atom}" )
	result=$?
	[[ $result == 0 ]] || { echo "equery -Cq files ${atom} failed." >&2 ; exit $result ; }
	count=$( echo "${files}" | wc -l )
	(( total += count ))
	while read filename ; do
		(( totalfilechars += ${#filename} ))
	done < <( echo "${files}" )
	if [[ ${verbose} == yes ]] ; then
		if [[ ${redic} == yes ]] ; then
			echo "${files}"
		else
			echo "${atom}: ${count}" >&2
		fi
	fi
done
[[ ${verbose} == yes ]] && echo >&2 && echo >&2

[[ ${verbose} == yes ]] && echo -n "TOTAL: "
echo -n "${total}"

averagepathlen=$(( totalfilechars / ${total} ))
[[ ${verbose} == yes ]] && echo -n " files (in ${#atoms[*]} ebuilds, average path length: ${averagepathlen})"
echo
echo

exit 0

[-- Attachment #3: dumpworld --]
[-- Type: text/plain, Size: 582 bytes --]

#!/bin/bash

declare -a atoms
if [[ x$1 == x ]] ; then
	atoms=( '@world' )
else
	atoms=( "$@" )
fi

emerge_result=$( emerge --ignore-default-opts -epqD --backtrack=999 --with-bdeps=y "${atoms[@]}" 2>/dev/null ) 

trouble=$?

echo "${emerge_result}" |grep -v ^.uninstall | grep -v ^.blocks | sed 's/^.[^]]*] /=/;s/ \[[^]]*].*$//'

if [[ ${trouble} != 0 ]] ; then
	echo "WARNING: results not reliable due to portage failure." >&2
	echo "since portage stderr is ignored by this script, this" >&2
	echo "could mean anything, perhaps depsolving trouble?" >&2
	exit ${trouble}
fi

exit 0

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Tomáš Pružina]

Not really, Linus has his own web of trust and he don't take stuff
from unknown sources, he has his liutennants and every single patch
and change must be reviewed by at least two other maintainers below
Linus.
After all, Linux does not belong to Linus and his branch is by
definition of distributed system no better than yours.
Exception being is that he generally makes right decisions and can be
reason with.
It would be much simpler to push _good_ feature into kernel than into
gentoo [imho].

@systemd:
I liked it in it's early stages but every month code gets more and
more bloated and for (to me) unknown reason it's slowing on my machine
every new version. It also did not deliver on promise of stability as
early scripts I wrote don't work with latest version.


On Thu, Aug 9, 2012 at 8:53 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Thu, Aug 9, 2012 at 1:31 PM, William Hubbs <williamh@gentoo.org> wrote:
>> On Thu, Aug 09, 2012 at 11:12:46AM -0700, Olivier Crête wrote:
>>> > Most ideas behind systemd are interesting, their current implementation
>>> > is sometimes completely wrong and given the experience with pulseaudio
>>> > we all know that they won't change even if you provide code for it.
>>>
>>> This is bullshit, if you have good reasoned arguments, Lennart is a very
>>> reasonable guy, but if you just say "your ideas are shit, you code is
>>> terrible", then yes, he'll just ignore you.
>>
>> Sorry to call you on this one, but that is not the experience I had.
>>
>> I proposed adding configure switches to their build system to accomodate
>> source base distros, such as gentoo, who at times want to use udev
>> without systemd. I even went out of the way to make sure that I didn't
>> change their default settings.
>>
>> Look at a thread on their ml called minimal builds along with their wiki
>> page on minimal builds for Lennart's answer. He even went so far as to
>> say that our package managers are broken, and there was absolutely no
>> negotiating this point. We are wrong as far as he is concerned.
>
> By the same reasoning, Linus is even a bigger asshole. In the kernel
> they flatly refuse to merge code from a LOT of people; that's their
> job in the end.
>
> I read the thread where you proposed the changes to systemd's build
> system. I wish it was accepted, but I also understand why they didn't.
> As I said in other threads, they really don't care for source based
> distros; and that sucks for Gentoo (and every other source based
> distro), but it's their call. And it certainly helps them to keep the
> build system simple, assuming that it would be used only by packagers
> for binary distros.
>
> That doesn't say anything about the design of systemd, which is why I
> use it; not because of the build system.
>
> Regards.
> --
> Canek Peláez Valdés
> Posgrado en Ciencia e Ingeniería de la Computación
> Universidad Nacional Autónoma de México
>

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 526 bytes --]

On Thu, 09 Aug 2012 11:12:46 -0700
Olivier Crête <tester@gentoo.org> wrote:
> This is bullshit, if you have good reasoned arguments, Lennart is a
> very reasonable guy, but if you just say "your ideas are shit, you
> code is terrible", then yes, he'll just ignore you.

No no. If you agree with him, he's a reasonable guy. If you suggest
that there's a possible alternative to a decision he's already made, or
that some of his justifications don't stand up to scrutiny, then he
ignores you.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Canek Peláez Valdés]

On Thu, Aug 9, 2012 at 3:42 AM, Luca Barbato <lu_zero@gentoo.org> wrote:
[snip]
> Repeat after me: having your first process require anything more than
> libc is stupid and dangerous.

No, it's not. You can (and should) depend on whatever libraries helps
to achieve the desired goals. If one of the libraries has a bug, guess
what? It should be fixed. And then you repeat until all the used
libraries are as stable as libc (or more, if possible), and then the
statement that "having your first process require anything more than
libc is stupid and dangerous" makes no sense at all.

(As a side note, I would like to see the bugrate of libpthread,
libudev, libpam, libaudit, libcap, libdbus, etc. I'm pretty sure the
latest versions are pretty much rock solid).

That's in part what I like the approach taken by systemd (and
PulseAudio, by the way); it wants to be a proper solution, and if in
using something else they detect a bug, they push to get the bug fixed
in the external library (or the kernel sometimes). They don't
"workaround" real problems. It's the only way to guarantee that the
*whole* stack (not only libc, or the kernel) actually works as it
should.

So yes, PID 1 should use whatever libraries it makes sense to use, and
if there are bugs in them *they should get fixed*. Otherwise lets
program everything in assembler, because maybe gcc has a bug
somewhere.

> Once that concept gets accepted then we could discuss about why
> reinventing shellscript may not be that sound and other less glaring,
> horrid and appalling design choices.

The didn't reinvent shellscript; they replaced it with unit files.
That's the best design choice about systemd, IMHO: the unit files say
*what* a service should do, not *how*. And besides, you can still use
shellscript if your daemon is so fucked up that a regular unit file
doesn't cover your case. You should fix your daemon, really; but the
option to use shellscript is still there.

> Most ideas behind systemd are interesting, their current implementation
> is sometimes completely wrong and given the experience with pulseaudio
> we all know that they won't change even if you provide code for it.

Really? I'm subscribed to the systemd ML, and the author accept all
kind of contributions. If they don't agree with one in particular they
explain why and the discuss a compromise if necessary. Doing the
following in my git clone of the project:

git log --format='%aN' | sort -u | wc

shows a total of 337 contributors to systemd. So I really believe that
you are talking nonsense in this particular point.

> Obviously it is always fun seeing people first say "accept it or fork
> it", then "do not keep your fork you are wasting time" once somebody
> starts forking and/or working for an alternative.

By all means, fork it. Just allow Gentoo users to use udev/systemd as
upstream intended. And while we are at it, don't put OpenRC in the
dependency list of baselayout, otherwise it gets pulled in (and
sysvinit with it) for all systemd users even if we don't use it at
all. I maintain a really small overlay to use systemd exclusively in
Gentoo, so I don't need to install OpenRC and sysvinit:

https://github.com/canek-pelaez/gentoo-systemd-only/
http://xochitl.matem.unam.mx/~canek/gentoo-systemd-only/

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Rich Freeman]

On Thu, Aug 9, 2012 at 2:44 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Thu, Aug 9, 2012 at 3:42 AM, Luca Barbato <lu_zero@gentoo.org> wrote:
> [snip]
>> Repeat after me: having your first process require anything more than
>> libc is stupid and dangerous.
>
> No, it's not. You can (and should) depend on whatever libraries helps
> to achieve the desired goals. If one of the libraries has a bug, guess
> what? It should be fixed.

Look, there is a balance here.  This isn't really the thread to
discuss it, but there is a balance between having your only
password-reset UI being the passwd program, and having a 2MB suid root
X11 application like IRIX.  Most sane solutions today just have a
non-root front-end, that calls a small well-audited suid app (perhaps
just passwd).

Sure, fixing bugs should be admired, but planning to be robust even in
the face of future unknown bugs is the bedrock of secure software.

Rich

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Walter Dnes]

On Thu, Aug 09, 2012 at 01:44:25PM -0500, Canek Pel??ez Vald??s wrote
> On Thu, Aug 9, 2012 at 3:42 AM, Luca Barbato <lu_zero@gentoo.org> wrote:
> 
> > Obviously it is always fun seeing people first say "accept it or fork
> > it", then "do not keep your fork you are wasting time" once somebody
> > starts forking and/or working for an alternative.
> 
> By all means, fork it. Just allow Gentoo users to use udev/systemd as
> upstream intended. And while we are at it, don't put OpenRC in the
> dependency list of baselayout, otherwise it gets pulled in (and
> sysvinit with it) for all systemd users even if we don't use it at
> all.

  Good idea.  While we're at it, please also let's not make
systemd/udevd/dbus/pam mandatory.

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Canek Peláez Valdés]

On Thu, Aug 9, 2012 at 6:00 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> On Thu, Aug 09, 2012 at 01:44:25PM -0500, Canek Pel??ez Vald??s wrote
>> On Thu, Aug 9, 2012 at 3:42 AM, Luca Barbato <lu_zero@gentoo.org> wrote:
>>
>> > Obviously it is always fun seeing people first say "accept it or fork
>> > it", then "do not keep your fork you are wasting time" once somebody
>> > starts forking and/or working for an alternative.
>>
>> By all means, fork it. Just allow Gentoo users to use udev/systemd as
>> upstream intended. And while we are at it, don't put OpenRC in the
>> dependency list of baselayout, otherwise it gets pulled in (and
>> sysvinit with it) for all systemd users even if we don't use it at
>> all.
>
>   Good idea.  While we're at it, please also let's not make
> systemd/udevd/dbus/pam mandatory.

I agree. Systemd is not mandatory; dbus is not mandatory, and thanks
to your efforts udev is not mandatory, right? I don't know about PAM,
but I'm not opposed for it to not being mandatory. So lets stop making
OpenRC mandatory, and besides in a completely artificial way: nothing
really depends on functionalitty provided by OpenRC.

So let people make their OpenRC+mdev systems without systemd, and let
people make their systemd+udev systems without OpenRC. Everybody wins.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Peter Stuge]

Canek Peláez Valdés wrote:
> So let people make their OpenRC+mdev systems without systemd, and let
> people make their systemd+udev systems without OpenRC. Everybody wins.

I for one expect nothing less of Gentoo.


//Peter

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Sylvain Alain]

[-- Attachment #1: Type: text/plain, Size: 374 bytes --]

Yeah me too, and the best solution win then :P

2012/8/9 Peter Stuge <peter@stuge.se>

> Canek Peláez Valdés wrote:
> > So let people make their OpenRC+mdev systems without systemd, and let
> > people make their systemd+udev systems without OpenRC. Everybody wins.
>
> I for one expect nothing less of Gentoo.
>
>
> //Peter
>
>


-- 
Salut
alp
Sylvain

[-- Attachment #2: Type: text/html, Size: 756 bytes --]

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Olivier Crête]

[-- Attachment #1: Type: text/plain, Size: 942 bytes --]

On Thu, 2012-08-09 at 19:00 -0400, Walter Dnes wrote:
> On Thu, Aug 09, 2012 at 01:44:25PM -0500, Canek Pel??ez Vald??s wrote
> > On Thu, Aug 9, 2012 at 3:42 AM, Luca Barbato <lu_zero@gentoo.org> wrote:
> > 
> > > Obviously it is always fun seeing people first say "accept it or fork
> > > it", then "do not keep your fork you are wasting time" once somebody
> > > starts forking and/or working for an alternative.
> > 
> > By all means, fork it. Just allow Gentoo users to use udev/systemd as
> > upstream intended. And while we are at it, don't put OpenRC in the
> > dependency list of baselayout, otherwise it gets pulled in (and
> > sysvinit with it) for all systemd users even if we don't use it at
> > all.
> 
>   Good idea.  While we're at it, please also let's not make
> systemd/udevd/dbus/pam mandatory.

Can we also have a desktop that doesn't use X?


-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Chí-Thanh Christopher Nguyễn]

Olivier Crête schrieb:
> Can we also have a desktop that doesn't use X?

Yes, through Wayland or DirectFB.


Best regards,
Chí-Thanh Christopher Nguyễn

[gentoo-dev] Re: Questions about SystemD and OpenRC

[Duncan]

Chí-Thanh Christopher Nguyễn posted on Fri, 10 Aug 2012 01:26:53 +0200 as
excerpted:

> Olivier Crête schrieb:
>> Can we also have a desktop that doesn't use X?
> 
> Yes, through Wayland or DirectFB.

<aol>Me too!</aol>

Seriously, they're working on it, ubuntu already has a target switch-to 
date (tho it's predicted to slip, but it /does/ make for faster 
progress), qt is planning to support it with qt5(point-something) and 
preliminary support is there already, same with kde frameworks (aka kde5) 
altho AFAIK it's mostly just kwin/plasma dev experiments ATM, and I 
believe gnome support may actually be further along than kde, especially 
with ubuntu pushing it, given that they still use the gnome foundations 
with unity.

That's WAY farther along than any of the previous efforts toward 
replacing X on (other than embedded/Android) Linux got, and it actually 
looks like it's going to happen this time.

So give it a couple years, but it's coming.

Actually, wayland's exactly the thing I had in mind in my "five years" 
post as the next likely "worldview disrupter".  I think X will still be 
around in five years, but it'll be "legacy" for many, maybe most.  I 
don't know that the full implications of the switch to wayland can be 
predicted at this point, /I'm/ certainly not going to attempt it, and 
it's quite possible that as a result of that shift, systemd will look as 
"wrong solution for the wrong problem" as hal ended up looking.  But the 
only way to know is to live thru it and see where the experience takes us.

-- 
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

Re: [gentoo-dev] Questions about SystemD and OpenRC

[G.Wolfe Woodbury]

On 08/09/2012 07:12 PM, Olivier Crête wrote:
> Can we also have a desktop that doesn't us X?

That is NOT likely to happen.  X Windows is about the only *nix
windowing system around.
There may be others, but their use is rare.  Practically all the
graphical interface software
uses X and its addons.

-- 
G.Wolfe Woodbury
redwolfe@gmail.com

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Rich Freeman]

On Thu, Aug 9, 2012 at 7:26 PM, G.Wolfe Woodbury <redwolfe@gmail.com> wrote:
> On 08/09/2012 07:12 PM, Olivier Crête wrote:
>> Can we also have a desktop that doesn't us X?
>
> That is NOT likely to happen.  X Windows is about the only *nix
> windowing system around.
> There may be others, but their use is rare.  Practically all the
> graphical interface software
> uses X and its addons.

/me looks down at my phone...  :)

But whatever, you write it, you write an ebuild, and if you're
desperate I'll be happy to proxy maintain it for you.  Last time I
checked svgalib was still in tree...

Rich

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 600 bytes --]

On Thu, 09 Aug 2012 10:42:15 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:

> Repeat after me: having your first process require anything more than
> libc is stupid and dangerous.

But you are aware that glibc is probably much, much worse than most of
those 'stupid and dangerous' libraries, right?

> Once that concept gets accepted then we could discuss about why
> reinventing shellscript may not be that sound and other less glaring,
> horrid and appalling design choices.

Yes, exactly. So why does openrc reinvent that horrible shellscript?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Luca Barbato]

On 08/09/2012 09:43 PM, Michał Górny wrote:
> On Thu, 09 Aug 2012 10:42:15 +0200
> Luca Barbato <lu_zero@gentoo.org> wrote:
> 
>> Repeat after me: having your first process require anything more than
>> libc is stupid and dangerous.
> 
> But you are aware that glibc is probably much, much worse than most of
> those 'stupid and dangerous' libraries, right?

Then we have a bigger problem, since everything in our system is based
on that.

>> Once that concept gets accepted then we could discuss about why
>> reinventing shellscript may not be that sound and other less glaring,
>> horrid and appalling design choices.
> 
> Yes, exactly. So why does openrc reinvent that horrible shellscript?

It is not re-invented, in fact we can use any compatible shell.

lu

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1181 bytes --]

On Thu, 09 Aug 2012 22:30:02 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:

> On 08/09/2012 09:43 PM, Michał Górny wrote:
> > On Thu, 09 Aug 2012 10:42:15 +0200
> > Luca Barbato <lu_zero@gentoo.org> wrote:
> > 
> >> Repeat after me: having your first process require anything more
> >> than libc is stupid and dangerous.
> > 
> > But you are aware that glibc is probably much, much worse than most
> > of those 'stupid and dangerous' libraries, right?
> 
> Then we have a bigger problem, since everything in our system is based
> on that.

Yes, we do, sir.

> >> Once that concept gets accepted then we could discuss about why
> >> reinventing shellscript may not be that sound and other less
> >> glaring, horrid and appalling design choices.
> > 
> > Yes, exactly. So why does openrc reinvent that horrible shellscript?
> 
> It is not re-invented, in fact we can use any compatible shell.

Or anything else what can be spawned for shell. And a lot more what you
won't expect. And guess what, people are actually doing crazy things
with it because someone forgot to tell them how a init.d script should
work.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

[gentoo-dev] Re: Questions about SystemD and OpenRC

[Duncan]

Michał Górny posted on Thu, 09 Aug 2012 22:47:38 +0200 as excerpted:

> On Thu, 09 Aug 2012 22:30:02 +0200 Luca Barbato <lu_zero@gentoo.org>
> wrote:
> 
>> On 08/09/2012 09:43 PM, Michał Górny wrote:
>>> On Thu, 09 Aug 2012 10:42:15 +0200 Luca Barbato <lu_zero@gentoo.org>
>>> wrote:

>>>> [W]e could discuss about why reinventing shellscript may
>>>> not be that sound and other less glaring, horrid and
>>>> appalling design choices.
>>> 
>>> Yes, exactly. So why does openrc reinvent that horrible shellscript?
>> 
>> It is not re-invented, in fact we can use any compatible shell.
> 
> Or anything else what can be spawned for shell. And a lot more what you
> won't expect. And guess what, people are actually doing crazy things
> with it because someone forgot to tell them how a init.d script should
> work.

Sounds interesting.  A couple quick links to examples of what you had in 
mind would be nice. =:^)

(Or a bit more description, enough to both get the concept and google 
with would be good, but links could be quicker if you have them handy, 
and are less likely to spawn even further afield subthreads.)

-- 
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

Re: [gentoo-dev] Re: Questions about SystemD and OpenRC

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1934 bytes --]

On Fri, 10 Aug 2012 05:04:40 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> Michał Górny posted on Thu, 09 Aug 2012 22:47:38 +0200 as excerpted:
> 
> > On Thu, 09 Aug 2012 22:30:02 +0200 Luca Barbato <lu_zero@gentoo.org>
> > wrote:
> > 
> >> On 08/09/2012 09:43 PM, Michał Górny wrote:
> >>> On Thu, 09 Aug 2012 10:42:15 +0200 Luca Barbato
> >>> <lu_zero@gentoo.org> wrote:
> 
> >>>> [W]e could discuss about why reinventing shellscript may
> >>>> not be that sound and other less glaring, horrid and
> >>>> appalling design choices.
> >>> 
> >>> Yes, exactly. So why does openrc reinvent that horrible
> >>> shellscript?
> >> 
> >> It is not re-invented, in fact we can use any compatible shell.
> > 
> > Or anything else what can be spawned for shell. And a lot more what
> > you won't expect. And guess what, people are actually doing crazy
> > things with it because someone forgot to tell them how a init.d
> > script should work.
> 
> Sounds interesting.  A couple quick links to examples of what you had
> in mind would be nice. =:^)
> 
> (Or a bit more description, enough to both get the concept and google 
> with would be good, but links could be quicker if you have them
> handy, and are less likely to spawn even further afield subthreads.)

vdr is a first example which comes to my mind. They workaround program
configuration limitations and the init.d scripts become a complex
extra-configuration parser + plugin loader. Well, another thing here is
that upstream AFAIK is not willing to cooperate to fix their config
parsing.

'oldnet' is an another example. I'm not saying it should go; I'm saying
it should be a stand-alone executable called from the init.d script.

Last time I looked, squid init.d was performing post-inst in start().
Many users may find that beneficial but that's not what init.d scripts
should be doing.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Re: Questions about SystemD and OpenRC

[Luca Barbato]

On 08/10/2012 09:43 AM, Michał Górny wrote:
> vdr is a first example which comes to my mind. They workaround program
> configuration limitations and the init.d scripts become a complex
> extra-configuration parser + plugin loader. Well, another thing here is
> that upstream AFAIK is not willing to cooperate to fix their config
> parsing.
> 
> 'oldnet' is an another example. I'm not saying it should go; I'm saying
> it should be a stand-alone executable called from the init.d script.
> 
> Last time I looked, squid init.d was performing post-inst in start().
> Many users may find that beneficial but that's not what init.d scripts
> should be doing.

This discussion is really derailing.

Currently most people using certain features from openrc feel quite
defensive and mildly uneasy with the current situation since systemd is
pretty much swallowing components we used to rely on and force radical
changes w/out providing explanations to people that do not care and that
are perfectly happy with what they have.

Now Canek seems to feel like that I'm willing to kill systemd and make
it impossible to use it in Gentoo.

That's not the case, I consider systemd a bad idea since it is only
geared to solve some specific issues and does that in a way that I
consider dangerous for the global usage patterns I'm aware of.

systemd ideas are interesting and for a dumb linux desktop the
implementation would be ok.

systemd doesn't work in many scenarios and when it gets pointed
apparently there is a disagreement on that because "systemd is perfect"
like it happens with it gets pointed that pulseaudio has shortcomings
(that come from its design) or avahi doesn't seem that stable.

I can live with a seldom broken audio subsystem and I can cope with the
fact pidgin-bonjour could randomly crash, I'm not happy to be forced to
move to something with the same attitude as my init system.

The whole point of the debate should be if easier to have systemd split
itself in usable components so people with certain focuses could
leverage it on linux and replace those on non-linux (apparently not a
chance) or have what we currently have and works decently and hopefully
be compatible (so have a compatible interface for user-daemons, a
compatible dbus interface for the desktop integrations and so on), not
which project we should help to kill the others.


lu

Re: [gentoo-dev] Re: Questions about SystemD and OpenRC

[Rich Freeman]

On Fri, Aug 10, 2012 at 4:45 AM, Luca Barbato <lu_zero@gentoo.org> wrote:
> The whole point of the debate should be if easier to have systemd split
> itself in usable components so people with certain focuses could
> leverage it on linux and replace those on non-linux (apparently not a
> chance) or have what we currently have and works decently and hopefully
> be compatible (so have a compatible interface for user-daemons, a
> compatible dbus interface for the desktop integrations and so on), not
> which project we should help to kill the others.

I understand where you're coming from, but keep in mind that upstream
the debate is more along the lines of what else to integrate, not what
to split apart.  There is also little interest in supporting non-linux
systems with systemd - I don't think anybody working on it uses
anything but linux, and I think one of their goals is to not be held
back by features not available elsewhere.  That might make it more of
a niche solution, but it is a niche that probably includes almost all
of the boxes running a typical linux distro (servers, desktops, etc -
not toasters, phones, DVRs, etc).  Things like Prefix or FreeBSD are a
very low in market share.

In any case, this list is really the wrong place for such a debate,
since nobody who has any power to change anything is listening.  The
success/failure of systemd will have almost nothing to do with how
Gentoo adopts it, it is already moderately well-supported on Gentoo as
a non-default, and while there are concerns about how udev/etc is
packaged and where a few things are installing their files, for the
most part nothing is broken.  Some purists are concerned that whatever
rc system they're not using is sticking files on their system that
don't do anything, and that they can't control this, and that seems to
be a fault with all of the options, and most of the packages in the
tree that install init scripts.

There is also quite a bit of people calling each other's babies ugly,
which isn't terribly productive or helpful for the community.

Rich

[gentoo-dev] Re: Questions about SystemD and OpenRC

[Duncan]

Michał Górny posted on Fri, 10 Aug 2012 09:43:26 +0200 as excerpted:

> On Fri, 10 Aug 2012 05:04:40 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
> 
>> Michał Górny posted on Thu, 09 Aug 2012 22:47:38 +0200 as excerpted:
>> 
>> > Or anything else what can be spawned for shell. And a lot more what
>> > you won't expect. And guess what, people are actually doing crazy
>> > things with it because someone forgot to tell them how a init.d
>> > script should work.
>> 
>> Sounds interesting.  A couple quick links to examples of what you had
>> in mind would be nice. =:^)

> vdr is a first example which comes to my mind. They workaround program
> configuration limitations and the init.d scripts become a complex
> extra-configuration parser + plugin loader. Well, another thing here is
> that upstream AFAIK is not willing to cooperate to fix their config
> parsing.
> 
> 'oldnet' is an another example. I'm not saying it should go; I'm saying
> it should be a stand-alone executable called from the init.d script.
> 
> Last time I looked, squid init.d was performing post-inst in start().
> Many users may find that beneficial but that's not what init.d scripts
> should be doing.

Thanks.

(As I said my intent wasn't to start a subthread on it, but just to see 
where you were going with the comment, as it was rather opaque to me as 
it stood.  Oldnet was an especially useful example here given that I run 
openrc-9999 to more closely follow individual commits, and I've traced 
and reported a few bugs in oldnet over the years.  Now that I know where 
that comment was going, I'll shutup and contemplate.)

-- 
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

Re: [gentoo-dev] Questions about SystemD and OpenRC

[vivo75]

Il 07/08/2012 14:47, Sylvain Alain ha scritto:
> Hi everyone, for a couple of months now, I see on the list some of 
> activities about OpenRC been ported to FreeBSD or OpenRC to Debian and 
> other stuff related to SystemD.
>
> I have some basic questions about all that :
>
> 1. The SystemD and Udev projetcs are merged now, so what is the impact 
> on the Gentoo on a short term period ?
The answer is in the hand of others, I sincerely hope someone will fork
>
> 2. I saw on some lists that Gnome/Kde and Xfce plan to use some 
> SystemD API, so does it means that we will need to install SystemD 
> aside of OpenRC ?
It's not possible at the moment. systemd break non-systemd setups.

>
> 3. In a long term vision, can OpenRC still exist on a Gentoo 
> box(OpenRC might be able to boot the box then give the control to 
> SystemD/Udev for the rest of the boot process)  or we will need to 
> migrate to SystemD to be able to use Gnome/Kde or Xfce ?
PID 1 has some own properties, but systemd can work at user privileges, 
maybe
>
> 4. Finally, is there any reason why Gnome/Kde/Xfce wants to add deps 
> related to SystemD ? I don't understand why these desktops want to 
> depend on a specific Sysint....

Because starting daemons it's much more error prone than everyone 
thinks, at least everyone which didn't become involved in coding for it.

And now my personal rant with some considerations, from memory, may be 
not totally accurate.

Tried systemd (SD from now) the other day, as everyone knows it need to 
rebuild some part of the system with the "systemd" use flag.
These things broke when not started by SD, for example pulseaudio, had 
problems also with auto-mount possibly more not even noticed.

This box has 3 disk:
sda) ssd on sda for gentoo whole disk (not partitioned)
sd{b,c})  /home /srv /boot md raid 1

First problem udev/SD has is that it can't see all the file system 
labels, for some reason it only see sda and sdb so it's able to partly 
proceed in the boot sequence, mount / (root) but can't mount anything else.

After putting in fstab the real /dev paths (something really old siecle) 
manually mount them with systemctl --ignore-deps (the name of the option 
is different please bear with me) works but the dependancies are not 
satisfied, for two reasons:
a) SD does not re-calculate it's deptree/services when exiting from 
rescue shell, it still try to start the "virtual" services as fstab 
would have never modified, a reboot is needed
b) since it does not work even after reboot, there must be something 
else, but what? this bring us to the point

SD has mainly two things to debug boot `systemctl dump` and 
`systemd-journal` but the very much magnified advantages of the binary 
log^W journal are totally invisible in this case because it's 
difficult^W nearly impossible even to understand WHAT failed to start, 
not to mention WHY

the magnificient binary log^W^W journal is kept on tmpfs (in ram) so 
it's not even available at boot in different situation.

every try needed many minutes because SD wait for a long timeout before 
going to the rescue shell, gave up after few hours of try, upgrading 
Vista SP0 to current needed less reboot and time.

But this has been beneficial because I've now realized few important 
things that will be probably never disappear from SD and will be there 
forever, things that make me think this stuff is really dangerous.

List of problems that will _never_ be fixed

- SD does not see anything else than systemd for boot.
Interaction with SD from a livecd, is difficult, almost all tools don't 
work because SD is not running.
transported on remote server administration this is a *nightmare*, 
various provider offer livecd like system which don't offer SD.
so no easy migration, no easy first install, every failure is 
definitive, a no go

- the journal will never become simpler, can only grow, debugging things 
in the shell will be nearly impossible for excess of data (and lack of 
useful one if it continue this way)

- virtual/autogenerated services are and will be difficult to cope with, 
impossible to disable

- every change in the early boot procedure will require reboot

- which sum to: SD will work until it work, when something does not will 
be a royal pain to solve _and_ nothing else other than SD will be 
available to alleviate the pain

difficult to accept for the desktop, impossible for the server.

written by someone which like _some_ of the SD stuff.

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Peter Stuge]

vivo75@gmail.com wrote:
> First problem udev/SD has is that it can't see all the file system labels, 
> for some reason it only see sda and sdb so it's able to partly proceed in 
> the boot sequence, mount / (root) but can't mount anything else.

What software parses the filesystem labels when you boot with openrc?

(I ask because I never use labels myself.)


> a) SD does not re-calculate it's deptree/services when exiting from rescue 
> shell, it still try to start the "virtual" services as fstab would have 
> never modified, a reboot is needed

systemctl --system daemon-reload ?


> b) since it does not work even after reboot, there must be something else, 
> but what? this bring us to the point

I'm not contesting that there is a problem with your systemd setup,
and maybe it is a problem with systemd, but unless you know for sure
maybe it's premature to say that "it" is systemd? I would investigate
what the problem really is.


> SD has mainly two things to debug boot `systemctl dump` and 
> `systemd-journal`

Hm, debug boot like how? I mean: what problem did you want to resolve
when you say that you were debugging boot?


> impossible even to understand WHAT failed to start, not to mention WHY

There are no logfiles for the individual services?


> the magnificient binary log^W^W journal is kept on tmpfs (in ram) so
> it's not even available at boot in different situation.

I'm not sure what the purpose of the binary log is, maybe it makes
sense to have it per session, but in any case I guess the services
should be doing some logging of their own?


> every try needed many minutes because SD wait for a long timeout before 
> going to the rescue shell

I would be interested in understanding why there was a long wait, I
mean: what was systemd waiting for?


> - SD does not see anything else than systemd for boot.
> Interaction with SD from a livecd, is difficult, almost all tools don't 
> work because SD is not running.

I just work with the files on disk. The only time I use tools is if
systemd is running and needs to get told about updates. I don't think
there are any files that are not plain text, so I don't think any
tools are actually required.


> transported on remote server administration this is a *nightmare*

If there's a way to boot into a shell prompt, even if it is just bash
running as pid 1, then any system can be fixed. It requires knowing a
lot about how the system works though, so a lot about systemd if the
system uses systemd. Ie. knowing what files to change how in order to
accomplish desired results.


> various provider offer livecd like system which don't offer SD.
> so no easy migration, no easy first install, every failure is
> definitive, a no go

I don't understand this at all. Even if we go with what you write,
then I expect that some providers will start to offer an ecosystem of
systemd-optimized experiences for those who want it - but I do not
believe for a second that those would somehow be exclusive to other
systems.


> - the journal will never become simpler, can only grow, debugging things in 
> the shell will be nearly impossible for excess of data (and lack of useful 
> one if it continue this way)

Configure it to write into files?


> - virtual/autogenerated services are and will be difficult to cope with, 
> impossible to disable

Hm, do they matter?


> - every change in the early boot procedure will require reboot

Is that different from another pid 1?


> - which sum to: SD will work until it work, when something does not will be 
> a royal pain to solve _and_ nothing else other than SD will be available to 
> alleviate the pain

This does not match my experience at all. I don't know what you did
wrong though, your email wasn't very specific. :\


//Peter

[gentoo-dev] Re: Questions about SystemD and OpenRC

[Duncan]

Peter Stuge posted on Sun, 12 Aug 2012 02:12:38 +0200 as excerpted:

> vivo75@gmail.com wrote:
>> First problem udev/SD has is that it can't see all the file system
>> labels, for some reason it only see sda and sdb so it's able to partly
>> proceed in the boot sequence, mount / (root) but can't mount anything
>> else.
> 
> What software parses the filesystem labels when you boot with openrc?
> 
> (I ask because I never use labels myself.)

Short answer, mount and udev, and the kernel directly when fed that 
information for root= on the kernel commandline.  Openrc has basically 
nothing to do with it.  As such, I don't know what systemd's doing, but 
if it indeed is a systemd bug, it's obviously doing /something/ rather 
different... probably interacting in some unpredicted way with udev now 
that they're integrating it.

Slightly more detail, quoting the mount (8) manpage:

>>>>>
It is possible to indicate a block special device using its volume LABEL  
or UUID (see the -L and -U options below).

The recommended setup is to use LABEL=<label> or UUID=<uuid> tags rather 
than /dev/disk/by-{label,uuid} udev symlinks in the /etc/fstab file.
The tags are more readable, robust and portable. The mount(8) command 
internally uses udev symlinks, so use the symlinks in /etc/fstab has no 
advantage over LABEL=/UUID=. For more details see libblkid(3).

Note that mount(8) uses UUIDs as strings. The UUIDs from command line or
fstab(5) are not converted to internal binary representation. The string 
representation of the UUID should be based on lower case characters.

<<<<<

The implication of the "as strings, not converted to binary" in the last 
paragraph is that mount's simply doing a dumb string match against the 
appropriate /dev/disk/by-* symlink names and dereferencing the symlink 
after which it can proceed as usual if there's a match.  It's udev (and 
thus now systemd, since they're combining) that's actually doing the 
work, exposing the /dev/disk/by-* symlinks with the correct references.

As such, mount basically supports anything found in that location, 
including device hardware ID (combined with partition number where 
appropriate, listed in /dev/disk/by-id), the already mentioned filesystem 
LABEL (/dev/disk/by-label), PARTLABEL (GPT partitions have a partition 
label that's similar in function to the filesystem label, but set at gdisk 
time, not mkfs time, obviously this doesn't apply to legacy MBR 
partitioning), PARTUID, PATH (bus path, tho like traditional /dev/[hs]dX, 
this can be dynamic and the bus paths are longer and more obtuse for 
humans so there's generally little practical use for this one), and (as 
the manpage mentions, partition) UUID.

It is however worth noting that PARTLABEL at least is new enough that at 
least as of a couple months ago when I looked at it for my md/raid setup, 
while udev passed thru the PARTLABEL for physical devices, it was NOT 
doing so for partitioned md/raid devices.  (That mobo died and I don't 
have md/raid on the new system so I can't verify current kernel 3.6-rc1+ 
and udev-187-r3 PARTLABEL-on-md/raid behavior.)  So while people could 
setup their md/raid gpt partitions with partition-labels using gptfdisk 
(aka gdisk) or whatever, and I did so, only the ones on the physical 
disks showed up in udev, and at the time I was looking at it, I was 
running md/raid on virtually everything, so the feature was about useless 
for me.

But that does mean that if mdev or whatever creates similar /dev/disk/by-
*, that mount and friends should use it just as they would with udev, 
since all they're doing is a dumb string match and symlink deref.

It'a also worth noting that the kernel's root= line can take a number of 
these (I'm not sure if it can take them all), including partlabel, 
according to information someone posted on the btrfs list (which I was 
following at the time, before I decided btrfs was too unstable still and 
that I'd wait until next year to try again).  I was going to try it, but 
lost interest when I found I couldn't use it with fstab for my mdraid-
based gpt partitions anyway.  So all I can say is that it was reported to 
work on the btrfs list, and no one contradicted it, so...

>> a) SD does not re-calculate it's deptree/services when exiting from
>> rescue shell, it still try to start the "virtual" services as fstab
>> would have never modified, a reboot is needed
> 
> systemctl --system daemon-reload ?

I've not tried systemd yet nor have I yet researched it (I have the 
research vaguely scheduled for next year, sometime), but thanks to both 
of you for these details.  Based on past experience, I expect I'm 
collecting the pieces even tho I don't have context to assemble them in, 
but as a result, when I /do/ research it and get that context, the pieces 
I already have thanks to discussions like this, will fall into place, and 
it'll be far easier to get upto speed than it would have been had I tried 
going into it "cold turkey".

So while I could guess, I'll just shutup and listen for this part.

> I just work with the files on disk. The only time I use tools is if
> systemd is running and needs to get told about updates. I don't think
> there are any files that are not plain text, so I don't think any tools
> are actually required.

Useful to know. =:^)

> If there's a way to boot into a shell prompt, even if it is just bash
> running as pid 1, then any system can be fixed. It requires knowing a
> lot about how the system works though, so a lot about systemd if the
> system uses systemd. Ie. knowing what files to change how in order to
> accomplish desired results.

FWIW, I actually have a set of grub2 menu entries with init=/bin/bash, 
for troubleshooting. =:^)

But I think his point (valid or not) was that systemd's closing this 
avenue off as it's simply too monolithic to get information out of or to 
trial-start individual services even when not run as init, as is possible 
with openrc, for instance.

With openrc, if you boot with init=/bin/bash, then try to start an openrc 
initscript, it'll protest that it's not init and that results may not be 
as intended due to lack of dependency tracking, etc, but it'll let you 
override and try anyway, you just have to manage the service deps 
manually or deal with the fallout if you screw it up.

He appears to be saying that this doesn't work with systemd.  If it's not 
init, it refuses to do /anything/ with its unit-file initscript 
substitutes.  That /does/ sound like just the sort of complaint (of 
serveral) I've seen about systemd, but is it accurate?

If it is, then yes, booting to init=/bin/bash (or from live-rescue media) 
and troubleshooting systemd problems from there *IS* going to be more 
difficult than doing the same thing from openrc, because openrc has the 
ability to override and one-off, while if this is correct, openrc doesn't.

> I don't understand this at all. Even if we go with what you write, then
> I expect that some providers will start to offer an ecosystem of
> systemd-optimized experiences for those who want it - but I do not
> believe for a second that those would somehow be exclusive to other
> systems.

In all these systemd threads, someone posted a link to gregkh's take on 
gentoo as posted on google+.  In the comments that followed, Ted T'so and 
Kay S. had a rather interesting ping-pong in which one of them mentioned 
the concern that Red Hat and an init implementor for them had about all 
of this at the enterprise level.  For those interested in such things, 
it's worth going back and looking at that if you skipped it (either find 
the link here or just go back and look at gregkh's G+ from ~April).  I 
knew there were enterprise implications, but that was the first time I 
realized that RH wasn't necessarily 100% onboard with the full systemd 
thing, addressing it "upstream" since AFAIK Lennart is a RH employee as 
well.

From that, it looks like they're more or less waiting for things to 
settle down as well, and they plan on some perhaps major patches being 
necessary for the first few RH releases with systemd.  Of course, even 
assuming those patches eventually make it upstream, Red Hat's release 
cycle is long enough and their paying customers generally conservative 
enough, that it may be some time before they actually have to worry about 
supporting systemd in a deployed release.

And of course, Ubuntu's continuing to stick to upstart for the time 
being, AFAIK.  And CentOS and ScientificLinux being RH offshoots, they'll 
follow RH.

In practice, I think that means that remote-hosted servers shouldn't have 
to worry about systemd issues for another couple years, anyway, gentoo or 
not.  Of course if they run fedora, it might be a problem rather sooner.  
But people running fedora should be used to dealing with such leading 
edge issues, so no big deal for them either, really.

And given enterprise support terms, I guess we're looking at something 
approaching a decade before folks are actually FORCED to systemd, by 
falling off the end of the support train.

Meanwhile, that gives plenty of time for other "entrprisish" parties to 
wait for redhat to decide what it's doing, then come up with their own 
solutions once a bit more about the ultimate target is known.  And until 
then, except for those choosing to run fedora or the like, the existing 
live-media-style remote rescue solutions should continue to work as they 
have.

And in particular for gentoo users with remote hosts to worry about, 
since it's already clear that for at least the near term (say a year or 
two), gentoo's going to continue to default to openrc, there shouldn't be 
a problem for at least /that/ long.  And by the time any such problem 
/were/ to appear, it's very likely that solutions for it will be 
available as well... or given the day jobs of various gentoo devs, 
there'd certainly be sufficient interest in continuing systemd-
alternative gentoo support, since they have similar issues themselves.

-- 
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

Re: [gentoo-dev] Re: Questions about SystemD and OpenRC

[Rich Freeman]

On Sun, Aug 12, 2012 at 5:43 AM, Duncan <1i5t5.duncan@cox.net> wrote:
> Peter Stuge posted on Sun, 12 Aug 2012 02:12:38 +0200 as excerpted:
>>
>> What software parses the filesystem labels when you boot with openrc?
>>
>> (I ask because I never use labels myself.)
>
> Short answer, mount and udev, and the kernel directly when fed that
> information for root= on the kernel commandline.
>...
> It'a also worth noting that the kernel's root= line can take a number of
> these (I'm not sure if it can take them all), including partlabel,
> according to information someone posted on the btrfs list

I'm pretty sure that this particular part of your post is incorrect,
but I'd be happy to be corrected.

The kernel cannot interpret a root= parameter that doesn't reference a
device node that it can't internally generate (with a devtmpfs/etc).
I'm pretty sure that rules out just about anything but a physical
device (not even /dev/by-uuid/...).

I think that people get this confused because 99% of linux users have
an initramfs (and about 2% of Gentoo users it seems), and most
initramfs implementations DO interpret the root=parameter.  If you
specify an initramfs then the kernel actually ignores the
root=parameter entirely, mounting the initramfs as root, and passing
control to its init.  The initramfs is expected to mount root (or not
- you could just run the whole system off an initramfs I guess).  Most
initramfs implementations just parse the root= line on the kernel,
although it is worth noting that genkernel's initramfs does not and
uses real_root instead.

So, I could see how many linux users might think that interpreting a
complex root= parameter is a kernel function, when it is really just
the fact that they use an initramfs.

If somebody is running with root=LABEL=foo or something like that
without an initramfs I'll happily stand corrected.

Rich

Re: [gentoo-dev] Re: Questions about SystemD and OpenRC

[vivo75]

Il 12/08/2012 14:25, Rich Freeman ha scritto:
> On Sun, Aug 12, 2012 at 5:43 AM, Duncan<1i5t5.duncan@cox.net>  wrote:
>> Peter Stuge posted on Sun, 12 Aug 2012 02:12:38 +0200 as excerpted:
>>> What software parses the filesystem labels when you boot with openrc?
>>>
>>> (I ask because I never use labels myself.)
>> Short answer, mount and udev, and the kernel directly when fed that
>> information for root= on the kernel commandline.
>> ...
>> It'a also worth noting that the kernel's root= line can take a number of
>> these (I'm not sure if it can take them all), including partlabel,
>> according to information someone posted on the btrfs list
> I'm pretty sure that this particular part of your post is incorrect,
> but I'd be happy to be corrected.
>
> The kernel cannot interpret a root= parameter that doesn't reference a
> device node that it can't internally generate (with a devtmpfs/etc).
> I'm pretty sure that rules out just about anything but a physical
> device (not even /dev/by-uuid/...).
>
> I think that people get this confused because 99% of linux users have
> an initramfs (and about 2% of Gentoo users it seems), and most
> initramfs implementations DO interpret the root=parameter.  If you
> specify an initramfs then the kernel actually ignores the
> root=parameter entirely, mounting the initramfs as root, and passing
> control to its init.  The initramfs is expected to mount root (or not
> - you could just run the whole system off an initramfs I guess).  Most
> initramfs implementations just parse the root= line on the kernel,
> although it is worth noting that genkernel's initramfs does not and
> uses real_root instead.
>
> So, I could see how many linux users might think that interpreting a
> complex root= parameter is a kernel function, when it is really just
> the fact that they use an initramfs.
>
> If somebody is running with root=LABEL=foo or something like that
> without an initramfs I'll happily stand corrected.
>
> Rich
>
Yes it's incorrect, a kernel w/out initrd is not able to mount by LABEL, 
even with automounted /dev
experienced few weeks ago.

Re: [gentoo-dev] Re: Questions about SystemD and OpenRC

[Chí-Thanh Christopher Nguyễn]

Rich Freeman schrieb:
> So, I could see how many linux users might think that interpreting a
> complex root= parameter is a kernel function, when it is really just
> the fact that they use an initramfs.
> 
> If somebody is running with root=LABEL=foo or something like that
> without an initramfs I'll happily stand corrected.

If your disk is GPT partitioned, then you can use root=PARTUUID=...
without initramfs.
Note that PARTUUID is the partition UUID, not the filesystem UUID.


Best regards,
Chí-Thanh Christopher Nguyễn

[gentoo-dev] Re: Questions about SystemD and OpenRC

[Duncan]

Chí-Thanh Christopher Nguyễn posted on Sun, 12 Aug 2012 15:43:02 +0200 as
excerpted:

> Rich Freeman schrieb:
>> So, I could see how many linux users might think that interpreting a
>> complex root= parameter is a kernel function, when it is really just
>> the fact that they use an initramfs.
>> 
>> If somebody is running with root=LABEL=foo or something like that
>> without an initramfs I'll happily stand corrected.
> 
> If your disk is GPT partitioned, then you can use root=PARTUUID=...
> without initramfs.
> Note that PARTUUID is the partition UUID, not the filesystem UUID.

Thanks.

Note that the btrfs list discussion was in the context of gpt partlabels 
(and that I specifically said I don't know if the kernel takes all such 
assignments in root= or just that in the discussion), so it's quite 
possible only partlabels and partuuids are accepted, as these are found 
in the gpt partition table itself, which the kernel must know how to 
parse in general, so teaching it to parse and honor these probably 
wasn't /that/ much more work than teaching it to parse the table but 
ignore them.

And the gpt handling code is new enough, it may have simply been added 
with/for it, without touching the legacy mbr code.

Another variable may be bootloader.  Grub2 has legacy linux16 loader 
support, as well as 32-bit "linux" support.  Between that and the fact 
that it was designed to handle both BIOS and EFI systems, it's quite 
possible that the legacy 16-bit linux loader protocol doesn't support 
these features, while the 32-bit (and presumably 64-bit EFI) kernel 
loader protocol does.  I've no idea what grub-legacy used, but it 
wouldn't surprise me if it was the legacy 16-bit loader protocol, and 
that feeding root=PARTID= won't work for it but will with the 32-bit 
loader grub2 defaults to.

I really should try it one of these days and know from personal 
experience, but in this case, it really /is/ easier to just talk than to 
do, since trying it requires rebooting, so I can't simply try it in 
another window while I keep this post open, waiting on the result...

-- 
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

Re: [gentoo-dev] Re: Questions about SystemD and OpenRC

[Mike Gilbert]

On Sun, Aug 12, 2012 at 8:25 AM, Rich Freeman <rich0@gentoo.org> wrote:
> I think that people get this confused because 99% of linux users have
> an initramfs (and about 2% of Gentoo users it seems), and most
> initramfs implementations DO interpret the root=parameter.  If you
> specify an initramfs then the kernel actually ignores the
> root=parameter entirely, mounting the initramfs as root, and passing
> control to its init.  The initramfs is expected to mount root (or not
> - you could just run the whole system off an initramfs I guess).  Most
> initramfs implementations just parse the root= line on the kernel,
> although it is worth noting that genkernel's initramfs does not and
> uses real_root instead.

Small correction: genkernel's /init script accepts both real_root and
root on the kernel command line. If real_root is not specified, the
value of root is used.

It seems that the real_root option is a remnant of the initrd (not
intramfs) code, where root needed to be a ram disk (/dev/ram0). With
initramfs, the kernel ignores root, so we are free to use it for
specifying the actual root device.

So, when you see grub2-mkconfig generating entries with root=...,
please do not panic; this works just fine. :-)

Re: [gentoo-dev] Re: Questions about SystemD and OpenRC

[vivo75]

Il 12/08/2012 11:43, Duncan ha scritto:
> Peter Stuge posted on Sun, 12 Aug 2012 02:12:38 +0200 as excerpted:
>
>> vivo75@gmail.com wrote:
>>> First problem udev/SD has is that it can't see all the file system
>>> labels, for some reason it only see sda and sdb so it's able to partly
>>> proceed in the boot sequence, mount / (root) but can't mount anything
>>> else.
>> What software parses the filesystem labels when you boot with openrc?
>>
>> (I ask because I never use labels myself.)
> Short answer, mount and udev, and the kernel directly when fed that
> information for root= on the kernel commandline.  Openrc has basically
> nothing to do with it.  As such, I don't know what systemd's doing, but
> if it indeed is a systemd bug, it's obviously doing /something/ rather
> different... probably interacting in some unpredicted way with udev now
> that they're integrating it.

exactly my bet, since openrc with the _same_ (not recompiled) udev does work

>
> Slightly more detail, quoting the mount (8) manpage:
>
> It is possible to indicate a block special device using its volume LABEL
> or UUID (see the -L and -U options below).
>
> The recommended setup is to use LABEL=<label>  or UUID=<uuid>  tags rather
> than /dev/disk/by-{label,uuid} udev symlinks in the /etc/fstab file.
> The tags are more readable, robust and portable. The mount(8) command
> internally uses udev symlinks, so use the symlinks in /etc/fstab has no
> advantage over LABEL=/UUID=. For more details see libblkid(3).
>
> Note that mount(8) uses UUIDs as strings. The UUIDs from command line or
> fstab(5) are not converted to internal binary representation. The string
> representation of the UUID should be based on lower case characters.
>
> <<<<<
>
> The implication of the "as strings, not converted to binary" in the last
> paragraph is that mount's simply doing a dumb string match against the
> appropriate /dev/disk/by-* symlink names and dereferencing the symlink
> after which it can proceed as usual if there's a match.  It's udev (and
> thus now systemd, since they're combining) that's actually doing the
> work, exposing the /dev/disk/by-* symlinks with the correct references.
>
> As such, mount basically supports anything found in that location,
> including device hardware ID (combined with partition number where
> appropriate, listed in /dev/disk/by-id), the already mentioned filesystem
> LABEL (/dev/disk/by-label), PARTLABEL (GPT partitions have a partition
> label that's similar in function to the filesystem label, but set at gdisk
> time, not mkfs time, obviously this doesn't apply to legacy MBR
> partitioning), PARTUID, PATH (bus path, tho like traditional /dev/[hs]dX,
> this can be dynamic and the bus paths are longer and more obtuse for
> humans so there's generally little practical use for this one), and (as
> the manpage mentions, partition) UUID.
>
> It is however worth noting that PARTLABEL at least is new enough that at
> least as of a couple months ago when I looked at it for my md/raid setup,
> while udev passed thru the PARTLABEL for physical devices, it was NOT
> doing so for partitioned md/raid devices.  (That mobo died and I don't
> have md/raid on the new system so I can't verify current kernel 3.6-rc1+
> and udev-187-r3 PARTLABEL-on-md/raid behavior.)  So while people could
> setup their md/raid gpt partitions with partition-labels using gptfdisk
> (aka gdisk) or whatever, and I did so, only the ones on the physical
> disks showed up in udev, and at the time I was looking at it, I was
> running md/raid on virtually everything, so the feature was about useless
> for me.
>
> But that does mean that if mdev or whatever creates similar /dev/disk/by-
> *, that mount and friends should use it just as they would with udev,
> since all they're doing is a dumb string match and symlink deref.
>
> It'a also worth noting that the kernel's root= line can take a number of
> these (I'm not sure if it can take them all), including partlabel,
> according to information someone posted on the btrfs list (which I was
> following at the time, before I decided btrfs was too unstable still and
> that I'd wait until next year to try again).  I was going to try it, but
> lost interest when I found I couldn't use it with fstab for my mdraid-
> based gpt partitions anyway.  So all I can say is that it was reported to
> work on the btrfs list, and no one contradicted it, so...
>
>>> a) SD does not re-calculate it's deptree/services when exiting from
>>> rescue shell, it still try to start the "virtual" services as fstab
>>> would have never modified, a reboot is needed
>> systemctl --system daemon-reload ?
> I've not tried systemd yet nor have I yet researched it (I have the
> research vaguely scheduled for next year, sometime), but thanks to both
> of you for these details.  Based on past experience, I expect I'm
> collecting the pieces even tho I don't have context to assemble them in,
> but as a result, when I /do/ research it and get that context, the pieces
> I already have thanks to discussions like this, will fall into place, and
> it'll be far easier to get upto speed than it would have been had I tried
> going into it "cold turkey".
>
> So while I could guess, I'll just shutup and listen for this part.

seem possible, when bug this bug will be fixed, honestly, I've not tried 
that, also because the bigger delay was added by a timeout not a reboot 
(that take 10 seconds)
https://bugzilla.redhat.com/show_bug.cgi?id=815727
unless we discover that virtual services are too complex to manage and 
SD will always be bugged by similar stuff. Time will tell

>
>> I just work with the files on disk. The only time I use tools is if
>> systemd is running and needs to get told about updates. I don't think
>> there are any files that are not plain text, so I don't think any tools
>> are actually required.
> Useful to know. =:^)

All the virtual services don't have a corresponding file on disk, except 
for the radix say ManageDisk@.device which get multiplexed automatically 
(similar to some openrc services does with symlinks, think at net.eth0).
Having those materialized would be of great help in debugging

>
>> If there's a way to boot into a shell prompt, even if it is just bash
>> running as pid 1, then any system can be fixed. It requires knowing a
>> lot about how the system works though, so a lot about systemd if the
>> system uses systemd. Ie. knowing what files to change how in order to
>> accomplish desired results.
> FWIW, I actually have a set of grub2 menu entries with init=/bin/bash,
> for troubleshooting. =:^)
>
> But I think his point (valid or not) was that systemd's closing this
> avenue off as it's simply too monolithic to get information out of or to
> trial-start individual services even when not run as init, as is possible
> with openrc, for instance.
>
> With openrc, if you boot with init=/bin/bash, then try to start an openrc
> initscript, it'll protest that it's not init and that results may not be
> as intended due to lack of dependency tracking, etc, but it'll let you
> override and try anyway, you just have to manage the service deps
> manually or deal with the fallout if you screw it up.
>
> He appears to be saying that this doesn't work with systemd.  If it's not
> init, it refuses to do /anything/ with its unit-file initscript
> substitutes.  That /does/ sound like just the sort of complaint (of
> serveral) I've seen about systemd, but is it accurate?
>
> If it is, then yes, booting to init=/bin/bash (or from live-rescue media)
> and troubleshooting systemd problems from there *IS* going to be more
> difficult than doing the same thing from openrc, because openrc has the
> ability to override and one-off, while if this is correct, openrc doesn't.
correct, with an addition, even if things are fixable complexity _does_ 
matter, over a certain point of resources needed it really became "too 
difficult" == "unfixable".
Near enough example to this discussion was the initrd used some years 
ago from redhat (before dracut), it was simply plain unmodifiable in 
human time, and this doing something _much_ simpler than SD.
>
>> I don't understand this at all. Even if we go with what you write, then
>> I expect that some providers will start to offer an ecosystem of
>> systemd-optimized experiences for those who want it - but I do not
>> believe for a second that those would somehow be exclusive to other
>> systems.
> In all these systemd threads, someone posted a link to gregkh's take on
> gentoo as posted on google+.  In the comments that followed, Ted T'so and
> Kay S. had a rather interesting ping-pong in which one of them mentioned
> the concern that Red Hat and an init implementor for them had about all
> of this at the enterprise level.  For those interested in such things,
> it's worth going back and looking at that if you skipped it (either find
> the link here or just go back and look at gregkh's G+ from ~April).  I
> knew there were enterprise implications, but that was the first time I
> realized that RH wasn't necessarily 100% onboard with the full systemd
> thing, addressing it "upstream" since AFAIK Lennart is a RH employee as
> well.
>
>  From that, it looks like they're more or less waiting for things to
> settle down as well, and they plan on some perhaps major patches being
> necessary for the first few RH releases with systemd.  Of course, even
> assuming those patches eventually make it upstream, Red Hat's release
> cycle is long enough and their paying customers generally conservative
> enough, that it may be some time before they actually have to worry about
> supporting systemd in a deployed release.
>
> And of course, Ubuntu's continuing to stick to upstart for the time
> being, AFAIK.  And CentOS and ScientificLinux being RH offshoots, they'll
> follow RH.
>
> In practice, I think that means that remote-hosted servers shouldn't have
> to worry about systemd issues for another couple years, anyway, gentoo or
> not.  Of course if they run fedora, it might be a problem rather sooner.
> But people running fedora should be used to dealing with such leading
> edge issues, so no big deal for them either, really.
permit me to be worried anyway, systemd seem to going the "mutually 
exclusive" route, while enterprise customers benefit from backporting of 
fixes and rarely new versions added, gentoo does not.
>
> And given enterprise support terms, I guess we're looking at something
> approaching a decade before folks are actually FORCED to systemd, by
> falling off the end of the support train.
>
> Meanwhile, that gives plenty of time for other "entrprisish" parties to
> wait for redhat to decide what it's doing, then come up with their own
> solutions once a bit more about the ultimate target is known.  And until
> then, except for those choosing to run fedora or the like, the existing
> live-media-style remote rescue solutions should continue to work as they
> have.
>
> And in particular for gentoo users with remote hosts to worry about,
> since it's already clear that for at least the near term (say a year or
> two), gentoo's going to continue to default to openrc, there shouldn't be
> a problem for at least /that/ long.  And by the time any such problem
> /were/ to appear, it's very likely that solutions for it will be
> available as well... or given the day jobs of various gentoo devs,
> there'd certainly be sufficient interest in continuing systemd-
> alternative gentoo support, since they have similar issues themselves.
>
hopefully

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 623 bytes --]

On Sun, 12 Aug 2012 01:29:43 +0200
"vivo75@gmail.com" <vivo75@gmail.com> wrote:

> > 2. I saw on some lists that Gnome/Kde and Xfce plan to use some 
> > SystemD API, so does it means that we will need to install SystemD 
> > aside of OpenRC ?  
> It's not possible at the moment. systemd break non-systemd setups.

Elaborate.

I do my best to make it possible to be able to do at least minimal
OpenRC boot when systemd is used (for fallback). Even during the time
of 'systemd providing udev' systemd depended on udev-init-scripts
to ensure that openrc was able to boot.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Questions about SystemD and OpenRC

[vivo75]

Il 12/08/2012 09:44, Michał Górny ha scritto:
> On Sun, 12 Aug 2012 01:29:43 +0200
> "vivo75@gmail.com"<vivo75@gmail.com>  wrote:
>
>>> 2. I saw on some lists that Gnome/Kde and Xfce plan to use some
>>> SystemD API, so does it means that we will need to install SystemD
>>> aside of OpenRC ?
>> It's not possible at the moment. systemd break non-systemd setups.
> Elaborate.
>
> I do my best to make it possible to be able to do at least minimal
> OpenRC boot when systemd is used (for fallback). Even during the time
> of 'systemd providing udev' systemd depended on udev-init-scripts
> to ensure that openrc was able to boot.
>
enable systemd USE flag, start with openrc.
Pulseaudio will break, I suspect automount will break too, worried the 
list will grow.

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Samuli Suominen]

On 08/07/2012 03:47 PM, Sylvain Alain wrote:
> Hi everyone, for a couple of months now, I see on the list some of
> activities about OpenRC been ported to FreeBSD or OpenRC to Debian and
> other stuff related to SystemD.
>
> I have some basic questions about all that :
>
> 2. I saw on some lists that Gnome/Kde and Xfce plan to use some SystemD
> API, so does it means that we will need to install SystemD aside of
> OpenRC ?

For Xfce it only means that xfce4-session will try to query credentials 
also from systemd, not ConsoleKit alone

There are no plans of removing ConsoleKit support for Xfce wrt upstream 
anytime soon since Xfce is committed for long-term BSD support, and the 
Xfce development team includes developers, from eg. OpenBSD

> 4. Finally, is there any reason why Gnome/Kde/Xfce wants to add deps
> related to SystemD ? I don't understand why these desktops want to
> depend on a specific Sysint....

|| ( sys-auth/consolekit sys-apps/systemd ) or something can be done if 
the package tries to query both via DBUS calls
As in, something needs to tell PolicyKit (polkit) that you are a local 
user and thus grant access to eg. USB removable devices

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Christopher Head]

On Sun, 12 Aug 2012 11:03:01 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:

> > 2. I saw on some lists that Gnome/Kde and Xfce plan to use some
> > SystemD API, so does it means that we will need to install SystemD
> > aside of OpenRC ?
> 
> For Xfce it only means that xfce4-session will try to query
> credentials also from systemd, not ConsoleKit alone
> 
> There are no plans of removing ConsoleKit support for Xfce wrt
> upstream anytime soon since Xfce is committed for long-term BSD
> support, and the Xfce development team includes developers, from eg.
> OpenBSD
> 
> > 4. Finally, is there any reason why Gnome/Kde/Xfce wants to add deps
> > related to SystemD ? I don't understand why these desktops want to
> > depend on a specific Sysint....
> 
> || ( sys-auth/consolekit sys-apps/systemd ) or something can be done
> if the package tries to query both via DBUS calls
> As in, something needs to tell PolicyKit (polkit) that you are a
> local user and thus grant access to eg. USB removable devices
> 

What about those of us who are perfectly happy using neither one? I’ve
never had any of the Kits installed, and the recommendation has always
been to just put yourself in the “plugdev” group which has worked fine.
Is this going to continue to be possible, or is this going away?

Chris

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1787 bytes --]

On Mon, 13 Aug 2012 12:47:51 -0700
Christopher Head <headch@gmail.com> wrote:

> On Sun, 12 Aug 2012 11:03:01 +0300
> Samuli Suominen <ssuominen@gentoo.org> wrote:
> 
> > > 2. I saw on some lists that Gnome/Kde and Xfce plan to use some
> > > SystemD API, so does it means that we will need to install SystemD
> > > aside of OpenRC ?
> > 
> > For Xfce it only means that xfce4-session will try to query
> > credentials also from systemd, not ConsoleKit alone
> > 
> > There are no plans of removing ConsoleKit support for Xfce wrt
> > upstream anytime soon since Xfce is committed for long-term BSD
> > support, and the Xfce development team includes developers, from eg.
> > OpenBSD
> > 
> > > 4. Finally, is there any reason why Gnome/Kde/Xfce wants to add
> > > deps related to SystemD ? I don't understand why these desktops
> > > want to depend on a specific Sysint....
> > 
> > || ( sys-auth/consolekit sys-apps/systemd ) or something can be done
> > if the package tries to query both via DBUS calls
> > As in, something needs to tell PolicyKit (polkit) that you are a
> > local user and thus grant access to eg. USB removable devices
> > 
> 
> What about those of us who are perfectly happy using neither one? I’ve
> never had any of the Kits installed, and the recommendation has always
> been to just put yourself in the “plugdev” group which has worked
> fine. Is this going to continue to be possible, or is this going away?

I can't say whether at some point GNOME wouldn't try hard to force this
on us, but it will be still supported one way or another. There are
still people (like me) working on alternate solutions, and those people
will try hard to keep things working as they like them.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]