From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <20100217182126.GC17100@nibiru.local> References: <20100217143303.GC10816@nibiru.local> <0ffee4ba13816a49a6360ce6668e65f2@quintile.net> <3e1162e61002170828i451c9d81ka5061e492db6e6b4@mail.gmail.com> <20100217182126.GC17100@nibiru.local> Date: Wed, 17 Feb 2010 10:34:36 -0800 Message-ID: <3e1162e61002171034x765459b4v22b7755e47bbe7ff@mail.gmail.com> From: David Leimbach To: weigelt@metux.de, Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=000e0cd7065439e35e047fd01a9f Subject: Re: [9fans] Binary format Topicbox-Message-UUID: d5bfe5ba-ead5-11e9-9d60-3106f5b1d025 --000e0cd7065439e35e047fd01a9f Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 17, 2010 at 10:21 AM, Enrico Weigelt wrote: > * David Leimbach 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 > ---------------------------------------------------------------------- > > --000e0cd7065439e35e047fd01a9f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

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 pl= atforms
> 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 libr= ary code with filesystems. =A0I don't know why you'd want an RPC in= terface to an XML parser :-). =A0

Libraries may no= t always be more efficient than services. =A0Imagine if Intel released thei= r 48 core machine today, how would your system utilize those cores? =A0Sequ= ential programming optimizations don't (always) work in the parallel wo= rld, and in a lot of cases you actually want to work redundantly across mul= tiple processes in order to avoid communication overheads in a well optimiz= ed parallel algorithm. =A0

With all of that in mind, it can be better to distribut= e the services that make up an application, or a work flow, as decomposed p= ieces running together in concert via a sane RPC mechanism. =A0So, in the f= uture, 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
=A0
> 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
--
----------------------------------------------------------------------
=A0Enrico Weigelt, metux IT service -- http://www.metux.de/

=A0phone: =A0+49 36207 519931 =A0email: weigelt@metux.de
=A0mobile: +49 174 7066481 =A0 icq: =A0 210169427 =A0 =A0 =A0 =A0 skype: ne= krad666
----------------------------------------------------------------------
=A0Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------


--000e0cd7065439e35e047fd01a9f--