Day: GNOME OS [LWN.net]

Day: GNOME OS

Posted Aug 8, 2012 10:23 UTC (Wed) by slashdot (guest, #22014)
In reply to: Day: GNOME OS by krakensden
Parent article: Day: GNOME OS

Really?

This is pretty much the worst feature of Windows.

It's absolutely horrible to not be able to replace files in use, when such an operation is clearly conceptually trivial as shown by Linux.

Don't copy it please.

The RIGHT way of solving the problem is not that, but it is:

1. Install applications in their own versioned directories instead of scattering their files all over
2. Add kernel support to unlink a directory, which once the last reference drops (or after reboot) causes recursive unlink of all its contents (or alternatively, use a daemon+initscript to do the same)
3. Make applications keep the their directory open as an fd (and by keeping a connection to the daemon if using that solution), and use openat() on that fd to open their files
4. Package removal works using the new kernel unlink feature, but the directory is still accessible via the application's fd and is physically deleted only when application is closed or reboot (due to #2 and #3)
5. Package upgrade works by removing the previous version as before, then creating a new directory with a different version number with the new one, then redirecting /usr/bin/APP to that directory.

(Log in to post comments)

Day: GNOME OS

Posted Aug 8, 2012 10:39 UTC (Wed) by hummassa (subscriber, #307) [Link]

> 2. Add kernel support to unlink a directory, which once the last reference drops (or after reboot) causes recursive unlink of all its contents (or alternatively, use a daemon+initscript to do the same)

Just move it to the an application-recyclebin on uninstall/upgrade. (3) becomes unneeded, (4) and (5) become moot. And you can rollback upgrades and uninstall easily. Empty/tidy the application-recyclebin on boot.

Day: GNOME OS

Posted Aug 8, 2012 11:36 UTC (Wed) by slashdot (guest, #22014) [Link]

Well, the problem is that systems can just never get rebooted, and anyway waiting for reboot is suboptimal.

So, you need either the kernel or a daemon that can notice the application files are no longer in use and can zap then quickly.

Not totally sure on the best mechanism for that, but it's definitely possible.

Day: GNOME OS

Posted Aug 8, 2012 13:16 UTC (Wed) by nix (subscriber, #2304) [Link]

Well, once applications fall out of use they never go back into use again (since new invocations will invoke the new one): so have a cronjob that periodically hunts across deleted applications for files no longer in use by anything, and deletes them. This won't be noticeable performance-wise because most deleted applications will be not-in-use the instant they are removed, so can be aggressively deleted.

(Personally, I keep my versioned per-app trees around for a month to allow for later downgrading. I have never had a single problem with the script that deletes them after that much time.)

Day: GNOME OS

Posted Aug 8, 2012 16:41 UTC (Wed) by rahvin (subscriber, #16953) [Link]

Wouldn't that cause a severe impact to battery life on battery driven devices? You want everything sleeping unless it's in active use, what you suggest would keep the CPU active even when the device isn't being used. Of course if we don't concern ourselves with battery driven devices it's not a concern.

Day: GNOME OS

Posted Aug 8, 2012 17:11 UTC (Wed) by drag (subscriber, #31333) [Link]

You'd only need to run it once a month or something like that. And there are numerous other cron jobs that perform tasks on Linux.

It wouldn't be difficult to put a logic into the cron job to check to see if it's on battery and delay until it's on the charger or above 80% charge or something of that nature.

Day: GNOME OS

Posted Aug 10, 2012 8:18 UTC (Fri) by nix (subscriber, #2304) [Link]

My old uni did something like this. It was fiercely annoying because it made it *impossible* to upgrade anything without logging out. (Not as annoying as having to reboot to upgrade, but nearly as much.)

Far better to symlink the new things into place in some shared tree. (Of course, symlinks have slight annoying semantic changes, so a few pieces of software need adaptation to this, though maniac stow and graft users like me have already done it for most stuff. If this was really Plan 9, we could just bind-mount everything into place in your per-user /bin, and have a command that refreshed all your /bin mounts when you wanted them refreshed, flash-updating you to the latest goodies but only when you wanted it.)

Day: GNOME OS

Posted Aug 10, 2012 9:20 UTC (Fri) by etienne (subscriber, #25256) [Link]

It should be possible to open a new xterm and get newly installed applications in that process group, but I do agree you cannot run the new applications from the global menu without logging out - unless there is a way to "refresh menus".