Re: [gentoo-user] Apologize to everyone for my nonprofessional

["Canek Peláez Valdés" <caneko@gmail.com>]

On Sat, Oct 15, 2011 at 2:53 AM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Sat, 15 Oct 2011 00:34:10 -0700, Canek Peláez Valdés wrote:
>
>> /var != /var/run
>> /var != /var/lock
>>
>> /var/run is going in /run, but /var/run (by definition) only contains
>> things like PID files and runtime sockets. In the same vein, /var/lock
>> also is going into /run/lock. I have acknowledged this from the very
>> beginning, and I have been pointing out that implying that because
>> those two (really small and bounded) directories of /var are going
>> into /run and /run/lock,
>
> Putting the contents of /var/run and /var/lock on the root filesystem
> makes sense.
>
>> Nobody has even proposed that /var should go into the same partition
>> as /. *Nobody*, and the simplest proof of that is that nobody has
>> produced a single proof to the contrary. Not a single email, blog
>> post, or wiki entry from any system developer even mentions the
>> possibility of requiring /var to be in the same partition as /.
>
> The stated reason for requiring /usr on / is that udev can run
> *arbitrary* scripts and commands. If they are arbitrary, they could
> require access to anywhere, including /var or /home. That's the problem
> with this approach. Instead of saying "it can run stuff from anywhere, so
> anywhere must be mounted before udev is run" the fact that it is trying
> to run these arbitrary commands before filesystems are mounted should be
> addressed.

With an initramfs you can have everything mounted by udev execution
time. But forget about that.

It's arbitrary (basically) on executables and libraries. If an script
needs something more (from /var, lets say), then the rule should be
written in such a way that it can be called after that directory is
mounted. If you try to put the same restriction with *executables*
(not data, like in the ALSA case), then you need to start moving every
executable to /, because that's the only way to guarantee that it
would be available aearly on boot time (if you don't use an initramfs
and have /usr separated).

That sucks. /bin and /lib were the original hack, for this very
reason: some executables were needed early at boot time, and they put
them there so they were available. The initramfs solves this problem;
at some point, /bin /lib and /sbin will no longer be necessary.

So yeah, the udev rules can execute arbitrary code, but the should not
run stupid code. There is a difference.

>> Whoever says that /var will be required to be on the same partition as
>> / is either wildly speculating, or spreading FUD.
>
> It's not wild speculation, it is logical extrapolation of the current
> approach.

You don't have enough data to extrapolate.

>> It basically removes the need for a "pesky init* thingy", although for
>> the life of me I cannot understand why someone will not see the
>> technical advantages of actually using an initramfs.
>
> We understand its advantages in some circumstances, but  I cannot
> understand why someone will not see the technical disadvantages of
> actually using an initramfs.

Care to explain?

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México