[conspire] Distro thread

[Michael Paoli]

> From: Texx <texxgadget at gmail.com>
> Subject: Re: [conspire] Distro thread
> Date: Mon, 8 Apr 2019 22:47:51 -0700

> Sorry Rick, I wasnt clear.
> Its not the RPM tool that is at fault.
> Its the nimrods who WRITE the damn packages who need to be hauled out and
> burnt at the stake.
> I dont know what passes for QA in RPM, but I sure dont see it.

Well, ... just my humble opinion ;-) / "observations" (a single data
point ... one user/sysadmin/...) ...

QA in RPM?  I think it's (mostly) matter of distro.
As for Red Hat ... ugh, ... sure, not that it's *all* that bad,
and yes, I've generally been *paid* to work on Red Hat stuff (but
not develop their actual software) - so - my experience might also be
skewed by # of systems running what distros, and my #s of hours
experience/time on them, as opposed to other distros, ...

But taking all those caveats ;-) I generally find/encounter a friggin'
helluva lot more bugs in Red Hat, notably compared to Debian (my
preferred distro).  And, I don't think it's at *all* a package format
thing.  *Anyone* (well, in theory), can write up software and put it
into a .rpm or .deb package format - or just do the source and suitably
release it - none of those actions automagically get it into any
particular distro.  So, about anyone can write a cr*p package.  That's
also one of the significant hazards of 3rd party repositories,
PPAs, and the like - they are (generally/mostly/entirely) *beyond*
the control of the distro.

But ... distros themselves.  Sure, I've hit *some* bugs in Debian.
But in all my years experience with it (I've been running Debian
as my preferred distro since 1998), I've encountered relatively few
bugs.  Also, Debian's handling of bugs has been - I'd say excellent,
certainly at least very good.  They're well tracked, it's open (don't
have to be a paid customer or create a login to look at all or nearly
all of the relevant information, submit relevant information, etc.),
they tend (at least in my opinion) to get fixed relatively fast - and
well - at least relative to their criticality/importance, etc. - and with
the caveat that Debian stable is ... *stable* - it's not "pushed"
to stable unless it's either security, critical, or in some cases
at the "important" priority level (there's unstable/sid, and testing
if one needs faster/newer ... and also backports, for newer versions).

Red Hat, on the other hand, I've seen many drain bamaged really idiodic
bugs.  And I encounter them far too frequently.  E.g., latest I bumped
into?  authconfig.  Last week - might've even been Friday - or latter
part of the week (bug of the week?).  It's got option(s) to disable /
not use sss/sssd.  I run it, with all those applicable options.  And,
WTF does it bloody do?  Bloody reconfigures things for and enables
sss/sssd.  WTF?  Look over the man page - yep, it's absolutely doing
what it's not supposed to. ... man page ... AUTHORS ... every bloody
one of 'em @redhat.com.  "Of course".  Unfortunately this is the kind
of cr*p I expect from Red Hat - not that they're *always* that bad, and
certainly not on everything, but ... some things ... UGH!

Another Red Hat example - I think this may have been the first, or among the
first - bugs I ran into with Red Hat.  The up2date utility ... for updating.
It - at least was - their enterprise solution for how you get your Red Hat
system caught up on patches/updates - just run up2date.  Of course it
used Red Hat's server(s) to do its updating.  Well, first of all ...
about (>=)10% of the time I tried to use it - Red Hat's servers weren't
available - to The Internet - period.  They weren't online, or couldn't
handle the load, or whatever, they'd fail - definitely not enterprise
class solution (you've got that 3 hour window in the middle of the night
to get those hosts updated and reboot with the newer kernel ... yep,
can't get the data from Red Hat now - try rescheduling for another day -
thanks for paying Red Hat for this (dis)service).  But that's just where
the "fun" begins ... up2date.  What do you think would happen when it
failed - in *any* way?  Non-zero exit/return value?  Errors to stderr
and/or logs?  Heh, don't you wish.  Exit/return value of 0, no matter how
borked and out-of-service Red Hat's up2date service servers were.
And error diagnostics, ... oh no, not to stderr - or logs, but stdout.
Sheez.

Another brain dead Red Hat bug - hopefully they fixed this years/decade(s)
ago (but I'm almost afraid to test it).  So, let's say, for
security/performance and/or other reasons, you have /usr as a separate
filesystem (Fedora/Red Hat/CentOS no longer supports such option).
Let's say you've got it mounted read-only (ro) - at least most of the time.
And you would then remount it read-write (rw) to do software udpates,
e.g. like installing something with rpm (way back then), or (more typically
now) yum, or the like.  Let's say you happen to make the boneheaded mistake
of trying to install a package with rpm, but while /usr is mounted ro.
What does it do?  Throw lots of errors, and fail to install and give
a non-zero exit/return value?  Heh.  At least back then, the damn bloody
thing didn't give any errors, gave exit/return value of 0, happily went
along and updated its database tracking of what software it had installed
(which is tracked under /var), but of course fail to install any of the
software (all or most all of which went under /usr).  Bloody hell.
Don't they bother to check the return values of any of their operations,
procedures, system calls?  I mean I could do quite similar on Debian,
and it would, as one would expect of sane software, fail, and quite
clearly so - complaints to stderr, non-zero exit, and it wouldn't
update its database to say the software was now successfully installed,
but oh no, not Red Hat.  Sheesh.  And while I'm poking at Red Hat ...
yum ... vs. apt/apt-get.  With apt/apt-get, one can configure "hooks"
into it, so that, highly conveniently, one can do things like have
/usr remounted rw before doing apt/apt-get operations, and (attempt to)
remount it ro after.  The yum utility has no such capability anywhere in
its configurations - there's no where to put in any kind of "hook" whatsoever
to have it do any specific thing(s) at the start of, and/or end of, its
invocation.

Another one I remember a bit more vaguely - Red Hat's (at least once upon
a time) default DHCP client software.  It didn't work at all as documented.
Notably - I forget the details - but needed to use two different DHCP
servers, depending upon specific networks, or something like that ... it
just bloodly wouldn't work at all as documented.  Had Red Hat support,
great, call 'em up.  Their response?  Was basically, "Oh, yes, that's a
bug ... but it's not important enough for us to fix it in this major
release.  We might get around to fixing it in the next major release.
Thanks for paying for this."  Although they did give one useful piece of
information at that time - try <some other non-default DHCP client software
they also happened to package> ... that did happen to in fact actually work.

Many other, <cough, cough> "gems" ... but those kind'a stick out like a
sore thumb (if not much more so than that).

Of course I also don't like how the farther one gets from Red Hat's rather
minimal core repository stuff, the thinner and fainter the support
gets ... and "of course" one almost always needs (at least for many
typical server environments) - one or more packages (if not dozens or
more) from those lesser supported repos.  Ubuntu is rather similar in that
regard too.  By comparison, Debian - pretty much same support across all
(well, if you get away from stable, you don't have (official) security
support ... notwithstanding Debian's LTS and "oldstable" - while they're
so/still supported).

So, yeah, ... I really don't think it's the packaging.

Not that Red Hat is all cr*p (or even mostly so?).  They do *also* put
out - including releasing as Open Source, some(/much?) great/excellent
software too.  But alas, they sure also have a (more than?) fair bunch
'o cr*p that's pretty broken in their OS.

Anyway, that's my take/experience on it - yours probably is (at least a
bit) different.  I haven't used other distros "heavily enough" to have
particularly (strong) opinions/perspectives on their quality and
lack of bugs or not, ... I do also lump Fedora/Red Hat/CentOS together,
because they're mostly "similar enough" (CentOS - mostly exact same
source code, Fedora - I think of it as "Red Hat Beta" (or maybe Alpha?) -
as that's effectively what it is).