Computing freedom (was: a no-kernel system)

[Mike Prince]

I'm sorry it's taken me so long to reply, The holidays have taken their 
social toll.

On Wed, 28 Dec 1994, Francois-Rene Rideau wrote:

>    To me, as I may have said already before, the whole world is a computing
> system; so yes, communications may slow and unsafe indeed, and we may have
> to rely on an extremely heterogeneous hardware *and* software basis.

> free of all those ... stupid-commitee-issued restrictions

So you recognize there are actually smart-committee-issued restrictions ;) ?

> > Objects frequently migrate.  Now it's much tougher to maintain a working
> > set.
> > 
> > Links aren't stable or fast.  You don't have that required module, and
> > you have no way of getting it (or getting it fast).
> >
> > Modules characteristics change over space/time (scoping causes different
> > modules under same name at different times to be acessable).
> 
>    Yes, of course. Getting modules is *slow*. But why should it be *slower*
> than getting the program that needs the module ? This assumption is just
> plain stupid, and it may be true on existing systems just because OS
> providers do not care about modules at all.  But why should we make it true
> on our system ? There are *easy* solutions to that !

A program is made of modules.  But you are not thinking distributed if 
you assume the modules are local.  You could view html as a programming 
language.  If your next "module" is in Finland over a dial-up, I'll 
gaurantee that home-page with a full color picture of Finland will be 
slow to come up.  And please refrain from implicitly calling others 
stupid.  Please give me the *easy* solution to the real *distributed* 
problem.  

>    When you go to the software "shop", you'll bring a software map, that
> lists the modules you have (well, those that you and/or the automatic mapper
> deem interesting). Then, the "shop" will automatically select whatever
> modules you need that the "shop" has, and conversely, whatever modules
> you have, that the shop needs. Then, if security/copyright barriers are
> passed, module transfer will happen automatically.

>    Now, if you want to choose manually whatever modules you import and
> export, then *you* are responsible for modules lacking to obtain a working
> system.

Again, view the html example.

> > You can only afford very small computers (embedded).  When you're fighting
> > over a wasted byte, who can afford to support multiple standards?
> >
> > One thing you forget is the nature of businesses to support everything so
> > their users don't get pissed about a particular format not being
> > accessable.  If you foster the creation of multi-standards, then our beast
> > will grow large.
> 
>    Hey, are you argueing that nobody should be free to write a program that
> diverges from the standard distribution ? Are you trying to say that a
> centralized instance should do *all* the work, and that people would have
> just to enjoy the result and be happy ? This *is* communism and
> totalitarianism.

You know that's not what I'm saying.  But we have to realize that 
standards are around because they make sense, not because a group got 
bored one day and drafted them.  We must carefully craft standards where 
needed and allow freedom everywhere else.  We cannot make a "freedom" 
blanket statement.

[Freedom bit snipped...]

Yes we are free.  But you are going way off the subject.  The fact you 
can rip the ROMs out of your motherboard, connect up a front panel, and 
toggle in some code is proof of that.  No one will arrest you (at least 
not in the states).

What you really want to do is create a language standard, right?  Is that 
not limiting peoples freedom by even making those limitations?  Let's be 
real here.  We need standards, or else we have anarchy.  We'll try to 
employ KISS.  And we need this to work.  And nothing is cast in stone.  
If you don't like my standards throw them out later in favor of others or 
none.  But you have to start somewhere.

>    Now, as for small computers, let the small computer users choose themselves
> what modules they will use; be sure that *they* know far better than *you*
> what *they* do or do not need. If communication is fair and fast enough, bad
> modules will naturally be replaced by better ones, and people who require bad
> modules will be responsible for their modules not being supported. Centralized
> information providers (I insist on the plural) will help people choose modules
> from their actual specifications and/or other people's actual feedback, rather
> than just from the provider's prestige.

You're still stuck in this one computer paradigm. And you can't blame it 
on the users when things don't work.  It's our job to come up with a 
system that works.

Mike