[Gllug] Red Hat versus other qualifications
Joel Bernstein
joel at fysh.org
Wed Jul 1 11:15:29 UTC 2009
On 1 Jul 2009, at 11:23, Stuart Sears wrote:
> On 01/07/09 10:59, Joel Bernstein wrote:
>> IME Linux certification isn't worth the paper it's printed on. All
>> the RH-certified admins I worked with were morons who used GUIs to
>> admin servers, just like RH taught them (in 2002-2006, this may have
>> changed now). If you're hiring, I wonder whether certification is
>> being used to substitute for competent interviewing techniques? I
>> would hesitate to trust RH or LPI or whoever to do my interviews for
>> me.
>
> I really have to take issue with this as it is utter nonsense.
> I can't speak for the quality of the admins you have worked with,
> but I
> can speak to the RH courses and content of them - I was a Red Hat
> Instructor
> for 5 years (throughout most of that period, actually) and that is not
> how systems administration is (or was) taught. At all.
Very interesting, then you're definitely in a good position to speak.
I stand corrected.
> The tools can be used (and are often shown) but in general
> (admittedly,
> apart from
> configuring cups** and possibly X) administration is very much
> console-based,
> dealing with configuration files and command-line tools.
> [...]
>> Don't get me wrong. Recent anecdotal on-list evidence suggests the
>> RH certification has improved to the extent that they don't ONLY
>> teach admin using their horrible GUI tools. But I'm not convinced at
>> all by the argument that you need to be "certified" to use their
>> horrible mix of broken backports and ancient userland. Maybe
>> "certifiable" instead?
>
> Ah, I think we see a minor bias here... :)
Maybe. But one worn through blood, sweat, tears etc..
> That's an entirely unhelpful statement, IMHO (and inaccurate).
> broken backports of what? (that's a genuine question, btw)
Perl 5.8 is a good example.
Red Hat seem to have released more broken Perls than any other vendor
I've dealt with.
Staggeringly they managed to release a good set of major distro
versions with Perl's Scalar::Util (part of the Perl core, has a Pure-
Perl and a compiled version, the compiled version providing some key
features including dualvar()) broken by the maintainer forcibly
building only the Pure Perl version.
There's also the ridiculous saga of RH releasing a Perl 5.8 with in-
development (and broken) Perl changes, closing bugs opened by their
users as "upstream patch", and failing to integrate the upstream fixes
which closed the RH bugs. Which never existed in any non-RH Perl
releases since nobody else was stupid enough to try and track unstable
patches. No release of perl ever suffered from these bugs, it's purely
RH hubris.
http://blog.vipul.net/2008/08/24/redhat-perl-what-a-tragedy/
http://use.perl.org/~nicholas/journal/37274 Perl 5.8 pumpking
frustrated about it 9 months later
http://rhn.redhat.com/errata/RHBA-2009-0117.html official RH fix in
Jan 2009!
Maybe this is just one bad maintainer but my impression of the RHEL
support model is that they employ programmmers / maintainers to
backport fixes from upstream releases into the official versions they
released and must support. That's risky and difficult to sustain,
certainly it requires that the developers who do the work understand
the patches they're backporting and that they have some understanding
of the release schedules and repository statuses of the upstream code
they're tracking. Clearly, in this case, several levels of RH
procedures didn't allow that to happen.
I've had too many bug reports due to people deploying my code on a
range of RHEL and Fedora released Perls to recommend that people run
modern Perl applications on RH system-supplied Perl. I'm a Perl (not
"perl" the interpreter) programmer, somewhat involved in the Perl
community, though. So I'd hope to be aware of issues like this in a
package I work closely with. I'm concerned though that similar
patterns might run through RH releases and backported fixes in other
packages, too. If this were the case I would be aghast, but the little
evidence I have is worrying, you must agree?
> I should also make it clear that although I work for RH, I certainly
> do not
> speak on their behalf. Just in case, you understand.
Understood. I expect that everybody on this list is wholly responsible
for their opinions, regardless of their employers.
/joel
--
Gllug mailing list - Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug
More information about the GLLUG
mailing list