| |||||||||||||
Day: GNOME OSDay: GNOME OSPosted Aug 8, 2012 16:33 UTC (Wed) by cmccabe (guest, #60281)In reply to: Day: GNOME OS by walters Parent article: Day: GNOME OS
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.
(Log in to post comments)
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)
|
|||||||||||||