Fedora 15 will come with a lot of new features and interesting changes — including a whole new top-level directory in the form of /run for runtime data.
This may sound trivial to many, but top-level directories tend to be a touchy topic in some circles. Consider that there's an entire standard that was hashed out years ago, it's surprising to see a top-level directory casually introduced.
But Poettering says that he already has buy-in from the other major distributions:
In the past weeks key people from the Debian, SUSE, Ubuntu and Fedora camps (and others, too) discussed the whole issue forth and back, to find a solution to stop the misuse of /dev before it becomes even more widespread...
With this upload Fedora and SUSE have already adopted /run now. Debian folks will suggest this for their coming release. Ubuntu has agreed with introducing /run as well.
So what's the point of all this? The problem Poettering lays out is that too much was being stored under /dev — which is meant to be used for devices (such as /dev/sda for a hard disk, or /dev/sr0 for a optical drive, etc.) and not for runtime data. But more and more programs have been putting data there. Why is that a problem? According to Poettering:
However, /dev always has been an inappropriate and ugly place for runtime data: runtime data is not a device node, and thus simply does not belong there. Also, hiding the existance of directories from the administrator is a bad idea. Then, the fact that some runtime data was placed in /var/run/xxx, and other in /dev/.yyy is often not understandable to the user, and especially when tools originally intended to be used only after boot are needed during early boot a complicated move between these directories needed to take place.
So the upshot of this is that all the runtime data will be in the same place, and no more hidden files. Since Poettering has coordinated with other major distros, this should lead to it being standardized in fairly short order. And there's less confusion about what is persistent data and what's volatile (that is, how long data will be kept, or if it will be kept).
Expect to see a bit of heat about this from purists and/or maintainers of the FHS, but it's been ages since the FHS was updated — perhaps it's time for an update?