On Sun, 2012-01-01 at 15:33 +0800, Patrick Lauer wrote:
> On 01/01/12 15:12, Olivier Crête wrote:
> > Hi,
> > On Sat, 2011-12-31 at 19:59 -0600, William Hubbs wrote:
> >> I have been working with robbat2 on solutions to the separate /usr issue
> >> (That is why I have specifically cc'd him on this email)
> >> which will allow people to not use an initramfs. If we migrate
> >> everything off of the root fs to /usr, all of those solutions become
> >> moot. On the other hand, if we don't migrate, we run the risk of
> >> eventually having our default configuration not supported by upstream.
> > I think the general consensus among other distros is that initramfs is
> > the new /. Many core elements of the Linux system will start installing
> > themselves in /usr, starting with udev, so we won't have a choice
> > anyway. Also, I doubt it's currently possible to boot a Gentoo system
> > without /usr mounted anyway.
> "initramfs is the new /" ... and no one asked if maybe that doesn't
> really make sense?
> That people are now actively working on forcing one big system partition
> is annoying, but I really don't see the need to add a layer or two of
> complexification just because, well, why not.
We're absolutely not forcing a single system partition. We're just
saying that the bits required to mount all the partitions you want
should be in an initramfs.
> >> 1) Start migrating packages along with upstream and have everyone who
> >> has a separate /usr (including me by the way) start using an initramfs
> >> of some kind, either dracut or one that we generate specifically for
> >> gentoo. The reason I suggest the initramfs, is, unfortunately if we
> >> migrate everything, nothing else would work.
> > I also don't see a good reason to not adopt dracut,
> Make it work and I'll reconsider it, until then genkernel wins by default.
> > re-implementing
> > something that already works and is maintained by a competent upstream
> > seems wasteful to me. I really don't see why people resist using an
> > initramfs so much.
> What does it add, apart from time to the boot process? For some setups
> (like my notebook with luks+lvm) there's no reasonable way around it,
> but on my desktop it's worse than useless.
I don't see how it adds time to the boot process. Either you have a
single big partition (and then you don't even need an initramfs), or you
have multiple partitions and then most of the time is mounting them
> > The udev/kmod/systemd/dracut effort to standardise the base userspace of
> > Linux is probably scary for quite a few Gentoo-ers as it means that the
> > end result of an installed Gentoo system will be less differentiated
> > than it was before. But it still is a step in the right direction as
> > most of these standardized pieces are much better than what we currently
> > have. The OpenRC/baselayout-2 fiasco, not much better than baselayout-1
> > and unmaintained upstream shows that even a relatively large
> > distribution like us can't maintain a competitive base system solution,
> Eh what?
> I don't see an advantage in replacing a known-good solution with some
> random stuff that mostly doesn't work yet just because it's the future.
Random stuff that was well though to work together and works well enough
that all other major distros are adopting it.
> > adopting the udev/kmod/systemd way will allow us to use all the work
> > that they are doing and instead concentrate on making a better system.
> "Better" means no lennartware to me. I want to be able to fully debug
> init script failures, which systemd makes very hard to impossible. On
> some machines I have changes in the startup that would mean having to
> hack up something in C and hope that it doesn't crash init for systemd
> (what the bleeeep?)
You can start services with a shell scripts in systemd, you just have to
aim the .service unit file to you shellscript..
> Please don't try to bring the GnomeOS vision of having MacOS without
> paying for it to my computing experience ...
Honestly, so many things just work on MacOS and just need hours of
tweaking for us..