Re: [9fans] There is no fork

[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. It's almost as bad as the things git fanatics say. It's taking one small part of the problem and pretending that this is the important thing which it makes easier. The problem I'm talking about is not one small corner of the situation, it's an effect of the reason package managers exist. They exist to make it easy to find and install dependencies. 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.

> 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. I have. Many packages weren't bad, but some were downright painful. The painful ones particularly included dependencies for otherwise nice programs. I'd get 2 or 3 levels down the dependency tree, and suddenly, chaos! I always want to cite freedesktop.org who seemed to be leaders in making it painful, but it's been 9.5 years since i had anything to do with compiling their stuff so I won't say too much.

> 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.

Two or more years ago, a #cat-v regular found insurmountable difficulties running X statically linked with musl. Oh look, there's freedesktop.org again. I think it was Red Hat who had found a way to make it so hard, their name certainly came up. It's not the first time Red Hat has caused problems, they were doing it in the first release following their IPO, in 1998. My Bourne shell skills were almost permanently harmed by attempting to learn from their massively complex init scripts at the time. Looking back, the message is clear: "You can't cope with this on your own. Buy a support contract now!" Oh look, Red Hat pay Lennart Poettering's wages... and now everything depends on dbus and systemd! Supercomputer software which has no reason to do anything but compute its stuff now requires systemd's logger.

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. 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.

I'm now sticking to systems which have nothing to do with posix, at least for hobby use. I have a couple of android devices, but almost no desire to program them directly. I've even got qemu on one of them. I do use an emulator with a 2-level dependency, but if it had taken more than a tiny bit of effort to set up, i would have dropped it and used something else.

--
The lyf so short, the craft so long to lerne. -- Chaucer