Introducing /run | Hacker News Reader

Introducing /run

lwn.net

243 pointsrpledge38 comments

Nice. I'm happy our Linux overlords are so sensible.

Also!: /run/flame_war @ http://thread.gmane.org/gmane.linux.redhat.fedora.devel/1469...

Wow, the definition of flame war there I think :S

Am I missing something obvious? Is there an important reason why the FHS is considered so important and unchangeable? Or is it just political?

> Am I missing something obvious? Is there an important reason why the FHS is considered so important and unchangeable? Or is it just political?

My beard is long now, and the FHS has not changed since I was a child.

I thought I heard someone mention in a comment thread related to this that the last changes were ~6 years ago.

edit: Wikipedia says Jan 2004, so ~7 years ago.

Why don't we just fork the standard? It's just a document.

I didn't know that! I guess I wasn't a child, then. I thought it was more like 1995. ;)

The fifth response (by gmane's sorting) says it's a "crack ridden idea" and acuses the authors of raping the standard. So, yeah, flame on.

You can link right to it: http://article.gmane.org/gmane.linux.redhat.fedora.devel/146...

I'm pretty sure he's just trolling. He repeatedly misquotes the FHS and if you follow the thread down occasionally gives content-free "I disagree. This violates the FHS."

I love Lennart Poettering's (the OP) response:

"Die Wahl Deiner Worte adelt wahrlich Deine Gedanken"

It's German and actually really difficult to translate. I'll give it a shot: "Your choice of words truly ennobles your thoughts."

I can't understand people like Ralf Corsepius.

Your translation is quite literal. I wonder whether we can find a more idiomatic one.

I like the translation just fine, but perhaps one of the following:

"the words you elect to use perfectly reflect you and your views"

"the words you elect to use bring respect to your views"

"the words you choose to use can't fail to enthuse those who muse on your views"

The last one has lost a smidgen of German stoicism (does "Grüne Eier und Schinken von Herr Doktor Süss" even exist?) though I think...

"The words you choose to use can't fail to enthuse those who muse on your views." is great.

I'd like to read (or write) "Grüne Eier und Schinken von Herrn Doktor Süss". (I changed Herr to Herrn.)

Sensible approach from Lennart and the whole systemD folks. If you are wondering who lennart is, He is one of the creator of pulse audio and known for sending out an alternative kernel speedup patch http://www.webupd8.org/2010/11/alternative-to-200-lines-kern...

I've always wondered about the difference in lifecycle between /var/lock, /var/run, and other /vars. Happy that we've decided to make things simpler and easier to understand.

Type "man hier" at a command prompt.

Long-form version: http://pathname.com/fhs/pub/fhs-2.3.html

Short-form version: http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

Quite nice to see that different distros cooperate to keep certain thing coherent between the systems.

I strongly agree.

And while it would have been nice to update the standard prior to this change, in practice that would ensure that the change didn't happen for a long time, if ever. By having most of the major distros in on this we can be assured a quick adoption of the fix and hopefully a an update to the FHS.

Keeping in line with standards and specifications is extremely important to prevent fragmentation of the Linux ecosystem, but allowing those same documents to hold back [legitimate] progress is nothing more than foolish.

TL;DR summary: Hey, there's this problem that has been solved in a nonstandard way for too long. Here is a solution that all the major distro's have agreed on

Unwashed masses: Hooray!

Random angry neckbeards: YOU ARE CRACK ADDICTED RAPISTS

I said no such thing.

What a joke. Thie filesystem hierary wasn't complex enough for him?

> /var/run otoh is only available very late at boot, since /var might reside on a separate file system

he forgot to mention that this is a non-standard, specialized setup. In normal case, /var is on the root partition.

> he forgot to mention that this is a non-standard, specialized setup. In normal case, /var is on the root partition.

Specialized it may be, but nonstandard it is not; the entire reason for /var to exist as a separate directory is so that it can be mounted from a local disk in cases where your root partition and /usr are NFS-mounted or otherwise read-only or shared between multiple machines.

It seems to me that moving /var/run to /run simplifies the filesystem "hierary" rather than making it more complex.

To add to this hypocrisy systemd doesn't allow /usr to be on a separate partition.

That's false: systemd handles a separate /usr just fine. It prints a warning, because most systems don't support a separate /usr partition reliably, no matter which /sbin/init they use. Consider udev scripts that rely on binaries or libraries from /usr and are triggered on hardware cold plug events, before /usr is mounted: poof, some of your hardware magically doesn't work on boot, until you re-plug. Have fun debugging it.

Can you suggest a single use case for putting /usr on a separate partition that wouldn't work far better without? Sharing /usr across the network makes no sense, since its contents need to come from the same packages and versions as /.

A homogeneous environment that doesn't have formal package management is the only use case I can envision.

It was a good idea back in the SunOS days (and it's probably still workable to a limited extent for the BSDs, and perhaps folks like Gentoo) when local storage wasn't as plentiful as it is today, but I think we've safely moved on at this point.

On modern Solaris systems, isn't /bin a symlink to /usr/bin anyway? Kind of shoots down the old reasoning that /bin has the absolute minimum to get a broken system fixed, and /usr/bin has everything else.

I understand that use case, I just don't see why it makes sense to share /usr rather than sharing /.

One of our supercomputing clusters does run with a shared / and a separate /var that is local to the machine. /var is local to the disk because the nodes are stateless but we would like a persistence store for things like logs.

I realize that you're probably just providing a tangential anecdote, but his reasoning for why sharing /usr is useless doesn't really apply to /var.

My recollections may not be totally accurate, but I'll try.

In 1997, I was working at TCSI. My SPARC 5 workstation had a small local disk, which had crucial things like vi on it, which were fast to access. It might have been 500 megabytes or less. /usr was NFS-mounted over an unswitched 10-megabit Ethernet to a gigantic 35-gigabyte NFS server, from which I had access to a huge variety of software, including something like 8 versions of the CenterLine C++ compiler, much more than would fit on my local machine, but which was much slower to access. My home directory was also NFS-mounted.

Installing the huge variety of software on everybody's workstation would have meant that we had to have dozens of copies of it, using up precious disk space, and furthermore that installing or updating software would need to be done on every single workstation, instead of just on the NFS server. rdist existed but wasn't widely used; rsync had just been invented.

Also, "packages and versions"? pkg_add isn't what you think of as a package management system. The FHS was adapted from Unix workstation practice established before Debian invented package management as we know it today, and at a time that Slackware still didn't have package management. You could install your packages wherever you wanted, much as people do today with easy_install or gems.

It sounds like one of the motivations for this change is to allow the root partition to be kept read-only. For that to work, /var would need to be a separate partition and writable. There are still a few files and directories, like /etc/lvm/cache, which currently need to be writable and could be moved to /run.

There is an exchange between Lennart and a commenter in the comments to that effect. /etc/mtab is mentioned and Lennart says that in F15 it will be a symlink to /proc/self/mounts.

http://lwn.net/Articles/436022/

If this was such a niche issue, then getting all of the major distros to agree on a course of action would have been much harder.

> he forgot to mention that this is a non-standard, specialized setup. In normal case, /var is on the root partition.

I guess I have been hanging out in BSD land and haven't setup a Linux system. Is this correct? I generally have /var separate from / (along with /usr, /tmp, /home). How does the average HNer setup their Linux partitions?

Your experience does not mirror my own, I'm afraid.

The failure mode of not separating out /var from the rest of the system is interesting; spool, cache, lib, and log can be particularly problematic, depending on the purpose of your system.

Not separating filesystems for hobby systems and home computing is perfectly reasonable in the name of simplicity, but there's a reason longbeards like me prefer to do things this way.

(Sadly, I was cursed with fair, slow-growing hair, so I have never quite reached my bearded potential. My poor attitude about your new-fangled gadgets will have to suffice.)

To wrap all your responses up: in non-trivial production systems, having separate /var is a good, practical idea without serious downsides -- and my original critique was unfounded for anything but simplest use cases.

Thanks for all your responses :-)

Reply on news.ycombinator.com