Hello, On Mon, Dec 8, 2008 at 9:15 PM, <olafbuddenha...@gmx.net> wrote:
> On Wed, Dec 03, 2008 at 09:07:48PM +0200, Sergiu Ivanov wrote: > > On Wed, Dec 3, 2008 at 4:20 AM, <olafbuddenha...@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. > Yep, I've got it :-) I don't really like this top-down thing at all... I've seen people writing hundreds of sheets of papers by hand (!) just to spend even more time on them afterwards, when corrections were required... Thanks for information :-) Regards, scolobb
