[mdlug] Plan 9 from Bell Labs

[Adam Tauno Williams]

On Wed, 2009-10-14 at 14:16 +0000, Jacob Todd wrote:
> On Wed, Oct 14, 2009 at 01:28:52PM -0400, Adam Tauno Williams wrote:
> > > So, has anyone else ever heard of this or used it? Here's[2] most of the papers
> > > and here[3] is the official website in case anyone is interested.
> > I think the Plan 9 project has been at least moribund for a long time,
> > and is probably dead.  Plan 9 is the perfect example [agreed on by just
> > about everyone] of solution-in-search-of-a-problem. 
> I don't know what the hell you are talking about, but just about every
> time I start up my qemu image of plan 9 I get updates to a fair amount of files.
> There's a decent size community of people that develope programs for p9, they
> usually just don't advertise it until it's finished. And I doubt anyone agrees
> that p9 is a 'perfect example of solution-in-search-of-a-problem'; whatever
> that may be.

I suggest you read several of the papers looking at plan 9 from a
historical perspective.

> > Numerous bits from
> > Plan 9 like clone and /proc have been assimilated into various other
> > operating systems.  If I recall correctly Plan 9's big 'feature' was
> > everything-is-a-filesystem.  Only all abstractions are leaky and there
> > really is no compelling reason to deal with the leaks in order to
> > pretend that some resource is a file or filesystem. 
> What exactly is 'leaky'? You don't seem to know what you're talking about, and
> seem to have never used p9 for more than a few moments.

?  That abstraction layers are leaky is a common concept in computer
science.   

Take FUSE, for example, it does much of what Plan 9 does.  But if you
make an RDMBS, an LDAP server, an IMAP store, etc...  all look like a
filesystem - you have certainly created something that is useful for
performing common operations in a uniform way.  But you have also
disposed of the distinctiveness of each 'backend' and in the process the
individual strengths of each - by wrapping them with the wet blanket of
an abstraction.  Most modern LDAP servers can perform searches for
certificates based on certificate components,  RDBMS systems can perform
complex joins, IMAP stores [at least real ones like Cyrus] can perform
full-text searches and provide hints for efficient synchronization.  But
not once you pretend-they-are-a-filesystem.  To really exercise the
power of those backends you need to reach around your abstraction layer
- in so doing you essentially recreate the ioctl() of old, just one
layer of abstraction up.  In most circumstances it is a valid question
to ask: "Why bother?"

> > One of the biggest
> > gripes against UN*X was the 'arbitrary' ioctl() call but both BSD and
> > LINUX have effectively eliminated those.
> I can't speak about the BSD's, but I know Linux uses ioctl() all the time. I
> don't know who told you that Linux 'effectively eliminated those' 

There are standard fairly ioctl() calls.  /proc, sysctl, and /sys have
eliminated much of the ioctl() crazy stuff and made a lot more possible.