On Thu, Sep 8, 2011 at 3:59 AM, Neil Bothwick <n...@digimed.co.uk> wrote: > On Wed, 7 Sep 2011 23:30:16 -0400, Canek Peláez Valdés wrote: > >> > Because you can't boot from an LV, so you'd than need a separate /boot >> > and an initramfs. Without LVM, you are unlikely to be able to resize / >> > or /usr as it is not usually the last partition on the drive. >> >> So, you guys want a separated /usr, but don't want a separate /boot. >> Awesome. > > I want as much as possible on LVM, and no initramfs. A small / and > everything else on LVM fulfils that need.
If you really want it, go ahead and code the support for it. The code for every single piece on the stack is available, and you have the right to modify it if you don't like upstream decisions. Upstream(s) don't need or have to care about what I (or you, or anybody) wants. They (for reasons that we may or may not agree) will decide what set of configurations will be supported. Don't like the decision? Use the source, Luke. >> >> Again, I don't see the reason for a separated /usr. >> > >> > That doesn't mean there aren't several valid reasons to do so. >> >> I didn't say they were invalid, I say that *I* don't see the reason to >> separate /usr. The arguments exposed just don't convice me. But >> anyway, you will be able to do it with an initramfs. > > No one is saying YOU should change your preferred setup. Please do us the > same courtesy. I do: I don't want you to change your setup. Absolutely nobody is saying that. I'm truly sorry if thats the way I sounded (my first language is not English). However, if you don't want to change your setup, you will have two options: either you don't upgrade (which is feasible, if you limit yourself to security upgrades), or you write the code necessary for your particular configuration. We (neither you nor I) can force the developers (being udev, kernel, Gentoo or whatever) to write the code supporting configuration X or Y, no matter how "rational" it seems to you (or me). When upstream wants to changes stuff, I change my setup and relearn how to do it with the new technology/options. It happens all the time: we moved from devfs to udev, from OSS to ALSA (and then PulseAudio), from ipchains to iptables... I could go on and on. > want, what we need and how best to achieve it. How would you feel if you > were told that you had to separate /usr, install extra packages, go > through extra configuration steps and introduce more points of failure, > just to do what you are already doing? I will do it. I have done it. And the reason is that the kernel churns out a new version every 2 or 3 months, GNOME gets a new version every six months, and everything gets (usually) better so fast thatt you want to keep ip. And the only way to keep up with development, is sometimes you need to change your setup. Of course there are different setups. My laptop I keep it updated every week. Sometimes shit gets wrong: I fix it, no problem. A production server only gets security updates, and I keep a twin setup ready if something goes wrong updating. If an update is intrusive (say, I need to change /usr to the same partition as /), then I do it first on the twin, and when it's ready I change them and do the same in the primary. And life goes on. >> Then don't update. > > I can't decide whether this comment is arrogant or ingenuous. It's called "being in production". You don't upgrade your kernel in production, unless there is a security flaw that affects you. If there is a security flaw in NFS, and you don't use NFS, you don't upgrade. You don't upgrade Apache unless there is a security flaw. You don't upgrade *anything* if it's working. Want the new features? Guess what? You need to use the supported setups, or write the code for your particular setup. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
