On Sun, 27 Sep 2009, Henrique de Moraes Holschuh <h...@debian.org> wrote:
> For which I am very grateful.  The backlash against über-fragile and
> over-complex boot environments has already started, and you could see it
> really well in LKML (refer for the tmpdevfs threads, for example).
> RedHat's initrd has often been refered to with strong words there, I
> don't think we should commit to *requiring* something like that.

That's interesting.

I think that the initrd should do NOTHING other than make it possible to mount 
root.

> Also, RedHat could care less for the smaller boxes, they don't optimize
> for anything that doesn't have hardware RAID.  That's fine for RHEL user
> demographics, but we're not like that, our user demographic is not like
> that, and our values are not in perfect sync with theirs.  What's good
> for RedHat is not necessarily good for Debian.

I think that you are exaggerating slightly.  RHEL and Fedora work quite nicely 
on systems with software RAID.  Admittedly they don't work as well as Debian 
which allows you to do unusual but convenient things such as installing to a 
degraded RAID-1.

> IME, simple initrds that don't really impact on your hability to boot
> are fine (and great to load firmware, CPU microcode and kernel modules),
> but anything else (like root on lvm or on non-auto-started md arrays)
> will cause trouble sooner or later.

Root on LVM is good for backups and gives the potential for changing the size 
of root with little inconvenience.  Given that 10G is large for a root 
filesystem (I don't think that I run a machine with more than 8G for root) 
and the smallest newly manufactured hard drive seems to be something in 
excess of 300G (with 2T being common) it seems that there is no real benefit 
in changing the size of root (just make it reasonably large for all 
machines - we have space to burn).

-- 
russ...@coker.com.au
http://etbe.coker.com.au/          My Main Blog
http://doc.coker.com.au/           My Documents Blog


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to