On Thu, 8 Sep 2011 11:32:27 -0400
Canek Peláez Valdés <can...@gmail.com> wrote:
> On Thu, Sep 8, 2011 at 6:11 AM, Alan McKinnon
> <alan.mckin...@gmail.com> wrote:
> > 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.
initramfs exists primarily because there's no other sane way to boot a
binary distro without one and still have something approximating the
goal of only having what's required. The other case is booting off a
volume that the boot loader does not support (such as / on LVM)
I have yet to see a valid reason for requiring an initramfs for normal
use. Every reason advanced so far to my mind reduces to "because I
changed the code to work that way".
Do note that I'm not asking the devs to engage is some peculiar code
writing or support something unusual. I'm asking them to leave the
existing code in place because it works just fine without security
risks or difficult technical issues (as far as I can see)
> 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?)
Just because FHS is not being tweaked often does not mean it is no
longer valid. It contains many excellent ideas, such as the possibility
of a minimal / with only 4 required directories containing everything
needed to boot and repair.
FHS never said anywhere that one could not have extra directories
like /usr/libexec, one is free to make and use such if one wishes.
Yes, I do use /srv. I do like to keep my externally shared data (ftp,
web etc) in a different place to my internally shared data (portage
caches etc). I like and use this idea because I think it's a good idea.
But I'm not required to and I understand that. /srv is merely a good
idea that can assist with maintenance, it is nowhere near being the
same class as the minimal contents of /, this is a core design feature
that determines how the entire system as a whole works. Not really
comparable
>
> But, if you think /usr in a separate partition is a good idea, then by
> all means write the code for it.
Why not let me keep the code I already have, which is not broken?
I have yet to see a valid reason why this sane default is no longer
valid.
> > 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.
I'd like this aspect to remain just as it is currently. I see no defect
with it and you are not advancing one.
>
> > 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.
I do not need to write this code. It already exists and is shipped with
the standard tarballs I build Gentoo systems from right now.
> > 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.
It may make sense - I will of course concede that, but I have yet to
see a valid explanation of the reasoning. Once again, it may exist, it
simply hasn't become visible to me.
> > 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.
And sometimes the guy that writes code fucks it up enormously.
The onus for proving my ideas are good rests with me, I accept this.
Similarly, the onus is on the author of a new feature to demonstrate
that his idea is not dangerous, and if it is to offer valid reasons as
to why it is preferable to proceed. I don't see either of these
arguments from the udev maintainer.
>
> 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.
Why is it so hard for these same maintainers to leave things as they
are? It is not broken currently
--
Alan McKinnnon
alan.mckin...@gmail.com
