| |||||||||||||
Day: GNOME OSDay: GNOME OSPosted Aug 8, 2012 8:40 UTC (Wed) by drag (subscriber, #31333)In reply to: Day: GNOME OS by krake Parent article: Day: GNOME OS
> I am not sure I understand all details, but it sounds like the Windows or OS X app stores do not overwrite the files programs when they apply updates.
Not sure how it works for either platform. I am very much a Linux guy and have ignored other platforms.
With Windows you have locks on the files you have open. So at least you can know if files you are using have been changed when you fork+exec stuff. With the application handling updates, like Windows versions of Firefox and Chrome do, then that gives you a lot of control. You just launch a update process and tell the user to stop the application before the application is applied. With Linux not allowing regular users to do updates and plus having the update process entirely outside of the control of the application this sort of functionality is probably impossible to replicate.
It is probably also worth examining closely how Microsoft has gotten to mitigate the problems surrounding 'DLL Hell' for the majority of use cases. Versioning issues can and do certainly occur in Windows, but for the majority of users it isn't going to a problem unless their system has been around for a very long time or they are dealing with very old and creaky software.
Going back to 'Gnome OS'...
It seems like the 'Gnome OS' approach that is currently being explored is to avoid the use of traditional Linux package management and utilize some modern Linux file system tricks to make it possible to install applications and much of their dependencies in unique directories while minimizing the amount of duplicated files between application directories.
Here is one of their initiatives right now:
https://live.gnome.org/OSTree/
> Fundamentally, OSTree is designed with the idea that having multiple "roots" installed is a normal condition, and is optimized for it.
On the surface it sounds similar to what I, and I believe many others, typically do to deal with installing video games on Linux. Since most of the time most 'native games' I want to play are not packaged directly for my distribution I very much prefer to download tarballs of binaries then to build them. Even if I build them I still want them separate from my 'OS'. So typically I just install everything in my ~/.local/ directory and launch from from scripts via the command line. Other people may have ~/apps or ~/games, but it's similar.
Also this is the approach taken by things like the old Cedega or the newer 'Playonlinux' stuff for installing non-native games. Each game gets their own tailored wine versions and environment since best compatibility with the distro-installed wine version is unlikely. They have many 'multiple roots' for each game's specific windows environment. This seems to work out really well for what is normally a very unpleasant/difficult activity (installing windows games on Linux)
http://www.playonlinux.com/en/
I haven't heard about this before the above mentioned blog post so what I said in regards to Gnome's approach is likely largely incorrect.
(Log in to post comments)
Day: GNOME OS Posted Aug 8, 2012 8:58 UTC (Wed) by krake (subscriber, #55996) [Link]
"With the application handling updates, like Windows versions of Firefox and Chrome do, then that gives you a lot of control."
Of course. But the article doesn't cover privately controlled installations but how to cope with app store based updates.
Or maybe the article was misleading in that it is actually not about Linux being more difficult to handle but app store based application updates vs. privatly controlled ones.
One has to wonder if the author's intent was to simply bash Linux by using a tightly vendor controlled installation on the other platforms and a store controlled installation on Linux, making the latter more complex to handle.
Of course this would be absurd but I've seen similar things way to often to completely rule it out.
Day: GNOME OS Posted Aug 8, 2012 10:10 UTC (Wed) by drag (subscriber, #31333) [Link]
The author's intent was to describe why they have to use a zygote process on Linux to watch over spawning new processes and why they don't need to jump through all the same hoops do that in Windows or OS X.
Another way to put it, more or less:
Due to Windows habit of locking files it has forced people to use a model of installing that avoids file clobbering issues present in Linux. Something else magically happens on OS X.
It seems to do the same thing in Linux with a system-wide package manager you would need a package manager that is aware of the processes that users are running, installs the software update to a alternate directory, sends a notification to users to shut down the application, and when they do that then rename the new directory over the old one.
Or something like that.
I am very interested in how iOS/OS X handles application updates through the app store. The blog posted hinted at versioning directories in the app bundle, but I have no clue what happens with iOS and such.
Day: GNOME OS Posted Aug 8, 2012 11:36 UTC (Wed) by krake (subscriber, #55996) [Link]
"The author's intent was to describe why they have to use a zygote process on Linux to watch over spawning new processes and why they don't need to jump through all the same hoops do that in Windows or OS X."
Well, he clearly failed on the second part, since the posting does not contain enough information why that is not a problem on Windows and OS X.
For example it is missing the information krakensden added, i.e. that Windows can schedule a rename to the next reboot, allowing the app store to schedule replacement of files but on the downside also requiring system restart.
As I said it I don't want to assume the worst but it smelled a lot like comparing different types of upgrade mechanisms
Day: GNOME OS Posted Aug 8, 2012 14:19 UTC (Wed) by drag (subscriber, #31333) [Link]
Well the guy doesn't know how they really do it on OS X.
And yes it is comparing update methods. They need to do what they do in order to deal with some of the bad aspects of how Linux installs packages.
They could ignore that completely and have each user install Chrome in their home directory, but apparently it is easier to write a bunch of code to work around rpm/deb-style package management then to try to convince Linux users to not depend on rpm/deb for installing and updating Chrome/Chromium.
He also seems to indicate that it's not going to be a issue with them on Chromium OS.
Day: GNOME OS Posted Aug 8, 2012 14:40 UTC (Wed) by krake (subscriber, #55996) [Link]
"And yes it is comparing update methods."
Well, than the blog posting is without merrit.
Like complaining that parallel processing with child processes needs extra work when accessing shared data and stating that multi threading would make that way easier.
"They could ignore that completely and have each user install Chrome in their home directory..."
Or globally.
"...but apparently it is easier to write a bunch of code to work around rpm/deb-style package management then to try to convince Linux users to not depend on rpm/deb for installing and updating Chrome/Chromium."
Well, if it is easier to deal with app store limitations than not to be in the app store than that is a conscient choice. Complaining on how easy it would have been not to be in the app store is just whining.
So marketing (or managment) decided that being in the app store outweights extra engineering effort. Deal with it!
Day: GNOME OS Posted Aug 8, 2012 16:19 UTC (Wed) by cmccabe (guest, #60281) [Link]
The issue is that they don't want to have to restart Chrome/ium after an update. And they don't want to deal with version skew between different files. Their solution seems reasonable to me overall.
Day: GNOME OS Posted Aug 8, 2012 16:24 UTC (Wed) by drag (subscriber, #31333) [Link]
Seems that he thinks it's much easier task to accomplish if they didn't have to deal with Linux apt/rpm style updates.
Day: GNOME OS Posted Aug 9, 2012 8:31 UTC (Thu) by krake (subscriber, #55996) [Link]
True, but they decided that getting into the app stores made the additional engineering costs acceptable.
They could have avoided the issues by going the route of a stand-alone installer but obviously found it more viable to do it the other way.
Day: GNOME OS Posted Aug 8, 2012 12:40 UTC (Wed) by Mog (subscriber, #29529) [Link]
Something I don't understand : why anyone would expect a browser session to continue fine after an update ?
Windows gave us the expectation of a reboot after IE updates (I know, this may not be mandatory nowadays but old habits die slowly). On my Linux boxes, I close all applications, especially browsers, before running 'yum update'.
Day: GNOME OS Posted Aug 8, 2012 13:17 UTC (Wed) by nix (subscriber, #2304) [Link]
Really? That sounds terribly disruptive. I never close a thing before doing updates (unless the update is huge, e.g. pushing all of KDE from 4.7 to 4.8 or something like that, in which case I generally log in again afterwards), and have never had trouble.
Day: GNOME OS Posted Aug 8, 2012 14:10 UTC (Wed) by drag (subscriber, #31333) [Link]
> Something I don't understand : why anyone would expect a browser session to continue fine after an update ?
Well the application or user is given no notification that a update was performed for most (if not all) Linux systems unless the user is the one that did the update itself.
If it's a single user environment then it's not that big of deal, but I suppose it can cause headaches unless the administrator makes sure to upgrade the system while everybody is logged out.
Day: GNOME OS Posted Aug 8, 2012 14:43 UTC (Wed) by krake (subscriber, #55996) [Link]
If the software depends on anything not changing after startup, it could monitor those files.
I believe that this is possible nowadays. Might even be possible to monitor the application's installation directory as a whole
Day: GNOME OS Posted Aug 8, 2012 16:22 UTC (Wed) by drag (subscriber, #31333) [Link]
yeah. Inotify and such. I believe that sort of thing is what they Zygote process for (as mentioned in the blog post), which is extra steps that they don't have to do on other systems.
The code used to do such things is suppose to be rather ugly, but unfortunately Google has terminated it's code search stuff and thus the links from his post showing what Chrome does is broken. I don't have time to hunt down the details myself right now.
Day: GNOME OS Posted Aug 8, 2012 20:08 UTC (Wed) by nix (subscriber, #2304) [Link]
Nah, the Zygote process does nothing as crazy as inotify. It's just a run mode of the chrome binary where it does nothing but listen for requests to fork off children to do other work. Thus, it ensures that those children are all the same instance of the same binary, so are guaranteed to be able to engage in IPC with each other (and with the master browser process) smoothly.
The thing is, a forking architecture like this is a good architecture for other reasons, compared to a plain exec() architecture. Among other things, it means that relocation happens only once, so it saves memory because pages dirtied by relocations are dirtied only once, and it saves time because relocation happens just once, at Chrome startup (an important consideration when the binary is 110Mb). KDE 3 used exactly this architecture just to minimize relocation overhead.
Again, this thing is *five hundred lines*. It's *trivial*. I've written similar things in under a day. And people are proposing massive invasive changes to every program storing state in /etc, and massive invasive changes to the way updates are carried out, to save on the terrible overhead of writing something tiny like this. Why? I am baffled.
Day: GNOME OS Posted Aug 8, 2012 22:26 UTC (Wed) by walters (subscriber, #7396) [Link]
<p>Why don't you go out and patch every application to do it then? I think you'll quickly find that it's <b>insanely tedious</b> for application authors to have to keep a file descriptor open on every file they use.</p>
<p>What's even better - it's <b>still racy</b>. If the user launches an application while an update is happening, the app can get half of the old files, and half of the new. There is no way to solve this without coordination at every layer of the stack.</p>
Day: GNOME OS Posted Aug 8, 2012 23:00 UTC (Wed) by nix (subscriber, #2304) [Link]
Have you responded to the wrong comment? There's nothing in the zygote model requiring file descriptors to be kept open to anything at all, and it's not racy if you keep each application in its own root (as nixos does: I'd agree this is one of the things it gets right), because the binaries and non-shared datafiles for a given package are never overwritten.
In fact with only a few exceptions (e.g. Perl if you want to use CPAN), you can mark such subtrees immutable and nothing whatsoever breaks. (I've been doing this for years.)
Yet again, this seems like a massive invasive change for very nearly undetectable benefit -- and it still doesn't solve the only instance of this problem that I can ever recall encountering, the 'updated application state in your home directory breaking downgrade' problem.
It's a shame I'll not be at LPC or we could have a good argument over this :)))
Day: GNOME OS Posted Aug 9, 2012 15:41 UTC (Thu) by arafel (subscriber, #18557) [Link] I think you might have misread the blog post: This process opens every file we might use and then waits for commands from the main process. When it's time to make a new subprocess we ask the helper, which forks itself again as the new child. By virtue of always forking from the same initial process, we guarantee that we are always running the same code; even if the files we opened are replaced by a system update our handle on them is the handle for the previous file.
Day: GNOME OS Posted Aug 10, 2012 8:16 UTC (Fri) by nix (subscriber, #2304) [Link]
Oh yes, true enough. Of course the most important part of this is the 'always running the same code' part. You don't have to hold the files open: if there are lots of little ones you might prefer to suck them into memory instead.
(Obviously this model will not apply to everything, but it does in fact apply to a lot. You need an abstraction around file I/O to do it, but Chrome already *has* that, and thanks to libio and open_memstream() anything can get it quite easily, without major rewrites.)
Day: GNOME OS Posted Aug 8, 2012 16:48 UTC (Wed) by endecotp (guest, #36428) [Link]
> I am very interested in how iOS/OS X handles application
> updates through the app store.
On iOS, if you install an update to an app from the store, then any currently-running instance of the app is killed first.
Only one app is "foreground" at any time on iOS, so when the App Store app is in the foreground, the app being upgraded cannot be. When an app is backgrounded, it is told that it is going in to the background and it is expected to save its state. It might eventually be resumed but it could be terminated without any further notice due to power-off, low memory, etc. So the case of an update is not special.
I don't know how it works on the Mac, where presumably the app being upgraded might still have windows visible. My guess is that it is killed with some notice first.
Day: GNOME OS Posted Aug 9, 2012 8:39 UTC (Thu) by krake (subscriber, #55996) [Link]
"I don't know how it works on the Mac, where presumably the app being upgraded might still have windows visible. My guess is that it is killed with some notice first."
I wouldn't be so sure. The blog indicated that Chrome wants to be running during and after the upgrade and it said Linux makes that difficult and Windows and OS X don't.
Therefore we msut assume that the Mac store update process allows applications to continue to run. There is just no confirmation on that yet and not details how it does it.
Day: GNOME OS Posted Aug 9, 2012 9:30 UTC (Thu) by hummassa (subscriber, #307) [Link]
this is probably because the Mac upgrade process changes the whole /Applications/Google\ Chrome directory and the old application + the old shared objects is running from the old directory, so you don't have the problem you usually have *during* an apt-get dist-upgrade that if your running applications dlopen(), they do that with the *new* libraries (possibly inconsistently with what they are expecting).
Day: GNOME OS Posted Aug 8, 2012 9:00 UTC (Wed) by krakensden (subscriber, #72039) [Link]
> 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.
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)
Day: GNOME OS Posted Aug 8, 2012 10:36 UTC (Wed) by nix (subscriber, #2304) [Link] > Fundamentally, OSTree is designed with the idea that having multiple "roots" installed is a normal condition, and is optimized for it.Yep, and they can't handle /etc, so they plan to give up and simply rewrite all applications to not use /etc for anything. Who needs systemwide configuration state anyway? That's gonna fly.
Day: GNOME OS Posted Aug 8, 2012 11:44 UTC (Wed) by walters (subscriber, #7396) [Link]
It is not true that /etc makes the current OSTree design unworkable. It just makes the downgrade/bisection story harder.
Day: GNOME OS Posted Aug 8, 2012 13:13 UTC (Wed) by nix (subscriber, #2304) [Link]
Obviously you fix this by storing /etc in version control with something like etckeeper, branching it when you create a new subtree, and tying the branch names and subtree names together somehow.
This took me less than five seconds to think of, but *someone* thought that the problem was nasty enough to propose on the OSTree wiki the rewriting of all existing applications to not rely on /etc. Because that will be so much simpler.
Day: GNOME OS Posted Aug 8, 2012 13:28 UTC (Wed) by walters (subscriber, #7396) [Link]
Let's be clear: for nearly all of the stuff on the wiki, "someone" is me =)
The page you're referring to is the *long term* plan. It's doable over time.
There are a variety of shorter term approaches, and I have an OSTree branch that in fact started on a "stupid merge" strategy like what you're describing.
Anyways, if you are interested in coding instead of commenting in a textarea, you can also join ostree-list@gnome.org - thanks!
Day: GNOME OS Posted Aug 8, 2012 14:27 UTC (Wed) by walters (subscriber, #7396) [Link]
Also, for anyone planning to come to Linux Plumber's in San Diego, my talk there will focus on this:
https://blueprints.launchpad.net/lpc/+spec/lpc2012-boot-a...
Day: GNOME OS Posted Aug 8, 2012 16:33 UTC (Wed) by cmccabe (guest, #60281) [Link]
I realize you have good intentions, but do you really think creating another competitor to RPM and DEB is a good idea? I think it's just going to increase fragmentation.
It seems like the feature you want (atomic updates) could be retrofitted to the existing systems. btrfs supports the concept of transactions at the filesystem level, which is exactly what you need here.
I'm pretty sure that the RPM guys would be overjoyed to have someone sane take over as the upstream maintainer. Please, please, please, think before you reinvent the wheel.
Day: GNOME OS Posted Aug 8, 2012 16:53 UTC (Wed) by walters (subscriber, #7396) [Link]
I describe the BTRFS issues here: https://live.gnome.org/OSTree/RelatedProjects
Basically however you slice it, you need a way to have two operating systems installed. Whether they're squirreled away in a BTRFS snapshot or unpacked as hard links is really an implementation detail.
The *real* challenges are around configuration management, how you present this to the system administrator, etc. For example, it's clearly desirable if the system software management tool can tell you stuff like "you have N OS images installed, the additional snapshots are taking up XX megabytes of disk space compared to the current".
To do that kind of thing, you need something aware of *both* the rpm/deb state and the BTRFS state.
Furthermore, one huge advantage of the current OSTree design (that I need to promote more on the wiki) is that it parallel installs inside your existing distribution - you don't need to switch disk formats. All you sacrifice is disk space.
You don't have access to that package of bioinformatics software in the latest GNOME OS? No problem, reboot into your regular host distribution and use it. Switch back when you want to see the latest GNOME.
Day: GNOME OS Posted Aug 8, 2012 21:10 UTC (Wed) by cmccabe (guest, #60281) [Link]
There are two issues here:
1. Some package managers don't atomically put their new sets of files into place. This could cause problems in the event of an unexpected power cut. 2. Current package managers update application files while those applications are still open.
#1 can (probably) be solved just by batching everything up that rpm or deb does into a single btrfs transaction.
#2 is a little more subtle. Most update systems that I'm aware of don't even try to solve this problem. For example, Android forces you to restart your apps after you've upgraded them. (Application restarts are less of a big deal in Android, though, because of how they designed process lifecycle.)
In general, it seems sufficient to restart most applications. Maybe a flag could be introduced indicating whether the application needs to be auto-restarted, or whether it chooses to handle updates at the application level (by using inotfy, or by keeping a bunch of fds open like Chrome does).
Please don't bother re-inventing the chroot wheel for GNOME. I know how to set up chroots and virtual machines, thanks very much.
Day: GNOME OS Posted Aug 8, 2012 17:01 UTC (Wed) by walters (subscriber, #7396) [Link]
Also, my GUADEC 2012 presentation covers some of this: http://people.gnome.org/~walters/guadec-2012-building-gnome/
(It's now on the wiki too)
Day: GNOME OS Posted Aug 8, 2012 19:54 UTC (Wed) by nix (subscriber, #2304) [Link]
[Warning: this is a rant.]
As far as I can see, the 'stupid merge' strategy -- or a smarter one with custom merge drivers -- is the only sane approach. What's the alternative? As far as I can see, there is none other than some bizarre intent to avoid all systemwide configuration forever, which, as I said, is just not going to fly with virtually any upstream you don't already control.
Any system that retains configuration state in any way will retain the problem of merging it -- and systemwide state isn't the largest problem in any case, it's per-user state, which is far more mutable and often contains references to data that must not be lost (be that emails or financial info). What are you going to do, wipe everyone's dotfiles whenever a downgrade takes place? Keep the config with the earlier trees, so if you make a change after upgrading it's *lost* on downgrade? Neither seems even slightly sane to me.
What OSTree is proposing is somewhat unclear, but appears to require rebooting on *every single package upgrade* so as to switch into a new chroot containing that package. That means several times a day for me. Not a bloody chance am I letting something like *that* near any of my systems outside a VM: it is transparently ridiculous and optimizing for a very few programs that might need to take extra measures to avoid being broken by updates happening underneath them, like Chromium, yeah, already *did*, so it is clearly not impossible: the zygote is also not exactly rocket science, weighing in at well under a thousand lines of code).
Now maybe laptops don't mind being rebooted this often, but a server with NFS-mounted home and scads of daemons and remote users relying on it, no way. (And that's where I do most of my work, upgrading and downgrading everything but the kernel when necessary with nary a hiccup, and no reboot-associated state loss. Yes, I know this setup is 'obsolete' now in the brave new Web 3.0 world where everyone uses horrible proprietary web services rather than anything like shared filesystems, but it meant I and some friends could band together and buy one big RAIDed box with ECCRAM that none of us could otherwise afford, and it means lower power costs than each of us owning a medium-big box.)
What's bizarre is that you reference nixos, which does most of this right (and which I am not associated with in any way, despite the coincidence of names: nixos *does* do some things wrong, including, last time I looked, paying no attention to the fact that most shared library upgrades do not break compatibility) -- and then you go on to propose a system which is as far as I can tell worse in every way in which it differs from nixos. Why?!
Day: GNOME OS Posted Aug 8, 2012 20:05 UTC (Wed) by walters (subscriber, #7396) [Link]
So you're just wrong about the systemwide configuration bit; concretely, it will absolutely be possible to change say /etc/passwdqc.conf and have that apply to every root you boot into.
On the "live updates" part: Absolutely nothing precludes having a mechanism which attempts to apply "live" updates from the new root to the currently running system. In fact, one could trivally reproduce the semantics that dpkg/RPM provide by just doing a "rsync --delete /ostree/trees/new/ /ostree/trees/current/" underneath the bind mount.
But the point is that comes *afterwards*. Make operations safe by default, and optimize later. But remember - there's lots of evil race conditions that happen on "live" updates as package managers do today.
Also remember that I fully intend to allow having a hybrid OSTree+package model, where you have a base system (basically ostree+dependencies) that must be updated atomically, but everything else can be mutated at runtime, if you like.
|
|||||||||||||