[gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Greg KH]

On Sun, Apr 08, 2012 at 04:30:01PM +0200, Ulrich Mueller wrote:
> New udev and separate /usr partition
> ====================================
> Decide on whether a separate /usr is still a supported configuration.
> If it is, newer udev can not be stabled and alternatives should be
> investigated. If it isn't, a lot of documentation will have to be
> updated. (And an alternative should likely still be provided.)
> 
> The council has voted in favour of a separate /usr being supported
> (5 yes, 1 no vote).

What?

> During the discussion, some concerns were raised that we might not be
> able to provide a modified or forked udev version. Chainsaw assured
> that if necessary, he will maintain a udev version that supports said
> configuration.

It isn't udev that is the problem here, it's the loads of other
packages.  udev is just being "nice" and pointing out that the user has
a problem.

> It was remarked that a solution that comprises both the forked udev
> version (separate /usr) and the latest versions is possible and
> therefore should not block either way preferred by users.

How in the world are you going to support this type of thing, when it
isn't udev that is the issue?

And udev isn't even the problem, all you need is to mount your /usr from
initramfs.  So, the original proposal wasn't even a correct/valid
proposal in the first place.

Papering over the issue, by just keeping udev from reporting the
problem is NOT a valid solution.  You are shooting the messenger here.

greg k-h

Re: [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Rich Freeman]

On Sun, Apr 8, 2012 at 6:04 PM, Greg KH <gregkh@gentoo.org> wrote:
> On Sun, Apr 08, 2012 at 04:30:01PM +0200, Ulrich Mueller wrote:

>> The council has voted in favour of a separate /usr being supported
>> (5 yes, 1 no vote).
>
> What?

Perhaps the council should be the ones to clarify, but I think the
vote only was for separate /usr being supported.  The irc log seemed a
bit more nuanced than perhaps came out in the summary.  Maybe I'm
misreading it.  I didn't see anything in the log about a decision that
newer versions of udev are not able to be stabled.

So, as to what "a separate /usr being supported" means, the impression
I got was "don't worry if you're running it, you'll have an upgrade
path."  Right now it sounds like the proposed upgrade path is that
some devs will fork udev and keep it running more like the current one
(presumably breaking in the same situations that it already does
today).

> And udev isn't even the problem, all you need is to mount your /usr from
> initramfs.  So, the original proposal wasn't even a correct/valid
> proposal in the first place.

Well, as far as I can tell the proposal that was voted on didn't even
mention udev at all, or initramfs.  But, as you point out using an
initramfs is likely to be more reliable.

I'm sure the same arguments were going around back when people were
advocating for dropping bootloader support in the kernel and telling
people to bugger_off_msg.  An initramfs creates more flexibility, at
the cost of an extra layer of software, just like grub.  The main
downside to it is that it tends to require more maintenance, though if
you build the necessary drivers to mount /usr into the kernel I
imagine that an initramfs would probably work across differing kernel
versions.

In any case, we should still be updating documentation/etc regardless.
 A better guide to dracut/genkernel would be useful no matter how this
turns out.  I'd like to see stable Gentoo stay current with udev in
any case, but I don't mind using a forked version as long as it is of
similar quality to the original.  As you've pointed out already, that
may not actually help people with a separate /usr, so I'd encourage
people to get an initramfs working.

Rich

[gentoo-dev] Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Steven J Long]

Rich Freeman wrote:

> On Sun, Apr 8, 2012 at 6:04 PM, Greg KH <gregkh@gentoo.org> wrote:
>> On Sun, Apr 08, 2012 at 04:30:01PM +0200, Ulrich Mueller wrote:
> 
>>> The council has voted in favour of a separate /usr being supported
>>> (5 yes, 1 no vote).
>>
>> What?
> 
> Perhaps the council should be the ones to clarify, but I think the
> vote only was for separate /usr being supported.  The irc log seemed a
> bit more nuanced than perhaps came out in the summary.  Maybe I'm
> misreading it.  I didn't see anything in the log about a decision that
> newer versions of udev are not able to be stabled.
> 
> So, as to what "a separate /usr being supported" means, the impression
> I got was "don't worry if you're running it, you'll have an upgrade
> path."  Right now it sounds like the proposed upgrade path is that
> some devs will fork udev and keep it running more like the current one
> (presumably breaking in the same situations that it already does
> today).
>
Well I definitely read it as "supported without an initramfs":

<Betelgeuse> Chainsaw: So to clarify a universal initramfs is not enough?
<Chainsaw> Betelgeuse: No.

Otherwise there is no contention, nor need to consider patches.
 
>> And udev isn't even the problem, all you need is to mount your /usr from
>> initramfs.  So, the original proposal wasn't even a correct/valid
>> proposal in the first place.
>
If udev simply requires partitions mounted before it is started, that allows 
those of us who don't need udev to get partitions mounted (still not sure 
how that works if you do) to continue with initscript-based approaches (eg 
those mentioned at end.)
 
> Well, as far as I can tell the proposal that was voted on didn't even
> mention udev at all, or initramfs.  But, as you point out using an
> initramfs is likely to be more reliable.
>
As above, the discussion prior certainly mentioned initramfs, and being able 
not to use one seems to be a requirement, or there'd be no need to talk 
about "forking" udev to maintain the old behaviour (which I believe is the 
ability to retry failed scripts in udev-postmount, which ideally requires 
udev to distinguish between failures due to file not found, and true 
failures.)
 
> I'm sure the same arguments were going around back when people were
> advocating for dropping bootloader support in the kernel and telling
> people to bugger_off_msg.  An initramfs creates more flexibility, at
> the cost of an extra layer of software, just like grub.  The main
> downside to it is that it tends to require more maintenance, though if
> you build the necessary drivers to mount /usr into the kernel I
> imagine that an initramfs would probably work across differing kernel
> versions.
>
One thing that has bothered me with the mooting of an initramfs as the new 
rescue system that rootfs has traditionally been, is at the we are told at 
the same time that the initramfs can be very minimal. If so, how does it 
provide the same capabilities as rootfs (for those of us who can localmount 
without udev-configured devices)?
 
> In any case, we should still be updating documentation/etc regardless.
>  A better guide to dracut/genkernel would be useful no matter how this
> turns out.  I'd like to see stable Gentoo stay current with udev in
> any case, but I don't mind using a forked version as long as it is of
> similar quality to the original.  As you've pointed out already, that
> may not actually help people with a separate /usr, so I'd encourage
> people to get an initramfs working.
>
There are two alternatives currently on the forums which don't require an 
initramfs, nor patches to udev. earlymounts[1] is an initscript which runs 
before udev in sysinit, which appears to be having teething troubles eg with 
fsck, and I have posted an approach[2] which allows udev to start after 
localmount, ie in the manner it used to, which has no problems with fsck, 
but is trickier to setup.

Of course, neither of these can be used if you have root on lvm or encrypted 
partitions, ie the cases which traditionally required an initrd, or if you 
have need of udev-configured devices to get through localmount.
 
[1] http://forums.gentoo.org/viewtopic-t-918466.html
[2] http://forums.gentoo.org/viewtopic-t-901206.html
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Zac Medico]

On 04/09/2012 11:09 AM, Steven J Long wrote:
> One thing that has bothered me with the mooting of an initramfs as the new
> rescue system that rootfs has traditionally been, is at the we are told at
> the same time that the initramfs can be very minimal. If so, how does it
> provide the same capabilities as rootfs (for those of us who can localmount
> without udev-configured devices)?

We've had some discussion on this before [1], and I've suggested to copy 
the content of livecd/usb recovery disk onto a spare partition so that 
you can boot into that if necessary. The advantage of using this 
approach is that it eliminates the burden of maintaining the "/ is a 
self-contained boot disk that's independent of /usr" use case.

[1] 
http://archives.gentoo.org/gentoo-dev/msg_ceb908069aafdfff50e7f2d0732bf209.xml
-- 
Thanks,
Zac

[gentoo-dev] Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Steven J Long]

Zac Medico wrote:

> On 04/09/2012 11:09 AM, Steven J Long wrote:
>> One thing that has bothered me with the mooting of an initramfs as the
>> new rescue system that rootfs has traditionally been, is at the we are
>> told at the same time that the initramfs can be very minimal. If so, how
>> does it provide the same capabilities as rootfs (for those of us who can
>> localmount without udev-configured devices)?
> 
> We've had some discussion on this before [1], and I've suggested to copy
> the content of livecd/usb recovery disk onto a spare partition so that
> you can boot into that if necessary. The advantage of using this
> approach is that it eliminates the burden of maintaining the "/ is a
> self-contained boot disk that's independent of /usr" use case.
>
It's a nice idea, and could also be done without an initramfs, ofc. You 
mention configuring "initramfs to mount that as the root if something goes 
wrong with your real root."

Thing is, for most desktop/laptop installs, if something goes wrong mounting 
root from hard-disk, it's likely that booting into another partition will go 
wrong too. It's pretty rare to get errors just on rootfs, that aren't to do 
with the whole drive, and aren't fixed by fsck on a stable fs like ext3. (If 
you do, you have to go to backups ofc, and would be wise to suspect the 
whole drive.) At least, that's been my experience using separate partitions 
for everything.

In that circumstance, if a rescue shell weren't available, (you're able to 
boot the kernel or the the spare partition can't be booted to) I would just 
boot the latest sysresccd that was around, if not able to download from 
another box. If it were really that bad, I'd likely want to reinitialise any 
failing partition, and would probably want a recent minimal install disk.

Boot up problems which need admin-work on Gentoo, ime, tend to be about 
system upgrades not playing nicely, rather than the kernel unable to boot at 
all (once you know which drivers you need for eg PCI/SATA drives built-in, 
you usually are able to get at least root consistently, on an older kernel 
if you're upgrading.)

Again, being able to boot into the machine, and have the rootfs at hand for 
say dispatch-conf and rc-update, works nicely. A rescue partition would 
effectively work the same as a live-disk, in that you'd need to do all the 
chrooting etc afaics, and would need to be maintained to stay current.

I suppose you could script that, but again, it just seems like a lot of 
bother to implement an "alternative" that doesn't actually gain anything 
over the traditional setup (plus making sure that partitions are mounted 
before udev starts.)

As for the burden of ensuring that binaries installed to /{s,}bin don't link 
to libs in /usr, why not just automate a QA check for that, and let 
developers decide whether a fix is necessary? After all, core packages that 
do that even when configured with prefix and execprefix = /, aren't so 
portable, and Gentoo has always championed "doing the right thing" wrt 
helping upstream fix portability issues.

I realise "core" is subjective, but it amounts to "what our lovely devs 
decide on for us" which is part of the reason you choose a distro, and the 
trust you place in its developers.

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Zac Medico]

On 04/10/2012 07:28 PM, Steven J Long wrote:
> I suppose you could script that, but again, it just seems like a lot of
> bother to implement an "alternative" that doesn't actually gain anything
> over the traditional setup (plus making sure that partitions are mounted
> before udev starts.)

At least in the case of udev, we gain from not having to maintain a fork.

> As for the burden of ensuring that binaries installed to /{s,}bin don't link
> to libs in /usr, why not just automate a QA check for that, and let
> developers decide whether a fix is necessary? After all, core packages that
> do that even when configured with prefix and execprefix = /, aren't so
> portable, and Gentoo has always championed "doing the right thing" wrt
> helping upstream fix portability issues.

If the relevant ebuild developers really want to support that, it's fine 
I guess. Hopefully that won't involve using static links as workarounds 
for cross-/usr dependencies.
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[William Hubbs]

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

On Tue, Apr 10, 2012 at 09:09:03PM -0700, Zac Medico wrote:
> On 04/10/2012 07:28 PM, Steven J Long wrote:
> > I suppose you could script that, but again, it just seems like a lot of
> > bother to implement an "alternative" that doesn't actually gain anything
> > over the traditional setup (plus making sure that partitions are mounted
> > before udev starts.)
> 
> At least in the case of udev, we gain from not having to maintain a fork.
> 
> > As for the burden of ensuring that binaries installed to /{s,}bin don't link
> > to libs in /usr, why not just automate a QA check for that, and let
> > developers decide whether a fix is necessary? After all, core packages that
> > do that even when configured with prefix and execprefix = /, aren't so
> > portable, and Gentoo has always championed "doing the right thing" wrt
> > helping upstream fix portability issues.
> 
> If the relevant ebuild developers really want to support that, it's fine 
> I guess. Hopefully that won't involve using static links as workarounds 
> for cross-/usr dependencies.

Another issue to consider is binaries that want to access things in
/usr/share/*. If a binary in /{bin,sbin} needs to access something in
/usr/share/*, you have two choices. move the binary to /usr or move the
thing it wants to access to / somewhere which would involve creating
/share. Actually there is another choice, but I don't want to go there.
That would be writing patches.

The best way to solve all cross / - /usr dependencies imo is the /usr
merge (moving everything from /{bin,sbin,lib*} to the counterparts in
/usr), which has been discussed pretty extensively on this list, and
there hasn't been a lot of opposition to it.

William


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

[gentoo-dev] Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Steven J Long]

William Hubbs wrote:
> Another issue to consider is binaries that want to access things in
> /usr/share/*. If a binary in /{bin,sbin} needs to access something in
> /usr/share/*, you have two choices. move the binary to /usr or move the
> thing it wants to access to / somewhere which would involve creating
> /share. Actually there is another choice, but I don't want to go there.
> That would be writing patches.
>
I'm ignorant of which binaries do that? (It's understood that you might not 
have manpages in rescue-mode.) OT, it's odd that nano is in /usr/bin but on 
my system at least it only links to /lib64.

We're only discussing the same tools one might need in an initramfs, wherein 
they presumably also need to have their linkage checked.
 
> The best way to solve all cross / - /usr dependencies imo is the /usr
> merge (moving everything from /{bin,sbin,lib*} to the counterparts in
> /usr), which has been discussed pretty extensively on this list, and
> there hasn't been a lot of opposition to it.
>
There's been quite a bit of vocal opposition on the forums[1], and it's 
users who've setup their machines in line with Gentoo docs that this is 
going to impact. Even the link that was given to Red-Hat discussion about 
this a while back, showed opposition to the move from their users.

[1] http://forums.gentoo.org/viewtopic-t-914852.html
'It's about as good an idea as putting the entire content of /etc into a 
file and calling it "The Registry" 
Oh, wait, that's already been done and shown not to work.'
NeddySeagoon - whose experience in system-administration and IT I'll bow to 
anyday.

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1387 bytes --]

On Wednesday 11 April 2012 12:10:05 Steven J Long wrote:
> William Hubbs wrote:
> > Another issue to consider is binaries that want to access things in
> > /usr/share/*. If a binary in /{bin,sbin} needs to access something in
> > /usr/share/*, you have two choices. move the binary to /usr or move the
> > thing it wants to access to / somewhere which would involve creating
> > /share. Actually there is another choice, but I don't want to go there.
> > That would be writing patches.
> 
> I'm ignorant of which binaries do that?

off the top of my head:
	- this is why /etc/localtime is no longer a symlink to 
/usr/share/zoneinfo/
	- this is why we have copies for a few terminals in /etc/terminfo from 
/usr/share/terminfo/ ... hopefully the one you're using is listed there
	- this is why we have to delay running keymap and consolefont init.d 
scripts until after /usr has been mounted (/usr/share/keymaps 
/usr/share/consolefont /usr/share/consoletrans)
	- anything locale related doesn't work until /usr is mounted 
(/usr/lib/locale /usr/share/locale)
	- passwd changing relying on cracklib dicts won't work 
(/usr/lib/cracklib_dict* /usr/share/misc/)

> (It's understood that you might not
> have manpages in rescue-mode.) OT, it's odd that nano is in /usr/bin but on
> my system at least it only links to /lib64.

/usr/bin/nano is a symlink
-mike

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

[gentoo-dev] Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Steven J Long]

Mike Frysinger wrote:

> On Wednesday 11 April 2012 12:10:05 Steven J Long wrote:
>> William Hubbs wrote:
>> > Another issue to consider is binaries that want to access things in
>> > /usr/share/*.
>> 
>> I'm ignorant of which binaries do that?
> 
> off the top of my head:

Ah thanks, this is what I was after: interested in which ones make use of a 
rescue-shell or initramfs more difficult.

> - this is why /etc/localtime is no longer a symlink to
> /usr/share/zoneinfo/
- don't think that makes any difference to rescue situation.

> - this is why we have copies for a few terminals in /etc/terminfo from
> /usr/share/terminfo/ ... hopefully the one you're using is listed there
- while unfortunate, I'd say ditto since user can always copy any required 
file themselves for their particular setup.

> - this is why we have to delay running keymap and consolefont init.d
> scripts until after /usr has been mounted (/usr/share/keymaps
> /usr/share/consolefont /usr/share/consoletrans)

- this is one that really is annoying; having your keyboard switched to US 
layout. It's not totally insurmountable from a UK keyboard, but I'd imagine 
eg a Dvorak user would have trouble.

du -hs here, shows:
1.1M    /usr/share/keymaps
1000K   /usr/share/consolefonts
504K    /usr/share/consoletrans

..which is nothing I personally would mind on rootfs, if it meant my rescue-
shell used my keyboard layout.

> - anything locale related doesn't work until /usr is mounted
> (/usr/lib/locale /usr/share/locale)

This doesn't affect me as I'm fine with en_US vs en_GB.
1.7M    /usr/lib/locale
53M     /usr/share/locale
..is a lot heavier, though.

(Sorry, I'm not stating that anyone is going to want to maintain this, I'm 
just scoping out how much data we're talking about, and how it important it 
is. While latter might change according to user as here, it would be cool if 
it were nothing more than setting up a few symlinks during install.)

> - passwd changing relying on cracklib dicts won't work
> (/usr/lib/cracklib_dict* /usr/share/misc/)
>
I can see you might want the option after an attack on a host. NFC how 
viable moving and linking is (not sure what it uses in /usr/share/misc but I 
for one would love the pci and usb stuff [just over 1M] in rootfs. kk I know 
it's not going to happen officially ;) but libs are less than 300k here.
 
>> (It's understood that you might not
>> have manpages in rescue-mode.) OT, it's odd that nano is in /usr/bin but
>> on my system at least it only links to /lib64.
> 
> /usr/bin/nano is a symlink
ah d'oh, ta; i see it was switched back in 2004.

>> > If a binary in /{bin,sbin} needs to access something in
>> > /usr/share/*, you have two choices. move the binary to /usr or move the
>> > thing it wants to access to / somewhere which would involve creating
>> > /share. Actually there is another choice, but I don't want to go there.
>> > That would be writing patches.

Yeah, based on above, I'd feel okay about /lib/share/foo personally, linked 
to from /usr/share/foo on both bare rootfs with no mounts, and standard 
/usr. (Similar for /usr/lib/foo to /lib/foo.) If it's in 
/usr/{share,lib}/dir/* then the possibility at least of moving it fairly 
simply, exists. Otherwise you're into dealing with a build-system of one 
sort or another.

Regards,
Steve.
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 493 bytes --]

On Friday 04 May 2012 12:36:20 Steven J Long wrote:
> Mike Frysinger wrote:
> > - this is why /etc/localtime is no longer a symlink to
> > /usr/share/zoneinfo/
> 
> - don't think that makes any difference to rescue situation.

no, but that isn't the driving factor here.  programs get executed before /usr 
is mounted which means these things need to be available.  otherwise, dates in 
logs and such are wrong.  the rest of your comments should be taken in the 
same light.
-mike

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

[gentoo-dev] Re: Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Steven J Long]

Mike Frysinger wrote:

> On Friday 04 May 2012 12:36:20 Steven J Long wrote:
>> Mike Frysinger wrote:
>> > - this is why /etc/localtime is no longer a symlink to
>> > /usr/share/zoneinfo/
>> 
>> - don't think that makes any difference to rescue situation.
> 
> no, but that isn't the driving factor here.  programs get executed before
> /usr is mounted which means these things need to be available.  otherwise,
> dates in logs and such are wrong.  the rest of your comments should be
> taken in the same light.

OK, fair enough. I still don't think it makes much difference in terms of 
the viability of moving certain directories (for the admin, not the distro) 
given the current setup. Nonetheless, I'll just wait til your busybox applet 
is the officially-supported method of split /usr without an initramfs ;)

(It'll mean openrc by default gets a faster bootup, which matters to some 
people.)

Steve.
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

[gentoo-dev] Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Steven J Long]

Zac Medico wrote:

> On 04/10/2012 07:28 PM, Steven J Long wrote:
>> I suppose you could script that, but again, it just seems like a lot of
>> bother to implement an "alternative" that doesn't actually gain anything
>> over the traditional setup (plus making sure that partitions are mounted
>> before udev starts.)
> 
> At least in the case of udev, we gain from not having to maintain a fork.
>
"Making sure that partitions are mounted before udev starts" is a lot less 
of an ask than setting up an initramfs, and changing the way we've worked 
for years. It's what you proposed: an earlymounts init script, or patches to 
Gentoo initscripts to do the same thing. Neither involves any patches to 
udev proper, so no fork needs to be maintained.
 
>> As for the burden of ensuring that binaries installed to /{s,}bin don't
>> link to libs in /usr, why not just automate a QA check for that, and let
>> developers decide whether a fix is necessary? After all, core packages
>> that do that even when configured with prefix and execprefix = /, aren't
>> so portable, and Gentoo has always championed "doing the right thing" wrt
>> helping upstream fix portability issues.
> 
> If the relevant ebuild developers really want to support that, it's fine
> I guess. Hopefully that won't involve using static links as workarounds
> for cross-/usr dependencies.

Well I for one wouldn't like that, so no argument there: it's only for where 
the package would be definitely be considered for inclusion in a rescue-
disk/ initramfs/ partition, like say lvm2, mount or fsck. While you might 
not always be able to access the manpages, a system admin would want at 
least the binaries available.

I think it was mgorny who posted a check, which is why I brought it up. 
Perhaps an opt-in check if some variable is set, would be better? That way, 
only a maintainer who wants to mark the package as system-critical, and is 
happy to deal with linkage issues for binaries (including just deciding that 
some aren't so critical, which implies an optional exclusion variable, or 
listing binaries that should be checked) would set it, in the interests of 
overall portability and helping traditional users.

If a maintainer isn't interested, or upstream don't like it (ie won't accept 
bugs with such a setup even when linkage is not the issue), there's no 
additional burden.

Of course, if no developer thinks it's worth doing, the discussion is moot. 
It would seem at the least useful, if not necessary, however, if Gentoo is 
going to continue to support the traditional split /usr setup.

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Zac Medico]

On 04/11/2012 07:13 AM, Steven J Long wrote:
> Zac Medico wrote:
>
>> On 04/10/2012 07:28 PM, Steven J Long wrote:
>>> I suppose you could script that, but again, it just seems like a lot of
>>> bother to implement an "alternative" that doesn't actually gain anything
>>> over the traditional setup (plus making sure that partitions are mounted
>>> before udev starts.)
>>
>> At least in the case of udev, we gain from not having to maintain a fork.
>>
> "Making sure that partitions are mounted before udev starts" is a lot less
> of an ask than setting up an initramfs, and changing the way we've worked
> for years. It's what you proposed: an earlymounts init script, or patches to
> Gentoo initscripts to do the same thing. Neither involves any patches to
> udev proper, so no fork needs to be maintained.

It's not generally practical to do mounts prior to starting udev, since 
udev can may be needed to create the device nodes that are needed for 
for performing the mounts. Maybe a subset of users can get away with it 
by relying on devtmpfs and having the drivers built into the kernel, but 
that won't work for everyone.
-- 
Thanks,
Zac

[gentoo-dev] Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Steven J Long]

Zac Medico wrote:

> On 04/11/2012 07:13 AM, Steven J Long wrote:
>> Zac Medico wrote:
>>
>>> On 04/10/2012 07:28 PM, Steven J Long wrote:
>>>> I suppose you could script that, but again, it just seems like a lot of
>>>> bother to implement an "alternative" that doesn't actually gain
>>>> anything over the traditional setup (plus making sure that partitions
>>>> are mounted before udev starts.)
>>>
>>> At least in the case of udev, we gain from not having to maintain a
>>> fork.
>>>
>> "Making sure that partitions are mounted before udev starts" is a lot
>> less of an ask than setting up an initramfs, and changing the way we've
>> worked for years. It's what you proposed: an earlymounts init script, or
>> patches to Gentoo initscripts to do the same thing. Neither involves any
>> patches to udev proper, so no fork needs to be maintained.
> 
> It's not generally practical to do mounts prior to starting udev, since
> udev can may be needed to create the device nodes that are needed for
> for performing the mounts. Maybe a subset of users can get away with it
> by relying on devtmpfs and having the drivers built into the kernel, but
> that won't work for everyone.

OFC not: the generic method is to use an initramfs. But many of us *do* have 
the drivers for the device nodes built-in: it's part of the initial setup in 
configuring a kernel (manually) and getting it to boot.

I can't speak for others, but that level of control is why I, for one, chose 
Gentoo in the first place. I don't see the need for a source-based distro to 
include everything and the kitchen-sink: that principle applies via USE-
flags, and it applies via having a lean kernel that doesn't contain modules 
for 15 PCI controllers my motherboard doesn't have, and never could have.

The Council has voted that Gentoo continue to support that subset, without 
an initramfs.

I'm glad you accept that we don't need to fork udev to do this, though, so 
there isn't that maintenance issue, beyond Gentoo initscripts (and if there 
should be in future, a Council member has already committed to overseeing 
that work.)

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Rich Freeman]

On Sat, Apr 21, 2012 at 10:43 PM, Steven J Long
<slong@rathaus.eclipse.co.uk> wrote:
> The Council has voted that Gentoo continue to support that subset, without
> an initramfs.

Citation, please?

Rich

[gentoo-dev] Re: Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Steven J Long]

Rich Freeman wrote:
>> The Council has voted that Gentoo continue to support that subset,
>> without an initramfs.
>
(The "subset of users" being those who do not need udev before localmount.)

> Citation, please?
> 

<ulm> New udev and separate /usr partition
<Chainsaw> In my opinion, a separate /usr partition has been a supported 
configuration for a very long time and should remain so.
<Betelgeuse> Chainsaw: So to clarify a universal initramfs is not enough?
<Chainsaw> Betelgeuse: No. That is additional work for a clearly broken 
package.

So we must support separate /usr *without* an initramfs.

<dberkholz> who's going to either "port" udev as necessary, or maintain an 
old version forever?
<Chainsaw> I will keep an old version going until the end of time.
<Chainsaw> dberkholz: My plan is to patch reasonable behaviour back into 
udev, and going with the upstream releases as long as it is feasible.

To confirm again, that this is about without initramfs:
<dberkholz> sure i can. maintain old udev-XXX forever, put an elog in new 
udev that says "if you want separate /usr without initramfs, install old 
udev, mask new, or whatever"

And again, I ask: if it were *not* about running udev without an initramfs, 
then why would anyone even be discussing the possibility of patching or 
forking?

The only question is whether running without an initramfs means the same 
thing as not requiring udev before localmount. I contend that it is, since 
the basic requirement we've been given is that udev as a service requires 
/usr and /var mounted before starting, since some devices already require 
scripts which are in /usr or access /var (and going forward effectively can 
require a script anywhere.)

Wrt udev linking to /usr/lib, it seems that any such linkage would need to 
be satisfied in an initramfs too, so the same data could be used for people 
who don't have an initramfs (how we deal with it on our systems is up to 
us.)

I would dearly love to hear a walkthrough of how you deal with device nodes 
created by udev which are required for udev to start in your initramfs, but 
it does not affect the basic requirement for our use-case: that udev is not 
needed for localmount.

Regards,
Steve.
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Mike Gilbert]

On Sun, Apr 22, 2012 at 1:28 AM, Steven J Long
<slong@rathaus.eclipse.co.uk> wrote:
> Rich Freeman wrote:
>>> The Council has voted that Gentoo continue to support that subset,
>>> without an initramfs.
>>
> (The "subset of users" being those who do not need udev before localmount.)
>
>> Citation, please?
>>
>
> <ulm> New udev and separate /usr partition
> <Chainsaw> In my opinion, a separate /usr partition has been a supported
> configuration for a very long time and should remain so.
> <Betelgeuse> Chainsaw: So to clarify a universal initramfs is not enough?
> <Chainsaw> Betelgeuse: No. That is additional work for a clearly broken
> package.
>
> So we must support separate /usr *without* an initramfs.
>
> <dberkholz> who's going to either "port" udev as necessary, or maintain an
> old version forever?
> <Chainsaw> I will keep an old version going until the end of time.
> <Chainsaw> dberkholz: My plan is to patch reasonable behaviour back into
> udev, and going with the upstream releases as long as it is feasible.
>
> To confirm again, that this is about without initramfs:
> <dberkholz> sure i can. maintain old udev-XXX forever, put an elog in new
> udev that says "if you want separate /usr without initramfs, install old
> udev, mask new, or whatever"
>
> And again, I ask: if it were *not* about running udev without an initramfs,
> then why would anyone even be discussing the possibility of patching or
> forking?
>

Here is my interpretation: the council voted on the following question:

<ulm> The question is: "Decide on whether a separate /usr is still a supported
      configuration."

It did not decide the method that would be used to accomplish this. A
few council members (Chainsaw mainly) expressed a desire to do it
without an initramfs, but an official stance on this was not put
forward.

You are reading into it more that you should.

Re: [gentoo-dev] [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Ulrich Mueller]

>>>>> On Sun, 22 Apr 2012, Mike Gilbert wrote:

> Here is my interpretation: the council voted on the following
> question:

> <ulm> The question is: "Decide on whether a separate /usr is still a
>       supported configuration."

> It did not decide the method that would be used to accomplish this.
> A few council members (Chainsaw mainly) expressed a desire to do it
> without an initramfs, but an official stance on this was not put
> forward.

> You are reading into it more that you should.

Please don't cite single lines without context. My next line in that
log is:

<ulm> as in the agenda

Which says:

| 3. New udev and separate /usr partition (30 minutes)
| 
|    See [4]: "Decide on whether a separate /usr is still a supported
|    configuration. If it is, newer udev can not be stabled and
|    alternatives should be investigated. If it isn't, a lot of
|    documentation will have to be updated. (And an alternative should
|    likely still be provided.)"
|
| [4] <http://archives.gentoo.org/gentoo-project/msg_c96d1b724cd736702820fa5ff1547557.xml>

Ulrich

[gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Steven J Long]

Ulrich Mueller wrote:

> | 3. New udev and separate /usr partition (30 minutes)
> | 
> |    See [4]: "Decide on whether a separate /usr is still a supported
> |    configuration. If it is, newer udev can not be stabled and
> |    alternatives should be investigated. If it isn't, a lot of
> |    documentation will have to be updated. (And an alternative should
> |    likely still be provided.)"
> |
> | [4]
> | [<http://archives.gentoo.org/gentoo-
project/msg_c96d1b724cd736702820fa5ff1547557.xml>
> 
From the first reply:

"To clarify, the question is whether or not we support a separate /usr 
_without_ mounting it early via an initramfs."

I hope that settles that particular issue.

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Mike Gilbert]

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

On 04/22/2012 05:28 AM, Steven J Long wrote:
> Ulrich Mueller wrote:
> 
>> | 3. New udev and separate /usr partition (30 minutes)
>> | 
>> |    See [4]: "Decide on whether a separate /usr is still a supported
>> |    configuration. If it is, newer udev can not be stabled and
>> |    alternatives should be investigated. If it isn't, a lot of
>> |    documentation will have to be updated. (And an alternative should
>> |    likely still be provided.)"
>> |
>> | [4]
>> | [<http://archives.gentoo.org/gentoo-
> project/msg_c96d1b724cd736702820fa5ff1547557.xml>
>>
> From the first reply:
> 
> "To clarify, the question is whether or not we support a separate /usr 
> _without_ mounting it early via an initramfs."
> 
> I hope that settles that particular issue.
> 

Hmm... I see that in Zac's reply, thanks for that.

Unfortunately, from what I can tell, that clarification was not actually
part of the proposed agenda [5], nor was it directly referenced. So the
subject of the vote still seems open to interpretation.

Ultimately, the council's only "power" is to stop things from happening
under threat of expulsion from the project. I think it would be a
mistake for this particular council vote to be used as the sole
justification for preventing devs from committing changes that would
require an initramfs for separate /usr support. It simply does not seem
clear enough for that.

[5]
http://archives.gentoo.org/gentoo-project/msg_ac95bed78694852cd09f20a07437b805.xml


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

Re: [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Zac Medico]

On 04/22/2012 10:55 AM, Mike Gilbert wrote:
> On 04/22/2012 05:28 AM, Steven J Long wrote:
>> Ulrich Mueller wrote:
>>
>>> | 3. New udev and separate /usr partition (30 minutes)
>>> | 
>>> |    See [4]: "Decide on whether a separate /usr is still a supported
>>> |    configuration. If it is, newer udev can not be stabled and
>>> |    alternatives should be investigated. If it isn't, a lot of
>>> |    documentation will have to be updated. (And an alternative should
>>> |    likely still be provided.)"
>>> |
>>> | [4]
>>> | [<http://archives.gentoo.org/gentoo-
>> project/msg_c96d1b724cd736702820fa5ff1547557.xml>
>>>
>> From the first reply:
>>
>> "To clarify, the question is whether or not we support a separate /usr 
>> _without_ mounting it early via an initramfs."
>>
>> I hope that settles that particular issue.
>>
> 
> Hmm... I see that in Zac's reply, thanks for that.
> 
> Unfortunately, from what I can tell, that clarification was not actually
> part of the proposed agenda [5], nor was it directly referenced. So the
> subject of the vote still seems open to interpretation.

Yeah, it almost seems as though the council was being intentionally
vague and leaving things open to interpretation. In response, we had
William post about the ">= udev-182 tracker" [1], to which Tony seemed
to respond positively [2].

[1]
http://archives.gentoo.org/gentoo-dev/msg_015e73cfccbd72fa956a8bdbc2e9cdc0.xml
[2]
http://archives.gentoo.org/gentoo-dev/msg_fb17ccaadc95c7f3f27d0613c13aa04e.xml
-- 
Thanks,
Zac

[gentoo-dev] Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Steven J Long]

Zac Medico wrote:

> On 04/22/2012 10:55 AM, Mike Gilbert wrote:
>> On 04/22/2012 05:28 AM, Steven J Long wrote:
>>> From the first reply:
>>>
>>> "To clarify, the question is whether or not we support a separate /usr
>>> _without_ mounting it early via an initramfs."
>>>
>>> I hope that settles that particular issue.
>>>
>> 
>> Hmm... I see that in Zac's reply, thanks for that.
>> 
>> Unfortunately, from what I can tell, that clarification was not actually
>> part of the proposed agenda [5], nor was it directly referenced. So the
>> subject of the vote still seems open to interpretation.
> 
> Yeah, it almost seems as though the council was being intentionally
> vague and leaving things open to interpretation.

Wow, man, never thought I'd see *you* weasel out of something like that ;)

> In response, we had
> William post about the ">= udev-182 tracker" [1], to which Tony seemed
> to respond positively [2].
>
That was about process to do with stabilisation. Of course having a tracker 
to monitor any issues is a positive step.

It doesn't say anything at all about what the base requirement was, nor what 
was up for discussion at the meeting. You yourself clarified that it was 
about no initramfs as soon as it was raised to Council: that was the only 
thing that could cause a technical issue, specifically to users who have 
setup according to official documentation, requiring a policy decision.

And that's what all the discussion was about: the consequence of making that 
policy decision (ie who would maintain patches, which are no longer needed.)

Still, this got silly weeks ago. Clearly Council needs to vote again with 
clear wording, or people will keep trying to pretend that they weren't 
discussing what they were asked to discuss.

Regards,
Steve.
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Zac Medico]

On 05/04/2012 08:20 AM, Steven J Long wrote:
> Zac Medico wrote:
> 
>> On 04/22/2012 10:55 AM, Mike Gilbert wrote:
>>> On 04/22/2012 05:28 AM, Steven J Long wrote:
>>>> From the first reply:
>>>>
>>>> "To clarify, the question is whether or not we support a separate /usr
>>>> _without_ mounting it early via an initramfs."
>>>>
>>>> I hope that settles that particular issue.
>>>>
>>>
>>> Hmm... I see that in Zac's reply, thanks for that.
>>>
>>> Unfortunately, from what I can tell, that clarification was not actually
>>> part of the proposed agenda [5], nor was it directly referenced. So the
>>> subject of the vote still seems open to interpretation.
>>
>> Yeah, it almost seems as though the council was being intentionally
>> vague and leaving things open to interpretation.
> 
> Wow, man, never thought I'd see *you* weasel out of something like that ;)
> 
>> In response, we had
>> William post about the ">= udev-182 tracker" [1], to which Tony seemed
>> to respond positively [2].
>>
> That was about process to do with stabilisation. Of course having a tracker 
> to monitor any issues is a positive step.
> 
> It doesn't say anything at all about what the base requirement was, nor what 
> was up for discussion at the meeting. You yourself clarified that it was 
> about no initramfs as soon as it was raised to Council:

I *tried* to clarify it, but was apparently unsuccessful, since the
agenda item contained no mention of initramfs:

http://archives.gentoo.org/gentoo-dev/msg_2eaaf4a4e302bf0e6c20accaec61db82.xml

> that was the only 
> thing that could cause a technical issue, specifically to users who have 
> setup according to official documentation, requiring a policy decision.

I'm not so sure. The one question that really stood out for me was the
question of whether or not newer udev could be stabilized, since it
would be problematic for separate-/usr-without-initramfs systems.
-- 
Thanks,
Zac

[gentoo-dev] Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Steven J Long]

Mike Gilbert wrote:

> On 04/22/2012 05:28 AM, Steven J Long wrote:
>> "To clarify, the question is whether or not we support a separate /usr
>> _without_ mounting it early via an initramfs."
>> 
>> I hope that settles that particular issue.
>> 
> 
> Hmm... I see that in Zac's reply, thanks for that.
> 
> Unfortunately, from what I can tell, that clarification was not actually
> part of the proposed agenda [5], nor was it directly referenced. So the
> subject of the vote still seems open to interpretation.
>
Chainsaw proposed the item. zmedico immediately clarified that it was about 
supporting separate /usr without an initramfs mounting it.

Chainsaw was asked to describe the issue. He was asked whether a "minimal 
universal" initramfs was a sufficient solution, and he explicity turned it 
down. All further discussion was about who would continue to maintain any 
patches that might be needed.

Again, those could not have been needed, unless one were discussing split 
/usr without an initramfs, since udev with an initramfs already supports a 
separate /usr. Or do you disagree?

To say that it was not referenced in the discussion seems disingenuous: it 
_was_ the topic of discussion.
 
> Ultimately, the council's only "power" is to stop things from happening
> under threat of expulsion from the project. I think it would be a
> mistake for this particular council vote to be used as the sole
> justification for preventing devs from committing changes that would
> require an initramfs for separate /usr support. It simply does not seem
> clear enough for that.
>
Woah, no-one's even talking about anything along those lines.

The Council *does* decide on overall technical policy, and this procedure is 
used for eg resolution of PMS and EAPI issues. Obviously, like all 
collaborative processes, and indeed policing in general, it only works by 
consent.

There's no issue of changes to udev, since those can be handled at 
initscript/ busybox-applet level for those who want to continue without an 
initramfs and split partitioning.

There might be future problems with linkage, but I've already stated a 
couple of times, that the same issues arise for the newer use-case of an 
initramfs, and it would make sense to tackle those systematically for at 
least some tools like lvm and mdadm. Given the systematic ability, it's much 
easier for users to apply elsewhere, and has other uses (basically doing it 
right is LDEPEND or required-link deps which slot operators do *not* cover.)

What's wrong with doing that, so we all cooperate and we all benefit, 
instead of arguing?

Anyhow, wrt what the Council was actually discussing (remember that split 
/usr with an initramfs is a technical non-issue) as before, I'd like the 
Council just to clarify.

Guess I'll have to raise it on the agenda so they have to discuss it again?

Regards,
Steve.

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

[gentoo-dev] Re: Re: Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Steven J Long]

Mike Gilbert wrote:

> On Sun, Apr 22, 2012 at 1:28 AM, Steven J Long wrote:
>> And again, I ask: if it were *not* about running udev without an
>> initramfs, then why would anyone even be discussing the possibility of
>> patching or forking?
>>
> 
> Here is my interpretation: the council voted on the following question:
> 
> <ulm> The question is: "Decide on whether a separate /usr is still a
> supported
>       configuration."
> 
> It did not decide the method that would be used to accomplish this. A
> few council members (Chainsaw mainly) expressed a desire to do it
> without an initramfs, but an official stance on this was not put
> forward.
>
While I agree it would be better if the vote had specified "without an 
initramfs" it seems clear to me that that was what was under discussion, 
since a) Chainsaw was asked to describe the issue and specifically turned 
down an initramfs, and b) udev with an initramfs already supports a separate 
/usr partition, so why would the Council need to vote on it?

It's already supported if you use an initramfs, so there isn't anything to 
discuss, nor vote on as technical policy.

> You are reading into it more that you should.

Well two of the votes specifically mention initramfs:
<Betelgeuse> As long as there is no automated help for people to 
automatically get initramfs I vote yes
<hwoarang> i vote no, because diverting from upstream is not an ideal option
for me

If it were not about supporting users without an initramfs, why would a yes 
vote mean diverging from upstream?

At this point, I'd like the Council to clarify. I really don't see what else 
could have required a vote, and the whole discussion was about not using an 
initramfs, who would maintain any patches needed, and what the potential 
consequences might be.

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Walter Dnes]

On Sun, Apr 22, 2012 at 06:28:08AM +0100, Steven J Long wrote

> <dberkholz> who's going to either "port" udev as necessary, or maintain an 
> old version forever?
> <Chainsaw> I will keep an old version going until the end of time.
> <Chainsaw> dberkholz: My plan is to patch reasonable behaviour back into 
> udev, and going with the upstream releases as long as it is feasible.

  I use busybox's mdev, and it works fine for my simple system.  See
https://wiki.gentoo.org/wiki/Mdev  The busybox web site is
http://busybox.net/ and the maintenance is handled by them.  The mailing
list info is at http://lists.busybox.net/mailman/listinfo/busybox

> To confirm again, that this is about without initramfs:
> <dberkholz> sure i can. maintain old udev-XXX forever, put an elog in new 
> udev that says "if you want separate /usr without initramfs, install old 
> udev, mask new, or whatever"

  systemd and udev are being merged into one tarball.  For the "foreseeable
future", it will still build 2 separate binaries.  What happens down the
road if/when it all becomes one combined binary?

> And again, I ask: if it were *not* about running udev without an
> initramfs, then why would anyone even be discussing the possibility
> of patching or forking?

  Forking/patching udev would be a major undertaking.  Maybe we'd be
better off making add-ons for mdev to provide missing udev functionality.
Note that busybox is intended for embedded systems, and they're not
going to add major additional functionality to the base code.  That's
why I suggest optional add-ons for any additional functionality.

  BTW, how would a non-programmer (at least not C programmer) like me
forward these ideas to the Gentoo Council?

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Zac Medico]

On 04/22/2012 06:25 PM, Walter Dnes wrote:
>   systemd and udev are being merged into one tarball.  For the "foreseeable
> future", it will still build 2 separate binaries.  What happens down the
> road if/when it all becomes one combined binary?

If becomes a problem, then it will be dealt with. There's no sense in
doing anything until it becomes a real problem though. Meanwhile, we can
sit back and relax. :-)

>   Forking/patching udev would be a major undertaking.  Maybe we'd be
> better off making add-ons for mdev to provide missing udev functionality.

Or, just use an initramfs. :-)

>   BTW, how would a non-programmer (at least not C programmer) like me
> forward these ideas to the Gentoo Council?

You'll see an email on this list a week or two before the next council
meeting, and you can reply to that with your idea.
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Walter Dnes]

On Sun, Apr 22, 2012 at 11:04:54PM -0700, Zac Medico wrote
> On 04/22/2012 06:25 PM, Walter Dnes wrote:

> >   BTW, how would a non-programmer (at least not C programmer) like me
> > forward these ideas to the Gentoo Council?
> 
> You'll see an email on this list a week or two before the next council
> meeting, and you can reply to that with your idea.

  Thanks (and also to Fabian).  I'll be watching this list.

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-dev] Council meeting summary for 3 April 2012

[Fabian Groffen]

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

On 22-04-2012 21:25:40 -0400, Walter Dnes wrote:
>   BTW, how would a non-programmer (at least not C programmer) like me
> forward these ideas to the Gentoo Council?

Make sure you post pointers, with preferably a clear question, in reply
to the next call for agenda items (this Tuesday).


-- 
Fabian Groffen
Gentoo on a different level

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

[gentoo-dev] Re: Re: Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Steven J Long]

Walter Dnes wrote:

> Steven J Long wrote
> 
>> <dberkholz> who's going to either "port" udev as necessary, or maintain
>> an old version forever?
>> <Chainsaw> I will keep an old version going until the end of time.
>> <Chainsaw> dberkholz: My plan is to patch reasonable behaviour back into
>> udev, and going with the upstream releases as long as it is feasible.
> 
>   I use busybox's mdev, and it works fine for my simple system.

Does it handle USB and other media hotplug? That's the real killer for 
desktops. (Running scripts in response to events is another issue, and what 
has led to the udev problem.)

> 
>> To confirm again, that this is about without initramfs:
>> <dberkholz> sure i can. maintain old udev-XXX forever, put an elog in new
>> udev that says "if you want separate /usr without initramfs, install old
>> udev, mask new, or whatever"
> 
>   systemd and udev are being merged into one tarball.  For the
>   "foreseeable
> future", it will still build 2 separate binaries.  What happens down the
> road if/when it all becomes one combined binary?
>
Well I've read assertions that it will be possible to build udev without 
systemd for distros and users who want it, and this is supposedly a firm 
commitment into the future. Then again, experience doesn't bode well for 
those kind of commitments.

(It's much easier to introduce coupling between software in the same 
package. GregKH has also mooted a tightly-coupled "core" Linux distro, which 
afaict is the same reasoning as GnomeOS, and /that/ sounds like a 
clusterfsck waiting to happen.)
 
>> And again, I ask: if it were *not* about running udev without an
>> initramfs, then why would anyone even be discussing the possibility
>> of patching or forking?
> 
>   Forking/patching udev would be a major undertaking.

The point I was making was that it couldn't even be an issue, _unless_ one 
were talking about an install without an initramfs, since udev with an 
initramfs supports a split /usr.

(That's required for the usr-bin merge to be useful, since the idea is to 
enable snapshotting of all distribution binaries; after years of rubbishing 
any possible reason admins might have for a split /usr, it's now critical to 
a major 'new' feature of Fedora, and all the traditional benefits are 
selling-points of the "new design".)

As for the effort, so long as you don't need udev to create nodes for 
localmount, you don't need an initramfs with either our patched approach, or 
an earlymounts initscript, and now there's vapier's busybox applet to do the 
mounts for you. None of which require any modification to udev, nor 
maintenance of an initrd and the binaries therein.

Regards,
Steve.
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Greg KH]

On Fri, May 04, 2012 at 03:50:24PM +0100, Steven J Long wrote:
> >> To confirm again, that this is about without initramfs:
> >> <dberkholz> sure i can. maintain old udev-XXX forever, put an elog in new
> >> udev that says "if you want separate /usr without initramfs, install old
> >> udev, mask new, or whatever"
> > 
> >   systemd and udev are being merged into one tarball.  For the
> >   "foreseeable
> > future", it will still build 2 separate binaries.  What happens down the
> > road if/when it all becomes one combined binary?
> >
> Well I've read assertions that it will be possible to build udev without 
> systemd for distros and users who want it, and this is supposedly a firm 
> commitment into the future. Then again, experience doesn't bode well for 
> those kind of commitments.
> 
> (It's much easier to introduce coupling between software in the same 
> package. GregKH has also mooted a tightly-coupled "core" Linux distro, which 
> afaict is the same reasoning as GnomeOS, and /that/ sounds like a 
> clusterfsck waiting to happen.)

"mooted"?

And since when does having a set of tightly coupled base libraries and
systems that work well together somehow turn into "GnomeOS"?  Reaching
like that is just foolish on your part.

greg k-h

[gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Steven J Long]

Greg KH wrote:

> On Fri, May 04, 2012 at 03:50:24PM +0100, Steven J Long wrote:
>> >> To confirm again, that this is about without initramfs:

>> > systemd and udev are being merged into one tarball.  For the
>> > "foreseeable future", it will still build 2 separate binaries.
>> > What happens down the road if/when it all becomes one combined
>> > binary?
<snip>
>> (It's much easier to introduce coupling between software in the same
>> package. GregKH has also mooted a tightly-coupled "core" Linux distro,
>> which afaict is the same reasoning as GnomeOS, and /that/ sounds like a
>> clusterfsck waiting to happen.)
> 
> "mooted"?
>
Yes, in the sense of "raised it as a possibility" or in this case a future 
direction[1] as discussed on debian-dev[2].

I'll assume you're just not familiar with the word 'moot' as a verb; 
originally the adjective meant 'on the agenda' or 'on the table', and 'to 
moot' means to raise an item for discussion. Its modern meaning of 'no 
longer worth discussing' comes from the judiciary: for it to be dismissed, 
it had to be under discussion in the first place, and so usage evolved.

> And since when does having a set of tightly coupled base libraries and
> systems that work well together somehow turn into "GnomeOS"?  Reaching
> like that is just foolish on your part.
> 
When did I say that it's the same thing? I simply said it sounds like "the 
same reasoning." Compare:

"There are a number of folk in the Linux ecosystem pushing for a
small core of tightly coupled components to make the core of a modern
linux distro. The idea is that this 'core distro' can evolve in sync
with the kernel, and generally move fast. This is both good for the
overall platform and very hard to implement for the 'universal'
distros [such as Gentoo or Debian]." [1]

..with:
"The future of GNOME is as a Linux based OS.  It is harmful to pretend
that you are writing the OS core to work on any number of different
kernels, user space subsystem combinations, and core libraries..
Kernels just aren't that interesting.  Linux isn't an OS.  Now it is
our job to try to build one - finally.  Let's do it."[3]

They sound like very similar reasoning to me. You misinterpreted what I 
said, which is one thing: there was no need to be discourteous.

Let me be clear: I don't personally have an issue with udev talking to dbus 
(a requirement for it sounds wrong to me, but that's by-the-by.) It would 
annoy me no end, however, if udev required systemd, since I don't want to 
switch to it. And that is what we were discussing: possible future coupling 
between the two, which is much easier to do when the sources are part of the 
same package.

Everything I need done on a desktop or a laptop in terms of hotplug, acpid 
events and wifi, the current udev has been able to do for years. I'd find it 
odd (read: the design smells) if those use-cases suddenly required new 
external dependencies. AFAIC vertical integration is supposed to mean closer 
downward coupling, typically skipping a layer or two; if it also means 
upward coupling, then the design is flawed ime.

*shrug* What you do with your time, is your business. I'll evaluate any 
coupling that does or doesn't come up as and when, and make my own decisions 
then.

That it's been mooted by you ;) means I'm glad others are doing work on 
busybox and mdev integration into openrc (I've read tonight that mdev works 
fine for simple hotplug like USB sticks) especially the applet to fsck and 
mount /usr early.

OFC you could just assure us that udev will never rely on systemd as a 
design decision. I can understand that systemd might need close integration 
with the underlying udev implementation[PS].

SteveL.

[1] https://plus.google.com/u/0/111049168280159033135/posts/V2t57Efkf1s
[2] http://lists.debian.org/debian-devel/2012/04/msg00649.html
[3] http://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00439.html

[PS] Though it reminds me of packages distributing libraries, and I'd 
question why one git repo can't be used to make two tarballs, with beta 
testing of udev alone by distros like Gentoo or Debian. A separate tarball 
would mean automated tests can be done, which is useful as a basis for 
systemd et al: another benefit of no upward coupling.

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Richard Yao]

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

On 05/07/12 21:40, Steven J Long wrote:
> "The future of GNOME is as a Linux based OS.  It is harmful to pretend
> that you are writing the OS core to work on any number of different
> kernels, user space subsystem combinations, and core libraries..
> Kernels just aren't that interesting.  Linux isn't an OS.  Now it is
> our job to try to build one - finally.  Let's do it."[3]

For what it is worth, the OS core is the kernel, libc and bootloader.
GNOME runs on top of that.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Greg KH]

On Tue, May 08, 2012 at 02:40:41AM +0100, Steven J Long wrote:
> OFC you could just assure us that udev will never rely on systemd as a 
> design decision. I can understand that systemd might need close integration 
> with the underlying udev implementation[PS].

Nope, can't make that assurance at all.

Actually, maybe I can make the opposite assurance, let's see what the
future brings... :)

greg k-h

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Fabio Erculiani]

I foresee a new udev fork then.
If udev is going to end up like avahi is, this is *highly* probable.

With "avahi is ..." I actually mean, one single tarball blob depending
on the whole world and its solar system and galaxy.

Please stop throwing lennartware at people. FailAudio has been enough, thanks.
-- 
Fabio Erculiani

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Greg KH]

On Wed, May 09, 2012 at 08:51:37PM +0200, Fabio Erculiani wrote:
> I foresee a new udev fork then.

Please feel free to do so, the code has been open since the first day I
created it.

Remember, forks are good, there's nothing wrong with them, I strongly
encourage people to do them if they wish to, it benefits everyone
involved.

> If udev is going to end up like avahi is, this is *highly* probable.

That's an odd transition...

> With "avahi is ..." I actually mean, one single tarball blob depending
> on the whole world and its solar system and galaxy.

Hyperbole, how nice :(

> Please stop throwing lennartware at people. FailAudio has been enough, thanks.

The use of these terms is both rude and totally uncalled for.  You
should be ashamed of yourself.

Seriously, that's unacceptable behavior from anyone.

No one forces you to use any of this software if you do not want to.
There are lots of other operating systems out there, feel free to switch
to them if you do not like the way this one is working out, no one is
stopping you.  But for you to disparage someone who has given immense
bodies of work to the community, and you, for free, is horrible behavior
and needs to stop right now.

greg k-h

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Patrick Lauer]

On 05/10/12 06:36, Greg KH wrote:
> On Wed, May 09, 2012 at 08:51:37PM +0200, Fabio Erculiani wrote:
>> I foresee a new udev fork then.
> Please feel free to do so, the code has been open since the first day I
> created it.
>
> Remember, forks are good, there's nothing wrong with them, I strongly
> encourage people to do them if they wish to, it benefits everyone
> involved.
Forks are often unnecessary.

Now instead of working on something useful I get to spend my time
reverting to previous behaviour, just so I can have a working solution
instead of a shiny one.

Are we really doing so well that we can just rewrite everything instead
of maybe, for once, have things boring predictable and bugfree? I mean
... things were going so well. Machines Just Booted Every TIme.

And now - UEFI is glitching all over the place, the GPT-aware
bootloaders have config files with insane complexity and are exquisitely
buggy, and someone thought making the init system exciting would just
make life oh so much better. Result: I can't get more than a blinking
cursor out of some machines without resorting to Dirty Hacks I would
really prefer not to even consider.


Seriously. I don't have time for these games. Stop breaking stuff!
>
>> If udev is going to end up like avahi is, this is *highly* probable.
> That's an odd transition...
Same people involved, same mentality - and we don't want to be standing
on the sides saying "Told you so" again. Gets boring.
>
>> With "avahi is ..." I actually mean, one single tarball blob depending
>> on the whole world and its solar system and galaxy.
> Hyperbole, how nice :(
>
>> Please stop throwing lennartware at people. FailAudio has been enough, thanks.
> The use of these terms is both rude and totally uncalled for.  You
> should be ashamed of yourself.
It's reactive. I've been called stupid, conservative, behind the times,
user of obsolete software that will go the way of the dinosaurs. Why
should we be ashamed of not agreeing with these funny pranksters?
>
> Seriously, that's unacceptable behavior from anyone.
Then make it stop? :)
>
> No one forces you to use any of this software if you do not want to.
Yeah, I can just stop updating. Sounds like a solution to all problems ;)
> There are lots of other operating systems out there, feel free to switch
> to them if you do not like the way this one is working out, no one is
> stopping you.  But for you to disparage someone who has given immense
> bodies of work to the community, and you, for free, is horrible behavior
> and needs to stop right now.
Goes both ways. We're here because of Freedom, in various flavours.
Freedom to copy things around and use for free. Freedom to swap out one
part and use another.
Freedom to break things badly.

So why would I give up my freedom to tinker just because someone else is
writing more code than I do?
And I still have the freedom to complain all day long about undesigned
stuff people try to force on me.

Hey, you even have the freedom to complain about my complaining.

Either way, I hope I can continue using Free Linux for a while and not
be forced to use random things that are silly. I'd have expected you to
support that.

Take care,

Patrick

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Rich Freeman]

On Wed, May 9, 2012 at 9:08 PM, Patrick Lauer <patrick@gentoo.org> wrote:
> On 05/10/12 06:36, Greg KH wrote:
>> On Wed, May 09, 2012 at 08:51:37PM +0200, Fabio Erculiani wrote:
>>> Please stop throwing lennartware at people. FailAudio has been enough, thanks.
>> The use of these terms is both rude and totally uncalled for.  You
>> should be ashamed of yourself.
> It's reactive. I've been called stupid, conservative, behind the times,
> user of obsolete software that will go the way of the dinosaurs. Why
> should we be ashamed of not agreeing with these funny pranksters?

Look, I have pretty mixed feelings about all the vertical integration.
 However, let's at least do each other the professional courtesy of
not resorting to name-calling.  We're allowed to disagree, and that's
OK.  By all means voice your opinion.  However, let's talk about the
issues, and not the people advocating them.

This is just polite behavior.  It is also the rules for posting on
this list, especially if you hold a g.o address.

> So why would I give up my freedom to tinker just because someone else is
> writing more code than I do?

I understand your frustration.  Really, I do - I often find myself
sharing it.  However, in the end people working on FOSS are basically
free to do what they want, and everybody is free to use or support
what they want.  I don't like the fact that most people contributing
to Android tend/aspire to be associated with the commercial market for
smartphones, and as a result they tend to embrace pro-developer /
anti-consumer solutions (like not allowing easy blocking of ads, or
randomizing calls to read the IMEI, etc).  However, the market is what
it is.  The only thing that is really any different today is that
companies are at least releasing the source for the stuff they do - in
the past they'd have just closed it all off so that there wouldn't
even be the option of forking.  If I want to I can at least find the
API call to read my IMEI and tamper with it.

I think part of the community frustration is the increasing level of
commercial support around Linux.  That has given us much more robust
stuff to play with, but it also has resulted in a loss of control and
change in general atmosphere.  In the world of 1999 Linux market share
took a back seat to hackability.  In the world of the Canonicals,
market share matters a great deal, and appealing to open source
contributors matters a lot less.

Rich

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Fabio Erculiani]

I think expressing my own opinion about Lennart-made software is my
right, after all.
Firstly, it's almost impossible nowadays to avoid including avahi,
systemd and pulseaudio into a desktop distro so, there is no real
choice. This issue became a sensible matter for those users who for
instance, wanted to have a silly mp3 player working without going
through the PA nonsense, really missing the old
ALSA-oh-it-was-always-working days.
If you want to bring complexity but you end up not being able to
handle it, then you're not a really good engineer, IMHO.

Having said that, I also wonder where's the lovely modularity the
various *nix platforms had. If this is the actual direction of Linux
Foundation, Redhat and Canonical, I am worried that Linux would end up
being an OSX-wannabe.

Of course, I am not only bringing my personal opinion here, but the
one of the majority of users I've been talking with.
I am not against changes, I am actually in favor of them, but only
when they really make sense and solve problems, which it doesn't seem
the case lately.

I didn't want to offend anyone, but just having fun (sigh) of IMHO bad
design decisions.
-- 
Fabio Erculiani

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Olivier Crête]

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

Hi,

On Thu, 2012-05-10 at 06:34 +0200, Fabio Erculiani wrote:
> I think expressing my own opinion about Lennart-made software is my
> right, after all.

I would express my opinion about Fabio made software, but I've never
heard of any.

> Firstly, it's almost impossible nowadays to avoid including avahi,
> systemd and pulseaudio into a desktop distro so, there is no real
> choice. This issue became a sensible matter for those users who for
> instance, wanted to have a silly mp3 player working without going
> through the PA nonsense, really missing the old
> ALSA-oh-it-was-always-working days.

Maybe the reason every sensible distribution uses Avahi, Pulseaudio, etc
is because they are better than other solutions out there? 
Do you think is a fast conspiracy to make your life suck? I believe
engineers in every distribution are looking at what's available and
picking what they think is the best solution, and it turns out Lennart
is pretty damn good at making useful software.

Was alsa always working? I remember spending hours trying to figure out
the right control in alsamixer and fighting with alsa's arcane
configuration languages (it has 3 different ones). And how do you deal
with modern technologies like Bluetooth audio without Pulseaudio
exactly?

> Of course, I am not only bringing my personal opinion here, but the
> one of the majority of users I've been talking with.

I think you only hear from users who like to complain, others are just
happy that everything works for them thanks to Pulseaudio, systemd, etc.
If you think that Lennart does not solve problems, maybe it's because
you don't even understand what the problems were? For example, I
encourage you to read about how the dynamic latency in PA allows for
lower power usage or how modern audio hardware is designed to use a
userspace sound server, etc.

-- 
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] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Luca Barbato]

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

On 10/05/12 09:54, Olivier Crête wrote:
> Hi,
> 
> On Thu, 2012-05-10 at 06:34 +0200, Fabio Erculiani wrote:
>> I think expressing my own opinion about Lennart-made software is my
>> right, after all.
> 
> I would express my opinion about Fabio made software, but I've never
> heard of any.

Not his fault, he wrote plenty of interesting stuff though.
Fabio attitude still isn't that horrible regarding feedbacks, Rigo got
created more or less because the previous UI got a sound "it sucks".

His quite short and a bit extreme reaction probably is due having lots
of unhappy user complaining at him for some issue with avahi (hangs in
bonjour now and then) and pulse (skype freezing randomly anyone).

>> Firstly, it's almost impossible nowadays to avoid including avahi,
>> systemd and pulseaudio into a desktop distro so, there is no real
>> choice. This issue became a sensible matter for those users who for
>> instance, wanted to have a silly mp3 player working without going
>> through the PA nonsense, really missing the old
>> ALSA-oh-it-was-always-working days.
> 
> Maybe the reason every sensible distribution uses Avahi, Pulseaudio, etc
> is because they are better than other solutions out there?

If there are solutions somebody will use them, if people are aware of
them and doesn't get too hard. I did like the concept about pulse and
even wrote support for pulse in a certain fringe software you might use.

The pulse concept is quite good, some corner cases and some design
issues make it annoying at time. The fact some of them are consider
"features" or "design" obviously make the whole thing less nice.

> Do you think is a fast conspiracy to make your life suck? I believe
> engineers in every distribution are looking at what's available and
> picking what they think is the best solution, and it turns out Lennart
> is pretty damn good at making useful software.

No, he is pretty damn good in getting interesting concepts, having
people sold on them and then you need 5 years to have the audio seldom
crash, bonjour seldom kill pidgin and so on.

Till it is some minor annoyance that is comparable to not having the
feature or the same to other feature provider (dmix isn't exactly great
as well) you surely can live with it.

> Was alsa always working? I remember spending hours trying to figure out
> the right control in alsamixer and fighting with alsa's arcane
> configuration languages (it has 3 different ones). And how do you deal
> with modern technologies like Bluetooth audio without Pulseaudio
> exactly?

I used to do that and it was working sort of fine even if it was
crashing in dbus...

>> Of course, I am not only bringing my personal opinion here, but the
>> one of the majority of users I've been talking with.
> 
> I think you only hear from users who like to complain, others are just
> happy that everything works for them thanks to Pulseaudio, systemd, etc.

As said, if they are minor annoyances most people would just cope with them.

A - "Skype hangs because pulse? oh well, let's reload it no biggie"
B - "AAaargh I missed the important confcall because #%$#@ skype hang
due pulse, I hate YOU Lennart!"

A and B are different reactions from the same small issue.

> If you think that Lennart does not solve problems, maybe it's because
> you don't even understand what the problems were? For example, I
> encourage you to read about how the dynamic latency in PA allows for
> lower power usage or how modern audio hardware is designed to use a
> userspace sound server, etc.

I recall when the whole thing got initially reported and it was "pulse
eats my batter" and if you consider that the stock pulse on ubuntu
oneric eats about a *least* 10% cpu on imx51 due funny resampling loops
you know something needed some more attention. I guess I'm digressing.

The main issue is that udev best replacement so far is mdev plus some
additional helpers to let applications using libudev or the dbus
interface still get compatibility.

So having udev merge with systemd is quite in the shovel meet throat side.

People that had and have some bad experience with pulse and avahi or
directly with Lennart stubborn and abrasive personality can be *quite*
concerned about this "vertical" and linux-only approach.

If you consider that in 2 weeks the whole thing went from "udev moves to
systemd since is easier for us, but not be concerned udev can build
stand alone" to "udev stand alone is unsupported" you can see that isn't
that simple and lots of people might start to get angry.

lu

- -- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

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

iEYEARECAAYFAk+xU3sACgkQ6Ex4woTpDjTNewCfU5cahmNPbgKQJt/2GkbVBh4o
F1gAnjheSaIVRF55g1//9wu5dFe8ga3w
=FlU7
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Alec Warner]

On Thu, May 10, 2012 at 6:34 AM, Fabio Erculiani <lxnay@gentoo.org> wrote:
> I think expressing my own opinion about Lennart-made software is my
> right, after all.
> Firstly, it's almost impossible nowadays to avoid including avahi,
> systemd and pulseaudio into a desktop distro so, there is no real
> choice. This issue became a sensible matter for those users who for
> instance, wanted to have a silly mp3 player working without going
> through the PA nonsense, really missing the old
> ALSA-oh-it-was-always-working days.

Er, the source is open, so choice is always there. What I think your
complaint is the fact that it used to be easy to do those things
(because upstream supported those options and USE flags exposed them
to you) and now upstream is not supporting those options and there is
no easy way to remove the dependencies without doing a bunch of work.

> If you want to bring complexity but you end up not being able to
> handle it, then you're not a really good engineer, IMHO.

I don't think anyone expects complexity to come bug-free. Cathedral
and the Bazaar? Release Early and Release Often? I expect the software
to reach a stable state in a reasonable amount of time given the
complexity involved.

>
> Having said that, I also wonder where's the lovely modularity the
> various *nix platforms had. If this is the actual direction of Linux
> Foundation, Redhat and Canonical, I am worried that Linux would end up
> being an OSX-wannabe.

The problem as I understand it is that you want other people to write
software that meets your needs and it turns out that the world doesn't
always work that way.

You can fork the software you hate (using versions before you hated
it) or you can write your own software (like mdev + busybox) to
replace the hated components. Both of those things are actually
somewhat useful. Complaining about how some random people on the
internet don't write software that you find palatable is just silly.

> Of course, I am not only bringing my personal opinion here, but the
> one of the majority of users I've been talking with.
> I am not against changes, I am actually in favor of them, but only
> when they really make sense and solve problems, which it doesn't seem
> the case lately.
>
> I didn't want to offend anyone, but just having fun (sigh) of IMHO bad
> design decisions.
> --
> Fabio Erculiani
>

[gentoo-dev] Re: Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Steven J Long]

Alec Warner wrote:

> Fabio Erculiani <lxnay@gentoo.org> wrote:
>> I think expressing my own opinion about Lennart-made software is my
>> right, after all.
>> Firstly, it's almost impossible nowadays to avoid including avahi,
>> systemd and pulseaudio into a desktop distro so, there is no real
>> choice. This issue became a sensible matter for those users who for
>> instance, wanted to have a silly mp3 player working without going
>> through the PA nonsense, really missing the old
>> ALSA-oh-it-was-always-working days.
> 
> Er, the source is open, so choice is always there. What I think your
> complaint is the fact that it used to be easy to do those things
> (because upstream supported those options and USE flags exposed them
> to you) and now upstream is not supporting those options and there is
> no easy way to remove the dependencies without doing a bunch of work.
>
I think it's more a matter of process. These changes force major userspace 
changes, which since they are not a matter of ABI export, don't really 
concern kernel devs (after all, they design for userspace to do crazy stuff, 
or their OS is not robust: beyond ABI stability, the contract they fulfil, 
in the main they don't really care what happens there.)

However the changes are forced on admins and users, unless we take on a 
development effort which means we're no longer just admins or users. And 
yeah, people are clearly looking at doing that with mdev, though we'd rather 
not have to be forced into that.

>> If you want to bring complexity but you end up not being able to
>> handle it, then you're not a really good engineer, IMHO.
> 
> I don't think anyone expects complexity to come bug-free. Cathedral
> and the Bazaar? Release Early and Release Often? I expect the software
> to reach a stable state in a reasonable amount of time given the
> complexity involved.
>
The way to handle complexity is with small, modular components that are 
loosely-coupled and cohesive. AKA "Do one thing, and do it well." Like udev 
has been doing for quite a while.
 
>>
>> Having said that, I also wonder where's the lovely modularity the
>> various *nix platforms had. If this is the actual direction of Linux
>> Foundation, Redhat and Canonical, I am worried that Linux would end up
>> being an OSX-wannabe.
> 
> The problem as I understand it is that you want other people to write
> software that meets your needs and it turns out that the world doesn't
> always work that way.
> 
> You can fork the software you hate (using versions before you hated
> it) or you can write your own software (like mdev + busybox) to
> replace the hated components. Both of those things are actually
> somewhat useful. Complaining about how some random people on the
> internet don't write software that you find palatable is just silly.
>
It's not about that: the point is that massive changes are being pushed 
through, and the people who actually have to implement them in the real-
world haven't been consulted. When they are, after their concerns about 
administration (you know, their jobs) are dismissed and they're asked for 
technical reasons, they draw attention to Unix principles, simply because 
they have been proven over decades to be the best basis for software-
engineering.

And please: "random people on the internet"? That's not how I'd describe 
upstream udev or kernel maintainers. Or is this your "it's the developer's 
playground" philosophy again?

Simply put, there is no space in kernel mailing-lists, nor in upstream udev 
et al, to have this discussion. It affects Gentoo users most, because we are 
far more likely to run using custom-compiled kernels with base system 
modules like motherboard disk-controllers built-in, and to have setup eg 
/usr on LVM in accordance with docs, and since we use a rolling-release we 
haven't needed to change what wasn't broken.

Nor do many of us think we've heard any benefit to outweigh the 
disadvantages. For instance, we've been told several times that a) an 
initramfs is the new root, in that we don't need rescue tools on an easy to 
mount root anymore, our initramfs will be a souped-up rescue-shell; and b) 
that an initramfs is easy to set up and maintain, and should typically only 
be a few hundred kilobytes (so it's not going to bloat the boot process.)

Everything I've seen of people's configs in forum posts about setting up 
initramfs, and heard of the process, makes me think it's going to be a 
custom design per-Gentoo user, and tweaking what's in there is going to be 
part of standard setup and ongoing maintenance. Forgive me for assessing 
that as a regression in usability.

Ultimately of course, udev maintainers will do what they want. That's fine, 
and I'll shut up about the whole thing as my concerns are on the record: 
just so long as no-one pretends they've justified the breaches of basic 
design principles.

Regards,
Steve.
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Chí-Thanh Christopher Nguyễn]

Greg KH schrieb:
> On Wed, May 09, 2012 at 08:51:37PM +0200, Fabio Erculiani wrote:
>> Please stop throwing lennartware at people. FailAudio has been enough, thanks.
> The use of these terms is both rude and totally uncalled for.  You
> should be ashamed of yourself.
>
> Seriously, that's unacceptable behavior from anyone.

You mean as unacceptable as calling C++ proponents "full of
bullshit"[1], developers of another operating system "masturbating
monkeys"[2] and security researchers as "people wanking around with
their opinions"[3]?

> No one forces you to use any of this software if you do not want to.
> There are lots of other operating systems out there, feel free to switch
> to them if you do not like the way this one is working out, no one is
> stopping you.  But for you to disparage someone who has given immense
> bodies of work to the community, and you, for free, is horrible behavior
> and needs to stop right now.

Insulting other people is indeed not nice. A borderline statement would
be the "card-carrying member of the Poettering gang" which was coined by
a well-known kernel developer who shall remain unnamed here.
But using harsh words to describe other people's software? C'mon.


Best regards,
Chí-Thanh Christopher Nguyễn


[1] http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918
[2] https://lkml.org/lkml/2008/7/15/296
[3] https://lkml.org/lkml/2007/10/1/217

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Zac Medico]

On 05/10/2012 04:44 AM, Chí-Thanh Christopher Nguyễn wrote:
> Greg KH schrieb:
>> No one forces you to use any of this software if you do not want to.
>> There are lots of other operating systems out there, feel free to switch
>> to them if you do not like the way this one is working out, no one is
>> stopping you.  But for you to disparage someone who has given immense
>> bodies of work to the community, and you, for free, is horrible behavior
>> and needs to stop right now.
> 
> Insulting other people is indeed not nice. A borderline statement would
> be the "card-carrying member of the Poettering gang" which was coined by
> a well-known kernel developer who shall remain unnamed here.
> But using harsh words to describe other people's software? C'mon.

Specific criticism's can be be constructive, but calling PulseAudio a
name like FailAudio certainly isn't. I'd enjoy reading this thread a lot
more if it contained more discussion about solutions, and less of what
seems like whining due to self-pity.
-- 
Thanks,
Zac

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Greg KH]

On Thu, May 10, 2012 at 01:44:53PM +0200, Chí-Thanh Christopher Nguyễn wrote:
> Greg KH schrieb:
> > On Wed, May 09, 2012 at 08:51:37PM +0200, Fabio Erculiani wrote:
> >> Please stop throwing lennartware at people. FailAudio has been enough, thanks.
> > The use of these terms is both rude and totally uncalled for.  You
> > should be ashamed of yourself.
> >
> > Seriously, that's unacceptable behavior from anyone.
> 
> You mean as unacceptable as calling C++ proponents "full of
> bullshit"[1], developers of another operating system "masturbating
> monkeys"[2] and security researchers as "people wanking around with
> their opinions"[3]?

Did I say any of that?

I have no idea why you are comparing me to anyone else.  Who ever said
that those links are acceptable behavior either?  I never did.

greg k-h

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[David Leverton]

Greg KH wrote:
> No one forces you to use any of this software if you do not want to.
> There are lots of other operating systems out there, feel free to switch
> to them if you do not like the way this one is working out, no one is
> stopping you.

Or alternatively, the people who hate Unix could move to some other OS 
that suites them better, rather than trying to destroy what everyone 
else is perfectly happy with.

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Zac Medico]

On 05/10/2012 11:57 AM, David Leverton wrote:
> Greg KH wrote:
>> No one forces you to use any of this software if you do not want to.
>> There are lots of other operating systems out there, feel free to switch
>> to them if you do not like the way this one is working out, no one is
>> stopping you.
> 
> Or alternatively, the people who hate Unix could move to some other OS
> that suites them better, rather than trying to destroy what everyone
> else is perfectly happy with.

Isn't it presumptuous to say that they hate Unix? Maybe their vision of
how they'd like Unix to be is just different from yours?
-- 
Thanks,
Zac

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[David Leverton]

Zac Medico wrote:
> Isn't it presumptuous to say that they hate Unix? Maybe their vision of
> how they'd like Unix to be is just different from yours?

If "how they'd like Unix to be" goes so blatantly against its 
fundamental design principles then I think it's reasonable to say that 
they hate it.

[gentoo-dev] Re: Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Duncan]

David Leverton posted on Thu, 10 May 2012 19:57:30 +0100 as excerpted:

> Greg KH wrote:
>> No one forces you to use any of this software if you do not want to.
>> There are lots of other operating systems out there, feel free to
>> switch to them if you do not like the way this one is working out, no
>> one is stopping you.
> 
> Or alternatively, the people who hate Unix could move to some other OS
> that suites them better, rather than trying to destroy what everyone
> else is perfectly happy with.

I see the "hate Unix" angle tho I'd call it a bit strong...

But trying to destroy what everyone else is perfectly happy with??

How is simply writing some software, which after all is FLOSS and which 
nobody is forced to use, "destroying"?  They're taking their own software 
where their vision points it, no more, no less.  I don't really agree 
with where it's going either, but that's part of the very freedom of the 
FLOSS community we're all a part of.  Others can fork the software or 
provide less integrated substitutes, if desired.  Meanwhile, if it's what 
other coders choose to build on, well, they're free to do that too.  It 
doesn't mean I have to use their software!

FWIW, that's one reason I'm no longer using kmail, for instance.  When 
kmail akonadified, I tried it, then switched to claws-mail. It's ALSO one 
reason I'm using gentoo, I get to choose whether I build kde with akonadi 
and semantic-desktop support, or not.  And I choose not.  I see the kdepim 
folks vision, and they're free to pursue it, but their path and my path 
simply diverged, that's all.  Kde runs SO much nicer without the weight 
of semantic-desktop dragging it down.

And if the systemd and udev path fully merge, I'll have a choice at that 
point.  If systemd looks mature and stable enough at that point to be 
used on my system, I'll probably try it.  I might like it. =:^)  Or, like 
akonadified kmail, I may find it a rube goldberg of a system that I'd 
rather stay away from.  Given history, I'm sure there will be alternate 
solutions available, tho it'll no doubt take some serious work and 
adaptation on my part to switch.

-- 
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] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 05/09/2012 07:51 PM, Fabio Erculiani wrote:
> I foresee a new udev fork then. If udev is going to end up like
> avahi is, this is *highly* probable.
> 
> With "avahi is ..." I actually mean, one single tarball blob
> depending on the whole world and its solar system and galaxy.
> 
> Please stop throwing lennartware at people. FailAudio has been
> enough, thanks.

I sincerely hope someone has "hacked" into your account and he is
writing on your behalf. This sort of trash talk does not belong to a
public Gentoo mailing list. Make a constructive criticism if you
really need to rant about software that nobody forces you to use.

- -- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBCgAGBQJPrB0WAAoJEPqDWhW0r/LCFGYQAJiKzJ6RUYrkCswRBeWFk9Vn
6kOybbC9nn8LgQuoSjlNXWQ2jm5qqYEWhwzmFJMaeYJ7vpaVNL9nDTslloiXiw46
2dEjBUyXzmx90VIAvAvos3lec2C45vHXUYwjCp8VfwIfL+syPfb0wIXIn+RETAHg
2c4vyPRvv145zCPRkdF/b0GV4ai6JozRTrUOn2dobEs2SaqadqY4cw5uj1P47Msd
Jezdz4MaPUPf16q0CoK6yi4U0jkzEqGtJbinHT4ib9PMhYX8WXjJtLloaBiQk01l
bKNJWOAMIEpWK6dD2rko5pY4igS9ccbFCLlEDnELQBSHXDGAmarmGRlN6C/qVasY
019n3fSUsLt+kMeH2WgfmmXViyBgPeQxMY0E4HVkV+ztwNp3by8gG3jtuQeX+Kij
WaECR/2/DwUTU+kLLkkEa2FZSrg8xwG3Ty5SpCAVQWcJIn3L1tziD58kt1DtpJjs
jt0bV1eT2JnxL4v7GopxUI55n4bmqqzRP7SebkK4B7AOlae1fxjukqpNC6s6oTgc
CBoWiJ7DkRbcTk+ww+MF+xUCmYrqPFlf8aQ8+j16LogaTCeV09QIhAqUKkcQB8Lx
k6gGD6H5elPsYDm1gP/wBe1WEe6zLXDLd6LFiEYKHjyiznGDs1BAEk0oJMbob5I3
HbAYiBP8P7D7FBosO7oj
=INQn
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Ciaran McCreesh]

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

On Thu, 10 May 2012 20:55:02 +0100
Markos Chandras <hwoarang@gentoo.org> wrote:
> Make a constructive criticism if you really need to rant about
> software that nobody forces you to use.

Not that I agree with anything Fabio has ever said, but I believe the
issue under discussion here is that tight coupling and vertical
integration means we are in effect forced to use rather a lot of
software that we would prefer not to.

- -- 
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAk+sHi8ACgkQ96zL6DUtXhGZoQCeN5o15CIzO0xJTCNkOW9EhPoc
rjgAoL5WoPQpcxRhceifxFkfecZg5YqK
=+nyf
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Michał Górny]

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

On Thu, 10 May 2012 20:59:40 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Thu, 10 May 2012 20:55:02 +0100
> Markos Chandras <hwoarang@gentoo.org> wrote:
> > Make a constructive criticism if you really need to rant about
> > software that nobody forces you to use.
> 
> Not that I agree with anything Fabio has ever said, but I believe the
> issue under discussion here is that tight coupling and vertical
> integration means we are in effect forced to use rather a lot of
> software that we would prefer not to.

No, I don't think you are forced to use anything. As was proven before,
there are always alternatives.


-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Ciaran McCreesh]

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

On Thu, 10 May 2012 22:13:33 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> > On Thu, 10 May 2012 20:55:02 +0100
> > Markos Chandras <hwoarang@gentoo.org> wrote:
> > > Make a constructive criticism if you really need to rant about
> > > software that nobody forces you to use.
> > 
> > Not that I agree with anything Fabio has ever said, but I believe
> > the issue under discussion here is that tight coupling and vertical
> > integration means we are in effect forced to use rather a lot of
> > software that we would prefer not to.
> 
> No, I don't think you are forced to use anything. As was proven
> before, there are always alternatives.

That's a somewhat disingenuous claim when the alternatives are moving
steadily towards "don't use Linux at all" or "use the full GnomeOS
stack".

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Michał Górny]

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

On Thu, 10 May 2012 21:14:33 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Thu, 10 May 2012 22:13:33 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> > > On Thu, 10 May 2012 20:55:02 +0100
> > > Markos Chandras <hwoarang@gentoo.org> wrote:
> > > > Make a constructive criticism if you really need to rant about
> > > > software that nobody forces you to use.
> > > 
> > > Not that I agree with anything Fabio has ever said, but I believe
> > > the issue under discussion here is that tight coupling and
> > > vertical integration means we are in effect forced to use rather
> > > a lot of software that we would prefer not to.
> > 
> > No, I don't think you are forced to use anything. As was proven
> > before, there are always alternatives.
> 
> That's a somewhat disingenuous claim when the alternatives are moving
> steadily towards "don't use Linux at all" or "use the full GnomeOS
> stack".

Then go rant upstream about it. Or another upstream. Or do something
useful yourself.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Fabio Erculiani]

On Thu, May 10, 2012 at 9:55 PM, Markos Chandras <hwoarang@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
>
> I sincerely hope someone has "hacked" into your account and he is
> writing on your behalf. This sort of trash talk does not belong to a
> public Gentoo mailing list. Make a constructive criticism if you
> really need to rant about software that nobody forces you to use.

No, this was really me. Forgive me for the rant, but the problem here
is real and no, the alternative would be either giving up with the
Linux stack or living with unreliable, overengineered software. I
don't see any other viable alternative.

Just answer my question, what is going to happen the day udev will
require systemd in order to work properly?

On a side note, I find it quite odd to be accused of trash talking by
Linux Kernel people.

>
> - --
> Regards,
> Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
>
> iQIcBAEBCgAGBQJPrB0WAAoJEPqDWhW0r/LCFGYQAJiKzJ6RUYrkCswRBeWFk9Vn
> 6kOybbC9nn8LgQuoSjlNXWQ2jm5qqYEWhwzmFJMaeYJ7vpaVNL9nDTslloiXiw46
> 2dEjBUyXzmx90VIAvAvos3lec2C45vHXUYwjCp8VfwIfL+syPfb0wIXIn+RETAHg
> 2c4vyPRvv145zCPRkdF/b0GV4ai6JozRTrUOn2dobEs2SaqadqY4cw5uj1P47Msd
> Jezdz4MaPUPf16q0CoK6yi4U0jkzEqGtJbinHT4ib9PMhYX8WXjJtLloaBiQk01l
> bKNJWOAMIEpWK6dD2rko5pY4igS9ccbFCLlEDnELQBSHXDGAmarmGRlN6C/qVasY
> 019n3fSUsLt+kMeH2WgfmmXViyBgPeQxMY0E4HVkV+ztwNp3by8gG3jtuQeX+Kij
> WaECR/2/DwUTU+kLLkkEa2FZSrg8xwG3Ty5SpCAVQWcJIn3L1tziD58kt1DtpJjs
> jt0bV1eT2JnxL4v7GopxUI55n4bmqqzRP7SebkK4B7AOlae1fxjukqpNC6s6oTgc
> CBoWiJ7DkRbcTk+ww+MF+xUCmYrqPFlf8aQ8+j16LogaTCeV09QIhAqUKkcQB8Lx
> k6gGD6H5elPsYDm1gP/wBe1WEe6zLXDLd6LFiEYKHjyiznGDs1BAEk0oJMbob5I3
> HbAYiBP8P7D7FBosO7oj
> =INQn
> -----END PGP SIGNATURE-----
>



-- 
Fabio Erculiani

[gentoo-dev] Re: Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Duncan]

Fabio Erculiani posted on Thu, 10 May 2012 22:48:29 +0200 as excerpted:

> On a side note, I find it quite odd to be accused of trash talking by
> Linux Kernel people.

hwoarang is a kernel person?

If you note, gregkh didn't post that.  I can't agree with udev/systemd 
integration, but it's worth noting that gregkh has for the most part 
stayed out of that debate, and simply stated where he sees udev going, as 
an upstream person who thus speaks with authority on the subject.

It may very well be that a fork is thus required.  I guess we wait and 
see.  But I don't see the kde folks being willingly subsumed into a 
gnomeos black hole, and time and again, floss history has demonstrated 
that when there's an immediate need, forks do occur.  Both gnome and kde 
have their forks in recent history, xorg is a fork, there's the glibc and 
gcc history, etc.  If integration gets too close, a fork /will/ happen.

But that history is available to everyone and the wise will take heed.  
Meanwhile, for the moment at least, upstream udev and systemd have both 
taken pains to state that while they're going to ship in a unified 
tarball, at least for now, udev will remain buildable on its own, 
SPECIFICALLY to support folks not ready to go systemd just yet.  So 
there's still hope.

And 3-5 years is an eternity in an ecosystem such as the FLOSS world, 
evolving at the speed of the net!  Looking back from there, it's quite 
possible this debate will look petty and short-sighted, regardless of how 
things ultimately turn out.

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

[gentoo-dev] Re: Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Duncan]

Duncan posted on Fri, 11 May 2012 00:59:22 +0000 as excerpted:

> Fabio Erculiani posted on Thu, 10 May 2012 22:48:29 +0200 as excerpted:
> 
>> On a side note, I find it quite odd to be accused of trash talking by
>> Linux Kernel people.
> 
> hwoarang is a kernel person?

FWIW, I see the gregkh post you were referring to, now.  Odd indeed, tho 
he just said rude, not trash talk.

FWIW2, I'd have probably included a "IME" (in my experience) disclaimer 
to that failaudio, tho I don't disagree with that label.  Toning down may 
be worthwhile for all sides, tho.  This isn't lkml and I don't think most 
would want it to be.

-- 
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: Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Walter Dnes]

On Fri, May 11, 2012 at 12:59:22AM +0000, Duncan wrote

> It may very well be that a fork is thus required.  I guess we wait and 
> see.  But I don't see the kde folks being willingly subsumed into a 
> gnomeos black hole, and time and again, floss history has demonstrated 
> that when there's an immediate need, forks do occur.  Both gnome and kde 
> have their forks in recent history, xorg is a fork, there's the glibc and 
> gcc history, etc.  If integration gets too close, a fork /will/ happen.

  There already is a lightweight udev implementation ("mdev") included
in busybox.  Given busybox's philisophy and goals, we can be certain
that mdev will remain lightweight.  I'm not a programmer or developer,
but I was annoyed enough to start what became
https://wiki.gentoo.org/wiki/Mdev  BTW, there is a sort of "udev rules"
equivalant.  See http://git.busybox.net/busybox/plain/docs/mdev.txt

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Richard Yao]

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

On 05/09/2012 06:36 PM, Greg KH wrote:
> On Wed, May 09, 2012 at 08:51:37PM +0200, Fabio Erculiani wrote:
>> I foresee a new udev fork then.
> 
> Please feel free to do so, the code has been open since the first day I
> created it.
> 
> Remember, forks are good, there's nothing wrong with them, I strongly
> encourage people to do them if they wish to, it benefits everyone
> involved.
> 
>> If udev is going to end up like avahi is, this is *highly* probable.
> 
> That's an odd transition...
> 
>> With "avahi is ..." I actually mean, one single tarball blob depending
>> on the whole world and its solar system and galaxy.
> 
> Hyperbole, how nice :(
> 
>> Please stop throwing lennartware at people. FailAudio has been enough, thanks.
> 
> The use of these terms is both rude and totally uncalled for.  You
> should be ashamed of yourself.
> 
> Seriously, that's unacceptable behavior from anyone.
> 
> No one forces you to use any of this software if you do not want to.
> There are lots of other operating systems out there, feel free to switch
> to them if you do not like the way this one is working out, no one is
> stopping you.  But for you to disparage someone who has given immense
> bodies of work to the community, and you, for free, is horrible behavior
> and needs to stop right now.
> 
> greg k-h
> 

Greg, would you clarify what you meant by this?

Your recent comments suggest to me that you did not mean what I thought
you meant.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Greg KH]

On Sun, Nov 18, 2012 at 02:54:38AM -0500, Richard Yao wrote:
> On 05/09/2012 06:36 PM, Greg KH wrote:
> > On Wed, May 09, 2012 at 08:51:37PM +0200, Fabio Erculiani wrote:
> >> I foresee a new udev fork then.
> > 
> > Please feel free to do so, the code has been open since the first day I
> > created it.
> > 
> > Remember, forks are good, there's nothing wrong with them, I strongly
> > encourage people to do them if they wish to, it benefits everyone
> > involved.
> > 
> >> If udev is going to end up like avahi is, this is *highly* probable.
> > 
> > That's an odd transition...
> > 
> >> With "avahi is ..." I actually mean, one single tarball blob depending
> >> on the whole world and its solar system and galaxy.
> > 
> > Hyperbole, how nice :(
> > 
> >> Please stop throwing lennartware at people. FailAudio has been enough, thanks.
> > 
> > The use of these terms is both rude and totally uncalled for.  You
> > should be ashamed of yourself.
> > 
> > Seriously, that's unacceptable behavior from anyone.
> > 
> > No one forces you to use any of this software if you do not want to.
> > There are lots of other operating systems out there, feel free to switch
> > to them if you do not like the way this one is working out, no one is
> > stopping you.  But for you to disparage someone who has given immense
> > bodies of work to the community, and you, for free, is horrible behavior
> > and needs to stop right now.
> > 
> > greg k-h
> > 
> 
> Greg, would you clarify what you meant by this?

Meant by what part of the above response?  Written 6 months ago?

> Your recent comments suggest to me that you did not mean what I thought
> you meant.

What did you think I meant about what?

Again, I have no objection to people forking projects, it's great, and
fun to watch happen.  Fork away on your own site, with whom ever you
want to.

But if this fork is now the "official Gentoo fork", owned by the Gentoo
Foundation, and it's the way forward that Gentoo the distro is going to
take with regards to how the boot process works on the system, then I
have something to say about it, as it affects me, a Gentoo developer.

And that is how this thread started, I wanted to know what was the
resolution of the council meeting with the very unclear and vague
meeting minutes.  I have yet to get that answer, which is troubling.

thanks,

greg k-h

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Richard Yao]

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

On 11/18/2012 03:08 AM, Greg KH wrote:
> On Sun, Nov 18, 2012 at 02:54:38AM -0500, Richard Yao wrote:
>> On 05/09/2012 06:36 PM, Greg KH wrote:
>>> On Wed, May 09, 2012 at 08:51:37PM +0200, Fabio Erculiani wrote:
>>>> I foresee a new udev fork then.
>>>
>>> Please feel free to do so, the code has been open since the first day I
>>> created it.
>>>
>>> Remember, forks are good, there's nothing wrong with them, I strongly
>>> encourage people to do them if they wish to, it benefits everyone
>>> involved.
>>>
>>>> If udev is going to end up like avahi is, this is *highly* probable.
>>>
>>> That's an odd transition...
>>>
>>>> With "avahi is ..." I actually mean, one single tarball blob depending
>>>> on the whole world and its solar system and galaxy.
>>>
>>> Hyperbole, how nice :(
>>>
>>>> Please stop throwing lennartware at people. FailAudio has been enough, thanks.
>>>
>>> The use of these terms is both rude and totally uncalled for.  You
>>> should be ashamed of yourself.
>>>
>>> Seriously, that's unacceptable behavior from anyone.
>>>
>>> No one forces you to use any of this software if you do not want to.
>>> There are lots of other operating systems out there, feel free to switch
>>> to them if you do not like the way this one is working out, no one is
>>> stopping you.  But for you to disparage someone who has given immense
>>> bodies of work to the community, and you, for free, is horrible behavior
>>> and needs to stop right now.
>>>
>>> greg k-h
>>>
>>
>> Greg, would you clarify what you meant by this?
> 
> Meant by what part of the above response?  Written 6 months ago?
> 
>> Your recent comments suggest to me that you did not mean what I thought
>> you meant.
> 
> What did you think I meant about what?
> 
> Again, I have no objection to people forking projects, it's great, and
> fun to watch happen.  Fork away on your own site, with whom ever you
> want to.
> 
> But if this fork is now the "official Gentoo fork", owned by the Gentoo
> Foundation, and it's the way forward that Gentoo the distro is going to
> take with regards to how the boot process works on the system, then I
> have something to say about it, as it affects me, a Gentoo developer.
> 
> And that is how this thread started, I wanted to know what was the
> resolution of the council meeting with the very unclear and vague
> meeting minutes.  I have yet to get that answer, which is troubling.
> 
> thanks,
> 
> greg k-h

You are the one claiming that this is our official fork. None of us are.

This will be an official Gentoo project when we make the announcement in
the next few days. That makes it one project of many. GLEP 0039 clearly
states how this works. If you are unhappy with GLEP 0039, then you
should discuss that with the council.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Greg KH]

On Sun, Nov 18, 2012 at 03:10:08AM -0500, Richard Yao wrote:
> You are the one claiming that this is our official fork. None of us are.

It's on the Gentoo github site, and it has the Gentoo Foundation
copyright all over all of the files in one of the branches, reviewed by
you.

I think I would be pretty foolish if I somehow thought it was _not_ an
official fork :)

> This will be an official Gentoo project when we make the announcement in
> the next few days. That makes it one project of many. GLEP 0039 clearly
> states how this works. If you are unhappy with GLEP 0039, then you
> should discuss that with the council.

I fail to see how 0039 has to do with this, please explain.  I also
don't see the copyright issue here, nor do I see where the decision of
the council was made.

Again, that's my original question, "What is the decision of the council
regarding this issue"?

thanks,

greg k-h

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Richard Yao]

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

On 11/18/2012 03:19 AM, Greg KH wrote:
> On Sun, Nov 18, 2012 at 03:10:08AM -0500, Richard Yao wrote:
>> You are the one claiming that this is our official fork. None of us are.
> 
> It's on the Gentoo github site, and it has the Gentoo Foundation
> copyright all over all of the files in one of the branches, reviewed by
> you.
> 
> I think I would be pretty foolish if I somehow thought it was _not_ an
> official fork :)
> 
>> This will be an official Gentoo project when we make the announcement in
>> the next few days. That makes it one project of many. GLEP 0039 clearly
>> states how this works. If you are unhappy with GLEP 0039, then you
>> should discuss that with the council.
> 
> I fail to see how 0039 has to do with this, please explain.  I also
> don't see the copyright issue here, nor do I see where the decision of
> the council was made.
> 
> Again, that's my original question, "What is the decision of the council
> regarding this issue"?
> 
> thanks,
> 
> greg k-h

I am sick of the harassment that I have received from you and a few
others both in public and in private. The public branch has been
deleted. Come back after we have done our first release. Otherwise,
leave us alone. That is all that I have to say.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Greg KH]

On Sun, Nov 18, 2012 at 12:19:21AM -0800, Greg KH wrote:
> On Sun, Nov 18, 2012 at 03:10:08AM -0500, Richard Yao wrote:
> > You are the one claiming that this is our official fork. None of us are.
> 
> It's on the Gentoo github site, and it has the Gentoo Foundation
> copyright all over all of the files in one of the branches, reviewed by
> you.
> 
> I think I would be pretty foolish if I somehow thought it was _not_ an
> official fork :)

Oh, and the README file says it is a Gentoo project:
	This is a Gentoo sponsored project and testing is currently
	being done with openrc.  However, we aim to be distro neutral
	and welcome contribution from others using a variety of system
	initializations.  We also aim towards POSIX compliance.

So why would I think otherwise?

thanks,

greg k-h

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Pacho Ramos]

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

El dom, 18-11-2012 a las 00:27 -0800, Greg KH escribió:
> On Sun, Nov 18, 2012 at 12:19:21AM -0800, Greg KH wrote:
> > On Sun, Nov 18, 2012 at 03:10:08AM -0500, Richard Yao wrote:
> > > You are the one claiming that this is our official fork. None of us are.
> > 
> > It's on the Gentoo github site, and it has the Gentoo Foundation
> > copyright all over all of the files in one of the branches, reviewed by
> > you.
> > 
> > I think I would be pretty foolish if I somehow thought it was _not_ an
> > official fork :)
> 
> Oh, and the README file says it is a Gentoo project:
> 	This is a Gentoo sponsored project and testing is currently
> 	being done with openrc.  However, we aim to be distro neutral
> 	and welcome contribution from others using a variety of system
> 	initializations.  We also aim towards POSIX compliance.
> 
> So why would I think otherwise?
> 
> thanks,
> 
> greg k-h
> 
> 

Looks like we think different about what a "Gentoo project" means, lets
read:
http://devmanual.gentoo.org/general-concepts/herds-and-projects/index.html

That would explain why both, eudev and systemd "Gentoo projects" can
coexist:
http://www.gentoo.org/proj/en/base/systemd/index.xml

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

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Diego Elio Pettenò]

On 18/11/2012 00:08, Greg KH wrote:
> But if this fork is now the "official Gentoo fork", owned by the Gentoo
> Foundation, and it's the way forward that Gentoo the distro is going to
> take with regards to how the boot process works on the system, then I
> have something to say about it, as it affects me, a Gentoo developer.

Please note that I would be the first one, from a QA point of view, to
raise a huge question mark if somebody is planning to make this the
default anytime soon.

You want to keep it around as an option? Sure, feel free.

Moving as default? Over my dead public key.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Samuli Suominen]

On 18/11/12 10:21, Diego Elio Pettenò wrote:
> On 18/11/2012 00:08, Greg KH wrote:
>> But if this fork is now the "official Gentoo fork", owned by the Gentoo
>> Foundation, and it's the way forward that Gentoo the distro is going to
>> take with regards to how the boot process works on the system, then I
>> have something to say about it, as it affects me, a Gentoo developer.
>
> Please note that I would be the first one, from a QA point of view, to
> raise a huge question mark if somebody is planning to make this the
> default anytime soon.
>
> You want to keep it around as an option? Sure, feel free.
>
> Moving as default? Over my dead public key.
>

Amen.

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Vadim A. Misbakh-Soloviov]

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

By the way, Diego, what is you current point of view on Gentoo default
init system?
i.e., what do you personally prefer to see as default init here: SystemD
or OpenRC?


[Just asking because all you angry answers to some devs make me think
that you're on SysD side, when tons of Gentoo users and Gentoo devs are
on "non-SysD-related udev" side.]

And, if anyone is interested in my opinion: I *HATE* when somebody (will
it be distro maintainers or RedHat corporation) forcing me their opinion
on _what_ should I use and _how_ should I use this. Thats why I hate
Ubuntu, Debian, CentOS, RHEL, SuSE and so on.
Thats why I'm using  Gentoo and Gentoo-derivatives (Sabayon, for
example) for almost 10 years.
Thats why I am an evangelist of Gentoo and it's derivatives.
More of that, thats why Daniel Robbins created Gentoo itself.
So, I really hope, that Gentoo will not obey RedHat's will and will not
force SystemD as default init system, and not drop pretty OpenRC to
trash. And I hope, that ryao's eudev will be most used (if not default)
variant of udev, since I'm sad with last vanilla udev functionality
"downgrades".



--
Best,
mva



18.11.2012 15:21, Diego Elio Pettenò пишет:
> On 18/11/2012 00:08, Greg KH wrote:
>> But if this fork is now the "official Gentoo fork", owned by the Gentoo
>> Foundation, and it's the way forward that Gentoo the distro is going to
>> take with regards to how the boot process works on the system, then I
>> have something to say about it, as it affects me, a Gentoo developer.
> 
> Please note that I would be the first one, from a QA point of view, to
> raise a huge question mark if somebody is planning to make this the
> default anytime soon.
> 
> You want to keep it around as an option? Sure, feel free.
> 
> Moving as default? Over my dead public key.
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Rich Freeman]

On Sun, Nov 18, 2012 at 6:11 AM, Vadim A. Misbakh-Soloviov <mva@mva.name> wrote:
> So, I really hope, that Gentoo will not obey RedHat's will and will not
> force SystemD as default init system, and not drop pretty OpenRC to
> trash. And I hope, that ryao's eudev will be most used (if not default)
> variant of udev, since I'm sad with last vanilla udev functionality
> "downgrades".

I'm sure all of the options will be offered as options for as long as
people care to take care of them.  With the number of anti-systemd
posts on -dev I don't see openrc going away anytime soon.

I'm sure the default will stay as it is unless a substantial majority
want it otherwise - we can't go flipping that every time the latest
whatever comes along.

And frankly, I could care less what it is since I can change it.  If I
wanted to be rigidly bound by defaults there are a lot of distros
easier to maintain than Gentoo.  iOS comes to mind.  :)

I run OpenRC on my main box, and systemd on a VM hosted within it.  I
wouldn't be surprised if I move to systemd some day as my experience
with it has been a good one, but I'll use the tools I think are best
for the problem at hand, and not what somebody else chooses for me,
and I'll be the last to force a choice on anybody else.  That said,
Gentoo can only offer the options that devs step up and maintain, so
if you care greatly about something start writing patches.

That is my biggest concern over a lot of this mess - and Greg KH did a
good job putting it into words in the six-month old thread that was
just resurrected.  Lennart et al only have the power you give to them
- anybody can fork at any time or keep an old project going.  If you
don't like Gnome 3 then start writing code for Gnome 2.  This is all
FREE software, and it only exists when people take the time to write
it.  If nobody bothers to maintain the alternatives, then I guess
collectively we're going to be stuck with whatever people take the
time to write.

So, feel free to offer advice/comments/etc.  However, let's keep the
tone civil.  Unless you're their employer, the guys writing the
software you don't like owe you precisely nothing.

Rich

[gentoo-dev] Re: Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Duncan]

Rich Freeman posted on Sun, 18 Nov 2012 07:26:17 -0500 as excerpted:

> I'm sure all of the options will be offered as options for as long as
> people care to take care of them.  With the number of anti-systemd posts
> on -dev I don't see openrc going away anytime soon.
> 
> I'm sure the default will stay as it is unless a substantial majority
> want it otherwise - we can't go flipping that every time the latest
> whatever comes along.

[For close followers of the discussion, this is a repeat.  But it's worth 
repeating in the hope that the message gets out to gentoo users who don't 
follow so closely.]

Based on previous posts from other gentoo users, this point seems to have 
been lost on some, but it's absolutely true.  As I've pointed out before 
as well, even if by some miracle all of gentoo turned on a dime and 
became a virulently pro-systemd distro today, in practice it'd take time 
for that to work into the implementation.  We're looking at probably a 
year minimum, more practically closer to two, before end-users could 
really be "forced" over, and that's if somehow the policy changed on a 
dime, today, which isn't going to happen.  So even if gentoo ultimately 
heads that direction, and I think the default _may_ _eventually_ be 
systemd but with *SERIOUS* stress on BOTH _MAY_ and _EVENTUALLY_, in 
reality we're looking at 3-5 years.

And in the free software world, a _LOT_ happens in 3-5 years!  So much so 
that five years really is at the horizon in any case -- there will be 
enough currently unforeseen changes between now and then that it's really 
hard to predict anything out that far anyway, and MOST people attempting 
to do so in anything but trivial ways will get MAJOR parts of their 
prediction wrong, simply because events will overtake them.

> And frankly, I could care less what it is since I can change it.  If I
> wanted to be rigidly bound by defaults there are a lot of distros easier
> to maintain than Gentoo.  iOS comes to mind.  :)

That's a point that should be near and dear to any serious gentooer's 
heart! =:^)

> I run OpenRC on my main box, and systemd on a VM hosted within it.  I
> wouldn't be surprised if I move to systemd some day as my experience
> with it has been a good one, but I'll use the tools I think are best for
> the problem at hand, and not what somebody else chooses for me, and I'll
> be the last to force a choice on anybody else.

With the previous caveats about trying to predict anything in the FLOSS 
world too far out, in 2-3 years, I expect I'll be on systemd myself.  But 
there's no rush, and I intend to wait until it stabilizes somewhat, 
first.  At present it's simply evolving too fast for my tastes, for 
something so system-basic.  I enjoy running alphas and betas as much as 
the next guy and it's a rare time indeed that I don't have /something/ 
not-absolutely stable running on my systems, but that doesn't mean I 
want /all/ of my system unstable and shifting out from under me, and  
system init is an area where I'm just not ready to make a change as big 
as systemd, when it's still actively growing and changing at the rate it 
seems to be doing so today.  

That said, I _do_ run openrc-9999, mainly because I found the changes of 
~arch openrc too coarse-grained and hard to troubleshoot when things go 
wrong.  By running the live-git version and examining git-whatchanged 
every time I update, often looking at the diffs for individual commits, I 
get the incremental changes as they come in, and can much faster pinpoint 
where a particular problem is when I see it, making the necessary changes 
locally and of course bug-filing upstream as I need to, to get it fixed.  

But running a live-git version of something I'm already on, in ordered to 
more closely follow individual commits and pinpoint and resolve bugs 
faster, is quite different from deciding I'm going to switch to something 
with as much churn as systemd seems to still have, engulfing and 
extinguishing entire projects like some ravenous black hole or gray goo.  
Yes, I expect at some point I'll be assimilated myself, but there's no 
reason that point needs to be now, and the future where I expect it to 
happen remains to be written, with a good chance the plot line will 
change significantly between now and then, such that I may never be 
assimilated after all.  For all I know, the whole worldview will change 
between now and then, and other events might well overtake this gray goo 
that now seems to be engulfing everything that it touches, such that it 
never does in fact engulf me and my systems.

> That said, Gentoo can
> only offer the options that devs step up and maintain, so if you care
> greatly about something start writing patches.

This too is a point that's often lost on people.  Take kde as an 
example.  Yes, kde3 was relegated to the kde-sunset overlay, where it's 
being maintained in some state by users (see the gentoo-desktop list for 
the discussion on that, if interested).  But that was simply because no 
current gentoo devs were interested in maintaining it in-tree.  All the 
gentoo/kde folks were on kde4.  If there had been active devs interested 
in keeping a working kde3 in-tree, it would have stayed in-tree.  Only 
when the active gentoo dev interest fell below a sustainable level was it 
removed, and even then, it's still in kde-sunset, because there's 
sustainable interest at /that/ level.

The same of course applies to trinity, the still active fork from kde3.  
I think it'd be great to have it in the gentoo tree again.  But it's not 
going to happen unless/until there's enough active gentoo devs interested 
in making it happen to have it as a project.

And the same applies to systemd/udev.  The choices available to gentoo 
users are a direct reflection of the interest of gentoo devs.  As it 
happens, there's a couple gentoo devs with the interest and motivation to 
have the systemd OPTION in gentoo, but that's exactly where it stands 
ATM, a non-default OPTION.  And that's exactly where it's likely to 
remain for at least a few years, because the primary gentoo dev interest 
still seems to be focused on openrc and a udev-alike that remains 
sufficiently unentangled from systemd that it's still buildable (to some 
degree) and runnable (to a much larger degree) on its own.

The only way that's going to change is if the critical level of interest 
amongst gentoo devs changes.  Thus, the way to either keep a gentoo 
systemd default from happening, or increase the speed at which it 
happens, and to maintain choice regardless of the default depending on 
your own interest, is to do your part to ensure the critical level of 
gentoo interest in your preferred outcome remains strong.

If current wider-Linux-and-FLOSS-universe trends continue, then at some 
point, probably most gentoo devs will be interested in systemd, as it's 
what they're familiar with from their previous and continuing outside-of-
gentoo experience.  However, as I pointed out above, that's not a 
particularly safe prediction to make, because gentoo as it is today is 
rather far from that, and by the time it could reasonably get to that 
point thru normal gentoo dev attrition and recruitment, the whole Linux/
FLOSS worldview may well have changed, and systemd/udev may well be as 
much yesterday's news as the old kernel's even/odd stable/dev kernel 
cycle, or the xfree86/xorg split before that, or the gcc/egcs split 
before that, or...

> That is my biggest concern over a lot of this mess - and Greg KH did a
> good job putting it into words in the six-month old thread that was just
> resurrected.  Lennart et al only have the power you give to them -
> anybody can fork at any time or keep an old project going.  If you don't
> like Gnome 3 then start writing code for Gnome 2.  This is all FREE
> software, and it only exists when people take the time to write it.  If
> nobody bothers to maintain the alternatives, then I guess collectively
> we're going to be stuck with whatever people take the time to write.

This is simply reinforcing and underlining the above, only now we're 
looking at the upstream level, not the gentoo/distro level.

> So, feel free to offer advice/comments/etc.  However, let's keep the
> tone civil.  Unless you're their employer, the guys writing the software
> you don't like owe you precisely nothing.

++ on keeping it civil! =:^)

-- 
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] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Diego Elio Pettenò]

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

On 18/11/2012 03:11, Vadim A. Misbakh-Soloviov wrote:
> 
> [Just asking because all you angry answers to some devs make me think
> that you're on SysD side, when tons of Gentoo users and Gentoo devs are
> on "non-SysD-related udev" side.]

The fact you're asking means you really haven't been following anything
I've been doing lately. As many other developers can easily attest, I
don't use systemd and I'm not planning to use it anytime soon.

So your whole rant picking up on my post is completely misdirected.

And let this be a reminder that you can still disagree with the "systemd
everywhere, and only" crowd while still not becoming laughing stock.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 551 bytes --]

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Samuli Suominen]

On 18/11/12 17:04, Diego Elio Pettenò wrote:
> On 18/11/2012 03:11, Vadim A. Misbakh-Soloviov wrote:
>>
>> [Just asking because all you angry answers to some devs make me think
>> that you're on SysD side, when tons of Gentoo users and Gentoo devs are
>> on "non-SysD-related udev" side.]
>
> The fact you're asking means you really haven't been following anything
> I've been doing lately. As many other developers can easily attest, I
> don't use systemd and I'm not planning to use it anytime soon.
>
> So your whole rant picking up on my post is completely misdirected.

Same here. I haven't even tried it and got no plans to.

I'm still happy enough with building udev out from systemd tree and 
letting sep. /usr consept from 90s to finally die in favour of 
simplifying the system.
The BIOSes have been upgraded last century to support booting from 
larger partitions, the need has long past.
Nobody has ever provided a valid reason for using sep. /usr in the ML 
either.

- Samuli

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Diego Elio Pettenò]

On 18/11/2012 07:16, Samuli Suominen wrote:
> 
> 
> I'm still happy enough with building udev out from systemd tree and
> letting sep. /usr consept from 90s to finally die in favour of
> simplifying the system.
> The BIOSes have been upgraded last century to support booting from
> larger partitions, the need has long past.
> Nobody has ever provided a valid reason for using sep. /usr in the ML
> either.

Ibidem.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Fabian Groffen]

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

On 18-11-2012 17:16:18 +0200, Samuli Suominen wrote:
> Nobody has ever provided a valid reason for using sep. /usr in the ML 
> either.

No need for a reason.

It is a fact that it is in use *right now*.

(Existing systems/installs that are not to be phased out anywhere near
soon.)

Fabian

-- 
Fabian Groffen
Gentoo on a different level

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

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Vadim A. Misbakh-Soloviov]

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

To be honest, in my opinion, «killing of separate /usr» can reasonable
be continued by moving all it's content to / (/usr/bin -> /bin, /usr/lib
-> lib, and so on) in despite of all objections, as it was invented just
because of disk space exhaustion.


18.11.2012 22:16, Samuli Suominen пишет:
> On 18/11/12 17:04, Diego Elio Pettenò wrote:
>> On 18/11/2012 03:11, Vadim A. Misbakh-Soloviov wrote:
>>>
>>> [Just asking because all you angry answers to some devs make me think
>>> that you're on SysD side, when tons of Gentoo users and Gentoo devs are
>>> on "non-SysD-related udev" side.]
>>
>> The fact you're asking means you really haven't been following anything
>> I've been doing lately. As many other developers can easily attest, I
>> don't use systemd and I'm not planning to use it anytime soon.
>>
>> So your whole rant picking up on my post is completely misdirected.
> 
> Same here. I haven't even tried it and got no plans to.
> 
> I'm still happy enough with building udev out from systemd tree and
> letting sep. /usr consept from 90s to finally die in favour of
> simplifying the system.
> The BIOSes have been upgraded last century to support booting from
> larger partitions, the need has long past.
> Nobody has ever provided a valid reason for using sep. /usr in the ML
> either.
> 
> - Samuli
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Diego Elio Pettenò]

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

On 18/11/2012 07:34, Vadim A. Misbakh-Soloviov wrote:
> To be honest, in my opinion, «killing of separate /usr» can reasonable
> be continued by moving all it's content to / (/usr/bin -> /bin, /usr/lib
> -> lib, and so on) in despite of all objections, as it was invented just
> because of disk space exhaustion.

Well, the objection to that was what actually "caused" this udev fork, so...

Also, I doubt anybody would argue that it's not commutative (move to
/usr, move to /) — it's just pragmatic, most stuff uses /usr anyway as
base, so the move / -> /usr is infinitely less painful than /usr -> /.

To me, I don't care. I haven't even used /boot in years.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 551 bytes --]

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Fabian Groffen]

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

On 18-11-2012 07:42:40 -0800, Diego Elio Pettenò wrote:
> Also, I doubt anybody would argue that it's not commutative (move to
> /usr, move to /) — it's just pragmatic, most stuff uses /usr anyway as
> base, so the move / -> /usr is infinitely less painful than /usr -> /.

You end up with a symlink (e.g. bin -> ./usr/bin) from one place to the
other regardless, so it doesn't matter much.


-- 
Fabian Groffen
Gentoo on a different level

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

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Vadim A. Misbakh-Soloviov]

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

18.11.2012 22:51, Fabian Groffen пишет:
> You end up with a symlink (e.g. bin -> ./usr/bin) from one place to the
> other regardless, so it doesn't matter much.

So, why not to make /usr/bin -> ../bin (or, maybe even /usr/bin -> /bin
(notice the «/»)) ? :D


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Rich Freeman]

On Mon, Nov 19, 2012 at 3:20 AM, Vadim A. Misbakh-Soloviov <mva@mva.name> wrote:
> 18.11.2012 22:51, Fabian Groffen пишет:
>> You end up with a symlink (e.g. bin -> ./usr/bin) from one place to the
>> other regardless, so it doesn't matter much.
>
> So, why not to make /usr/bin -> ../bin (or, maybe even /usr/bin -> /bin
> (notice the «/»)) ? :D

So, given the choices of:
1.  Re-establishing FHS standards so that I can boot with / only.
2.  Consolidating everything under /usr so that just about all
OS-managed files are in a single place.
3.  Stuffing everything in /usr into my root partition.

I'd say that #3 is the worst of all possible worlds.  At least there
is some kind of expected benefit from the /usr move.  Sure, you COULD
shove everything into root, but I can't think of anybody in this
debate who would consider that a useful solution.

Go read the Fedora reasons-for-the-/usr-move page.  Whether you think
it is worth it or not is one thing, but at least there are reasons for
it.  I can't think of any benefits from doing the reverse.

Rich

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Fabian Groffen]

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

On 19-11-2012 15:20:56 +0700, Vadim A. Misbakh-Soloviov wrote:
> 18.11.2012 22:51, Fabian Groffen пишет:
> > You end up with a symlink (e.g. bin -> ./usr/bin) from one place to the
> > other regardless, so it doesn't matter much.
> 
> So, why not to make /usr/bin -> ../bin (or, maybe even /usr/bin -> /bin
> (notice the «/»)) ? :D

Dunno if Linux has a way to, but if you use an alternative mountpoint,
it's nice when the symlink points in the right direction, and not
accidentially to a life filesystem coming from a rescue device or
whatever.

Fabian

-- 
Fabian Groffen
Gentoo on a different level

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

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Luca Barbato]

On 11/18/2012 04:34 PM, Vadim A. Misbakh-Soloviov wrote:
> To be honest, in my opinion, «killing of separate /usr» can reasonable
> be continued by moving all it's content to / (/usr/bin -> /bin, /usr/lib
> -> lib, and so on) in despite of all objections, as it was invented just
> because of disk space exhaustion.

And since we have lots of wonderful file systems, a neat and interesting
device mapper and a plethora of fun way to shot ourselves in the foot
not only you have a separate /usr but even fun separate /usr/bin from
/usr/share and other strange layout that some people prepared to solve
some of their problems.

The radical solution is to have a rich early boot able to do this kind
of setup, for the transition you might want to not have init and udev
non-workable because somebody decided that is useful using glib or some
other library residing in /usr/

lu

[gentoo-dev] Re: Tightly-coupled core distro

[Steven J. Long]

On Sun, Nov 18, 2012 at 05:16:18PM +0200, Samuli Suominen wrote:
> I'm still happy enough with building udev out from systemd tree and 
> letting sep. /usr consept from 90s to finally die in favour of 
> simplifying the system.

 It's from a lot earlier than the 90s. Perhaps we should get rid of pipes,
too- they're /so/ 1970s.

 Torvalds expressed it well[1]:
  You made the statement that you want to get away from 30 years of
  history, but the fact is, "30 years of history" is a damn good argument
  for "that thing worked".

> The BIOSes have been upgraded last century to support booting from 
> larger partitions, the need has long past.
> Nobody has ever provided a valid reason for using sep. /usr in the ML 
> either.
> 
 So at the same time as you have never heard a valid reason, the need (which
you have never understood) is long past? Pfft.

 To reiterate again: many of us are used to keeping /usr on a separate
partition for security and backup purposes (other use-cases for a separate
partition include mounting /usr over NFS, or a common partition for
virtual machines.) I'm sure other people would have more. Irrespective,
it should be about mechanism, not policy, and certainly not about breaking
existing setups.

 Many of the advertised benefits of the "merge /bin and /sbin to /usr"
concept are in fact just benefits of having a separate /usr partition,
though of course they're presented as new and unique to the merge. So, if
you accept those as benefits, you cannot logically deny them as benefits of
a traditional /usr split.

 Further, as one user pointed out[2]:
"I'd be more likely to just stick /usr back on / than create an initramfs
- it was only because the LVM guide recommended that /usr go on its own
partition that I now face this situation."

 We were given a simple requirement ages ago: udev requires /usr and
/var (and going forward may require /opt for 3rd party drivers) mounted
before it starts, not for udev itself but for helper scripts that it may
call. Why get bogged down in anything else?

 The recommended (which became "supported") method to do this was
to use an initramfs, since apparently any chicken-and-egg problems (such
as requiring a udev-initiated device to mount /usr) are easier to handle
there. (Note that no-one has ever provided a description of how they did
that, eg for their bluetooth keyboard, so that the issues, and how they
are addressed, could be made more transparent to everyone.)

 A few us are happily running initramfs-less machines by fulfilling the
requirement with a couple of patches to openrc initscripts[2]. (It's
been working fine here since last August.) This works in the case where
you didn't need an initramfs before, ie have modules for local-disks and
filesystems built-in, root not on LVM or encrypted, but other partitions
might be-- which includes LVM users who followed the Gentoo docs.

 If that's not enough, there is *already* a forked udev version which quite
a few users have been using[3] and reporting success with. I'd hope the
new fork would just collaborate with them, but it's entirely up to them
what they do.

 All of this argues that, irrespective of your views of the layouts admins
prefer to use, they will still use them regardless, and indeed users will
put in the work you yourself told them to.[4] I really don't understand
why people are getting beat up on, just for going ahead and doing what
they've been told to: provide code for an alternative.

 If a Gentoo developer doesn't understand what a Gentoo project means,
that's his problem. Nor should Gentoo projects suddenly change what they
are because "the internet" doesn't understand them. That's a ridiculous
basis for any change.

 The thing none of the proponents of an initramfs, with no other support
for a separate /usr (apart from busybox sep /usr which does NOT fulfil the
requirements presented by Chainsaw, which Council voted to approve before:
for a start it doesn't handle /usr on LVM), have ever answered is:

 How do you deal with the mismatch problem?

 That is, when you have programs or libs upgraded, just as part of normal
system upgrades, and they are now different, potentially incompatible, to
the initramfs. (The potential exists, therefore it must be addressed for
a solution even to be considered as robust.)

 Do you now need another script to run after every emerge to check that
files in your initramfs are in sync? After all, we've been told the
initramfs is "the new root": iow that we should think of it as our rescue
system, so this matters.

 At the same time, we've been told "it's only a few hundred kilobytes at
most." That contradiction has never been answered, either.

[1] http://lwn.net/Articles/492134/
[2] http://forums.gentoo.org/viewtopic-t-901206.html
[3] http://forums.gentoo.org/viewtopic-t-934678.html
[4] http://forums.gentoo.org/viewtopic-p-6987380.html#6987380
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: Tightly-coupled core distro

[Alec Warner]

On Mon, Nov 19, 2012 at 5:07 AM, Steven J. Long
<slong@rathaus.eclipse.co.uk> wrote:
> On Sun, Nov 18, 2012 at 05:16:18PM +0200, Samuli Suominen wrote:
>> I'm still happy enough with building udev out from systemd tree and
>> letting sep. /usr consept from 90s to finally die in favour of
>> simplifying the system.
>
>  It's from a lot earlier than the 90s. Perhaps we should get rid of pipes,
> too- they're /so/ 1970s.
>
>  Torvalds expressed it well[1]:
>   You made the statement that you want to get away from 30 years of
>   history, but the fact is, "30 years of history" is a damn good argument
>   for "that thing worked".
>
>> The BIOSes have been upgraded last century to support booting from
>> larger partitions, the need has long past.
>> Nobody has ever provided a valid reason for using sep. /usr in the ML
>> either.
>>
>  So at the same time as you have never heard a valid reason, the need (which
> you have never understood) is long past? Pfft.
>
>  To reiterate again: many of us are used to keeping /usr on a separate
> partition for security and backup purposes (other use-cases for a separate
> partition include mounting /usr over NFS, or a common partition for
> virtual machines.) I'm sure other people would have more. Irrespective,
> it should be about mechanism, not policy, and certainly not about breaking
> existing setups.
>
>  Many of the advertised benefits of the "merge /bin and /sbin to /usr"
> concept are in fact just benefits of having a separate /usr partition,
> though of course they're presented as new and unique to the merge. So, if
> you accept those as benefits, you cannot logically deny them as benefits of
> a traditional /usr split.
>
>  Further, as one user pointed out[2]:
> "I'd be more likely to just stick /usr back on / than create an initramfs
> - it was only because the LVM guide recommended that /usr go on its own
> partition that I now face this situation."
>
>  We were given a simple requirement ages ago: udev requires /usr and
> /var (and going forward may require /opt for 3rd party drivers) mounted
> before it starts, not for udev itself but for helper scripts that it may
> call. Why get bogged down in anything else?
>
>  The recommended (which became "supported") method to do this was
> to use an initramfs, since apparently any chicken-and-egg problems (such
> as requiring a udev-initiated device to mount /usr) are easier to handle
> there. (Note that no-one has ever provided a description of how they did
> that, eg for their bluetooth keyboard, so that the issues, and how they
> are addressed, could be made more transparent to everyone.)
>
>  A few us are happily running initramfs-less machines by fulfilling the
> requirement with a couple of patches to openrc initscripts[2]. (It's
> been working fine here since last August.) This works in the case where
> you didn't need an initramfs before, ie have modules for local-disks and
> filesystems built-in, root not on LVM or encrypted, but other partitions
> might be-- which includes LVM users who followed the Gentoo docs.
>
>  If that's not enough, there is *already* a forked udev version which quite
> a few users have been using[3] and reporting success with. I'd hope the
> new fork would just collaborate with them, but it's entirely up to them
> what they do.
>
>  All of this argues that, irrespective of your views of the layouts admins
> prefer to use, they will still use them regardless, and indeed users will
> put in the work you yourself told them to.[4] I really don't understand
> why people are getting beat up on, just for going ahead and doing what
> they've been told to: provide code for an alternative.
>
>  If a Gentoo developer doesn't understand what a Gentoo project means,
> that's his problem. Nor should Gentoo projects suddenly change what they
> are because "the internet" doesn't understand them. That's a ridiculous
> basis for any change.
>
>  The thing none of the proponents of an initramfs, with no other support
> for a separate /usr (apart from busybox sep /usr which does NOT fulfil the
> requirements presented by Chainsaw, which Council voted to approve before:
> for a start it doesn't handle /usr on LVM), have ever answered is:
>
>  How do you deal with the mismatch problem?
>
>  That is, when you have programs or libs upgraded, just as part of normal
> system upgrades, and they are now different, potentially incompatible, to
> the initramfs. (The potential exists, therefore it must be addressed for
> a solution even to be considered as robust.)
>
>  Do you now need another script to run after every emerge to check that
> files in your initramfs are in sync? After all, we've been told the
> initramfs is "the new root": iow that we should think of it as our rescue
> system, so this matters.

Debian / Ubuntu have a tool that basically does this. Its
update-initramfs. I believe it is called from..the postinst of
packages that are supposed to be in the initramfs? honestly I'd have
to look up how they implemented it.

-A

>
>  At the same time, we've been told "it's only a few hundred kilobytes at
> most." That contradiction has never been answered, either.
>
> [1] http://lwn.net/Articles/492134/
> [2] http://forums.gentoo.org/viewtopic-t-901206.html
> [3] http://forums.gentoo.org/viewtopic-t-934678.html
> [4] http://forums.gentoo.org/viewtopic-p-6987380.html#6987380
> --
> #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
>

Re: [gentoo-dev] Re: Tightly-coupled core distro

[Rich Freeman]

On Mon, Nov 19, 2012 at 11:32 AM, Alec Warner <antarus@gentoo.org> wrote:
>
> Debian / Ubuntu have a tool that basically does this. Its
> update-initramfs. I believe it is called from..the postinst of
> packages that are supposed to be in the initramfs? honestly I'd have
> to look up how they implemented it.

Not a bad idea, with a corresponding eselect tool to control what kind
of initramfs you have (dracut, genkernel, none,
remind-me-but-I-roll-my-own, etc).  The ebuild would just call the
function, and the function would handle it accordingly.

Rich

Re: [gentoo-dev] Re: Tightly-coupled core distro

[Diego Elio Pettenò]

On 19/11/2012 08:52, Rich Freeman wrote:
> Not a bad idea, with a corresponding eselect tool to control what kind
> of initramfs you have (dracut, genkernel, none,
> remind-me-but-I-roll-my-own, etc).  The ebuild would just call the
> function, and the function would handle it accordingly.

Glad to hear we're now addressing the problem from the technical
prospective.

Thanks Rich,
-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

[gentoo-dev] Re: Re: Tightly-coupled core distro

[Steven J. Long]

On Mon, Nov 19, 2012 at 11:52:46AM -0500, Rich Freeman wrote:
> On Mon, Nov 19, 2012 at 11:32 AM, Alec Warner <antarus@gentoo.org> wrote:
> >
> > Debian / Ubuntu have a tool that basically does this. Its
> > update-initramfs. I believe it is called from..the postinst of
> > packages that are supposed to be in the initramfs? honestly I'd have
> > to look up how they implemented it.
> 
> Not a bad idea, with a corresponding eselect tool to control what kind
> of initramfs you have (dracut, genkernel, none,
> remind-me-but-I-roll-my-own, etc).  The ebuild would just call the
> function, and the function would handle it accordingly.
>
The issue there is "packages that are supposed to be in the initramfs," since
we've been told the initramfs is a custom thing for our situation. (Which is
kinda my issue with just dumping the whole problem on end-users and admins 
who are not using a prepackaged distro without customisation, instead of
maintaining backward-compatibility.)

Mind, I don't have an issue with developers deciding certain packages are
critical: after all the same knowledge informs what should be on root.

I just don't think that the above answers the problem comprehensively (and
thus it isn't worth the maintenance headache, if it can be avoided.)

All the tutorials, and packages, I've seen on the forums take you through
deciding exactly what you need in the initramfs. So given that each user
has a potentially different set of stuff on there, the robust method would
appear to require the mangler to know which packages had files on there, and
to update them accordingly (or run the generation tool, or warn, as you said)
when one of that set were updated.

Simply triggering a warning when one of a named set is built, sounds like a
start. (The initramfs generation script could run qfile to build/check the
set.) Thereafter it's "just" a matter of hooking into that, if the functionality
is not already present.

(I don't run unstable portage any more, as I need to be close to what end-users
of our emerge wrapper are using, so I'm not up on the current state of 2.2. I'd
prefer not to have to script round this issue, since it doesn't affect me at all.)

Regards,
SteveL.
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: Tightly-coupled core distro

[Peter Stuge]

Steven J. Long wrote:
> Nor should Gentoo projects suddenly change what they are because
> "the internet" doesn't understand them. That's a ridiculous basis
> for any change.

If a friend whom I care about and respect tells me that they don't
understand something I do then I try to consider if maybe I should
change my ways.

If the internet tells me, then even though I probably don't care
about them I might still consider a change, because of the numbers.

It doesn't always matter what others think, but it is always worth
considering. It matters a lot for how one is understood.


//Peter

Re: [gentoo-dev] Re: Tightly-coupled core distro

[Rich Freeman]

On Mon, Nov 19, 2012 at 12:43 PM, Peter Stuge <peter@stuge.se> wrote:
> Steven J. Long wrote:
>> Nor should Gentoo projects suddenly change what they are because
>> "the internet" doesn't understand them. That's a ridiculous basis
>> for any change.
>
> It doesn't always matter what others think, but it is always worth
> considering. It matters a lot for how one is understood.

Sure, but what's the alternative?  GLEP-39 was written precisely
because a more top-down system wasn't really working well.

The new model is much more bazar-like, with the Council as a forum for
appeal if things get out of hand.

If once in a while we have to deal with the fallout of something like
this I'll take that any day if it makes it more likely for the next
X32/Prefix/etc to take off on Gentoo.

Rich

Re: [gentoo-dev] Re: Tightly-coupled core distro

[Peter Stuge]

Rich Freeman wrote:
> >> Nor should Gentoo projects suddenly change what they are because
> >> "the internet" doesn't understand them. That's a ridiculous basis
> >> for any change.
> >
> > It doesn't always matter what others think, but it is always worth
> > considering. It matters a lot for how one is understood.
> 
> Sure, but what's the alternative?  GLEP-39 was written precisely
> because a more top-down system wasn't really working well.

I'm thinking that perhaps sunrise projects could be useful. It would
be up to each developer if they choose to start their project as a
"normal" project, or as a sunrise project. It could just as well be
called bootstrap or experimental or one of many other fine names.

There would not be much difference between the two, other than
perhaps that they are hosted in different places to more clearly
communicate intent of the developers who work on the project.

It would also be up to developers if they want to move their project
between the two "types".


> The new model is much more bazar-like, with the Council as a forum
> for appeal if things get out of hand.

They could make recommendations about where new projects should
probably start, but developers could still be free to choose the
other type.


> If once in a while we have to deal with the fallout of something
> like this I'll take that any day if it makes it more likely for the
> next X32/Prefix/etc to take off on Gentoo.

I don't think it's strictly neccessary to accept fallout from
misunderstandings just to have room for innovation.


//Peter

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Vadim A. Misbakh-Soloviov]

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


> The fact you're asking means you really haven't been following anything
> I've been doing lately. 
Nope ;) I knew that, but as far as I read some of your emails, it was
thoughts that you protect udev+sysD integration and followed udev's
functionality downgrade.

> So your whole rant picking up on my post is completely misdirected.

Sorry, if I write it in that manner, that last part looks like adressed
to you. I tried to write it mostly for GregKH and people, that protect
SystemD-way distro-development path.

> And let this be a reminder that you can still disagree with the "systemd
> everywhere, and only" crowd while still not becoming laughing stock.

And, by the way, I doubt, that people "laugh" about eudev (previously
named udev-ng) creation. Mostly they just can't understand why gentoo
devs created third udev's fork, where it was already done (and
maintained) fork for LFS (somewhere on bitbucket)



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Diego Elio Pettenò]

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

On 18/11/2012 07:43, Vadim A. Misbakh-Soloviov wrote:
> And, by the way, I doubt, that people "laugh" about eudev (previously
> named udev-ng) creation. Mostly they just can't understand why gentoo
> devs created third udev's fork, where it was already done (and
> maintained) fork for LFS (somewhere on bitbucket)

People _are_ laughing at it. On G+, on Twitter, I suppose identi.ca and
IRC as well.

But yes, many more can't understand that... and neither do I.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 551 bytes --]

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Fabian Groffen]

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

On 18-11-2012 07:47:22 -0800, Diego Elio Pettenò wrote:
> On 18/11/2012 07:43, Vadim A. Misbakh-Soloviov wrote:
> > And, by the way, I doubt, that people "laugh" about eudev (previously
> > named udev-ng) creation. Mostly they just can't understand why gentoo
> > devs created third udev's fork, where it was already done (and
> > maintained) fork for LFS (somewhere on bitbucket)
> 
> People _are_ laughing at it. On G+, on Twitter, I suppose identi.ca and
> IRC as well.

It's your choice to participate on those social platforms.  Please don't
make it our problem.  It doesn't add anything useful to this discussion.

Fabian

-- 
Fabian Groffen
Gentoo on a different level

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

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Diego Elio Pettenò]

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

On 18/11/2012 07:54, Fabian Groffen wrote:
> It's your choice to participate on those social platforms.  Please don't
> make it our problem.  It doesn't add anything useful to this discussion.

It adds. Because, while I don't know about you, I rely on Gentoo on my
job. And many others do, too.

And making Gentoo the laughing stock (_again_, I'd add) is something
that is detrimental to all of us there, as it makes it harder to let it
be seen for what it is (a very real, quit reliable distribution) rather
than a juvenile effort to be different from the rest.

How long did it take us to get rid of the "Gentoo is rice" fame? Do we
want to go back to that? _I_ don't think so.

So yes, the "social platforms" matter and are our problem. And it appals
me that a member of the council can't see that.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 551 bytes --]

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Fabio Erculiani]

It depends on who is actually laughing I'd say.

just my 0.01c.

--
Fabio Erculiani

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Luca Barbato]

On 11/18/2012 04:47 PM, Diego Elio Pettenò wrote:
> But yes, many more can't understand that... and neither do I.

Then would be nice if everybody shuts up, let people play with their
toys and if something useful happens evaluate the result.

According to the people that asked me to help the whole thing would had
been an experiment to see if would be possible to have a smaller and
cleaner udev.

I liked the idea since I like alternatives and I consider many choices
from upstream a tad narrow minded (beside the entertaining posts from
Linus about their bug management).

Nobody wanted hype there, just more people willing to chip in some time
and effort to get there.

lu

[gentoo-dev] Re: Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Duncan]

Diego Elio Pettenò posted on Sun, 18 Nov 2012 07:47:22 -0800 as excerpted:

> On 18/11/2012 07:43, Vadim A. Misbakh-Soloviov wrote:
>> And, by the way, I doubt, that people "laugh" about eudev (previously
>> named udev-ng) creation. Mostly they just can't understand why gentoo
>> devs created third udev's fork, where it was already done (and
>> maintained) fork for LFS (somewhere on bitbucket)
> 
> People _are_ laughing at it. On G+, on Twitter, I suppose identi.ca and
> IRC as well.

There's worse things than being laughed it.  In fact, what's the oft-used-
in-MS/Linux-context quote (Gandi if I'm not mistaken), something along 
the lines of...

First they ignore you, then they laugh at you, then they fight you, then 
you win!

If they're laughing, they're beyond the ignore stage.  And we see 
evidence of the fight stage now too.  If the idea behind that quote is 
correct...

But regardless, there's quite some coding to do before we see.  
Meanwhile, it may fizzle out, or other events may overtake.  Anyway you 
look at it tho, things could be interesting.

But there's still worse things than being laughed at.  Gentoo continued 
in spite of the ricer rep it once had, and this project seems to be being 
blown WAY out of proportion in all KINDS of ways, but gentoo will still 
continue, regardless.

(All that said, the copyright/legal thing is a bit concerning, but it 
already seems to be on its way to being worked out, best I can tell, so 
it too seems to have been blown way out of proportion, tho it may well 
have been felt that was necessary in ordered to stress the gravity of the 
situation.  As many find out too late, legal isn't a laughing matter, but 
regardless, that angle /does/ appear to be being addressed.  The 
others... let them laugh.)

-- 
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: Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Stelian Ionescu]

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

On Sun, 2012-11-18 at 17:19 +0000, Duncan wrote:
> Diego Elio Pettenò posted on Sun, 18 Nov 2012 07:47:22 -0800 as excerpted:
> 
> > On 18/11/2012 07:43, Vadim A. Misbakh-Soloviov wrote:
> >> And, by the way, I doubt, that people "laugh" about eudev (previously
> >> named udev-ng) creation. Mostly they just can't understand why gentoo
> >> devs created third udev's fork, where it was already done (and
> >> maintained) fork for LFS (somewhere on bitbucket)
> > 
> > People _are_ laughing at it. On G+, on Twitter, I suppose identi.ca and
> > IRC as well.
> 
> There's worse things than being laughed it.  In fact, what's the oft-used-
> in-MS/Linux-context quote (Gandi if I'm not mistaken), something along 
> the lines of...
> 
> First they ignore you, then they laugh at you, then they fight you, then 
> you win!
> 
> If they're laughing, they're beyond the ignore stage.  And we see 
> evidence of the fight stage now too. If the idea behind that quote is 
> correct...

People keep repeating that quote implying that whenever somebody laughs
at an idea it's because the idea is worth something, but that's
illogical and in fact false: just because B(worthy idea) was preceded by
A(laughter) doesn't mean that whenever there's A(laughter) then B(worthy
idea) ensues

http://xkcd.com/386/

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
http://common-lisp.net/project/iolib


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

[gentoo-dev] Re: Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Steven J Long]

Greg KH wrote:
> Steven J Long wrote:
>> And that is what we were discussing: possible future coupling between the 
>> two, which is much easier to do when the sources are part of the 
>> same package.
..
>> OFC you could just assure us that udev will never rely on systemd as a
>> design decision. I can understand that systemd might need close
>> integration with the underlying udev implementation.
> 
> Nope, can't make that assurance at all.
> 
> Actually, maybe I can make the opposite assurance

Well, thanks for being straightforward about it: clearly you're keeping the 
option of udev requiring systemd open, and in fact want to move toward that.

> , let's see what the future brings... :)
> 
Yeah, we'll see :) You have udev working nicely, fulfilling a whole load of 
use-cases, and now you want to upwardly-couple to er, a service-manager. 
Running as pid 1, no less, even though it's not necessary. (I predict that 
latter decision will get reversed in a while, just like a /usr partition 
went from an anachronism to a grand new design, and xml config formats are 
no longer talked about; thankfully binary logs got slammed back out the door 
in-kernel at least[1].)

Not build another thing utilising udev and dbus, not even one closely 
integrated, but upwardly-couple every Linux system to that new userspace 
project. Good luck with that.

steveL.

[1] http://lwn.net/Articles/492134/
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Rich Freeman]

On Tue, Apr 10, 2012 at 10:28 PM, Steven J Long
<slong@rathaus.eclipse.co.uk> wrote:
> As for the burden of ensuring that binaries installed to /{s,}bin don't link
> to libs in /usr, why not just automate a QA check for that, and let
> developers decide whether a fix is necessary? After all, core packages that
> do that even when configured with prefix and execprefix = /, aren't so
> portable, and Gentoo has always championed "doing the right thing" wrt
> helping upstream fix portability issues.

The only issue with that logic is that upstream is perfectly aware of
what they're doing already, and bugs are likely to be closed as
WONTFIX.  So, all the QA checks would do is ensure that we slowly
start maintaining forks of more and more packages.  Right now the
problem is probably manageable, but I'm not convinced it will stay
that way.  Once upstream developers consider all constraints to be
removed on their dependencies you could see a lot of stuff getting
pulled into root if you tried to enforce this rule.

In any case, it sounds like the directive is to keep limping along for
a while longer, and that makes sense anyway until docs/etc are
improved.  I agree with Ralph's suggestion that the newer initramfs
tools should be stabilized as well.

Rich

[gentoo-dev] Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Steven J Long]

Rich Freeman wrote:

> On Tue, Apr 10, 2012 at 10:28 PM, Steven J Long
> <slong@rathaus.eclipse.co.uk> wrote:
>> As for the burden of ensuring that binaries installed to /{s,}bin don't
>> link to libs in /usr, why not just automate a QA check for that, and let
>> developers decide whether a fix is necessary? After all, core packages
>> that do that even when configured with prefix and execprefix = /, aren't
>> so portable, and Gentoo has always championed "doing the right thing" wrt
>> helping upstream fix portability issues.
> 
> The only issue with that logic is that upstream is perfectly aware of
> what they're doing already, and bugs are likely to be closed as
> WONTFIX.

It would only be for packages that are specifically marked, the ones you'd 
want in an initramfs. The "fix" is simply making sure the buildsystem 
doesn't look in /usr/lib etc when so marked, and checking that binaries 
don't link from / to anywhere but /lib*. If they do, it's up to the 
maintainer as to whether it's an issue.

You'd only file an upstream bug if the build-system was looking in /usr/lib 
despite being told not to (eg when only given -L /lib.) Making sure libs are 
available in the right location is down to the distro, same as for the 
initramfs.

> So, all the QA checks would do is ensure that we slowly
> start maintaining forks of more and more packages.  Right now the
> problem is probably manageable, but I'm not convinced it will stay
> that way.  Once upstream developers consider all constraints to be
> removed on their dependencies you could see a lot of stuff getting
> pulled into root if you tried to enforce this rule.
>
That might be true for some Linux-only packages, but I really find it hard 
to believe that any upstream targetting more than one OS (just adding a BSD 
is enough) with software that could be considered critical (I for one would 
include all POSIX utilities as well as basic stuff like mount, fsck and 
lvm2) would want to ignore this kind of thing; if the build-system is 
ignoring configuration, it's a bug.

Regardless of how Linux might move (and personally I think there is a lot 
more opposition to this than devs realise, as it throws the idea behind 
userspace compatibility completely out of the window, in that it massively 
impacts a generation of *nix working practices, even before one considers 
systemd's single-point of kitchen-sink failure) taking away choice from end-
users for no appreciable gain in functionality or efficiency seems like a 
bad idea.

I understand that the argument is "this is more efficient for our 
development" but we're not talking about every package in the tree. Just the 
binaries we might need in an initramfs; making sure their linkage is sound, 
is likely to be useful for that case too, since it's an even more restricted 
environment.

Wrt constraints on dependencies being removed, I don't really see that as 
upstream's job; they simply specify the dependencies required and where they 
actually are is up to the distro, and provided to the build by a mechanism 
like pkg-config, or just flags from the package manager. Distros always have 
been about managing dependencies for us.

> In any case, it sounds like the directive is to keep limping along for
> a while longer,

I read the decision from the Council to be "we will continue to support the 
traditional split /usr eg with lvm, and no initramfs" and a Council member 
put himself forward to maintain patches to udev to ensure that going 
forward, since it is needed in his employment.

Given that we can do it with initscripts, and don't need to fork udev at 
all, what's the problem?

It would only be for users who specifically opt in, knowing that they don't 
need udev to localmount, and with the awareness that they might need to 
configure things-- which any Gentoo user is used to hearing and evaluating.

> and that makes sense anyway until docs/etc are
> improved.  I agree with Ralph's suggestion that the newer initramfs
> tools should be stabilized as well.
> 
No argument on either of those.
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Rich Freeman]

On Wed, Apr 11, 2012 at 11:09 AM, Steven J Long
<slong@rathaus.eclipse.co.uk> wrote:
> That might be true for some Linux-only packages, but I really find it hard
> to believe that any upstream targetting more than one OS (just adding a BSD
> is enough) with software that could be considered critical (I for one would
> include all POSIX utilities as well as basic stuff like mount, fsck and
> lvm2) would want to ignore this kind of thing; if the build-system is
> ignoring configuration, it's a bug.

The issue is that if udev requires libfoo, then libfoo must not be in
/usr.  If libfoo is libx11 or dbus or some other complex library, that
will pull in a bunch of other stuff as well.  However, I doubt that
the maintainers of all those libraries would consider them
boot-essential, so they may not be inclined to make the move.

Obviously we're not there now, but it is a possible consequence of
moving in this direction.

Keep in mind that systemd in particular does not aim to be
cross-platform - they advertise this as one of their core features.
Since tight integration is their goal that could slowly bring in a lot
of other stuff.  The main platform pushing it along is Fedora, and
they're aiming to move everything into /usr, so this is a non-issue
for them.

> I read the decision from the Council to be "we will continue to support the
> traditional split /usr eg with lvm, and no initramfs" and a Council member
> put himself forward to maintain patches to udev to ensure that going
> forward, since it is needed in his employment.
>
> Given that we can do it with initscripts, and don't need to fork udev at
> all, what's the problem?

I can't really comment on what the decision from the Council actually
was.  However, maintaining patches to udev is effectively the same
thing as forking it.  Right now it probably isn't hard, and over time
that could change.

The only time patches != fork is if the patches have been submitted
upstream and are likely to be merged.

In any case, it isn't a crisis now and waiting a little to see which
way the wind ends up blowing probably makes sense.

Rich

[gentoo-dev] Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Steven J Long]

Rich Freeman wrote:

> On Wed, Apr 11, 2012 at 11:09 AM, Steven J Long wrote:
>> That might be true for some Linux-only packages, but I really find it
>> hard to believe that any upstream targetting more than one OS (just
>> adding a BSD is enough) with software that could be considered critical
>> (I for one would include all POSIX utilities as well as basic stuff like
>> mount, fsck and lvm2) would want to ignore this kind of thing; if the
>> build-system is ignoring configuration, it's a bug.
> 
> The issue is that if udev requires libfoo, then libfoo must not be in
> /usr.  If libfoo is libx11 or dbus or some other complex library, that
> will pull in a bunch of other stuff as well.  However, I doubt that
> the maintainers of all those libraries would consider them
> boot-essential, so they may not be inclined to make the move.
> 
> Obviously we're not there now, but it is a possible consequence of
> moving in this direction.
>
Sure, but I'm curious: how would you set up an initramfs under those 
conditions?

Where I'm going with this, is that in both cases (an initramfs or a 
traditional rootfs system) we need to be aware of what libs pull in what.
Given that, there is actually common work both sides need.

If we could focus on that, we'd all actually be cooperating to fix things 
for both setups, instead of arguing about which is best. :)

> Keep in mind that systemd in particular does not aim to be
> cross-platform - they advertise this as one of their core features.
> Since tight integration is their goal that could slowly bring in a lot
> of other stuff.  The main platform pushing it along is Fedora, and
> they're aiming to move everything into /usr, so this is a non-issue
> for them.
>
I have a feeling that "integration" is being used as an excuse to avoid 
thinking about coupling and cohesion.

>> I read the decision from the Council to be "we will continue to support
>> the traditional split /usr eg with lvm, and no initramfs" and a Council
>> member put himself forward to maintain patches to udev to ensure that
>> going forward, since it is needed in his employment.
>>
>> Given that we can do it with initscripts, and don't need to fork udev at
>> all, what's the problem?
> 
> I can't really comment on what the decision from the Council actually
> was.

Well, I've stated that several times now, and included the snippet from the 
log where Betelgeuse specifically asked Chainsaw to clarify that a 
"universal" minimal initramfs was not good enough, which was confirmed.

If Council members disagree with that interpretation, I'd welcome their 
clarification.

Split /usr with lvm was specifically discussed as a use-case, since it has 
been outlined in Gentoo documentation.

> However, maintaining patches to udev is effectively the same
> thing as forking it.  Right now it probably isn't hard, and over time
> that could change.
> 
> The only time patches != fork is if the patches have been submitted
> upstream and are likely to be merged.
>
udev != openrc or any other init system, which is what we are patching[1] so 
that udev is not started til after localmount, should the user set a 
currently unsupported udev.conf option (initramfs="no").

We're only making minor shell-script modifications to udev and udev-mount 
initscripts, not openrc itself.

Earlymounts[2] is simply an additional initscript.

IOW no patches to udev whatsoever, so no fork.

> In any case, it isn't a crisis now and waiting a little to see which
> way the wind ends up blowing probably makes sense.
> 
No indeed: those of us who wish to stay with our traditional setup, who have 
already configured our machines to localmount with built-in modules, can use 
the patched initscripts/earlymounts. What we'd like is for those, or 
equivalent functionality, to be maintained within Gentoo so we don't have to 
tweak patches whenever udev-init-scripts is updated, or in the earlymounts 
case there appear to be more issues, and those could use input from devs 
imo.

I prefer the patched approach, even if it is a bit more setup and I am 
biased, since it appears to have less potential for interaction with other 
stuff: if you never needed an initramfs before, and can localmount with just 
kernel-created device-nodes (eg: you need to change fstab from using 
/dev/vg/lv to /dev/mapper/vg-lv for lvm), then you're fine.

[1] http://forums.gentoo.org/viewtopic-t-901206.html
[2] http://forums.gentoo.org/viewtopic-t-918466.html
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[William Hubbs]

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

On Sun, Apr 08, 2012 at 03:04:22PM -0700, Greg KH wrote:
> On Sun, Apr 08, 2012 at 04:30:01PM +0200, Ulrich Mueller wrote:
> > New udev and separate /usr partition
> > ====================================
> > Decide on whether a separate /usr is still a supported configuration.
> > If it is, newer udev can not be stabled and alternatives should be
> > investigated. If it isn't, a lot of documentation will have to be
> > updated. (And an alternative should likely still be provided.)

There is no disagreement about whether or not separate /usr will be
supported. No one has said that you can't have a separate /usr
partition.

Was the council aware of the tracker bug we have open where we are
tracking the documentation changes explaining how to build an initramfs
if you have a separate /usr partition [1]?

Also, I am going to reiterate what Greg said. This is not an issue with
udev, but with the entire linux ecosystem.
There are binaries in /{bin,sbin} which link against libraries in
/usr/lib for example.

Also, with the appropriate documentation changes, which are being worked
on (see [1]), I feel that the statement above that newer udev can't be
stabled should be re-evaluated.

William

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

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

Re: [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Ralph Sennhauser]

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

On Tue, 10 Apr 2012 13:45:04 -0500
William Hubbs <williamh@gentoo.org> wrote:

> On Sun, Apr 08, 2012 at 03:04:22PM -0700, Greg KH wrote:
> > On Sun, Apr 08, 2012 at 04:30:01PM +0200, Ulrich Mueller wrote:
> > > New udev and separate /usr partition
> > > ====================================
> > > Decide on whether a separate /usr is still a supported
> > > configuration. If it is, newer udev can not be stabled and
> > > alternatives should be investigated. If it isn't, a lot of
> > > documentation will have to be updated. (And an alternative should
> > > likely still be provided.)
> 
> There is no disagreement about whether or not separate /usr will be
> supported. No one has said that you can't have a separate /usr
> partition.
> 

Isn't meant /usr without initramfs, independent of how "broken" some
people precieve it?

> Was the council aware of the tracker bug we have open where we are
> tracking the documentation changes explaining how to build an
> initramfs if you have a separate /usr partition [1]?
> 

That's an effort I welcome either way. So thanks for that.

> Also, I am going to reiterate what Greg said. This is not an issue
> with udev, but with the entire linux ecosystem.
> There are binaries in /{bin,sbin} which link against libraries in
> /usr/lib for example.
> 

With udev-182 its no longer only the ecosystem which produce some
broken products but udev itself which is broken. Otherwise we would
have gone on like we always did, right?

> Also, with the appropriate documentation changes, which are being
> worked on (see [1]), I feel that the statement above that newer udev
> can't be stabled should be re-evaluated.
> 

Long term newer udevs will be stabilized and I'm positive it wont take
as long as grub2 or portage-2.2 ;)

There is no particular hurry as far as I know so let's give Chainsaw
some time to look into an udev patch and don't go with the 30 day
with bug fixing rule.

Support for initramfs was rather poor until recently. For instance
dracut-0.17-r3 (haven't tested 0.18 so far) was the first to actually
produce a usable initramfs for me. Thus far I crafted them manually if
needed. Personally I would like to see the initramfs situation further
improved, this includes genkernel and dracut stable on all platforms and
then give it time to let the knowlage spread or alternatively an udev
patch which allows current setups to continue to work before the
council re-evaluates the udev stabilization again.

Cheers
Ralph

> William
> 
> [1] https://bugs.gentoo.org/show_bug.cgi?id=407959

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

Re: [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Luca Barbato]

On 10/04/12 11:45, William Hubbs wrote:
> Also, I am going to reiterate what Greg said. This is not an issue with
> udev, but with the entire linux ecosystem.

As in bluez using dbus and some mount helpers requiring libraries in /usr.

> There are binaries in /{bin,sbin} which link against libraries in
> /usr/lib for example.

We could try to have an exact list and figure out exactly what is it and
how impacting it is. If any of those are needed for early-boot it would
be something to address nonetheless.

> Also, with the appropriate documentation changes, which are being worked
> on (see [1]), I feel that the statement above that newer udev can't be
> stabled should be re-evaluated.

lu

-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

Re: [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Michał Górny]

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

On Sat, 28 Apr 2012 16:44:57 -0700
Luca Barbato <lu_zero@gentoo.org> wrote:

> On 10/04/12 11:45, William Hubbs wrote:
> > There are binaries in /{bin,sbin} which link against libraries in
> > /usr/lib for example.
> 
> We could try to have an exact list and figure out exactly what is it
> and how impacting it is. If any of those are needed for early-boot it
> would be something to address nonetheless.

I have already opened bugs for many of them. But the list will increase
in time, and we'll either move a lot of libraries to /lib* or decide to
go the other way.

Did someone mentioned mentioning two cross-linked program/data trees
(well, three or four in our case) with fuzzy classification rules is
against KISS?

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Luca Barbato]

On 28/04/12 23:44, Michał Górny wrote:
> I have already opened bugs for many of them. But the list will increase
> in time, and we'll either move a lot of libraries to /lib* or decide to
> go the other way.

repeat after me EARLY BOOT, as in initramfs. In initramfs you don't have
/usr with everything there because you are supposed to mount it. If you
need something (e.g. a mount helper using libs living somewhere) you
need to put it there, if you don't have a way to be aware of which is
where then you'll have users experiencing problems.

The proper way to fix it is either fix the programs or find replacement
that have less or no dependencies.

> Did someone mentioned mentioning two cross-linked program/data trees
> (well, three or four in our case) with fuzzy classification rules is
> against KISS?

Enumerate them, I'm sick of vague problems.

lu

-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

Re: [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Zac Medico]

On 04/29/2012 12:04 AM, Luca Barbato wrote:
> On 28/04/12 23:44, Michał Górny wrote:
>> I have already opened bugs for many of them. But the list will increase
>> in time, and we'll either move a lot of libraries to /lib* or decide to
>> go the other way.
> 
> repeat after me EARLY BOOT, as in initramfs. In initramfs you don't have
> /usr with everything there because you are supposed to mount it. If you
> need something (e.g. a mount helper using libs living somewhere) you
> need to put it there, if you don't have a way to be aware of which is
> where then you'll have users experiencing problems.
> 
> The proper way to fix it is either fix the programs or find replacement
> that have less or no dependencies.

Maybe it's reasonable for the initramfs to utilize a config file from
/etc of the future root filesystem, but having in depend on files from
the future /usr seems like a strange idea. Wouldn't it make more sense
to bundle all dependencies into the initramfs, so that it's mostly
self-contained, rather than have it be dependent on files from the
future root filesystem (or future /usr)?
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Luca Barbato]

On 29/04/12 15:40, Zac Medico wrote:
> Maybe it's reasonable for the initramfs to utilize a config file from
> /etc of the future root filesystem, but having in depend on files from
> the future /usr seems like a strange idea. Wouldn't it make more sense
> to bundle all dependencies into the initramfs, so that it's mostly
> self-contained, rather than have it be dependent on files from the
> future root filesystem (or future /usr)?

Well it is a bit unreasonable even rely on foreign /etc.

The root problem is that what you want to use for early boot should not
have huge deps and that assumption fails for a number of reasons, I
guess mostly due the fact who writes some software doesn't expect it to
be run on early boot =\

lu

-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero