Re: [9fans] There is no fork

[Giacomo Tesio <giacomo@tesio.it>]

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

2018-02-12 2:10 GMT+01:00 Ethan Grammatikidis <eekee57@fastmail.fm>:

> 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

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