[Sussex] Sky boxen / Embeded LINUX and NT

[Steve Dobson]

Geoff

On 27 September 2002 Geoff Teale said:
> Steve Dobson wrote:
> ====================
> <snippage>
> 
> >>This is a different question.  I was addressing the question:
> >>"How can we be sure that LINUX in embedded space isn't a lame 
> >>duck just like Windows?"  This is moving into the question of:
> >>"Now that `small' embedded computers are as powerful as the
> >>desktop systems of a few years ago.  How do we ensure that
> >>Linux wins over Windows and other commercial OSs?"
> >
> You're right!  I did loose the thread in the discussion someplace.

No problem; and I don't mind.  Very easy to do - but I was only
working from the one point of view, hence my response.  If we
widen the starting point then my PoV changes too.

> I think the answer is that LINUX will naturally adjust to the 
> roles it is used in.  More features (such as low-latency
> kernels) will get added in.  My only concern is that all of
> this will make the kernel more complex and harder to maintain.
>
> Slightly off topic, but, from a maintenance point of view 
> microkernels (the HURD excepted) are generally easier to
> maintain.  An analogy would be the maintenance of a
> unstructured program (i.e one where everything is executed
> in one long script) as opposed to maintenance of a well 
> structured object orientated program (incidentally the
> company I currently work for tend to write programs using
> the first unstructured approach - just one of several
> reasons why I'm looking for a new job after just 6 months).

I don't think that it is so far off topic.  And your two
paragraphs are so closely related that I left them linked
together so I could address the issues they raise in one go.

Yes: Linux will naturally adjust to the roles demanded of it,
unlike Windows that may be forced into areas where is just 
isn't suited.

Macro-kernels are by nature small.  After all they move some
of the monolithic kernel tasks (like file system handling)
out to user land processes.  By keeping the tasks of a system
small so the code is kept small and therefore easier to 
maintain [generalism].

However, Linux is a well OODed system with strong APIs between
the different parts of the system.  These APIs are where the
processes on a macro kernel would be sending messages, but in
Linux can be done faster as they are just direct routine calls.

By having a good set of APIs then replacement modules tuned to
the different environments can be "simply" plugged in.  The
trick here is to keep the APIs flexible and small, otherwise
the code could get far to complex to support.  I think this is
the way Linux is going, but I don't track the KDML.

<snip>
Where you agreed with my argument.  I'm not sure if it was the
weight of the argument or the weight of all those words. :-)
</snip>