Is RHEL5 the new XP?
For most people, it’s actually CentOS5 we’re talking about, as it’s the most popular RHEL5 clone. And free as in “you don’t need to pay a dime”.
What do have in common [the clones of] RHEL5 and Windows XP SP3?
- They’re already antiquated when comes to what software they provide (OK, Windows XP is much older, however how would you call GIMP 2.2 in the age of GIMP 2.6, the kernel 2.6.18 in the age of 2.6.30, and so on?).
- They’re the most stable and reliable choices in their respective classes (RHEL5 is the most reliable Linux distro, and XP is the most reliable desktop OS from Microsoft).
- Nobody knows when a better choice will show up (I don’t know when RHEL6 is scheduled to be born, and Windows 7 is not much more than Vista Second Edition).
- Therefore, they’re the preferred fallback (“faute de mieux”) solutions for too many people.
By the way, does anyone know when is RHEL6 tentatively scheduled to be released? What kernel will it have? What GNOME version? How about KDE3/KDE4? Will X.Org work reliably with Intel and ATI chips? Will ext4 be supported? Will the package management be PackageKit-based?
My personal opinion is that, given the overwhelming set of regressions in the Linux ecosystem in the last period (kernel, X.Org, KDE4), Red Hat will continue to offer Enterprise Linux 5 (5.3, 5.4, 5.5, 5.6, 5.7, 5.8, 5.9, 5.9.1, 5.9.2, etc.) for a long time, possibly even beyond 2014, and they will delay Enterprise Linux 6 for more than they initially wanted!
Unless they will release a non-X version of RHEL6.
RHEL6 can’t be based on Fedora 9 (too buggy for the enterprise). It can’t be based on Fedora 10 (it includes new technologies still to mature). As for Fedora 11… it has just been delayed for a week, as the best proof that releasing twice a year is unfeasible in a GNU/Linux system where nobody fixes bugs but they prefer to change everything all the time!
The status of RHEL6 is the best-kept IT secret of the moment.
So RHEL5 (or CentOS5 for most of you, or Scientific Linux 5, or StartCom Linux AS 5) is going to last more than initially expected. Isn’t the same for Windows XP?
I am tentatively considering the pros and cons of going for CentOS5. This means I would have to accept, among other things, to go back to ext3, which I dislike since I got the passion for JFS and XFS. Then we go to the extra repos… sigh.
I have just read Dag’s blog post Are there too few people who understand desktop Linux? — a fascinating reading indeed.
As for the dilemma of what clone to choose… I suppose CentOS 5.3 is the best-looking one (unless you want it to look more like 5.2).









May 20, 2009 at 17:50
It is rather astonishing to see that XP has very recent versions of the GIMP :
http://gimp-win.sourceforge.net/stable.html leads to the 2-6.6 versions. And, if empirical testing is efficient and convincing, a dree application is likely to find a greater, vibrant (of course -peut-être d’indignation-) user-base (one of the latest linux slogans) with the XP ports.
The decision to have incompatible versions is unconsistent with OOffice’s claims (that maDe its success and made FOSS popular) to be compatible with every version of M$$$$word (as if there were some people who can learn from errors, and others who create mistakes)…
I decided to switch from XP to Centos (at least at work) out of the holiest Chistian charity : I did not want my sysad to die from boredom, and he agreed to give me a Centos ready for safety, but without any applications (I could install more than I needed with pirut and, if necessary -too young- by compiling) and I did not have any failure. Then, I and my colleagues will freeze everything (as nobody is directly interested with bugs made by other people : power surges and self made bugs are sufficient Frozen Fedora can be used in a professional context : I once saw a (demo|debugging session) of a mechanical (not free- but the equations are-) software under a Fedora -this choice surprised me as I thought it was unstable- : the 20 people who tried it were sometimes defacto sysads.
Fedora did not crash (the rest did, of course), though people tried it….
No one went mad with ondulating windows -no need for Nautamin-, poorly configured editors -I noticed 10% of bugs (mine and from people I have to train) come from (poor|missing) syntactic highlighters- or unexplained crashes.
May 20, 2009 at 19:08
gimp-win32 is NOT part of WinXP. In Linux, GIMP is part of almost any distro. This is the main difference — the "megafreeze".
May 20, 2009 at 20:30
I'm sorry to inform you that RHEL 6 will be based upon Fedora 10 and 11
http://lwn.net/Articles/306807/
However, when RHEL 6 will be out, the technologies found in both versions should be stable.
May 20, 2009 at 21:26
I am sorry to say that it can't be based on *both* F10 and F11. (Which version of GNOME? Which kernel? Etc.)
And the message you pointed to is too confusing. "RHEL 6 planning HAS LOOKED TO USE Fedora 10 and Fedora 11 as releases TO WORK OUT new technologies and features that
are desired in RHEL 6." -> DOES NOT MEAN ANYTHING!
May 20, 2009 at 23:56
granted, It doesn't say RHEL 6 will be based upon both of them, my mistake. Still, to my mind it is likely that RHEL 6 will be based on Fedora 11. I even have the idea I read it somewhere but I cannot find the article. I'll keep looking.
May 21, 2009 at 10:33
A lot of technologies included in F11 are questionable for an enterprise usage.
Is PulseAudio mature enough for the enterprise?
Is PackageKit mature enough to replace Pirut (and Pup)?
Is X.Org 1.6.1 good enough for the enterprise, especially with Intel or ATI video? (And note that Intel will soon drop EXA and switch to UXA, which is highly unstable.)
What KDE branch? (If any.)
If RHEL6 won’t release in 2010/2011, take note that GNOME 3.0 will be defecated in March 2010. While it will be most likely as unfinished as KDE 4.0 was (although much less disrupting), they say “All technology and changes required on which the default GNOME 3.0 theme will be based must be included in GNOME 2.28.” So maybe the last “stable” (but unsupported) release is the current GNOME 2.26!
Will RHEL6 be based on GNOME 2.26? (Then RHEL6 will be the true XP.)
Or maybe they’ll drop the desktop completely and only release a server edition of RHEL6?
BTW, will RHEL6 include Mono?
May 22, 2009 at 13:19
What's the purpose of this rant!
You are missing the point.
RHEL is competing with HPUX, AIX and Solaris and all those OS are targeted to enterprise usage.
Enterprise user don't care about the latest version of GNOME or GIMP.
HPUX is still using CDE and for them GNOME is not stable. In AIX CDE is the default user interface.
May 22, 2009 at 13:29
Adi, baţi câmpii. It was not of RHEL as a Server, it was about RHEL as a Desktop OS.
In the last 2-3 years, the quality of all the Linux distros has severely decreased. And I know Linux since 1994-1995.
The fucktards are too busy to “add new features”, thus inflicting serious REGRESSIONS and breaking all the time THINGS THAT WORKED.
Breaking things twice a year is just insane! We’re not in Slackware 3.0, nor in Red Hat 3.0.3 anymore. The current level of complexity makes that releasing twice a year is IDIOTIC.
Read Dag’s post.
OTOH, the idiocy of each and every distro is that, once you stick with a long-term supported distro (say, CentOS, because in a LTS Ubuntu you can still have backports), you’re condemned to use a fixed version of each and every application! GIMP is part of the distro. OO.o is part of the distro. Etc. etc.
The megafreeze model is broken: http://www.modeemi.fi/~tuomov/b/archives/2007/03/03/T19_15_26/
Your main concern is that there wasn’t any Ubuntu CD to greet the user in Romanian. You must be a very happy person to have this as your main problem… or maybe a simpleton, but I don’t want to be rude.
Oh, and CDE is very good, thank you. What I need is: (i) applications; (ii) suspend-to-* for my laptop.
May 23, 2009 at 20:56
Having been using Fedora 8 for too long, I had to decide what to do. So I decided to “upgrade” to CentOS 5.3 myself, in part because of stability, in part because of wanting to try out things to be then installed on work computers (mostly DNS tools and network monitoring). Also on my laptop.
I am a fan of JFS and XFS too. It is actually fairly easy to use JFS and XFS with CentOS, there is a semi-official repo with a kernel with all the missing bits, including JFS and XFS. The installer does not support installing to JFS, so one has to install to a temporary root filesystem, add the CentosPlus repo, install the new kernel, format the real root filesystem, and copy the root over. This is not that bad (one can install a pretty small set of packages to start with just to boostrap).
In theory RHEL6 should have ‘ext4′ as default and BTRFS as an option perhaps, but the biggest and most amazing news are that RHEL5.4 (and CentOS 5.4) will have XFS as fully supported, which is a truly major change in Red Hat’s strategy.
The only issue that I found so far with JFS in CentOS Plus is that xattrs (and thus selinux) for symbolic links are broken. I have read that this was fixed later than 2.6.18, but of course CentOS have not backported the fix. Perhaps I’ll do it myself. I am not a huge fan of SELinux, but I have decided to try and use it.
As to the general ethos of “new half baked features” instead of bug fixes, the way to get a cool well paid job at Red Hat or another vendor is not to be an obscure bug fixer; it is to gain visibility as the initiator of some cool (if forever half finished) project. Such is the ecosystems and the consequences of PHBs.
May 24, 2009 at 01:12
centosplus sucks: usually, their JFS/XFS-enabled kernels are *not* synced with the latest kernel updates. Right now, they *are* all at 2.6.18-128.1.10, but usually the centosplus repo is behind with months!
And, as long as I cannot use JFS/XFS in Anaconda, they don’t exist for me. Temporary /, etc.: I don’t have time for all this shit.
XFS is going to be supported because it gained such a big popularity with the kernel developers, God knows why.
As for “the way to get a cool well paid job at Red Hat or another vendor”… this is the way America teaches people to be: SHALLOW. They export shallowness as the contemporary system of values.
As a very tiny note: while I dislike GIMP 2.6, I am not happy with GIMP 2.2 either: I really wanted GIMP 2.4
May 24, 2009 at 12:53
«JFS/XFS-enabled kernels are *not* synced with the latest kernel updates. Right now, they *are* all at 2.6.18-128.1.10, but usually the centosplus repo is behind with months!»
It does not matter that much because the CentOSPlus JFS/XFS modules are binary compatible with any CentOS or RHEL kernel of the same vintage. After all RHEL and CentOS keep their kernel releases stable also to ensure binary module compatibility.
«cannot use JFS/XFS in Anaconda, they don’t exist for me»
Then have a small ‘/’ with ‘ext3′.
«XFS is going to be supported because it gained such a big popularity with the kernel developers, God knows why.»
XFS performs very well on highly multithreaded server style applications, and ‘ext3′ (and ‘ext4′) are nowhere as good, and XFS is quite stable, and RHEL is targeted precisely at those applications.
«As for “the way to get a cool well paid job at Red Hat or another vendor”… this is the way America teaches people to be: SHALLOW.»
That’s one reason. But I have also heard another reason why apps are buggy, something that is not shallow: someone once argued that if he were to help fix the bugs in other people’s free software projects, people who are her potential competitors in the IT job market, she would be investing in *their* image and career development, and at the same time taking time away from developing her own cool half finished apps.
There is a point to that argument. Try to imagine two situations:
* Jack writes cool project Wankomatic, which sort of half works but is riddled with bugs and has no documentation. Jill volunteers bug fixes and writes its documentation, and has not time to write her own project. They both apply to Red Hat, and the Red Hat hiring manager knows by fame Jack as the author of Wankomatic, a cool project that also is well debugged and has good documentation. Jill instead is an obscure drone who wastes her time doing maintenance. Well, the Red Hat hiring manager offers a well paid cool job as Principal Architect to Jack, and thinks “well, I got thousands of indians applying for drone like maintenance roles like those Jill seems all she is good for, and they ask for 1/3 of her salary, forget about her”.
* Jack writes cool project Wankomatic, which sort of half works but is riddled with bugs and has no documentation. Jill invests in her own career by developing cool project Tosseron, which sort of half works but is riddled with bugs and has no documentation. They both apply to Red Hat, and the Red Hat hiring manager knows by fame Jack as the author of Wankomatic, a cool project, and Jill by fame as the author of Tosseron, another cool project. Both are buggy and have no documentation, but the Red Hat hiring manager has no reason to prefer Jack over Jill, and Jill has a fair chance to get the Principal Architect position. The Red Hat hiring manager is a bit disappointed that both projects have lots of bugs and no documentation, and thinks “well, I got thousands of indians applying for drone like maintenance roles doing bug fixes and documentation, Jack or Jill are both suitable as creative geniuses to develop cool projects”.
That’s is in a way about shallowness (the shallowness of hiring managers), but for Jack and Jill it is all about career development and marketability (their own, not their competitors).
May 24, 2009 at 15:50
1. Then why have Red Hat refused to support XFS for so many years in RHEL?
2. The "another reason why apps are buggy" is one of the best way to explain why FLOSS sucks when comes to quality. Features? Price? Security? Those are different matters. But quality…
"Feel free to fix the sources yourself" is utterly stupid given the complexity of nowadays software.
May 24, 2009 at 23:52
«<i>1. Then why have Red Hat refused to support XFS for so many years in RHEL?</i>»
Well, for two reasons:
* 'ext3' has been "adequate" for most of those years, and very, very reliable.
* If they support two core filesystems, they need to do quality assurance for both filesystems, which is a large burden.
Now the big problem is that 'ext3' is not longer even remotely adequate for many "enterprise" systems, both as to performance and limitations, so they have been trying to develop 'ext4' as an in-place upgrade. But 'ext4' while better than 'ext3' still has several of the same issues, and XFS is also very stable, and already very widely deployed, and most users of RHEL with XFS do not intend in the least to convert to 'ext4', and probably some big RHEL customer has just told Red Hat to support XFS or else.
«<i>2. The "another reason why apps are buggy" is one of the best way to explain why FLOSS sucks when comes to quality.</i>»
That's a bit of sweeping statement… Proprietary software also sucks when it comes to quality, and for a different set of reasons.
Also, the "don't make other people's cool project look better than they are" issue does not apply in two very important and very large areas:
* Projects owned by a faceless collective, like KDE, Debian, Linux, GNU, …
* Projects owned or supported by a corporation that pays people to do QA and improve them, like most distributions.
There is also a third case, where both the author of a cool project and contributors to it are selfless people with skills; and the author of the project does not leave it half finished, and contributors help polish it further. But this does not happen that often :-).
May 25, 2009 at 05:09
"1. Then why have Red Hat refused to support XFS for so many years in RHEL?"
Ext3 was sufficient and adding another filesystem has a considerable support impact if major customers were not calling it a deal breaker. Storage capacities have increased and Ext4 development was delayed quite a bit. Also Red Hat hired Eric Sandeen from SGI to work on Ext4 and XFS. Having in-house experts to fix problems is important for a vendor like Red Hat.
May 25, 2009 at 22:33
Something I know from my time at Red Hat: some large enterprise customers have been demanding XFS support. For certain applications with very large files and filesystems the performance boost offered by XFS is huge. Obviously I can't talk about which customer(s) or what their applications are but I can tell you that supporting XFS was happening unofficially already because the cost of not supporting it would have been very high. Now that Red Hat has the required in house talent it makes sense to make that support official.
One reason Red Hat wasn't keen on supporting XFS in the first place was their desire to see enterprise customers adopt GFS.
May 25, 2009 at 22:48
Ha! GFS or GFS2? No matter it's open source under GPL, Red Hat acted here exactly as Microsoft would have done! Trying to forcefully impose the shit they happened to like! (While people were asking for XFS and possibly JFS(2)…)
May 25, 2009 at 23:21
When I was at Red Hat there was no GFS2
I still wouldn't compare Red Hat to MS. Red Hat isn't forcing anyone to do anything. They never removed XFS support or JFS support from the kernel. They just limited their support offerings to control costs and to create a known good base of code from which to work. It made business sense.
Red Hat also is truly committed to F/OSS software. Microsoft is threatened by it.
May 25, 2009 at 23:28
They have not removed the XFS and JFS support from the Linux kernel, because the kernel doesn’t belong to them.
But they have removed the XFS and JFS support from the kernel shipped with RHEL, which is a nasty thing to do.
There is one thing to say: “it’s not OFFICIALLY supported, use it on your own risk” and “it’s not supported AT ALL, build your own kernel if you need it”.
Quite nasty, as I’ve said. Corporate culture is not much better than anything in the range [communism, fascism].
May 26, 2009 at 04:40
"There is one thing to say: “it’s not OFFICIALLY supported, use it on your own risk” and “it’s not supported AT ALL, build your own kernel if you need it”."
Red Hat customers would demand support for whatever Red Hat includes. They even did when Red Hat used to ship "kernel-unsupported" package and that's the reason Red Hat was forced to remove it. I suspect you haven't talked to large enterprises.
May 26, 2009 at 09:58
I always fail to understand what the fuck means to "support" a filesystem.
What does Microsoft do when they "support" NTFS? Are they paying you when you lose your data? C'mon.
XFS and JFS "just work". What the heck means for Red Hat to support them? What do they do to "support" ext3?
How can the enterprise users of FreeBSD live without paid support for UFS2? And again: what could such a "support" do when you already lost data?
Jun 11, 2009 at 13:22
A late comment.
Just dropped to say that, as usual, I tend to agree with you.
During the past couple of years, I have been kind of lost in the Linux world. After over a decade of Linux development and usage, the current state makes me sad. I feel confused. It is a shocking moment to realize one day that many things were better in the early 2000s or so. Makes you sad.
So here I am, also evaluating CentOS as my main desktop system. And when you have reached CentOS, you realize that there are not so many choices any more: in everywhere else you see unnecessary complexity, layers, bugs, unneeded rewriting of core components, too shot support cycles, instability, lack of design, regressions, glitter, usability that is not usability, and so forth. The only big plan seems to be to cater the newcomer masses and make money.
The kiss of death to KISS, so to speak.
Keep up ranting; there are plenty of us who feels the same.
Aug 3, 2009 at 08:21
I suspect it's the fact SELINUX probably causes all the problems with XFS. I remember reading where they messed up Reiserfs because the fiddled with the datastructures to make them bigger to add support for SELINUX.