[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