From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <1518397859.379213.1267373104.4DD6AB1E@webmail.messagingengine.com> References: <1518397859.379213.1267373104.4DD6AB1E@webmail.messagingengine.com> From: Giacomo Tesio Date: Mon, 12 Feb 2018 09:33:32 +0100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="001a1140dbb4c5f5220564ffbb39" Subject: Re: [9fans] There is no fork Topicbox-Message-UUID: cdea61f4-ead9-11e9-9d60-3106f5b1d025 --001a1140dbb4c5f5220564ffbb39 Content-Type: text/plain; charset="UTF-8" 2018-02-12 2:10 GMT+01:00 Ethan Grammatikidis : > linux-style package managers and bsd-style port trees facilitate and > enable coupling. > > What a package manager really facilitate is version management. That is when you want to use/update a software at version X that depends on libraries at version Y and Z. The use of dynamic linking make this complex and cumbersome. Also a single filesystem hierarchy does not help Plan 9 does not suffer of this problems because of several reasons: - it does not support dynamic linking - it is developed as a whole "batteries included" - few external packages have being ported to it, and people who use them know their stuff very well Plan 9 (and 9atom/9front) is developed and distributed as "a whole system": there is conceptually only one version for all the software and libraries included. Technically it's the simplest and optimal solution to the versioning problem. Indeed 9front uses a single mercurial repository (which is a versioning system) to manage both development and system updates. I carefully considered this approach for Jehanne too, but decided to try an alternative design. Obviously no dynamic linking will ever land in Jehanne, but I want to enable more external softwares to run on it. This way I reduce the responsibilities of the project and size it to the stable workforce (that is: I, me and myself). It might seem counter intuitive to say that using gcc instead of ken-c simplify the system. It's true that it increase the complexity of the system during compilation, but it reduce the scope of Jehanne itself. So Jehanne's core system can follow the whole system development approach of Plan 9, but it's a minimal system and an included package manager will allow the installation of other useful software. The problem is that the perfect package manager does not yet exists for the Jehanne design. Probably the nearest thing is BSD's pkgsrc, but it doesn't get advantage of namespaces. And which language should I use to code an alternative? Probably C. But I wonder if a more high level language could make the job easier without increasing too much the project scope. So far candidates alternatives (that I still need time to evaluate deeply) are Wirth's Oberon-07 and Obi's Myrddin. Giacomo --001a1140dbb4c5f5220564ffbb39 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
2018-02-12 2:10 GMT+01:00 Ethan Grammatikidis <eekee57@= fastmail.fm>:
linux-style package managers and b= sd-style port trees facilitate and enable coupling.


What a package manager really facilitate is version management.
That is when you want to use/update a software at version X th= at depends on libraries at version Y and Z.
The use of dynami= c linking make this complex and cumbersome. Also a single filesystem hierar= chy does not help

Plan 9 does not suffer of this problems= because of several reasons:
- it does not support dynamic li= nking
- it is developed as a whole "batteries included&q= uot;
- few external packages have being ported to it, and peo= ple who use them know their stuff very well


Plan 9 (a= nd 9atom/9front) is developed and distributed as "a whole system"= : there is conceptually only one version for all the software and libraries= included.


Technically it's the simple= st and optimal solution to the versioning problem.

Indeed= 9front uses a single mercurial repository (which is a versioning system) t= o manage both development and system updates.

=
I carefully considered this approach for Jehanne too, but de= cided to try an alternative design.

Obviously no dynamic = linking will ever land in Jehanne, but I want to enable more external softw= ares to run on it.
This way I reduce the responsibilities of = the project and size it to the stable workforce (that is: I, me and myself)= .

It might seem counter intuitive to say that using gcc i= nstead of ken-c simplify the system.
It's true that it in= crease the complexity of the system during compilation, but it reduce the s= cope of Jehanne itself.


So Jehanne's core system = can follow the whole system development approach of Plan 9, but it's a = minimal system and an included package manager will allow the installation = of other useful software.


The problem is that the per= fect package manager does not yet exists for the Jehanne design.
<= div>Probably the nearest thing is BSD's pkgsrc, but it doesn't get = advantage of namespaces.

And which language should I use to code an = alternative?
Probably C. But I wonder if a more high level la= nguage could make the job easier without increasing too much the project sc= ope.
So far candidates alternatives (that I still need time t= o evaluate deeply) are Wirth's Oberon-07 and Obi's=20 Myrddin.


Giacomo
--001a1140dbb4c5f5220564ffbb39--