Re: [9fans] SO for plan9?

Re: [9fans] SO for plan9?

[forsyth]

>>hate to see gnome ported and get 20meg staticaly linked
>>simple CD player

there are two ways to look at this.  some say `and therefore shared libraries
are needed'; others wonder `and why exactly is the stuff underpinning a
simple CD player 20 meg in the first place?'.

i had recently wondered why, in the computing world, names that
really ought to refer to rather nimble little things -- elf, dwarf and gnome, for instance --
almost invariably refer to overly large, complex, overblown things
(that were large to begin with).  what must their designers' gardens look like?

[9fans] efficient programs as distinct from humble programmers

[Richard Uhtenwoldt]

in the late 70s, Edsger Dijkstra and Tony Hoare advocated the
"humble-programmer" philosophy, which says that humans tend to
overestimate their ability to handle complexity in software and
consequently one should strive (in addition to one's other objectives)
to pessimize the complexity (measured in lines of code) of the software
one relies on.  often, this is achieved by finding a novel way of
viewing or conceptualizing the problem (like per-process namespaces).
they pointed out the programmer who can meet a set of requirements with
fewer lines of code is the better programmer because a smaller program
will usually be easier for the user to control, more likely to behave
the way the programmer thinks it will behave and easier for future
programmers to modify to do something the original programmer did not
provide for.

in summary, a "humbly-written" program will not unnecessarily waste the
time and the attention of the programmer trying to modify it or the user
trying to control it.

large (ie, rich, generally useful) humbly-written programs are rare. the
Plan 9 papers make it clear that the core designers of Plan 9 are humble
programmers: 3 or 4 times, I saw words to the effect "we were able to
provide this functionality in only XX,000 lines of code" (and yet Plan 9
appears to provide a rich, generally useful software environment).

it is important to distinguish between the aforementioned conserving of
human attentional resources and conserving memory, disk, bandwidth and
cpu resources.  memory size, disk size, bandwidth and cpu speed
double every few years.  the speed at which a person can learn or the
number of things a person can keep track of does not grow like that.

that is why I do not like the term "code bloat".  most Linuxers who use
that term are deploring the wasting of cpu or memory resources.  it would
be more clear if those people refer to "inefficiency".

some people --like dhog@plan9.bell-labs.com in the following quote-- use
the term "code bloat" to mean what I would rather call "gratuitous
complexity":

> > hate to see gnome ported and get 20meg staticaly linked
> > simple CD player
>
> So basically you want shared libraries to mitigate the effects
> of code bloat?  Why not do away with the code bloat instead?
> This is Plan 9's approach.

this use of "code bloat" managed to confuse at least one person,
who thought it referred to wasting memory:

>huh !?!
>
>i thought statically linking each and every application in the system
>IS code bloat

(note that I have not taken a position on shared libraries.)
--
Richard Uhtenwoldt

Re: [9fans] SO for plan9?

[Michael Dingler]

> i had recently wondered why, in the computing world, names that
> really ought to refer to rather nimble little things -- elf, dwarf and gnome,
> for instance -- almost invariably refer to overly large, complex, overblown
> things (that were large to begin with).  what must their designers' gardens
> look like?

Oh, was this paragraph meant as a troll?
SCNR

And to be honest, dwarfs and gnomes were quite small in
most folkloristic traditions, but often misshapen. So
the relationship might still be there.

BTW, what naming tradition would be suitable for Plan 9?
There aren't that many puns on Ed Wood movies. General
alien stuff? Men's names ('sam'). Cartoon references?
("Acme"). Or starting everything with "P"?
(Can't wait for the Plan9 Email Explorer)

...Michael...
(rumpelstiltskin already in use?)

Re: [9fans] SO for plan9?

[Nigel Roles]

> alien stuff? Men's names ('sam'). Cartoon references?

I don't think 'sam' implies a restriction to men's names.

Re: [9fans] SO for plan9?

[James A. Robinson]

> There aren't that many puns on Ed Wood movies. General
> alien stuff? Men's names ('sam'). Cartoon references?
> ("Acme").

I always wondered if Acme was "as in Acme Tools, Inc. (c)" or as in
"point of perfection." =)  If someone ports gnome that person can call
it Battlefield Bell Labs.


Jim

Re: [9fans] SO for plan9?

[Steve Kotsopoulos]

"Nigel Roles" wrote:
> > alien stuff? Men's names ('sam'). Cartoon references?
>
> I don't think 'sam' implies a restriction to men's names.

sam is actually short for Samantha

Re: [9fans] SO for plan9?

[Nigel Roles]

Oh, I was leaving that as an exercise to the reader.

----- Original Message -----
From: "Steve Kotsopoulos" <steve@nevex.com>
To: <9fans@cse.psu.edu>
Sent: Monday, June 26, 2000 3:22 PM
Subject: Re: [9fans] SO for plan9?


> "Nigel Roles" wrote:
> > > alien stuff? Men's names ('sam'). Cartoon references?
> >
> > I don't think 'sam' implies a restriction to men's names.
>
> sam is actually short for Samantha

Re: [9fans] SO for plan9?

[Michael Dingler]

> > > alien stuff? Men's names ('sam'). Cartoon references?
> >
> > I don't think 'sam' implies a restriction to men's names.
>
> sam is actually short for Samantha

Hmm, I remember seeing the name "jim" mentioned in the
original paper, where did that came from then,
"jimpanzees"?

...Michael...

Re: [9fans] SO for plan9?

[Steve Simon]

Michael Dingler wrote:
>
> > > > alien stuff? Men's names ('sam'). Cartoon references?
> > >
> > > I don't think 'sam' implies a restriction to men's names.
> >
> > sam is actually short for Samantha
>
> Hmm, I remember seeing the name "jim" mentioned in the
> original paper, where did that came from then,
> "jimpanzees"?
>
> ...Michael...

I could be wrong but I beleive it went:

	ed - The first Unix editor
	jim - a Mouse _only_ editor on the blit, where everything
		started with a 'j', somthing to do with a jerq
		but I never did find out what that was.
	sam - the end of editor evolution - perfection :-)

-Steve

Re: [9fans] SO for plan9?

[Nigel Roles]

> started with a 'j', somthing to do with a jerq
> but I never did find out what that was.

This is perhaps a pejorative reference to a certain
expensive ICL bitmapped workstation.

Re: [9fans] SO for plan9?

[Tom Duff]

On Jun 28, 10:40am, Nigel Roles wrote:
> Subject: Re: [9fans] SO for plan9?
> > started with a 'j', somthing to do with a jerq
> > but I never did find out what that was.
>
> This is perhaps a pejorative reference to a certain
> expensive ICL bitmapped workstation.

I was there, so I know the story.
When the Lucasfilm computer division
was founded in 1980, we looked around
for machines to use in animators'
and artists' workstations, and seeing
no other reasonable alternatives (Sun
and SGI had not been founded yet) we
picked the Three Rivers Computer
Corporation's PERQ (ICL sold these
in Britain.)  These gadgets were
closely modeled on the Xerox ALTO.
They could address 2MB of memory, and
had an 800x1024x1 bit display -- unheard-of
in those days of PDP-11s and cursor-
addressed terminals.

My first job at Lucasfilm was to produce
a C compiler for this machine.  Until
the compiler was written, the machine
was really only good for running the
canned trade-show demo that came with
it.  This was the usual travesty of
industrial hyperbole, making bold
claims and predictions that the
actual hardware and software could
live up to only in a marketeers
imagination.

It was inevitable that someone would
hack the demo to tell the real truth,
that the machine crashed all the time,
that the microcode was full of bugs,
that there was no software at all,
in the funniest and most embarrassing
manner possible.  The revised demo
referred to the machine as the Jerq.

Some time in early 1981, Rob came to
visit, saw the updated demo, and on
his return to Bell Labs, stole the
name to christen the similar beast
that he and Bart Locanthi (and Dave
Ditzel?) were working on.

The J theme did run through all the
jerq software names.  The debugger was
called joff (the Jerq Obscure Feature
Finder), the editor was jim, the
bitmap editor was jraw (or was that
the schematic capture program?)

--
Tom Duff.  You can't go anywhere without roots.

[9fans] Blit jerq etc - postscript

[Steve Simon]

Tom Duff wrote:

[snip...]
> Some time in early 1981, Rob came to
> visit, saw the updated demo, and on
> his return to Bell Labs, stole the
> name to christen the similar beast
> that he and Bart Locanthi (and Dave
> Ditzel?) were working on.
>
> The J theme did run through all the
> jerq software names.  The debugger was
> called joff (the Jerq Obscure Feature
> Finder), the editor was jim, the
> bitmap editor was jraw (or was that
> the schematic capture program?)
>

I always wondered where it all came from...

Just in case someone is interested more, the BLIT
software has been released at
http://www.bell-labs.com/user/dwd/5620faq.html

I found this a very usefull lesson in how to implement
graphics and particularly the blitblit() function which
I needed for an embedded graphics system recently.

-Steve

Re: [9fans] SO for plan9?

[Douglas A. Gwyn]

Steve Simon wrote:
>         jim - a Mouse _only_ editor on the blit, where everything
>                 started with a 'j', somthing to do with a jerq
>                 but I never did find out what that was.

"Jerq" was a pun on "PERQ", which was a bitmap-oriented workstation.

Re: [9fans] SO for plan9?

[Douglas Fraser]

Tom Duff wrote:

<snip>

> Some time in early 1981, Rob came to
> visit, saw the updated demo, and on
> his return to Bell Labs, stole the
> name to christen the similar beast
> that he and Bart Locanthi (and Dave
> Ditzel?) were working on.
>
> The J theme did run through all the
> jerq software names.  The debugger was
> called joff (the Jerq Obscure Feature
> Finder), the editor was jim, the
> bitmap editor was jraw (or was that
> the schematic capture program?)
>
> --
> Tom Duff.  You can't go anywhere without roots.

Being a subsequent _long_ time
owner/user of a AT&T 5620
bit mapped terminal, I appreciate the
little history here.
I picked one up (way cheap) from a small
engineering firm
that had gone bankrupt. That and a
3b2/300 and three 3B1s.
No one knew what they were so no one
else bid on them.

I used the 5620 for eight years before
finally getting
a 720 ('son of 5620') and eventually a
730 with (gasp!)
an X terminal cartridge. Thematically,
the three were
very consistent. The 5620 went to the
curb after finding
that no one (me included) wanted it
anymore. The 3b2 died.
The three 3b1s (all running...) were
donated to a young
man in Pennsylvania for his computer
museum last spring.

The TEK 4014 emulation on the 5620 was a
hoot.

--
Doug

[9fans] 8088 compiling blit (was Re: Blit jerq etc - postscript)

[Russell Nelson]

Steve Simon <steve@savan.demon.co.uk> writes:

> Just in case someone is interested more, the BLIT
> software has been released at
> http://www.bell-labs.com/user/dwd/5620faq.html

If anybody's interested, GPL'ed source code for my[1] 8088 compiling
blit is at ftp://ftp.crynwr.com/pa/ .  Most of a monochrome windowing
system is there, all in 8088 assembly language.

Look for compile_blit in painti.asm in pasrc.zip.

[1] Patrick Naughton wrote substantial parts of Painter's Apprentice,
however the compiling blit is all mine.

--
-russ nelson <sig@russnelson.com>  http://russnelson.com
Crynwr sells support for free software  | PGPok |
521 Pleasant Valley Rd. | +1 315 268 1925 voice | Is Unix compatible with
Potsdam, NY 13676-3213  | +1 315 268 9201 FAX   | Linux?

Re: [9fans] SO for plan9?

[rob pike]

	Some time in early 1981, Rob came to
	visit, saw the updated demo, and on
	his return to Bell Labs, stole the
	name to christen the similar beast
	that he and Bart Locanthi (and Dave
	Ditzel?) were working on.

All correct, even the ? part (Ditzel later dropped out), except
that 'stole' is inflammatory.  We asked John Seamons for
permission to use the name, and he gave it.

-rob

Re: [9fans] SO for plan9?

[forsyth]

>>picked the Three Rivers Computer
>>Corporation's PERQ (ICL sold these
>>in Britain.)  These gadgets were

the original microcode provided elaborate yet frustrating instructions,
and didn't work all that well.
ICL replaced the Three Rivers microcode to produce a much
faster, more reasonable target, for C and other languages
(I did a Pascal compiler for that version), and ported Unix
to it.   it used a variant of layers for the graphics.
it was not too bad (the user interface had one odd feature),
but Suns had begun to appear by that time and the project was dropped.

Re: [9fans] SO for plan9?

[Srinivasa, Balaji]

> > I had assumed it was a word play on emacs!?
I like the man pages on EMACS(1)

Re: [9fans] SO for plan9?

[john]

Nigel Roles wrote in reply to someone asking about the `jerq':
>> started with a 'j', somthing to do with a jerq
>> but I never did find out what that was.
>
>This is perhaps a pejorative reference to a certain
>expensive ICL bitmapped workstation.

Which was designed and originally made, if I recall correctly,
by a US company called `Three Rivers'(?).

What I do remember is that I spent a lot of time reemplacing
the drive belt of the internal 10Mb (?) disk of the several
instances we had of the workstation in question; these had a
tendency to come off in use.

John A. Murdie

Re: [9fans] SO for plan9?

[Chris Locke]

Skip Tavakkolian <skipt@real.com> wrote in message
news:3.0.5.32.20000626073125.00930420@mail.real.com...
> I had assumed it was a word play on emacs!?
>

That would be MACES
as in "to crack a nut"

Chris.

Re: [9fans] SO for plan9?

[Skip Tavakkolian]

I had assumed it was a word play on emacs!?

At 10:09 AM 6/26/00 -0400, you wrote:
>It's called Acme because it does everything.
>
>-rob
>
>

Re: [9fans] SO for plan9?

[rob pike]

It's called Acme because it does everything.

-rob

Re: [9fans] SO for plan9?

[Douglas A. Gwyn]

Steve Kilbane wrote:
> 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.

Actually, they're not "replacement" in the sense you're thinking.
They are the standard "redistributable" modules and are included
in the installer to make sure that the end-user has them.  Often
the end user doesn't have an important library or has a very old
version that doesn't support features the application depends on.

Re: [9fans] SO for plan9?

[Steve Kilbane]

>
> > Libraries are about sharing functionality. Not code, and not
> > services, but functionality.
>
> How does plan9 solve the problem that for some functionality, it is
> much more efficient (or at least simpler) to manipulate directly the
> C/C++/whatever data structures instead of having to write/read plan9
> files and convert the data gathered there? Does one, in such cases,
> write a wrapper library or do plan9 programs take a different route?

Like I said, each problem is solved on its individual merits, but
with a view that encompasses the whole system, rather than just the
local problem. One is unlikely to produce a file server to offer trig
functionality. Consider the difference between command-line option
parsing and making a network connection. Both are done by many programs.
Both start as calls to common library functions. Option handling, as
I understand it, doesn't go further, while network connections call on
the services of kernel- and user-level file servers. Where to draw the
line is a matter of judgement, but Plan 9 has more flexibility that
Unix does in the matter.

Efficiency is one thing, but simplicity is something else. If all the
application program does is a call a function, what does it care whether
the underlying implementation does everything in-process, or uses a
file server?

steve

Re: [9fans] SO for plan9?

[Tom Duff]

> How does plan9 solve the problem that for some functionality, it is
> much more efficient (or at least simpler) to manipulate directly the
> C/C++/whatever data structures instead of having to write/read plan9
> files and convert the data gathered there?

If it's more efficient, and efficiency is the problem, then that's what
you do.  It's not a religion, just an operating system.

--
Tom Duff.  Umkehren, immer umkehren!

Re: [9fans] SO for plan9?

[Kasper Peeters]

> Libraries are about sharing functionality. Not code, and not
> services, but functionality.

How does plan9 solve the problem that for some functionality, it is
much more efficient (or at least simpler) to manipulate directly the
C/C++/whatever data structures instead of having to write/read plan9
files and convert the data gathered there? Does one, in such cases,
write a wrapper library or do plan9 programs take a different route?

Kasper

Re: [9fans] SO for plan9?

[Douglas A. Gwyn]

Greg Hudson wrote:
> (Incidentally, the person who thought you could trivially get a root
> shell on Solaris using LD_LIBRARY_PATH should do his homework better.
> The run-time loader unsets the LD_* variables for setuid programs on
> all Unix systems supporting shared libraries; it's just too obvious of
> a security hole to have been left open.)

Obvious or not, in fact I did see it exploited just a couple of
years ago.

One also has to wonder what good LD_*_PATH is if some programs
have it taken away from them and are supposed to still operate
correctly.

Re: [9fans] SO for plan9?

[Steve Kilbane]

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.

Re: [9fans] SO for plan9?

[Greg Hudson]

> there is an article on what they call "DLL hell".  It debunks most
> of the supposed advantages of dlls and talks about all the problems
> they have caused.

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.  This concept
is totally foreign to most Unix developers (even commercial Unix
developers, in my experience).

I have to wonder how much of the anti-shared-library sentiment on this
list comes from Windows experience.  Unix-based systems have been
using shared libraries with reasonable success for ages.  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.

(Incidentally, the person who thought you could trivially get a root
shell on Solaris using LD_LIBRARY_PATH should do his homework better.
The run-time loader unsets the LD_* variables for setuid programs on
all Unix systems supporting shared libraries; it's just too obvious of
a security hole to have been left open.)

Re: [9fans] SO for plan9?

[Anthony Sorace]

//> So basically you want shared libraries to mitigate the effects
//> of code bloat?  Why not do away with the code bloat instead?
//> This is Plan 9's approach.
//
//huh !?!
//
//i thought statically linking each and every application in the system
//IS code bloat

maybe that's what _you_ mean when you talk about code bloat, but it's
certainly not the only thing that makes code get needlesly bigger. i
think generally people (myself, certainly) are refering to the writing
of the code itself, asside from how it's organized or built. take a
look at bash, for example. i don't care how you link it; that's still
bloated. shared libraries won't solve problems of bad programing.
: anothy;

Re: [9fans] SO for plan9?

[Howard Trickey]

> Shared libraries are the work of the devil,
> the one true sign that the apocalypse is
> at hand.

Actually, the devil may have seen the error
of his ways, too late.

The latest release of the Microsoft Developer
Network subscription (an ever-upgraded set
of documentation and articles for people
developing Windows apps, distributed by
Microsoft itself), there is an article on
what they call "DLL hell".  It debunks
most of the supposed advantages of dlls
and talks about all the problems they have
caused.  They have a 2-part "solution":

1) Windows 2000 will silently undo any
overwrites of the Microsoft dlls.
2) They recommend putting each dll
needed by an app in a private directory
for that app *only*.

Oh boy.

Re: [9fans] SO for plan9?

[Douglas A. Gwyn]

Tom Duff wrote:
> Shared libraries are the work of the devil,
> the one true sign that the apocalypse is
> at hand.  Seriously, they're good for two
> things, first for plug-in features, which
> in plan 9 are often better handled by 9P
> servers (obviously not always, for example
> if there's an otherwise unachievable latency
> or throughput requirement), and second for
> giving third parties permission to break your
> code after you've shipped it.  I am stunned
> and amazed that anybody that pays salary to
> customer service reps would ever consider
> using shared libraries.

The two usual selling points are that installed
applications benefit from bug fixes in the shared
libraries (e.g. the standard C runtime library),
and that it saves a *lot* of disk space, especially
when big libraries are involved, as in X11.

There are a lot of things wrong with shared libraries
(or sometimes just with particular implementations);
for one thing they make it fairly easy to break
security; suppose a privileged process checks that
you are allowed to perform some action then invokes
a usually innocuous library function that you have
prearranged in your substitute shared library (easy
to do in Plan 9 where you own your name space) to
perform some other action that you would not normally
have been permitted to do.  I've seen this in set-UID
root UNIX programs (just found another yesterday) on
systems such as Solaris where you can affect the
runtime library directory search order (LD_*_PATH);
it is easy to make such a program fire up a /bin/sh
with inherited UID 0, which allows you to do anything
at all!

Re: [9fans] SO for plan9?

[Oleg Krivosheev]

dhog@plan9.bell-labs.com writes:

> kriol@wally.fnal.gov writes:
> > first being the ability to share code between the application
> >
> > hate to see gnome ported and get 20meg staticaly linked
> > simple CD player
>
> So basically you want shared libraries to mitigate the effects
> of code bloat?  Why not do away with the code bloat instead?
> This is Plan 9's approach.

huh !?!

i thought statically linking each and every application in the system
IS code bloat

> In the case that there is some large-ish body of code that
> needs to be shared between applications, the Plan 9 way
> is to make that body of code into a file server which the
> applications can talk to (as already suggested on this list
> by Tom Duff).

and each and every communication will go through
system call and user/kernel transition?

doesn't sound good

> In the worst case, you might need a small
> stub library to put a procedure-call interface on top of
> the file server interface, but it certainly doesn't have to be
> as big as libX11.a!

nice thing about SO that they have exacly the same interface as
static stuff - just function call...

> Acme is an example of this approach; acme handles all the
> gory details of text windows, so that programs like the
> acme mail reader don't have to.

i have to look inside acme more...

>
> It might be interesting to take the Inferno Tk implementation
> and build it into a Plan 9 fileserver...

ok, what about another reason to have SO - patch libraries on the fly?

What do you do when you discover serios bug in libc/libm/whatever?

with Debian i just do "apt-get install libc6" and voila -
all bugs are fixed in no time (well, almost ;)) while
1/2 gig installation is intact.
And it would be probably 1gig installation for plan9 with
all stuff linked statically...

any hews/ideas here? i'm quite curious...

thank you

OK
\x01\x01\x01\x01

Re: [9fans] SO for plan9?

[Randolph Fritz]

On Wed, Jun 21, 2000 at 11:16:02AM -0400, dhog@plan9.bell-labs.com wrote:
>
> So basically you want shared libraries to mitigate the effects
> of code bloat?  Why not do away with the code bloat instead?
> This is Plan 9's approach.
>

My program is as memory efficient as possible, yours is big, *theirs*
has "code bloat?" :)

--
Randolph Fritz
Eugene, Oregon, USA

Re: [9fans] SO for plan9?

[dhog]

kriol@wally.fnal.gov writes:
> first being the ability to share code between the application
>
> hate to see gnome ported and get 20meg staticaly linked
> simple CD player

So basically you want shared libraries to mitigate the effects
of code bloat?  Why not do away with the code bloat instead?
This is Plan 9's approach.

In the case that there is some large-ish body of code that
needs to be shared between applications, the Plan 9 way
is to make that body of code into a file server which the
applications can talk to (as already suggested on this list
by Tom Duff).  In the worst case, you might need a small
stub library to put a procedure-call interface on top of
the file server interface, but it certainly doesn't have to be
as big as libX11.a!

Acme is an example of this approach; acme handles all the
gory details of text windows, so that programs like the
acme mail reader don't have to.

It might be interesting to take the Inferno Tk implementation
and build it into a Plan 9 fileserver...

Re: [9fans] SO for plan9?

[Alexander Viro]

On Tue, 20 Jun 2000, Tom Duff wrote:

> > AFAIK there are no shared libraries in plan9?
> > Any ideas will they be available?
>
> Shared libraries are the work of the devil,
> the one true sign that the apocalypse is
> at hand.  Seriously, they're good for two
> things, first for plug-in features, which
> in plan 9 are often better handled by 9P
> servers (obviously not always, for example
> if there's an otherwise unachievable latency
> or throughput requirement), and second for
> giving third parties permission to break your
> code after you've shipped it.  I am stunned
> and amazed that anybody that pays salary to
> customer service reps would ever consider
> using shared libraries.

Erm... There is one more reason to use them, but it requires a working
mmap() (OK, demand-paging of your binaries - if you can do that you can do
mmap() anyway). If foo and bar are statically linked against the same
library you will have no way to tell that parts of the image can be
shared (as long as they are clean, yodda, yodda). If they are using the
same shared library and you have a pagecache-based system you will get the
sharing for free.

Re: [9fans] SO for plan9?

[Oleg Krivosheev]

td@pixar.com (Tom Duff) writes:

> > AFAIK there are no shared libraries in plan9?
> > Any ideas will they be available?
>
> Shared libraries are the work of the devil,
> the one true sign that the apocalypse is
> at hand.  Seriously, they're good for two
> things,

huh !?!

well, three things for me...

first being the ability to share code between the application

hate to see gnome ported and get 20meg staticaly linked
simple CD player

> first for plug-in features, which
> in plan 9 are often better handled by 9P
> servers (obviously not always, for example
> if there's an otherwise unachievable latency
> or throughput requirement),

that is second for me. looks like porting something
like mozilla or gimp would be close to impossible, isn't it?

> and second for
> giving third parties permission to break your
> code after you've shipped it.  I am stunned
> and amazed that anybody that pays salary to
> customer service reps would ever consider
> using shared libraries.

third would be the ability to patch/replace
basic libraries without replacing the applications

> --
> Tom Duff.  At the end, one person called for an encore.

same as in Duff's device?

OK

Re: [9fans] SO for plan9?

[Tom Duff]

> AFAIK there are no shared libraries in plan9?
> Any ideas will they be available?

Shared libraries are the work of the devil,
the one true sign that the apocalypse is
at hand.  Seriously, they're good for two
things, first for plug-in features, which
in plan 9 are often better handled by 9P
servers (obviously not always, for example
if there's an otherwise unachievable latency
or throughput requirement), and second for
giving third parties permission to break your
code after you've shipped it.  I am stunned
and amazed that anybody that pays salary to
customer service reps would ever consider
using shared libraries.

--
Tom Duff.  At the end, one person called for an encore.

Re: [9fans] SO for plan9?

[rob pike]

	AFAIK there are no shared libraries in plan9?
	Any ideas will they be available?

We haven't felt the need for shared libraries in Plan 9.

	second but related question: are there advanced
	ELF-like features like weak symbol, .init/.fini
	sections etc?

The object file format is pretty straightforward. It doesn't
even have type symbols; those are written to a separate
file in the form of an acid(1) program.  See a.out(6) for
details of the object file format; 2c(1) and acid(1) for
the symbols.

-rob

[9fans] SO for plan9?

[Oleg Krivosheev]

Hi, All

AFAIK there are no shared libraries in plan9?
Any ideas will they be available?

second but related question: are there advanced
ELF-like features like weak symbol, .init/.fini
sections etc?

thank you

OK