[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Does the KISS principle apply?



Title: Re: Does the KISS principle apply?

Hi,

As I reread my msg, especially the subject line, I want it to be clear that I intend no disrepect to Larry Dickson, the views he expressed, or the subscribers to this list. Attempts at wry humor sometimes go astray.

Roy

--

Roy Wilson 
E-mail: designrw@xxxxxxxxxxxxxxxx

Original Message dated 10/9/00, 6:05:27 AM

Author: Roy Wilson <designrw@xxxxxxxxxxxxxxxx>

Re: Does the KISS principle apply?:




Larry,
        I wonder whether it would be easier or harder to get developers
for a
webserver or for what you suggest. 
        Given that CSP already offers the potential for a HUGE (am I
recalling
correctly? :-) ) technical win, a project based on JCSP might get
attention and use from the less technically devout world that the group
appears to wish to influence.

Roy

--

Roy Wilson 
E-mail: designrw@xxxxxxxxxxxxxxxx
 

>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<

On 10/8/00, 10:24:16 PM, tjoccam@xxxxxxxxxxxxx (Lawrence Dickson) wrote
regarding Re: For the love of CSP ...:


> All,

> May I enter this discussion as one with some experience (writing
> for Linux and dealing with, and watching my colleagues deal with,
> open-source code.)

> Just to paint the picture, here's the time-machine "if only":
> If only the original releases of the Transputer and occam had
included
> wide-ranging occam tools targeted to the PC... if only the
> Transputer's technical success had driven a ferment of open-source
> gcc-like occam development for ALL other chips... if only such
> wide-ranging operating-system-free communication capability had
> STUNTED THE GROWTH of operating systems which are now insanely stiff
> and bloated (as the Internet and distributed computing is finally
> starting to do, fifteen years late).

> Here's the upside: "Ring 0" development (interrupts, drivers, cached
> data flow) has become almost impenetrably stiff to develop, even
> under open source systems like Linux, so people tend to give up in
> despair and accept whatever botches the OS offers, and work only on
> top of it. As all of us remember, the Transputer and TRAMs made such
> work (SCSI drivers etc) a fluff job - and it was pretty easy under
> DOS too.

> We could offer a solution...

> >From: Roy Wilson <designrw@xxxxxxxxxxxxxxxx>
> >Date: Mon, 09 Oct 2000 01:02:15 GMT
> >Message-ID: <20001009.1021500@xxxxxxxxxxxx>
> >Subject: For the love of CSP ...
> >To: java-threads@xxxxxxxxx
> >
> >Hi, all!
> >
> >My original msg went to Adrian alone. Given the modest proposal I'm
> >making, I'm forwarding his response to mine.
> >
> ><SNIP>
> >
> >> > Most of the programmers I've worked with want proof by example:
that is,
> >> > examples of large-scale programs/systems written without undue
mental
> >> > anguish :-). It seems to me that this could be supplied, for
example by
> >> > converting the KROC based web-server to JCSP and commercializing
it - or
> >> > at least sticking it in people's faces (just kidding) - along
with
> >> > performance numbers ala ApacheBench (not unlike those provided
by Zeus).
> >> >
> >
> >> The "proof/demonstration" that the methods work on large problems
is somewhat
> >> different. I think that we have examples, but given the small
underfunded
> >> CSP efforts, it is hardly surprising that we can't display many
industrial
> >> examples. Chicken and egg. Of course, such examples are crucial.
My own
> >> feeling is that we need more automatic tools both to solve bigger
problems,
> >> and to make the methods more accessible to ordinary users. Almost
everything
> >> has been done by small isolated groups and often individuals
working in
> >> academia with virtually zero funding. It is amazing what has been
achieved
> >> with such limited resources and with so much discouragement. It is
because
> >> the approach is so elegant and powerful that it engenders
enthusiasm
> >> once one has understood properly.
> >
> >Here's the modest proposal: How about open source development? KROC
is
> >already almost open source (depending how you construe that phrase).
> >Might not a (not so ragtag) scattered band of CSP aficionados cobble
> >together a CSP-rendition of KROC on a par with Apache? If not
professors,
> >then undergraduates eager for fame! "All" it takes (he said naively)
is
> >a site at www.sourceforge.com.
> >
> >Roy

> My suggestion for an open-source development (I'll talk X86 but it
would
> apply to any chip):

> (a) A 32-bit DOS-like OS that, as DOS did, opens up Ring 0 to
programs,
> not just kernels; is similarly anarchic; but offers hooks so that the
> careful programmer can embed cooperative program status information
in
> each process instead of centralized. This keeps the OS tiny. It would
> not even be explicitly multitasking, but a smart process could
arrange
> multitasking loads itself; I did this in DOS.

> (b) An occam compiler that would generate smart processes of the
above
> sort, and work in concert with a C compiler that would be smart about
> dynamic stuff. One dynamic heritage can run amongst many static
parallel
> programs (these take the place of drivers, ELIMINATING THE
STIFFNESS).

> This all runs in Ring 0, so taken together, it can be characterized
as
> a means of writing a reconfigurable and understandable kernel from
> scratch, easily. It could underlie a whole other set of "standard"
user
> code programming, if desired. Or function as an easy, modular RTOS.

> Of course, our snappy, bottom-level, kernel-like stuff would also
have
> hardware ports and channels and thus be able to communicate with all
> other devices on the bare-metal level, without being trapped in
stiff,
> over-engineered software protocols and drivers. In my opinion,
nothing
> more is needed than the two-priority, round-robin interrupt system of
> the Transputer. Real-world slowness is from ill-adapted kernel
> buffering schemes, which we brush aside.

> This is the kind of thing that was easy fifteen years ago and now is
> almost impossibly hard. But the assembly-level hardware protocols are
> little changed in difficulty. We could walk into the gap and take it
> over. People who want to reconfigure bottom-level data flows could,
> I guess, save 90% of their effort using our tools. We could be to
> all the RTOS's what Linux is becoming to the bloat-OS's.

> Larry Dickson