Re: [9fans] linux stats in last year from linuxcon

[David Leimbach <leimy2k@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3393 bytes --]

On Tue, Sep 22, 2009 at 7:47 AM, erik quanstrom <quanstro@quanstro.net>wrote:

> > Are these systems more complex to reason about though?   Probably :-).
>  But
> > when you've only got 7 system calls (per the original L4 specifications
> I've
> > read over) you don't really have a lot to debug.  Just gotta make sure
> you
> > chose the correct primitives to compose all the software you need to
> write
> > on the system.
>
> that functionality doesn't disappear, does it?  where ever it goes,
> the bugs will follow.
>

That's absolutely correct.  However, if you can test a piece in isolation
from other noise, you can rule out certain areas as being suspect in the
process of diagnosing issues.


>
> if the argument is that it's easier to debug if it's not in the kernel,
> i think that argument requires some proof.
>
>
The argument is that if something is logically separable from a larger
system, and independently testable, then once you've verified it is correct,
and that the "glue" is correct that is used to compose a larger system, that
you can more readily decide where to look for problem sources.

This is actually the basis of pure functional programming.  Pure functions
can not deviate in the values they produce because they have a property
called referential transparency.  Not all code can be written this way
obviously, but if you can build a small system, test that it works, then
compose with another small system to do more processing, you can "glue"
those things together to build something more complex.

Think Unix/Plan 9 pipelines of small commands and you get the point.  I
believe this concept took a little mind-bending to get to as well, but seems
almost obvious now. You can think of sort, uniq, and grep as pure functional
routines, which you run some I/O through.  If the inputs are the same, the
outputs (damn well better) be the same.

Back in the "old days" (20 years ago?) Microkernels were going to make it so
that all software was organized this way.  It's just not practical to do so
though.  They wanted servers for disk access, servers for network etc.
 Basically it looked like what GNU Hurd was after... and we see how well
that's done.

You'll find systems based on the L4 microkernels today that implement a
single address space (like Inferno I suppose? or Singularity) and you'll
find stuff like L4-Linux, mostly being used as a way to bridge other OSes to
Linux's drivers, or just to run multiple instances of Linux as in a
virtualization like system like VMWare's high end products provide (they're
basically using a microkernel too for their high-end hypervisors).


> > However some of the more practical academics (yeah I know it's like jumbo
> > shrimp or military intelligence) have spun very interesting things off
> like
>
> we used to call these people research fellows at corporate
> labs.  sadly, their astroid has landed.
>

Yeah :-(.   It's a sad time.  Microsoft, for as much as they've been bashed,
is keeping that dream alive for some.  They seem to understand that R&D is
actually important to keeping on top of things.

I feel a little "icky" to admit it but I really like Visual Studio and F#.
 I was amazed at how quickly I was able to learn C# and write GUI programs
compared to say, Xcode and Cocoa.

Dave








>
> - erik
>
>

[-- Attachment #2: Type: text/html, Size: 4527 bytes --]