From mboxrd@z Thu Jan  1 00:00:00 1970
Message-Id: <200006222247.XAA17842@whitecrow.demon.co.uk>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] SO for plan9?
In-reply-to: Your message of "Thu, 22 Jun 2000 09:19:20 EDT."
             <200006221319.JAA25125@small-gods.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 22 Jun 2000 23:47:40 +0200
From: Steve Kilbane <steve@whitecrow.demon.co.uk>
Topicbox-Message-UUID: c819e904-eac8-11e9-9e20-41e7f4b1d025

Greg Hudson wrote:
> By coincidence, I've read this article.  The primary problems
> discussed in the article stem from the fact that Windows applications
> often ship with replacement DLLs for system libraries.

...in which case, they deserve what they get.

> I have to wonder how much of the anti-shared-library sentiment on this
> list comes from Windows experience.

Probably not a lot, at a guess. It comes down to the goals of libraries,
shared libraries, and plan 9.


> Unix-based systems have been
> using shared libraries with reasonable success for ages.

Lots of things have been done with reasonable success on Unix for
ages;  this does not necessarily mean they've been done in the
best way, or even a good way.

> I'm sure
> that it's more elegant if you can just use IPC or write small code,
> but Plan 9 accomplished that goal at the expense of backward
> compatibility with its predecessor, something a successful operating
> system can probably never do.

Well, here we come right back to goals again.

Libraries are about sharing functionality. Not code, and not services,
but functionality. For most of its life, Unix has been concerned with
finding a solution that fixes the current problem without causing others
elsewhere, and without requiring too much effort. The majority of
developers have been user-level programmers, and their solutions have
been user-level ones. Unix's stream-based functionality encourages
solutions using independent processes that interact through files.
All this lead to common libraries, and the myriad of solutions lead
to big programs, hence shared libraries. The ability to "upgrade" a lot
of programs at once was a big win for commercial vendors too.


Plan 9 takes a different approach. For starters, it's a development
system, and that means a problem is solved at the "best" place for it,
whether that means changing an application, a system call, a protocol,
a library or a language. Backwards compatibility with Unix is demonstrably
not an issue. Generally speaking, this means that there has usually been
an alternative approach to including the same functionality in many
programs.

It also means that the other big point of shared libraries - multiple
program fixing - isn't such an issue, because complete system rebuilds
are much less of a big deal to the developers than to the average user
of a commercial Unix system.

And, of course, the developers had limited time and resources. Plan 9
isn't "complete" - it's a broad, wide-reaching system that doesn't do
everything, because some things just weren't worth the effort, for the
benefit they'd provide.

If you want dynamic linking in a Plan 9-like environment, there's
always Inferno: different system goals, so a different solution.

As the early papers said, if you think of it as Unix, you'll be
disappointed. If Plan 9 doesn't have something Unix does, it's
usually worth asking whether it needs it.