On Thu, Sep 8, 2011 at 6:11 AM, Alan McKinnon <alan.mckin...@gmail.com> wrote:
> On Wed, 7 Sep 2011 23:23:45 -0400
> Canek Peláez Valdés <can...@gmail.com> wrote:
>
>> > I wound up being able to recover by doing a full reinstall of all
>> > packages on the live system after mounting /usr into a
>> > freshly-mkfs'd new lvm volume. If I'd taken the system offline, it
>> > would have been much more difficult.
>>
>> You can always remount / in another LVM module. Really, what's so
>> especial about /usr?
>
> Don't get me started. Oh, wait, you just did.
Uh oh :D
> Right, here goes:
>
> An initramfs is optional becuase i can disable it in the kernel. I
> would like to keep that optional.
udev at some point was optional, then it wasn't. Right now initramfs
is optional primarily because of embedded systems.
Change happens, I repeat.
> FHS says I can have /usr on a separate partition and I would like to
> keep that because it is a good idea.
FHS is dead: for years we didn't hear from it, and it was until a few
months that some activity was registered from it. For practical
reasons, it's dead, and nobody follows it completely (where in FHS is
/usr/libexec? do you use /srv like FHS says?)
But, if you think /usr in a separate partition is a good idea, then by
all means write the code for it.
> FHS says I can mount /usr read-only if I choose, which is also a good
> idea. On a shared jumphost with 570 concurrent users it's actually a
> VERY GOOD ODEA and I'd rather not lose that facility thankyouverymuch.
Then don't loose it. Just use an initramfs.
> I do not need, want nor can I find a valid reason to *require* an
> initramfs. Systems boot just fine without them.
Then either restrain yourself to security updates (which may be a good
idea if you support a server for 570 concurrent users), or write the
code to support a separated /usr without initramfs.
> FHS says I can have the minimal software and tools to effect a system
> repair on / and put then entirety of user-space on /usr. Everything
> involved in this thread runs early in the boot process and I fail to
> find a single convincing reason why /usr is involved at all. Anything
> required at this point can simply be put into /bin, /sbin and /lib{,64}
> which one will note is exactly how we have been doing it all along.
If it is so easy, then write the code to do it.
> This whole mess has every indication of a singular maintainer who
> cannot be bothered taking other people's needs into account and
> foisting off his own personal preferences onto an entire ecosystem.
And he magically convinces his distribution (and ours) to follow
through? Man, he must be really powerful. I don't think that it is
even possible that *maybe* some of his reasoning actually makes sense.
> I think such people should take note of how Torvalds works and emulate
> him as opposed to emulating say Drepper as a role-model for good
> project mantainership practice.
The people that writes the code, gets shit done. Code talks.
We always have the option to write the code ourselves, and get shit
done the way we want it. Don't want to do that? Then accept that you
will need to follow what the writers of the code decide.
Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
