“With the release of the first beta of Red Hat Enterprise Linux 5, eWEEK Labs was looking forward to getting an early look at the progress Red Hat has made with the platform since RHEL 4. Unfortunately, Beta 1 of Version 5 is too flaky for even testing purposes. The biggest problem we encountered was RHEL 5’s thoroughly broken software management system.”
This article talks about the “thouroughly broken package management system”, which leads me to believe something along the lines of the OpenSuse 10.1 debacle. However, the article later states that the problem came from “back-end troubles with Red Hat’s repositories nearly prevented yum from working at all”. While there might be big changes for Red Hat with respect to package management, at least the problem is limited to the repositories. What I mean to say is that Red Hat (more precisely Fedora) has extensive experience getting yum/pup/pirut to work with repositories, so I would expect them to have things working perfectly by the time RHEL 5 ships. That still, however, does not explain why they can’t get the repositories working right now.
the summary did give me a moments pause as well. broken package management (eg. patch deployment mechanism)? suse 10.1 zen brokenness again?? what’s up with these commercial distros nowadays…
you’re right, doesn’t sound as bad once you actually read the article, but seriously, the main reason for paying money for a commercial linux like suse or redhat is for having the peace of mind of easy and reliable well tested patch updates that you can deploy across your network/enterprise with some confidence and ease for a ‘guaranteed’ lifespan. (the whole “it’s to get commercial support” argument is a not much more than a line to keep the management happy, not really something that most unix admins worth their salt will actually benefit from.)
Remember, this is the Beta 1 release. The whole point of betas is to fix problems and make the final release more reliable. My impression is that the RHEL 5 betas will become much more stable after FC6 is released.
“the whole “it’s to get commercial support” argument is a not much more than a line to keep the management happy, not really something that most unix admins worth their salt will actually benefit from.”
I will have to disagree with you on this. While the chances are extremely low, having some kind of “commercial support” is very beneficial when something goes wrong at the code level. It doesn’t matter how good a Unix administrator you are, how are you going to debug problems with the VM, VFS, Scheduler when you have no idea what it is supposed to be doing. The only way you can do it yourself is if you do have a team of specialists on hand but that will end up far more expensive than RedHats support. RedHat has experts that do and that can actually debut it and because you are paying them, they will spend the time to isolate your problem and fix it. That said, we are very fortunate to have a very stable Linux system where those types of incidents are only 1 in a million.
I guess it depends on your setup and who you have running it. At the university I work at, there’s some very smart folk behind the scenes. So yes, in house kernel debugging and such is something that can be done here. Granted, not everyone has that advantage.
That said, a big problem with looking at commercial support as a being something really worth it is the problem of unsupported customizations. Tech support folk know that at the first sign of the customer having significantly altered the boxed setup, to terminate the call or to offer to move it to the development layer where you’ll get charged up the wazoo per the hour for them to even look at the problem (fixing it not being guaranteed of course). Now with that said, how many large linux based enterprises out there are stock in their layout? Like I’ve said elsewhere, one of Linux’s biggest advantages over the competition is how much freedom (not talking philosophically here, I mean technically speaking) it gives the end user to do what he/she wants with it, in this case the admin. By chaining yourself to the terms of a support contract, you do in effect limit what you can do to your own systems. For smaller installations, that might be quite fine, but for larger networks (such as a large research university) that limitation can be a real problem. Thing is, it’s those larger networks that the ‘enterprise’ distros are targetting as their base market… (I’ll admit, since the academic world I live in can be miles apart in culture and otherwise from the corporate realm, things may be very different in that latter.)
Mind you, hardware contracts, that’s totally different.
I’m happy that they now use YUM and its graphical interface YUMEX, both are very good, and now all RH products use the same tools. YUM has never failed here.
What was the main reason for the move to Yum over apt-get in the previous releases?
I like Yum but I also liked using apt-get better, it was easier to use and the command line options/arguments were eaiser to make sense out of.
The main thing in Rhel5 I wish they would work on is support for hardware and bug fixes. It seems as it grows the bugs are just patched over and never dealt with in a permanent manner.
One big limitation of apt was that it didn’t support multilib packages where the x86_64 and i386 versions of packages were installed at the same time. Also, apt-rpm was less mature than the original apt pkg. This has been added to apt-rpm recently.
Also, yum is written in Python like the rest of the Redhat admin tools. This means it was easier to write tools around. There are now a bunch of separate tools using the yum libraries. Including the anaconda installer and the yumex graphical interface.
RedHat admin tools are written in Python, so that makes sense on integration. Will this become the standard and apt-get become less widely used?
RHEL never used apt-get, it used up2date which is going to be superceded by yum. RHEL clones particulary Centos actually use yum as default package manager. Working in progress is Extras repository for RHEL
http://fedoraproject.org/wiki//Extras/Schedule/EnterpriseExtras
Didn’t apt-rpm go dormant for a bit until somebody new took the lead for the project? So unless Red Hat is ready to adopt the project as an offical part of the Red Hat project, it is best not to be dependent upon integral third party software. That said, Blag (a FC variant) has always used apt without any problems.
The RHN channel is very difficult to use, I had problems with it and wished they would change the format in the Enterprise world.
Given that a fair bit of stuff is missing, including the much vaunted Xen ‘Virtualisation Manager’, I can’t see how this can be a Beta release. All the functionality they wish to have in the release should be in there, albeit with certain minor caveats and problems to be picked up via wider feedback and testing. Sabayon should not lock up anything, directly or indirectly.
It’s nice to see Red Hat making better strides in providing graphical administration tools expected in the enterprise world. The directory server tools are a case in point, but they are leftover Java tools from Netscape. The command line and scripting skill are still vitally important in the Unix and Linux worlds, but in administrating and monitoring software like Xen and the directory server, quality graphical tools are a given.
However, I get the impression that these tools are largely incomplete, disjointed and not well integrated. Red Hat are going to have to improve on their underlying development technology if they want to do better and not run out of steam.
RHEL is a big bit of software with an awful lot of strings demanded from its bow now which would tax development in niche companies in themselves, such as Xen and RHDS and the whole administration and support infrastructure around them. I hope Red Hat isn’t going to end up running on empty.
Does Fedora have graphical administration like those in RHEL?
Yes, it has the same graphical admin tools, I am running Fedora Core 5 right now. I like it because it has lots of extra apps and programs you can add on.
i thought we already had this thread last week (and the wxwidgets gui one too?)
anyway, this really isn’t supposed to be beta 1, it’s actually just a preview release, more of an alpha i guess.
i originally thought rhel5 was going to be released in sept/oct and be based on fedora5, apparently now it’s going to be december (or later) and fc6….
and why would a heavily rpm-based distro, move to apt (written for debs) when yum has worked fine for fedora for years and apt-rpm is a joke? damned ubuntu nutters!
that said, up2date/rhn was a total mess, in fact it was one of the few things that centos differed from redhat with – they already moved to yum!
“””anyway, this really isn’t supposed to be beta 1, it’s actually just a preview release, more of an alpha i guess.”””
No. According to RedHat, Fedora is their alpha:
http://www.internetnews.com/dev-news/article.php/3628476
So it would be hard to call *this* an alpha, when the alpha that RHEL5 is supposed to be based upon (FC6) won’t be released until October.
It all get’s a bit confusing, I know.
I thought fedora was the rhel sandbox.
Nope. That idea was dropped long ago. RHEL is based on and takes stuff from Fedora but it is not it’s sandbox.