Kent Fredric posted on Thu, 15 Mar 2012 09:10:53 +1300 as excerpted:
> On 15 March 2012 07:48, Duncan <1i5t5.dun...@cox.net> wrote:
>> It does, especially when it's literally the case, including a /usr/etc
>> bind-mounted on a tmpfs-based rootfs, that by login time, all that's
>> visible of rootfs
On 3/14/12 10:59 AM, Rich Freeman wrote:
Well, anybody is welcome to create any replacement/addition for
(/usr)/sbin/init or (/usr)/sbin/rc that they wish. If you make it
good enough, perhaps others will even use it.
There is a SoC out there for that.
Beyond that, anything else is just a sug
On 3/14/12 4:37 PM, Greg KH wrote:
Not really, I don't think we support systems without udev anymore,
right? And we get away with a lot of these different "options" at
compile time, which makes it easier than what Debian has to handle, so
perhaps it's not a fair comparison.
I think we support
On 3/14/12 10:58 AM, Matthew Summers wrote:
__Everyone__ is already using an initramfs, therefore there are no
initramfs-less systems anymore (it may just be empty). Every single
person reading this thread that has not already done so needs to
immediately go read the relevant documentation locat
On 03/14/2012 02:05 PM, Richard Yao wrote:
> How did RedHat justify that lack of conformity that resulted from moving
> everything into /usr in the first place?
Does it really matter? What people in the
separate-/usr-without-initramfs camp really want is continued support
for the "/ is a self-cont
On 03/14/12 21:06, Zac Medico wrote:
> On 03/14/2012 05:58 PM, Richard Yao wrote:
>> On 03/14/12 20:36, David Leverton wrote:
>>> On 14 March 2012 23:47, Zac Medico wrote:
It's more about what we're _not_ doing that what we're doing.
>>>
>>> Clearly something must have changed in udev 181 to
On 03/14/12 21:07, Rich Freeman wrote:
> On Wed, Mar 14, 2012 at 7:51 PM, Richard Yao wrote:
>>
>> I proposed a way that this could work with no effort on the part of the
>> Gentoo developers in one of my earlier emails:
>>
>
> Then go ahead and make it happen. If as you say no dev participation
On 03/14/2012 06:07 PM, Rich Freeman wrote:
> For those who don't like the current direction, by all means create an
> overlay called udev-root, mdev-boot, noinitramfs, or whatever.
The simplest alternative to an initramfs that I can think of would be an
init wrapper like the one that I suggested
On Wed, Mar 14, 2012 at 7:51 PM, Richard Yao wrote:
>
> I proposed a way that this could work with no effort on the part of the
> Gentoo developers in one of my earlier emails:
>
Then go ahead and make it happen. If as you say no dev participation
is needed there is nothing Gentoo needs to do to
On 03/14/2012 05:58 PM, Richard Yao wrote:
> On 03/14/12 20:36, David Leverton wrote:
>> On 14 March 2012 23:47, Zac Medico wrote:
>>> It's more about what we're _not_ doing that what we're doing.
>>
>> Clearly something must have changed in udev 181 to make
>> /usr-without-initramfs not work anym
On 03/14/12 20:36, David Leverton wrote:
> On 14 March 2012 23:47, Zac Medico wrote:
>> It's more about what we're _not_ doing that what we're doing.
>
> Clearly something must have changed in udev 181 to make
> /usr-without-initramfs not work anymore, and someone must have done
> something to ma
On 15 March 2012 00:45, Zac Medico wrote:
> You're pointing your finger at udev, but the udev change is just a
> symptom of a more general shift away from supporting the "/ is a
> self-contained boot disk that is independent of /usr" use case.
OK, so there are multiple instances of people not not
On 03/14/2012 05:36 PM, David Leverton wrote:
> On 14 March 2012 23:47, Zac Medico wrote:
>> It's more about what we're _not_ doing that what we're doing.
>
> Clearly something must have changed in udev 181 to make
> /usr-without-initramfs not work anymore, and someone must have done
> something
On 14 March 2012 23:47, Zac Medico wrote:
> It's more about what we're _not_ doing that what we're doing.
Clearly something must have changed in udev 181 to make
/usr-without-initramfs not work anymore, and someone must have done
something to make that change happen, unless udev has aquired the
a
On 14 March 2012 23:44, Greg KH wrote:
> Oh, and somehow "consensus" will work? No, sorry, it will not.
No, logical analysis will, as I said in the rest of my post which you
conveniently ignored - either we conclude with evidence that there are
no issues, which should settle the matter for reaso
On Wed, Mar 14, 2012 at 07:58:23PM -0400, Richard Yao wrote:
> On 03/14/12 19:44, Greg KH wrote:
> > Now, to get back to what I said before, I'm done with this thread, it's
> > going nowhere, and it seems I'm just making it worse, my apologies. For
> > penance, I'll adopt the next abandoned packag
On 03/14/12 19:44, Greg KH wrote:
> Now, to get back to what I said before, I'm done with this thread, it's
> going nowhere, and it seems I'm just making it worse, my apologies. For
> penance, I'll adopt the next abandoned package someone throws at me, any
> suggestions?
Bug #360513 needs work. S
On 03/14/12 19:37, Greg KH wrote:
>> Portage provides use with the ability to do abstractions that other
>> distributions cannot do, such as permitting people to merge
>> /usr{bin,lib{32,64,},sbin} into /.
>
> Sure, but that doesn't mean that the packages that are being merged will
> actually work
On 03/14/2012 04:21 PM, David Leverton wrote:
> On 14 March 2012 22:51, Greg KH wrote:
>> Oh, that's simple, separate-/usr-without-initramfs will not work and
>> will not be supported :)
>
> See, it's this "we're doing it this way because we know best and we
> say so" that upsets people.
It's mo
On Wed, Mar 14, 2012 at 11:21:44PM +, David Leverton wrote:
> On 14 March 2012 22:51, Greg KH wrote:
> > Oh, that's simple, separate-/usr-without-initramfs will not work and
> > will not be supported :)
>
> See, it's this "we're doing it this way because we know best and we
> say so" that ups
On Wed, Mar 14, 2012 at 07:27:07PM -0400, Richard Yao wrote:
> >> 3. Why not let the users choose where these directories go and support
> >> both locations?
> >
> > Because a plethera of options is a sure way to make sure that half of
> > them don't work over the long run.
> >
> > We aren't Debi
On 03/14/12 18:49, Greg KH wrote:
> On Wed, Mar 14, 2012 at 06:39:05PM -0400, Richard Yao wrote:
>> With that said, I have a few questions:
>>
>> 1. Why does no one mention the enterprise use case at all?
>
> It has been pointed out before, why constantly repeat ourselves.
Simple. No one has docu
On 14 March 2012 22:51, Greg KH wrote:
> Oh, that's simple, separate-/usr-without-initramfs will not work and
> will not be supported :)
See, it's this "we're doing it this way because we know best and we
say so" that upsets people. I'm trying to encourage everyone to get
to the core reasons for
On Wed, Mar 14, 2012 at 10:14:54PM +, David Leverton wrote:
> On 14 March 2012 21:04, Greg KH wrote:
> > Haveing a separate /usr is wonderful, and once we finish moving /sbin/
> > and /bin/ into /usr/ it makes even more sense. See the /usr page at
> > fedora for all of the great reasons why t
On Wed, Mar 14, 2012 at 06:39:05PM -0400, Richard Yao wrote:
> Is this that page?
>
> http://fedoraproject.org/wiki/Features/UsrMove
>
> That refers to the systemd website on freedesktop.org.
>
> http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
Yes.
> With that said, I ha
On 03/14/12 17:04, Greg KH wrote:
> On Wed, Mar 14, 2012 at 07:57:52PM +, David Leverton wrote:
>> Would anyone else like to continue with their own favourite
>> separate-/usr reason?
>
> Haveing a separate /usr is wonderful, and once we finish moving /sbin/
> and /bin/ into /usr/ it makes eve
On 14 March 2012 21:04, Greg KH wrote:
> Haveing a separate /usr is wonderful, and once we finish moving /sbin/
> and /bin/ into /usr/ it makes even more sense. See the /usr page at
> fedora for all of the great reasons why this is good.
My point was examine, in detail, whether separate-/usr-wit
On Wed, Mar 14, 2012 at 08:07:07AM -0400, Joshua Kinard wrote
> Ah, bluetooth keyboards. The luddite in me finds those quite
> the oddity. I still use only PS/2, specifically because it's less
> complex and less likely to fail on me in a time of need.
Unicomp has licenced manufacturing rights
On 03/14/12 16:55, Zac Medico wrote:
> On 03/14/2012 01:03 PM, Richard Yao wrote:
>> I do not have a separate /usr partition, however I agree with Joshua
>> Kinard's stance regarding the /usr move. The point of having a separate
>> /usr was to enable UNIX to exceed the space constraints that a 1.5M
On Wed, Mar 14, 2012 at 07:57:52PM +, David Leverton wrote:
> Would anyone else like to continue with their own favourite
> separate-/usr reason?
Haveing a separate /usr is wonderful, and once we finish moving /sbin/
and /bin/ into /usr/ it makes even more sense. See the /usr page at
fedora f
On Wed, Mar 14, 2012 at 03:59:56PM +, Ciaran McCreesh wrote:
> On Wed, 14 Mar 2012 08:22:09 -0700
> Greg KH wrote:
> > The people doing the work today do understand them, by virtue of
> > doing the work involved, which gives them the say in how it is done.
> > That's how open source works, why
On 03/14/2012 01:03 PM, Richard Yao wrote:
> On 03/14/12 14:56, Zac Medico wrote:
>> On 03/14/2012 11:36 AM, Maxim Kammerer wrote:
>>> On Wed, Mar 14, 2012 at 19:58, Matthew Summers
>>> wrote:
Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite
nice to have a minimal rec
On Wed, Mar 14, 2012 at 08:04:31AM -0700, Greg KH wrote
> On Wed, Mar 14, 2012 at 10:51:44AM -0400, Philip Webb wrote:
> > 120314 Greg KH wrote:
> > > if you have /usr on a different filesystem today, with no initrd,
> > > your machine could be broken and you don't even know it.
> >
> > Whatever d
On 15 March 2012 07:48, Duncan <1i5t5.dun...@cox.net> wrote:
> It does, especially when it's literally the case, including a /usr/etc
> bind-mounted on a tmpfs-based rootfs, that by login time, all that's
> visible of rootfs is mountpoints, nothing else, and /usr literally IS the
> "unified system
On 03/14/12 14:56, Zac Medico wrote:
> On 03/14/2012 11:36 AM, Maxim Kammerer wrote:
>> On Wed, Mar 14, 2012 at 19:58, Matthew Summers
>> wrote:
>>> Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite
>>> nice to have a minimal recovery env in case mounting fails, etc, etc,
>>> et
On 14 March 2012 18:56, Zac Medico wrote:
> Whatever the arguments may be, the whole discussion boils down to the
> fact that the only people who seem to have a "problem" are those that
> have a separate /usr partition and simultaneously refuse to use an
> initramfs.
I wonder if it might help to
On Wed, 14 Mar 2012 12:58:26 -0500
Matthew Summers wrote:
> __Everyone__ is already using an initramfs, therefore there are no
> initramfs-less systems anymore (it may just be empty).
I happen to understand you're not attempting to start a flame war here,
but it may not obvious to everyone.
On 03/14/2012 12:14 PM, Michael Orlitzky wrote:
> On 03/14/12 14:56, Zac Medico wrote:
>> On 03/14/2012 11:36 AM, Maxim Kammerer wrote:
>>> On Wed, Mar 14, 2012 at 19:58, Matthew Summers
>>> wrote:
Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite
nice to have a minima
On 03/14/12 14:56, Zac Medico wrote:
> On 03/14/2012 11:36 AM, Maxim Kammerer wrote:
>> On Wed, Mar 14, 2012 at 19:58, Matthew Summers
>> wrote:
>>> Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite
>>> nice to have a minimal recovery env in case mounting fails, etc, etc,
>>> et
On 03/14/2012 11:36 AM, Maxim Kammerer wrote:
> On Wed, Mar 14, 2012 at 19:58, Matthew Summers
> wrote:
>> Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite
>> nice to have a minimal recovery env in case mounting fails, etc, etc,
>> etc.
>
> There is nothing bad about initramfs
Zac Medico posted on Wed, 14 Mar 2012 10:52:48 -0700 as excerpted:
> On 03/14/2012 05:00 AM, James Cloos wrote:
>>> "MS" == Marc Schiffbauer writes:
>>
>> MS> IIRC usr = unified system resources (not an abbrev. for "user")
>> Before sysv created /home, bsd used /usr for user dirs.
> Anyway
Joshua Kinard posted on Wed, 14 Mar 2012 08:07:07 -0400 as excerpted:
> Ah, bluetooth keyboards. The luddite in me finds those quite the
> oddity.
> I still use only PS/2, specifically because it's less complex and less
> likely to fail on me in a time of need.
>
> Or, put more comically:
> http
On Wed, Mar 14, 2012 at 19:58, Matthew Summers
wrote:
> __Everyone__ is already using an initramfs, therefore there are no
> initramfs-less systems anymore (it may just be empty).
I suggest that you take a look at CONFIG_BLK_DEV_INITRD.
> Why is an in-kernel initramfs so bad anyway? I am baffled
On Wed, 14 Mar 2012 12:58:26 -0500
Matthew Summers wrote:
> Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite
> nice to have a minimal recovery env in case mounting fails, etc, etc,
> etc.
Because the initramfs is just replacing what / used to be, and it's
even less well handle
On Wed, Mar 14, 2012 at 1:29 PM, Zac Medico wrote:
> On 03/14/2012 10:11 AM, Maxim Kammerer wrote:
>> What's wrong with:
>> * having an "early mounts" list file
>> * having an "early modules" list file
>> * init system in early boot (e.g., OpenRC in init.sh) loading "early
>> modules" and mo
On Wed, Mar 14, 2012 at 12:29 PM, Zac Medico wrote:
> On 03/14/2012 10:11 AM, Maxim Kammerer wrote:
>> What's wrong with:
>> * having an "early mounts" list file
>> * having an "early modules" list file
>> * init system in early boot (e.g., OpenRC in init.sh) loading "early
>> modules" and m
On 03/14/2012 05:00 AM, James Cloos wrote:
>> "MS" == Marc Schiffbauer writes:
>
> MS> IIRC usr = unified system resources (not an abbrev. for "user")
>
> Nope. It is in fact for user.
>
> Before sysv created /home, bsd used /usr for user dirs.
>
> /usr/bin et all came later.
Anyway, "un
On 03/14/2012 10:11 AM, Maxim Kammerer wrote:
> What's wrong with:
> * having an "early mounts" list file
> * having an "early modules" list file
> * init system in early boot (e.g., OpenRC in init.sh) loading "early
> modules" and mounting "early mounts" from /etc/fstab
You're assuming that
On Wed, Mar 14, 2012 at 17:22, Greg KH wrote:
> As for "fixing this", see the oft-linked webpage as to why it can't be
> fixed easily, if at all, and honestly, I don't think it needs to be
> fixed.
What's wrong with:
* having an "early mounts" list file
* having an "early modules" list file
On Wed, Mar 14, 2012 at 10:22 AM, Greg KH wrote:
> On Wed, Mar 14, 2012 at 03:08:27PM +, Ciaran McCreesh wrote:
>> On Wed, 14 Mar 2012 08:04:31 -0700
>> Greg KH wrote:
>> > Not always, no, it isn't obvious that something didn't start up
>> > correctly, or that it didn't fully load properly.
On Wed, 14 Mar 2012 08:22:09 -0700
Greg KH wrote:
> The people doing the work today do understand them, by virtue of
> doing the work involved, which gives them the say in how it is done.
> That's how open source works, why is this ever a surprise to people?
The problem is that when a small numbe
On Wed, Mar 14, 2012 at 03:08:27PM +, Ciaran McCreesh wrote:
> On Wed, 14 Mar 2012 08:04:31 -0700
> Greg KH wrote:
> > Not always, no, it isn't obvious that something didn't start up
> > correctly, or that it didn't fully load properly. Some programs later
> > on recover and handle things bet
On Wed, 14 Mar 2012 08:04:31 -0700
Greg KH wrote:
> Not always, no, it isn't obvious that something didn't start up
> correctly, or that it didn't fully load properly. Some programs later
> on recover and handle things better.
So why not work on fixing those things, since they're clearly symptom
On Wed, Mar 14, 2012 at 10:51:44AM -0400, Philip Webb wrote:
> 120314 Greg KH wrote:
> > if you have /usr on a different filesystem today, with no initrd,
> > your machine could be broken and you don't even know it.
>
> Whatever do you mean ? -- if it were truly broken,
> it wouldn't perform in so
120314 Greg KH wrote:
> if you have /usr on a different filesystem today, with no initrd,
> your machine could be broken and you don't even know it.
Whatever do you mean ? -- if it were truly broken,
it wouldn't perform in some important & obvious respect.
Do you mean "insecure" ? -- if so, what i
On Wed, Mar 14, 2012 at 08:40:46AM -0400, Joshua Kinard wrote:
> I chose to stick with Gentoo as my distro of choice because I didn't like
> the way Red Hat did things years ago. As well as a few other nitpicks I
> have. It bugs me to no end that, despite running a fairly vanilla setup on
> a sou
On Tue, Mar 13, 2012 at 8:29 PM, Joshua Kinard wrote:
>
> My contention is that I shouldn't need an initramfs loaded into my kernel to
> get my system into a minimally-usable state. I've been running separate
> /usr setups for 10+ years, and only now, such a setup breaks, hence my beef
> with Fed
On 03/14/2012 04:39, Duncan wrote:
>
> THAT is why they're moving /bin, /sbin and /lib to /usr rather than the
> other direction. rootfs will be ONLY a mountpoint, with even /etc/ being
> bind-mounted from /usr/etc, and all system data unified on /usr,
> including /etc.
>
> Viewed from that
On 03/14/2012 04:03, Duncan wrote:
>
> Bluez is a critical system service if that's your keyboard and you need
> to do init-diagnostics. Dbus isn't... yet... but it's likely to be, for
> some people at least, within a couple years, as systemd's going to be
> using it, and other init services
> "MS" == Marc Schiffbauer writes:
MS> IIRC usr = unified system resources (not an abbrev. for "user")
Nope. It is in fact for user.
Before sysv created /home, bsd used /usr for user dirs.
/usr/bin et all came later.
-JimC
--
James Cloos OpenPGP: 1024D/ED7DAEA6
On 3/11/12 6:27 PM, Mike Gilbert wrote:
> I moved some of the functions currently implemented in the ebuilds for
> www-client/chromium and www-client/google-chrome into a new eclass
> "chromium.eclass".
LGTM (Looks Good To Me).
It seems no one else commented on this one, so I'm totally fine with
Joshua Kinard posted on Tue, 13 Mar 2012 20:16:10 -0400 as excerpted:
> On 03/13/2012 07:54, James Broadhead wrote:
>
>> I believe that the Art of Unix Programming* says that /usr was the
>> result of the original UNIX 4MB hard disk becoming full, and that they
>> chose /usr to mount a second one
Joshua Kinard posted on Tue, 13 Mar 2012 20:13:53 -0400 as excerpted:
> On 03/13/2012 01:11, Luca Barbato wrote:
>
>> Our current init system doesn't have any problem with /usr being
>> mounted later, but udev might have issues.
>>
>> Same could be said about bluez and dbus.
>
> bluez and dbus
63 matches
Mail list logo
