[CS-FSLUG] A new distro model for the real-world desktop

[Timothy Butler]

On Dec 31, 2008, at 10:56 PM, Jonathan E. Brickman wrote:

> Here is a new distro model I am proposing.
>
> 	• Image-only installation, instead of package-installs.  This is  
> becoming the new standard in both Linux and Windows, and it produces  
> a more predictable result, because packages often break at bare- 
> hardware-install due to timing and power management and simplified  
> install-time drivers and other factors.


	I think this makes a lot of sense, so long as you don't dump  
packaging altogether. Frankly, packaging is the one thing I think  
Linux has gotten most right. Especially with dpkg and apt-get, though  
RPM works well enough.

>
> 	• Updates of the core are done all at once, in very large chunks,  
> initially not more than every six months, to be extended to not more  
> than once per year after the team gets its act together.  These are  
> filesystem tree wipes and recopies, not programmatic package  
> installs, and they will leave /home alone.  We'll have to design the  
> elements so that we can leave /home alone without destructive changes.


	This might be a bit draconian, I think. If a person adds a third  
party application that needs a new library, etc., it would probably be  
bad if the application can't count on a globally available location  
that won't be wiped out.

	I'm going to make several such comparisons here, but here's the  
first: I'd observe very closely the Mac OS X installation and upgrade  
processes. They are the least troublesome I know -- certainly the most  
oriented toward giving the average user something that is stable and  
prone to avoid failure.


> 	• Web browser is Firefox.  No packages per se:  just filesystem  
> tree copies.  Ditto OpenOffice.  Ditto Thunderbird.  This is the app- 
> set.  If possible, everything is under an /app tree, to make system  
> upgrades and debugging as simple as possible.  Updates of the app- 
> set are done just like updates of the core, with filesystem tree  
> wipes and recopies.

	Ok, here is number two. Not entirely dissimilarly, check out what  
Apple does with its application packages. They are essentially  
glorified folders that to the user appear to be single file  
applications. If you somehow merged that with your idea, but kept some  
package management, you'd have a real winner.

	What's really good about it: I've yet to meet a person who doesn't  
like the one drag installation of most Mac OS X apps (i.e. click the  
icon, drag it into the applications folder, bang, it works.).

	Principle: if installing software is made harder and not easier, even  
if it nets a more secure, stable system, you won't get users to adopt  
it. Linux is already harder to install software on than Mac OS X or  
Windows, though at the net gain of easy updates. If you can keep the  
easy updates *and* make it easier to install, you go a long way  
towards a real world desktop.

	The Mac OS X model is really good to expand on. It might even be  
worth integrating something into the default file manager like this.  
Say you use Nautilus (a good idea, I suspect). Add some "magic" that  
detects when a new app bundle is dropped into the Application folder  
(whether an upgrade or entirely new product) and it could register it  
with the package manager and run any user profile (etc.) updates  
necessary to make everything run smoothly.

	Or, for the sake of simplicity, simply follow Apple's model verbatim.  
The first time a new version of an app runs for a given, it checks to  
update its config files, etc. On second thought, this model is  
probably better. The other advantage is that while installing in / 
Applications is strongly encouraged, it isn't mandatory to make things  
work. I think in the long run, flexibility will pay off on a desktop.  
Users like flexibility.

>
>
> 	• Firewall and antimalware will need updates at rates different  
> than core and app-set.  This is the security-set.  The temptation is  
> to follow tradition, and make this in part a programmatical mod of  
> the core.  I would like to do literally whatever we have to do, to  
> avoid this temptation.  Programmatical mods are the principal  
> achilles-heel of distro packages.  The security-set, like the app- 
> set, needs to be a tree-copy install, not a programmatical mod.   
> Otherwise we open the door to unpredictable bug-causality.  I think  
> it can be done.


	I've yet to see an OS that could accomplish this. It'd be interesting  
if it did, but I wonder if it is possible. After all, don't you need  
scripting to update configuration files and such?

>
> 	• We should maintain three app-sets, vaguely matching desktop usage  
> patterns we see in real-world users, scaling according to hardware  
> age.  We could label them perhaps "Infra", "Chroma", and "Ultra", in  
> order to avoid denigration of those who prefer the oldest.  Right  
> now I would put GUI 'links' in "Infra", and Firefox 3 in "Chroma"  
> and "Ultra".  OpenOffice 1.1 in Infra, 2.4 in Chroma, 3.0 in Ultra.   
> We could plan on an eventual  fourth, "Xray", if an interest develops.

	Very interesting idea. I suppose relatively analogous to the Debian  
arrangement?
>
> 	• The longevity issue has to be handled using an agreed-upon  
> paradigm added to the above.  The glibc situation is our largest  
> liability.  We need someone who really understands the practical  
> issues involved, who is willing to dedicate to helping us.  Without  
> such a person I don't think we should start; without such a person,  
> in my perspective at least, we would simply be making a second Linux  
> Mint.  Before we start, I want to know precisely why we might not  
> want to try to recompile OpenOffice 2.4 for glibc 2.2; I want to  
> hear about strategies for using old glibc versions, and upgrade  
> risks, and hardware concerns if there are any (I frankly do not  
> know, I think I might have heard something once).

	It'd probably pay to observe RHEL closely on this. They have a 7 year  
life cycle in which they backport security updates rather than passing  
out major upgrades. With that in mind, they must do something like this.

	Good stuff! I'll be interested to hear more.

	-Tim


---
Timothy R. Butler | "He that has and a little tiny wit—
Editor, OFB.biz   | With hey, ho, the wind and the rain,—
tbutler at ofb.biz   | Must make content with his fortunes fit,
timothybutler.us  | For the rain it raineth every day."
                                   -- Feste the Fool (Shakespeare)