On Mon, Feb 12, 2018, at 8:33 AM, Giacomo Tesio wrote:
> 2018-02-12 2:10 GMT+01:00 Ethan Grammatikidis <eeke...@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

Reply via email to