9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: David Leimbach <leimy2k@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 10:34:36 -0800	[thread overview]
Message-ID: <3e1162e61002171034x765459b4v22b7755e47bbe7ff@mail.gmail.com> (raw)
In-Reply-To: <20100217182126.GC17100@nibiru.local>

[-- Attachment #1: Type: text/plain, Size: 2689 bytes --]

On Wed, Feb 17, 2010 at 10:21 AM, Enrico Weigelt <weigelt@metux.de> wrote:

> * David Leimbach <leimy2k@gmail.com> wrote:
>
> > A lot of "plug in" functionality you'll find on other platforms
> > that requires a shared library approach can be implemented via
> > a file system service technique.
>
> Of course, and I would really like to see that approach in the GNU
> world too (actually, I already did that in some projects). But it's
> really not easy to convice collegues or clients to this approach
> (often they dont even understand the concept of modularity - sad,
> but true).
>
> Even synthetic filesystems are good for moving bigger things to their
> own services, there're many cases where that wouldnt make sense, for
> example parsers. I doubt you'd really suggest putting an XML parser
> to its own filesystem for real productional use ;-p (having such a
> thing surely is a good idea for some cases, but for most cases an
> library would most likely be much easier and efficient.
>
>
No I'm not saying replace all library code with filesystems.  I don't know
why you'd want an RPC interface to an XML parser :-).

Libraries may not always be more efficient than services.  Imagine if Intel
released their 48 core machine today, how would your system utilize those
cores?  Sequential programming optimizations don't (always) work in the
parallel world, and in a lot of cases you actually want to work redundantly
across multiple processes in order to avoid communication overheads in a
well optimized parallel algorithm.

With all of that in mind, it can be better to distribute the services that
make up an application, or a work flow, as decomposed pieces running
together in concert via a sane RPC mechanism.  So, in the future, the Plan 9
way may be, in fact, more efficient than shared libs all piled up together.

Time will tell, but all indications from those who've been studying
computation for decades seems to point this way.

Dave


> > I don't know why everyone doesn't want to build software this way.
>
> Well, that's probably a psychological/social phenomenon. Maybe some
> "bigger is better" ideology ? ;-o
>
>
> cu
> --
> ----------------------------------------------------------------------
>  Enrico Weigelt, metux IT service -- http://www.metux.de/
>
>  phone:  +49 36207 519931  email: weigelt@metux.de
>  mobile: +49 174 7066481   icq:   210169427         skype: nekrad666
> ----------------------------------------------------------------------
>  Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
> ----------------------------------------------------------------------
>
>

[-- Attachment #2: Type: text/html, Size: 3444 bytes --]

  reply	other threads:[~2010-02-17 18:34 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
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 [this message]
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=3e1162e61002171034x765459b4v22b7755e47bbe7ff@mail.gmail.com \
    --to=leimy2k@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).