Re: [gentoo-user] udev + /usr

[Michael Mol <mikemol@gmail.com>]

On Mon, Sep 12, 2011 at 12:42 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Mon, Sep 12, 2011 at 12:21 PM, Dale <rdalek1967@gmail.com> wrote:
>> Canek Peláez Valdés wrote:
>>>
>>> On Mon, Sep 12, 2011 at 11:02 AM, Alan Mackenzie<acm@muc.de>  wrote:
>>>>
>>>> Hi, everybody.
>>>>
>>>> Hope nobody minds me starting a new thread with an accurate name.
>>>>
>>>> Which version of udev is it that has this nauseating feature of needing
>>>> /usr loaded to boot?
>>>>
>>>> Somewhere in that version's source will be several (or lots of) "/usr".
>>>> Just how difficult is it going to be to replace "/usr/bin" with "/bin"
>>>> throughout the source?
>>>>
>>>> udev is part of the kernel.  How come the kernel hackers aren't up in
>>>> arms about this as much as we are?  Or are they, maybe?  In which case,
>>>> maybe the kernel people would welcome an option to disrequire the early
>>>> mounting of /usr as much as we would.
>>>>
>>>> Anyhow, I'd like to take a peek at the source code which does this evil
>>>> thing.  Would somebody please tell me which version of udev is involved.
>>>>
>>>> Thanks.
>>>
>>> (This would be my only post in this new thread: I think I have made my
>>> point of view clear in the other thread).
>>>
>>> I have seen a lot of disinformation going on in the other threads
>>> (like some people suggesting that /var would not be able to be on its
>>> own partition at some point in the future). Just before everyone start
>>> to wildy conjecture, please take a look at this:
>>>
>>> http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
>>>
>>> Also, a look at this thread is maybe justified:
>>>
>>> http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/1728/
>>>
>>> Both things are in the context of systemd, but it's related to the
>>> discussion at hand. I know not everybody wants to use systemd, and
>>> think Lennart and Kay are the root of all that is wrong and evil on
>>> the world, but I will recommend everyone interested in the reasons of
>>> the push for a recommended initramfs to take a look at the page in
>>> fd.org, and the thread in the systemd mailing list. Even if you don't
>>> agree with the reasoning, it is worth to take a look at it.
>>>
>>> As for me, I would say one last time my POV: Linux strives to be much
>>> more than Unix, and that means do things differently. It will always
>>> be capable of do anything that Unix does, and most of the time it will
>>> do it better. But that doesn't (necessarily) means that it will do it
>>> in the same way.
>>>
>>> And many of us don't take "but my config/setup/partition works now" as
>>> a valid argument to restrain progress.
>>>
>>> Change happens.
>>>
>>> Regards everyone.
>>
>> You say it was disinformation about /var.  Care to explain why me and one
>> other person read the same thing?  It was mentioned on -dev.  I was pretty
>> sure it was and then another person posted they read the same.  So, I'm
>> almost certain it was said at this point.  Surely we can't both be wrong.
>
> Where did you guys read it? Who said /var could not be in its own
> partition anymore? What piece of code stops working if /var it's in
> its own partition? Who is proposing that a separated /var will not be
> supported in the future?
>
> The thread I post talks about /var/run and /var/lock needing to be
> symbolic links to /run and /lock, but AFAIK (and I tend to follow this
> sort of things) /var not only can be in its own partition, it is the
> recommended setup.
>
> Saying that proposing /run and /lock to be available at boot time
> means that in the future a separated /var partition could be not
> supported is, in my book, disinformation. /var/run and /var/lock (by
> definition) are almost empty (in space). /var/lib usually stores whole
> databases. The difference is important and relevant.
>
> Damn, this list is like crack.

http://xkcd.com/386/


-- 
:wq