[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Does the KISS principle apply?
Title: Does the KISS principle apply?
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.
>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 10/8/00, 10:24:16 PM, tjoccam@xxxxxxxxxxxxx (Lawrence Dickson) wrote
regarding Re: For the love of CSP ...:
> 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
> 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.
> >> > Most of the programmers I've worked with want proof by example:
> >> > examples of large-scale programs/systems written without undue
> >> > anguish :-). It seems to me that this could be supplied, for
> >> > converting the KROC based web-server to JCSP and commercializing
it - or
> >> > at least sticking it in people's faces (just kidding) - along
> >> > performance numbers ala ApacheBench (not unlike those provided
> >> >
> >> The "proof/demonstration" that the methods work on large problems
> >> different. I think that we have examples, but given the small
> >> CSP efforts, it is hardly surprising that we can't display many
> >> examples. Chicken and egg. Of course, such examples are crucial.
> >> feeling is that we need more automatic tools both to solve bigger
> >> and to make the methods more accessible to ordinary users. Almost
> >> has been done by small isolated groups and often individuals
> >> academia with virtually zero funding. It is amazing what has been
> >> with such limited resources and with so much discouragement. It is
> >> the approach is so elegant and powerful that it engenders
> >> once one has understood properly.
> >Here's the modest proposal: How about open source development? KROC
> >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
> >then undergraduates eager for fame! "All" it takes (he said naively)
> >a site at www.sourceforge.com.
> My suggestion for an open-source development (I'll talk X86 but it
> apply to any chip):
> (a) A 32-bit DOS-like OS that, as DOS did, opens up Ring 0 to
> not just kernels; is similarly anarchic; but offers hooks so that the
> careful programmer can embed cooperative program status information
> each process instead of centralized. This keeps the OS tiny. It would
> not even be explicitly multitasking, but a smart process could
> multitasking loads itself; I did this in DOS.
> (b) An occam compiler that would generate smart processes of the
> sort, and work in concert with a C compiler that would be smart about
> dynamic stuff. One dynamic heritage can run amongst many static
> programs (these take the place of drivers, ELIMINATING THE
> This all runs in Ring 0, so taken together, it can be characterized
> a means of writing a reconfigurable and understandable kernel from
> scratch, easily. It could underlie a whole other set of "standard"
> code programming, if desired. Or function as an easy, modular RTOS.
> Of course, our snappy, bottom-level, kernel-like stuff would also
> hardware ports and channels and thus be able to communicate with all
> other devices on the bare-metal level, without being trapped in
> over-engineered software protocols and drivers. In my opinion,
> 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