[CS-FSLUG] Desktop Distro Model, 0.3

[Ed Hurst]

Jonathan E. Brickman wrote:

> 1. 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.

This I like. Even recently I've had an installation fail from some 
process-based corruption, and had to do over from scratch. I've also 
lost two hard drives over the years to this very thing.

> 2. ...we steer very clear of those which are dependent on specific
> desktop environments. I think probably GTK+ is stable, common, and
> compatible enough, to be considered the standard GUI API set for
> config utilities.

I seem to recall a couple of toy projects using Qt as the toolkit for a 
plain window manager. Not many independent projects I know of use just 
the Qt without integrating into KDE directly, but tons of Gtk stuff not 
linked into GNOME.

> 3. 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.

Interesting idea. Balancing between the needs of incremental security 
fixes and the need for a flawless update does call for careful 
consideration. It occurs to me Linux as a whole seldom discovers really 
dangerous flaws in the context of the home user, which justifies some 
distros taking their time updating. This extension of the image-install 
concept might solve some very real problems with the other methods, but 
I wonder at what cost?

> 5. Updates of the app-set are done just like updates of the core,
> with filesystem tree wipes and recopies.  A mechanism will have to be
> in place for user-installed kernel modules.

Some items do stand alone as their own project, with their own handling.

> 9. There is also the *dev-set*.

I had envisioned catering to the kind of folks who would never want to 
build their own stuff. If you have a developer team, obviously they 
would need the dev stuff. OTOH, freedom is a good thing, as long as we 
remember who our target audience is.

> 10. The longevity issue has to be handled using an agreed-upon
> paradigm added to the above.  The glibc situation is our largest
> liability.

I seem to recall reading once a bigshot developer saying he was tired of 
hearing folks complain about bloat. He then proceeded to explain how the 
number one factor in bloating an upgrade was bloating in the libraries. 
I don't recall much more than that, because I never understood the 
details of his argument, but grasped that much.

I suppose one element is so-called 'backward compatibility' issue. I've 
seen compat-lib packages to cover this, but they never seemed to work as 
advertised on the few big items for which I wanted them. For example, 
once we got past RedHat 6.2, I never could get WP8 to run without 
crashing. I was pretty disappointed because I bought the retail version 
for Linux. It worked fine up to that point, but the compat stuff just 
wasn't that compatible.

We can't exactly cater to the third-party stuff companies inevitably do, 
and I know Applix 5.0 included an option to install their own earlier 
Gtk 1.2 lib dependencies, but then the installer scripts failed because 
the system calls were out of date and I never got it to run. As I 
understand, the big problem was this major shift in Glibc, and how it 
was so radically different, even compat-libs wouldn't help.

I still have WP8 and Applix 5 in the boxes, and a commercial box of RH 
6.2, but those days are gone. I can't even find a system old enough to 
run RH 6.2, so I won't be using those office packages. Nothing in 
existence today compares to WP8 in my mind. That sort of wistfulness 
can't rule our decisions, but we can't simply dismiss what it represents 
  *if* we plan to reach a wider audience for Linux.

Today, on one of my blogs, someone said we can't afford to pay any 
attention to the more common users because they just don't do anything 
for Linux as a whole. That's just plain wrong. So I replied with the 
idea, if more people used Linux versus that virus magnet OS, the Net 
would be a better place to play and work, and a lot more people would be 
better off, including we FOSS fans. A hobby is better when it welcomes 
everyone, because just having a larger presence is its own blessing.

-- 
Ed Hurst
------------
Associate Editor, Open for Business: http://ofb.biz/
Applied Bible - http://soulkiln.org/
Kiln of the Soul - http://soulkiln.blogspot.com/