<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Ed Hurst wrote:
<blockquote cite="mid:495CD277.4060007@soulkiln.org" type="cite">Jonathan
E. Brickman wrote:
<br>
<br>
<blockquote type="cite">1. Image-only installation, instead of
package-installs. This is
<br>
becoming the new standard in both Linux and Windows, and it produces
<br>
a more predictable result, because packages often break at
<br>
bare-hardware-install due to timing and power management and
<br>
simplified install-time drivers and other factors.
<br>
</blockquote>
<br>
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.
<br>
</blockquote>
Yup. I have actually lost count :-) The easy way to study this
approach, really, is to think of it as "putting a LiveDVD on your hard
drive". If the OS works well as LiveCD, just dump it to the hard drive
and it will do the same. Much easier concept, really, and *much*
easier to test the result.<br>
<blockquote cite="mid:495CD277.4060007@soulkiln.org" type="cite">
<blockquote type="cite">2. ...we steer very clear of those which are
dependent on specific
<br>
desktop environments. I think probably GTK+ is stable, common, and
<br>
compatible enough, to be considered the standard GUI API set for
<br>
config utilities.
<br>
</blockquote>
<br>
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.
<br>
</blockquote>
Exactly. And there is another issue. KDE and Gnome folk seem to love
tying low-level functions -- audio data paths, for one example -- into
high-level optional layers, i.e., KDE and Gnome. This is just
backwards. To work and to interoperate well across apps, such things
have to be low-level, not tied to optional layers. We'll support KDE
for the KDEeeers, because this is the right thing to do for them, and
because Koffice is an office platform in the rising; we'll support
Gnome because there are Gnomers who are producing results similarly
valuable for many; but let's be very careful <i>where we put </i>KDE
and Gnome in the thought processes. KDE and Gnome are not core. GTK+
is core. KDE and Gnome have to run for those who need them...but the
system has to run <u>well</u> without them. Or again, we just
building another Linux Mint. Mint will be a tough act to follow; if we
can fulfill all of DDM0.3 and build a machine that works as well as
Mint, we will be doing something amazing.<br>
<blockquote cite="mid:495CD277.4060007@soulkiln.org" type="cite">
<blockquote type="cite">3. Updates of the core are done all at once,
in very large chunks,
<br>
initially not more than every six months, to be extended to not more
<br>
than once per year after the team gets its act together.
<br>
</blockquote>
<br>
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?
<br>
</blockquote>
We need more input from current distromeisters on this topic. <br>
<br>
But in my definitely less-than-distromeister experience, solutions for
dangerous problems almost always come in the form of updates to (a)
kernel, (b) firewall, (c) malware, and (d) browser and browser-plugin.
So if the core is built from a known-good source-based distro, we are
covered well by their crew (and source-based distro crews, when they
are good, are very very good) for kernel. Firewall and malware are in
the security-set, which gets updated most commonly of all. Currently
browser and system-wide browser-plugin are in the app-set: they may
need to be moved to the security-set. I would much rather trust a
Linux firewall, if trustworthy to keep browser security, than the
browser developers: but I don't know if this is a good idea or not.
This is something for a security expert to ponder, and I'm not one.<br>
<blockquote cite="mid:495CD277.4060007@soulkiln.org" type="cite"><br>
<blockquote type="cite">5. Updates of the app-set are done just like
updates of the core,
<br>
with filesystem tree wipes and recopies. A mechanism will have to be
<br>
in place for user-installed kernel modules.
<br>
</blockquote>
<br>
Some items do stand alone as their own project, with their own
handling.
<br>
<br>
<blockquote type="cite">9. There is also the *dev-set*.
<br>
</blockquote>
<br>
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.
<br>
</blockquote>
That's it entirely. When a good distro is ready for production, its
developers use it, and use it to build it, hence the dev-set. But it's
the last on the list.<br>
<blockquote cite="mid:495CD277.4060007@soulkiln.org" type="cite">
<blockquote type="cite">10. The longevity issue has to be handled
using an agreed-upon
<br>
paradigm added to the above. The glibc situation is our largest
<br>
liability.
<br>
</blockquote>
<br>
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.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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.
<br>
</blockquote>
Right. This is one of the big rubs we have. <br>
<blockquote cite="mid:495CD277.4060007@soulkiln.org" type="cite">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.
<br>
</blockquote>
Agreed. This is how the auto racing community used to work, until
specialization took over. There still are traces, e.g., the rallies,
the Sports Car Club of America, and a few others not well-known and not
well-publicized.<br>
<br>
J.E.B.<br>
<br>
<br>
</body>
</html>