9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Nick LaForge <nicklaforge@gmail.com>
To: weigelt@metux.de, Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] Binary format
Date: Wed, 17 Feb 2010 11:00:13 -0800	[thread overview]
Message-ID: <1fc0d9801002171100g253bf0dci83af4b4026387091@mail.gmail.com> (raw)
In-Reply-To: <20100217150452.GE10816@nibiru.local>

Enrico Weigelt <weigelt@metux.de> wrote:
>> And another important feature of shared libraries is, that when
>> some lib is updated, importing programs dont have to be recompiled.

Enrico Weigelt <weigelt@metux.de> wrote:
> Actually, that's just a matter of clean dependency handling.
> Include an API/ABI version in the filename, etc.

Why create single points of failure?  The complexity to justify
creating a bureaucracy delegating responsibility of libraries to
different people is not there in Plan9.  The libraries are for
convenience and orthogonality; they are not the definitive API.  That
is defined by the kernel and by 9P.  They really are the black boxes.
And shouldn't you be inspecting any new code paths when using new
code?  Why assume the library writer has tested against YOUR code in
all paths, and bump to the new version, risking regression?

This to me seems insane for production environments, and is all too
common in the open source world where people seem to be writing new
code for it's own sake and to everyone's detriment.

A nice benefit of taking the simple route early on is that it becomes
easier down the road to implement the functionality in one fell swoop,
top-down.  Maybe in the future the kernel could remove redundant code.
 9vx and it's ilk already do something somewhat orthogonal to this by
executing code that is shorter after it's been dynamically re-written.



  parent reply	other threads:[~2010-02-17 19:00 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-17 13:31 Enrico Weigelt
2010-02-17  8:50 ` Jacob Todd
2010-02-17 13:58   ` Enrico Weigelt
2010-02-17 14:01     ` erik quanstrom
2010-02-17 14:06 ` Gorka Guardiola
2010-02-17 14:13   ` David Leimbach
2010-02-17 14:33   ` Enrico Weigelt
2010-02-17 14:55     ` Steve Simon
2010-02-17 15:04       ` Enrico Weigelt
2010-02-17 15:29         ` erik quanstrom
2010-02-17 15:48         ` blstuart
2010-02-17 17:54           ` lucio
2010-02-17 18:37         ` Lyndon Nerenberg (VE6BBM/VE7TFX)
2010-02-17 19:00         ` Nick LaForge [this message]
2010-02-18 15:08         ` Patrick Kelly
2010-02-17 15:58       ` David Leimbach
2010-02-17 16:14       ` Stuart Morrow
2010-02-17 16:28         ` David Leimbach
2010-02-17 18:21           ` Enrico Weigelt
2010-02-17 18:34             ` David Leimbach
2010-02-17 19:02               ` Enrico Weigelt
2010-02-17 19:35                 ` Enrico Weigelt
2010-02-17 18:38             ` Corey Thomasson
2010-02-18 15:16             ` Patrick Kelly
2010-02-17 15:13     ` Robert Raschke
2010-02-17 21:32     ` Jacob Todd
2010-02-17 21:26   ` Nathaniel W Filardo
2010-02-17 23:16     ` EBo
2010-02-17 23:22       ` David Leimbach
2010-02-17 14:38 ` blstuart
2010-02-17 14:58   ` Enrico Weigelt
2010-02-17 15:25     ` blstuart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1fc0d9801002171100g253bf0dci83af4b4026387091@mail.gmail.com \
    --to=nicklaforge@gmail.com \
    --cc=9fans@9fans.net \
    --cc=weigelt@metux.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).