Re: [9fans] There is no fork

[Giacomo Tesio <giacomo@tesio.it>]

2018-02-12 14:05 GMT+01:00 Ethan Grammatikidis <eekee57@fastmail.fm>:
> On Mon, Feb 12, 2018, at 8:33 AM, Giacomo Tesio wrote:
>> 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.
>
> That's the marketing blurb, I've heard it a thousand times before. [...]
> So, for the last 10-12 years, maybe more, mountains of software have been produced on the assumption that it will be easy to find and install all their dependencies. That's only true for users of big 'distributions' which have lots of people, a large professional team or many contributors, to create and maintain the package tree.

True, but part of cost here is the complexity of the package manager.

>
>> The use of dynamic linking make this complex and cumbersome. Also a single filesystem hierarchy does not help
>
> Dynamic linking is probably the largest, most visible part of the problem, but your saying this makes me think you haven't tried to compile very much software -- certainly not on anything other than Debian or a similarly large distro where, these days, you can get all the dependencies by pasting a line the package author provided.

Well, I use Debian from Potato, but I've got my headaches with
pinning, backports, conflicts and broken upgrades.

Also, I think I've compiled my amount of software.
As a rather recent example, automating the compilation of the gcc
cross-compiler for Jehanne took its time since I had to compile and
install locally specific versions of autotools and binutils, without
forcing users to install texinfo.

I think I have an idea of what I'm doing, but I'm pretty open to
suggestions and criticisms: the best time for them is now, since I did
no real work on the matter.

> The painful ones particularly included dependencies for otherwise nice programs. I'd get 2 or 3 levels down the dependency tree, and suddenly, chaos!
> [...]
> Thinking about this stuff makes me bitter, so I ought to stop now. It's possible the things you want won't intersect with the things which caused me trouble, but I think I have considerable reason for pessimism.

Well, obviously I'm naive enough to try to do something better! :-D

I think the problem is really tied to the nature of software
development... just because bugs are.

To my money you have an alternative:
- to be mostly self contained (as Plan 9/9front does), which is the
optimal solution to the problem
- to leverage outside softwares which evolve outside your control

Both solution have to cope with bugs:
- in Plan 9/9front you fix them
- in other systems you can still fix them but if you contribute back
the fix things turn "complex"...

Versioning, dependency trees (or sometime even graphs) and all these
monsters comes from this problem.

The self-contained approach is way more efficient... and simpler. Thus
it's very attractive to me.

But, my insight is that these monsters need to be faced, and defeated. :-)
Since you can't stop (or control) the evolution of software you do not
code yourself, there's no way to avoid versioning and using that
software.

But again my insight is that using static linking and namespaces,
packages can be way easier to maintain.


Still, I'd really like to know details about your concerns and your
painful experiences, since they could put me on the right track.



> I'd like to think there are enough people who don't want to be tied up in all this pain to create some semblance of a software ecosystem outside it, but when you consider that few people want to start from the ground up, and how poettering and fd.o have their tentacles in crucial parts of the posix-related ecosystem, it looks impossible.

Well, actually there are several hobby OSes that do not support posix
and package management.
(and some have interesting ideas too...)

But the problem with your approach is not just posix compliance.


For example, in Jehanne most tools you are used in Plan 9 are not part
of the core system.

For example, porting Plan 9/9front games to Jehanne is trivial (could
even be automated), but their changes should not cause the core system
to "evolve".

So the solution, again, is installing them as packages, with their own
versions. And this is the reason why there are no games in Jehanne:
they are waiting for a package manager.


The problem, as always, is to get the axes right.


An OS core system should evolve as a whole.
But since its usefulness depend on the amount of things people can do
with it, it should also be able to run exogenous software.


The Plan9/9front approach is optimal because it's perfectly useful
exactly to the people it want to be useful to.


Jehanne is useless. It's just a toy, aka a research operating system. :-)
But in it's research scope is how to enable software development to
scale more easily than in mainstream alternatives.


My insight is that, as a simpler system, Jehanne will be more powerful.
And the additional simplicity/power will make such complex problems
almost disappear.


Giacomo