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-contained boot disk that is independent of /usr"
use case, because without such support, the
separate-/usr-without-initramfs approach that they're accustomed to
becomes impossible.
The /usr merge [1] can be viewed as just one of many signs of a
widespread shift away from supporting the heavy burden of the "/ is a
self-contained boot disk that is independent of /usr" use case.
__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 located in
/usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt,
then and only then can a real discourse be had.
Yawn, I don't and I won't since I don't need it. Why should I?
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 at least for me is *totally* pointless.
My main system is with a single partition so I shouldn't care much, I
have a system that has a separate /usr so probably I'll have *some* pain
once I'll upgrade it if I don't merge /usr and / partitions before.
Still the whole idea brings us back to the freebsd "everything in /usr"
while would make more sense go the hurd way "everything in /" if there
is a sound reason to merge those. Beside the whole
/usr/share/id-data-du-jour-my-udev-rule-might-need and the I-want-glib
and I-want-dbus bandwagon I hadn't seen any compelling reason.
Having anything as complex as dbus for early boot sounds dangerous or frail.
lu
03-15-2012, 04:18 AM
Luca Barbato
Let's redesign the entire filesystem!
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 systems with launchd and devd quite well and we'd
love to support even some more.
Sure, but that doesn't mean that the packages that are being merged will
actually work
Only if upstream really wants to break them... And that is the perceived
situation, exacerbated by the past experience with a certain audio
daemon trying to do too much at the same time.
lu
03-15-2012, 04:24 AM
Luca Barbato
Let's redesign the entire filesystem!
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 suggestion. In the end the folks
writing udev and systemd are writing code, which gets them a lot
further than emails do...
People might be happy with what they have and might feel a bit
threatened when they have to switch away from the DE they like because
it forces on them an init system that they hate.
lu
03-15-2012, 07:13 AM
Martin Gysel
Let's redesign the entire filesystem!
Am 15.03.2012 00:37, schrieb Greg KH:
> 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.
Sure Gentoo does support such systems...
# equery g virtual/dev-manager
* Searching for dev-manager in virtual ...
>
> 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.
I'm well aware of what I run on my own box, and when something isn't
running, I figure it out pretty quickly. I tested udev-181 in a Gentoo VM
that I put together recently, giving it a separate /usr, and made sure that
CONFIG_DEVTMPFS was enbaled. The only service that failed to load properly
at startup was udev, specifically because udevadm couldn't locate libkmod
(likely because kmod installs into /usr/lib*, which wasn't available yet
because I also don't use an initramfs in my kernel). Everything else worked
fine, and udev later started properly once localmount was complete.
I even tried, out of curiosity, to tweak things and moved udev from sysinit
to boot and then to default runlevel. In 'boot', udevadm still fails to
load, so no change. In 'default', only net.lo failed because the 'lo'
device didn't yet exist until after udev was running. udev itself loaded
fine, and the networking scripts restarted themselves.
So with the one exception of networking, which in Linux, has never created
/dev nodes (has to be some historical piece on why), one almost doesn't need
udev at boot to even get things working on a very simple setup like mine.
And since udev is the one service that didn't load correctly, one COULD put
forth the hypothesis that it is udev that is "broken". But I doubt that
will get much traction, right?
This does lead me to wonder if a light-weight udev could exist that lacks
half or more of the functionality of the current udev. I'll be honest, I've
only edited my udev rules file once, and that was only when I installed a
Sun Happy Meal quad ethernet card in which all four ports utilize the same
MAC address and udev doesn't handle this very gracefully (if I had Solaris,
I could edit the card's firmware and change this setting).
Devtmpfs quite literally handles 98% of my particular usage scenario. Does
that apply to everyone? Nope. Just an interesting observation.
"The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
03-15-2012, 10:20 AM
Stelian Ionescu
Let's redesign the entire filesystem!
On Thu, 2012-03-15 at 00:29 +0000, David Leverton wrote:
> On 14 March 2012 23:44, Greg KH <gregkh@gentoo.org> 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 reasonable people, or we
> discover that there are, in which case they have to be dealt with one
> way or another. I really don't see how anyone can object to that,
> unless they're worried they won't like the result....
>
> > How about the basic FACT that today, such systems do not work
>
> This is debatable at best. You can keep screaming "but bluetooth
> won't work!" until you're blue in the face, but that's not relevant at
> all to people who don't use bluetooth.
That's true, but given the need to have a "one size fits all" boot
system(for obvious practical reasons), such boot system needs to work
with bluetooth input devices
--
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
http://common-lisp.net/project/iolib
03-15-2012, 11:09 AM
Joshua Kinard
Let's redesign the entire filesystem!
On 03/14/2012 18:14, David Leverton wrote:
> On 14 March 2012 21:04, Greg KH <gregkh@gentoo.org> 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-with-initramfs
> has any disadvantages compared to separate-/usr-without-initramfs.
> Either it has, in which case we have a concrete argument against
> requiring initramfs (albeit possibly one that can be fixed), or it
> hasn't, which should hopefully convince at least some people to accept
> it.
I went with a split filesystem design when I built my first Gentoo install
back in mid 2003 because at the time, both the Gentoo and Debian security
guides referenced it as being an option for a more secure system.
Specifically so that you could apply mount options to each partition. For
example, on /home, you would usually want to do nodev and nosuid, because
rarely does a user need the ability to create device nodes and SUID
binaries. On /var, nodev, nosuid, and noexec, with the one exception if you
ran qmail or a few other packages known to stick executables into /var. For
/usr, the guides suggested just nodev, because you rarely, if ever need to
create device nodes in /usr. Optionally, you could mount /usr ro and only
make it rw if updating packages.
You won't find A separate /usr mentioned specifically anymore in either
security guide, but I'm sure if you dig on the Wayback Machine (once it
comes back online), you can probably find these references. Search from
2003 to 2007. I'm not certain when they were removed.
"The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
03-15-2012, 11:16 AM
Joshua Kinard
Let's redesign the entire filesystem!
On 03/14/2012 18:51, Greg KH wrote:
> On Wed, Mar 14, 2012 at 10:14:54PM +0000, David Leverton wrote:
>> On 14 March 2012 21:04, Greg KH <gregkh@gentoo.org> 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-with-initramfs
>> has any disadvantages compared to separate-/usr-without-initramfs.
>
> Oh, that's simple, separate-/usr-without-initramfs will not work and
> will not be supported
"The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
03-15-2012, 11:23 AM
Joshua Kinard
Let's redesign the entire filesystem!
On 03/15/2012 07:20, Stelian Ionescu wrote:
> On Thu, 2012-03-15 at 00:29 +0000, David Leverton wrote:
>> On 14 March 2012 23:44, Greg KH <gregkh@gentoo.org> 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 reasonable people, or we
>> discover that there are, in which case they have to be dealt with one
>> way or another. I really don't see how anyone can object to that,
>> unless they're worried they won't like the result....
>>
>>> How about the basic FACT that today, such systems do not work
>>
>> This is debatable at best. You can keep screaming "but bluetooth
>> won't work!" until you're blue in the face, but that's not relevant at
>> all to people who don't use bluetooth.
>
> That's true, but given the need to have a "one size fits all" boot
> system(for obvious practical reasons), such boot system needs to work
> with bluetooth input devices
With Gentoo, that's really only for the preliminary installation. Once you
get the system up and running, you're free to modify it in whatever way
pleases you.
For binary distributions, especially those that deal in the enterprise
sector, the one-size-fits-all approach is damn near mandatory because most
admins run with the distro-provided kernel and typically are not custom
compiling them.
But we're not a binary distro. We're a source-based distro, although it's
possible to run Gentoo in a binary fashion. As such, we're not necessarily
beholden to the "one-size-fits-all" approach.
"The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between."
Let's redesign the entire filesystem!
