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