On Mon, Sep 12, 2011 at 12:42 PM, Canek Peláez Valdés <can...@gmail.com> wrote: > On Mon, Sep 12, 2011 at 12:21 PM, Dale <rdalek1...@gmail.com> wrote: >> Canek Peláez Valdés wrote: >>> >>> On Mon, Sep 12, 2011 at 11:02 AM, Alan Mackenzie<a...@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
