From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <1518440723.631581.1267818416.51CB1908@webmail.messagingengine.com> References: <1518397859.379213.1267373104.4DD6AB1E@webmail.messagingengine.com> <1518440723.631581.1267818416.51CB1908@webmail.messagingengine.com> From: Giacomo Tesio Date: Mon, 12 Feb 2018 16:21:54 +0100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] There is no fork Topicbox-Message-UUID: ceee2a4a-ead9-11e9-9d60-3106f5b1d025 2018-02-12 14:05 GMT+01:00 Ethan Grammatikidis : > On Mon, Feb 12, 2018, at 8:33 AM, Giacomo Tesio wrote: >> 2018-02-12 2:10 GMT+01:00 Ethan Grammatikidis : >>> linux-style package managers and bsd-style port trees facilitate and en= able 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 th= eir dependencies. That's only true for users of big 'distributions' which h= ave lots of people, a large professional team or many contributors, to crea= te 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 sing= le 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 muc= h software -- certainly not on anything other than Debian or a similarly la= rge 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 pr= ograms. 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 p= ossible 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, an= d how poettering and fd.o have their tentacles in crucial parts of the posi= x-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