On Sun, 2015-03-01 at 21:12 +0100, Philip Lacroix wrote: > As other members have already pointed out, this is not a fair > comparison.
Perhaps. The reasons I made the comparison are: a) All of them have a dependency chain so interwoven and complex that they become non-trivial to remove. You literally cannot have a Debian/Devuan system without things like Perl or Python installed. b) The software written in either language have complex module dependency chains. Install something like MailScanner, and you will install a dozen Perl modules as well as a requirement. c) In both languages, modules are usually something of a "black art" and notorious for being unreliable at unexpected times. In my experience, while you can generally expect things like the Perl core language to act reliably,you can't expect the same of the rest of the Perl ecosystem to do the same. The QA simply is not there. Not to mention that all of this can massively impact performance. Systemd comes on the scene. Like everything else, it naturally has its good and bad points. Soon it starts following a repeating pattern: a) Soon Linux requires it, and it is non-trivial to be rid of it. b) Modules are written in such a way that you must have the core or a shim to use the system. Then they are incorporated into yet more software, and it snowballs. (Sound familiar?) c) The systemd modules impact system performance, and are less than reliable. Again like the the above, the real QA is simply not there. So yes, I do feel the comparison is somewhat valid. My concern however is not a perfect symmetry, but rather the design philosophy behind them. Over the years I've been a programmer the level of abstraction has increased dramatically. More and more complex layers of dependencies are placed one on top of the other. It's the order of the day, and to what end? Call me a minimalist if you like, but as Scotty used to say: "The more you over-think the plumbing, the easier it is to stop up the drain." Software performance and reliability has actually decreased in spite of the fact that your machines are far, far more powerful than the old 8086 I used to spend my days on. You are, of course, welcome to disagree and even tell me to "stuff it" if you wish. Maybe I just come from another time, but I would characterize things like Perl, Python, and Systemd as the push for more and more abstraction that is detrimental to computer science in general. > Packaging is, in the end, just a > practical > way to manage compiled software on your system. On the other hand, what > a given > software does, and how that software is tied to other software, is > inherently > independent from which package management system is being used. If > software A > needs software B because its developer decided to rely on software B, > then it > doesn't matter whether the downstream packager decides to put B as a > dependency > or not. However, if he doesn't, then software A most probably won't work > as > intended, if it'll work at all. I'm not advocating abandoning the model entirely, rather that some of the constraints could be removed and that a more robust model could be created using version management software. I suggested that init files should be separated for example. Init files seldom change between versions. Sometimes they do, certainly - but the majority of the time they are virtually identical. Why repackage the same files over and over? It wastes repo space and user bandwidth every single time an update is issued. Furthermore, if Debian had had a policy of keeping init files apart from binary files, I doubt Devuan would have as much work as they eventually will when Debian goes all in on systemd. Only the init setups, and binaries linked to systemd would require systemd in their chain. At least, that's the way I see it. Feel welcome to disagree, it was just a brainstorm I was tossing about after considering that it was actually the System 5 maintenance resolution that crippled Debian, not systemd itself. The lack of any promise for System 5 is why we are here. Cheers! t.j. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
