Re: A proposed Roadmap

[Michael Casadevall]

On Mon, 2007-09-10 at 01:07 +0200, address@hidden wrote:
> Hi,
> 
> On Thu, Sep 06, 2007 at 10:24:05PM -0600, Michael Heath wrote:
> > On 9/6/07, address@hidden <address@hidden> wrote:
> 
> > > As I already said on IRC, this suggestion is totally out of the
> > > question IMHO.
> > 
> > 
> > First, please remember that a good number of people subscribed to this
> > list and replying to discussion on it are not in whatever IRC channel
> > you're talking about. If there is a relevant discussion or opinion,
> > write it/re-write it here, don't just talk about it like the matter is
> > settled and done without ever talking about the matter.
> 
> I did, and in mode detail in fact than on IRC. The reference was just
> for Steven to know that I am one of those who already replied on IRC.
> 
> > If you notice, you call these operating systems GNU/Linux. Why?
> > Because they are theoretically _based on the GNU operating system_.
> > GNU would not be competing with these things, it is what all of these
> > things have in COMMON.
> 
> No -- what you are describing is the current situation. GNU is the
> common base of all GNU/Linux distributions.
> 
> Releasing an "official" Linux-based GNU distribution wouldn't form a
> common base for other GNU/Linux distributions. Rather, it would be a
> direct competitor.
> 

The Linux Standard Base already exists for this purpose, and quite a few
distros don't even follow it to the letter. Even if we created an
offical GNU/Linux distro as a base, we'd simply be duplicating effort. 

> > I don't understand your argument about how "there would be absolutely
> > no chance of moving over to the Hurd unless it's almost perfect".
> > You're basically saying people shouldn't use software that works well
> > because it discourages interest in software that doesn't.
> 
> No, that's not what I am saying. I am saying that once people are stuck
> with something medicore but working, they have little inclination to
> switch to something better. Switching always means immediate work and
> giving up things one is used to, and people are very reluctant to do so,
> even if they know it would save work in the long run. There must be
> extremely strong inclination for a switch.
> 
> There must be even stronger inclination for a switch from to something
> that is only potentially better due to better design, but for the time
> being very rough and incomplete.
> 
> Think of oskit-mach. (Alias gnuamch2.) At it's time, it was generally
> meant to be a step forward; soon to replace the existing gnumach. It was
> believed to solve many of the existing problems, having a cleaner code
> base and a more promising approach to drivers. (Well, it seemed more
> promising at that time...)
> 
> oskit-mach was mostly complete; only little effort would have been
> necessary to make it work for most people. Yet, most people preferred
> putting effort into improving gnumach1.
> 
> Why was that? Because gnumach1 was already working for most people, and
> if it didn't, there was only little missing to make it work for any
> particular person. Although the total amount of work to make oskit-mach
> work would probably have been considerably less than the sum of all
> fixes and improvements to make gnumach1 work for everyone, for any
> single person, it was much easier to make gnumach1 work. The medicore
> solution prevailed.

This reminded me of an old quote:

"Plan 9 failed simply because it fell short of being a compelling enough
improvement on Unix to displace its ancestor. Compared to Plan 9, Unix
creaks and clanks and has obvious rust spots, but it gets the job done
well enough to hold its position. There is a lesson here for ambitious
system architects: the most dangerous enemy of a better solution is an
existing codebase that is just good enough."

> 
> The same would happen with a Linux-based GNU system. All the effort
> would go into providing specific workarounds and fixed to make Linux,
> and the system based on Linux, work for this or that specific purpose,
> rather than working on the Hurd, which having a better design, would
> avoid many of these problems in the first place.
> 

I wasn't around when gnumach2 was under development, but I thought there
were various issues regarding it and the way OSKit worked and
interacted.

> 
> -antrik-
> 
>

signature.asc
Description: This is a digitally signed message part