| |||||||||||||
Day: GNOME OSDay: GNOME OSPosted Aug 8, 2012 9:00 UTC (Wed) by krakensden (subscriber, #72039)In reply to: Day: GNOME OS by drag Parent article: Day: GNOME OS
> With Windows you have locks on the files you have open
Indeed. The Windows equivalent of rename(2) actually takes a flag that schedules the move after the system restarts, which makes lots of install/upgrade activities kind of trivial.
(Log in to post comments)
Day: GNOME OS Posted Aug 8, 2012 10:23 UTC (Wed) by slashdot (guest, #22014) [Link]
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
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 9, 2012 13:53 UTC (Thu) by etienne (subscriber, #25256) [Link]
Maybe simpler would be to install in a new directory and "play" with $PATH (or other environment variable) so that shells started before the install see only the previous version and shell started after the update see only the newer version?
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".
Day: GNOME OS Posted Aug 8, 2012 14:27 UTC (Wed) by nye (guest, #51576) [Link]
This is so awful that changing it would be the single biggest improvement to Windows I can imagine.
Honestly, 99% of the solution would be simply to use a flag that performs the rename not on next reboot, but when all current locks on the file have been dropped.
The kernel needs to know that anyway, so it should be possible without some nasty polling daemon, and it would turn 'reboot system' updates into 'restart application' updates, which solves the problem for anything other than updating files belonging to system processes, for which it doesn't feel so unreasonable to have to reboot.
Each version of Windows requires fewer reboots than the last, so maybe there actually is a flag that does this and it's "simply" a matter of updating the entire world to use it(?)
(Ultimately that would provide similar update semantics to Linux, which might mean the same problem described up-thread unless some thought is put into it, but it *would* mean that MS get to keep the semi-mandatory locking they love so much)
|
|||||||||||||