Re: /run vs. /lib/run
> Heh. You know, you could've just said "Yes, my heart is set on /run"
> right at the start and saved us all a lot of trouble...
Let's just say that you aren't doing very well at reading my heart. :)
Here's what I think about /run, or rather, R:
* A tmpfs R elegantly solves a handful of tricky problems.
* There are no good technical reasons not to implement R.
* There is no FHS prohibition of R.
* Other proposed solutions are technically inferior, mostly
because they are more complex.
* Various locations for R are possible and the choice ultimately
rests on aesthetic considerations about which people disagree.
Since the choice of location isn't that important, I'd have no
objection to putting R at /lib/run if there were something like a
consensus in favor of that location.
> So why don't we go with [making the technical changes necessary to
> ensure /var is mounted early]? Thomas?
>
> Here are the cases:
[...]
> For (d) and (e) you need special handling; using /run as a tmpfs and
> setting up /var/run -> /run symlinks on both / and /var. That's pretty
> special handling [...]
This is where I stop and ask why we would impose such a maintenance
burden on ourselves when there is an alternative that does not impose
such a burden.
The answer, I take it, is that the handful of programs, H, that
would use R can then use /var/run instead. The burden on H's
maintainers of knowing that their programs face special storage
problems is shifted onto the sysvinit maintainers and admins who
have to ensure that writable space is shoved under /var/run by
the time any of the H tries to write there.
--
Thomas Hood
Reply to: