"Flame away!"

Posted Mar 30, 2011 17:30 UTC (Wed) by cesarb (subscriber, #6266)
Parent article: Introducing /run

This email was very interesting. Every objection I had while reading it was addressed a bit later on the same email ("another bind mount? that makes the output of the mount command even harder to read" - reads a bit more - "For F16 [...] will become symlinks", for instance). It turned my initial annoyance at seeing the change in systemd.git ("/run" sounded wrong, perhaps because it has been "/var/run" since forever, and because adding new files or directories directly in the root always feels a bit dirty) into a belief that it can be a worthwhile change. I could see nothing left to flame about it.

It is great that we have people willing to do what is needed to enhance the Linux infrastructure, without being afraid of the predictable and unavoidable controversy.

And I am thankful to Corbet for posting this email here. Without seeing it, I would still be thinking "what an ugly change!".

"Flame away!"

Posted Mar 30, 2011 17:36 UTC (Wed) by vrfy (guest, #13362) [Link] (4 responses)

> For F16 [...] will become symlinks", for instance

If you want, you can do this manually already today. Systemd copes just fine with that, and it gets rid of the two bind mounts. See the details here:
http://cgit.freedesktop.org/systemd/commit/?id=2b583ce657...

"Flame away!"

Posted Mar 30, 2011 17:48 UTC (Wed) by cesarb (subscriber, #6266) [Link] (3 responses)

It is one thing me being able to do it (this is Linux, we are always able to do anything we want by editing some source code somewhere and recompiling).

It is another thing it being done by default, with thousands of people "testing" it (most people will see no need to change from the default), and with every thirdy-party program having to deal with it, with even obscure breakage caused by it being found sooner or later.

Do not underestimate the power of defaults.

"Flame away!"

Posted Mar 30, 2011 18:39 UTC (Wed) by vrfy (guest, #13362) [Link] (2 responses)

That will happen, sure. Actually, the installer of a system should do that today already.

It's just not entirely trivial to change that on the running system during a package update, but we will get there.

"Flame away!"

Posted Apr 1, 2011 3:45 UTC (Fri) by elanthis (guest, #6227) [Link] (1 responses)

It's not trivial (or even possible) to do a lot of things on a package update on a running system. It's utterly impossible to safely remove or replace an ABI-unstable shared library that is dynamically loaded by running applications, for instance. The only way to do that safely is to queue up the change until the next reboot, and then shuffle the files around then.

There's a _reason_ Windows requires a reboot for many updates.

(Windows fails in that it used to just require a reboot for everything out of laziness, which made it incredibly annoying to update all those things for which a reboot was totally unnecessary. It's a lot better about that these days. Many application vendors still demand reboots after their app installs, but those are generally ignorable and are not Windows' fault.)

"Flame away!"

Posted Apr 2, 2011 12:28 UTC (Sat) by kleptog (subscriber, #1183) [Link]

Umm, couldn't you just provide the new libraries under a new name? There is a question of when to delete the old files, but that's why having parallel installs of different versions is a good idea.