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.