On Wed, Dec 03, 2008 at 09:07:48PM +0200, Sergiu Ivanov wrote:
> On Wed, Dec 3, 2008 at 4:20 AM, <
olafBuddenhagen@gmx.net> wrote:
> I mean, should we adopt the idea of taking a BSD kernel, throwing out
> UNIX stuff, and implementing generic primitives as a possible roadmap.
> Working in this direction we could possibly obtain a modern
> microkernel (as you've said), capable of running modern device
> drivers.
Err, no, I said it would give us a modern Mach implementation -- that's
a very different thing from a modern microkernel... :-)
It would be a great help in solving the poor hardware support, but it
wouldn't change the fact that the Mach design is suboptimal. This is
pretty orthogonal to any efforts for porting to a really modern
microkernel.
> Can we treat this as a plan to achieve success?
Well, propor hardware support is obviously a precondition for success,
and we will have to tackle this sooner or later. Proper hardware support
alone won't result in success though.
Ah, I see...
> > Note that a third variant is possible: If people indeed begin using
> > a Hurd layer on top of some other system on a wider scale, they will
> > be interested in enhancing that underlying system more and more to
> > make the Hurd layer run as well as possible; eventually resulting in
> > something that can be considered native as well -- only that it is
> > created in an evolutionary process starting from something existing,
> > rather than written from scratch. Perhaps this is indeed the smarter
> > approach, in view of today's free software world...
>
> This indeed must be a clever idea. To your knowledge, are their any
> existing solutions that were achieved using this top-down approach (as
> massimo s. calls it)?
No idea what you mean. I know "top-down" in a software development
context only as something mandated by traditional software engineering
bullshit: First working out a design in all details, and only then
implementing actual code according to the design -- which, as everyone
having at least a bit of actual programming experience knows perfectly
well never works, and only results in wasted time, demotivated
developers, and a total mess. (As invariably fundamental problems in the
design will pop up at the last stage, which were humanly impossible to
forsee before actually implementing the stuff.)
That's clear, I'll remember the right name for this
``strategy''. Indeed, I've heard much about such
problems... Fourtunately, I've not yet encountered any personally so
far.
What I'm talking about is starting with a more or less clean slate and
adding the desired functionality bit by bit, versus starting with
something existing but not quite right, and turning it into the desired
thing bit by bit.
Note that both variants can be done evolutionary -- no top-down bullshit
in either of them :-) This is really a pretty orthogonal issue.