From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <20180212161341.GA1542@polynum.com> References: <1518397859.379213.1267373104.4DD6AB1E@webmail.messagingengine.com> <1518440723.631581.1267818416.51CB1908@webmail.messagingengine.com> <20180212161341.GA1542@polynum.com> From: Giacomo Tesio Date: Mon, 12 Feb 2018 21:40:22 +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: cf1494a0-ead9-11e9-9d60-3106f5b1d025 2018-02-12 17:13 GMT+01:00 : > 2018-02-12 14:05 GMT+01:00 Ethan Grammatikidis : >> 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 bee= n produced on the assumption that it will be easy to find and install all t= heir dependencies. That's only true for users of big 'distributions' which = have lots of people, a large professional team or many contributors, to cre= ate and maintain the package tree. > > From a different point of view, the problem is also that the developers, > using some developing tools (for example the GNU automake and autoconf), > don't really know what they are using, or, since "GNU is not Unix", > don't verify that their code is POSIX compliant (and to what level etc.; > when I began using Unix by discovering Linux, I remember reading a book > explaining that for C programming, when linking, you will add always > the Glib library because "there are probably things you will need in > it!"...). I might be proven wrong, but I doubt that developers not understanding their tools can build useful software. Or, if the software they build is useful, it may get enough traction to be rewritten after learning from mistakes. I cannot fix people linking glib just because it exists. Just like I cannot fix people writing a new JS framework/library/wtf. In general I cannot fix people. But, whenever I have to hack on something that depends on cmake, instead of autotools, I know it will take twice as much to get the task done. > > The amount of dependencies of some packages is simply appaling. (One > example is TeXlive, because using some macros involve using an amount > not necessarily kwown of "other" macros, for a lot of people it is > simpler to "take it all" just in order not to "fail"; and this is > when you need only a part of it that you discover that this "all" > depends on things that you do not have on your system---a C++ > compiler and so on). My bet is that, when Jehanne will be the one true OS everybody will hate, people will not install macro packages, but mount a remote file server through a caching file server, including the C++ compiler. Now before going crazy about security, consider that the shell running TeXlive will only see a limited namespace, containing only the file it has to work with and nothing else. But this is not going to happen soon... People do not hate Javascript enough, yet... :-D Giacomo