Downloaded the DVD ISO from RedHat; even gave them my details representing Open for Business. I’ll be writing a longer report for that, but for now, just a few notes.
Because I’m using a new-ish Radeon HD 4350 card on my machine, I expected some troubles. Didn’t happen. The bundled X.org handles it well enough I haven’t yet bothered to build and install ATI’s Catalyst drivers yet. Indeed, after the nice graphical greeter, this was the first ever Linux distro to offer a full text-mode screen display properly on my Dell 23″ LCD. The entire thing had that standard RedHat TUI blue background, but the fonts were in correct proportion. I was really surprised. Nice, tight little fonts on the 1920×1080 scale instead of huge scaled fonts to crowd my screen at 80×25 characters.
Then the graphical installer also did something new, because it was properly scaled to the pixel resolution, but in the center of the screen, still large enough to read clearly, in spite of the rather large black borders. Nice and sharp fonts, etc.
I made a mistake and misread the part about selecting which harddrives I wanted to include. For my own amusement, I did some frantic clicking on the screen. I think the installer noticed, because it went back and started over at the part about selecting the drives! Got it right on the second run.
I chose the desktop installation profile, with refining the selection with more packages later. When the packages were all finished, upon reboot, I was nearly blinded by my screen filled with intense red. I don’t like it, but that’s the boot screen. Cute little pie-chart progress meter. I had to configure the ethernet connection by manually selecting to have it connect by default on startup. Otherwise it was correct. While Kudzu recognized my printer, the version of HPLIP is just a little too old, and prints poorly. I’ll be updating that later.
The package manager window is a little wonky. I had to close it and restart every time something changed much, because it didn’t refresh very well. This was the first time I got a little confused picking the developer stuff I wanted. I really needed to add the bytecode hinting and subpixel rendering to the Freetype libs. It was easy enough, but now you add switches to the rpmbuild -bb command to rebuild a source RPM, instead of editing the SPEC file. Still, nice results, cleaned up the fonts display on my LCD very nicely.
Then, I looked into how hard it would be to add the usual hacker-multimedia packages. There is currently no 3rd party repository for this. While most of this release is built on Fedora Core 12 (FC 12), it’s not precisely the same, from what I could find. So I decided not to use the packages themselves, but built everything from SRPMs designed for FC 12. I started with Gstreamer Bad Plugins. That was a huge task.
Now, I did it because I knew I’d learn something, even if I failed. In keeping with the policy of staying as close as possible to the original release, I first checked the FC 12 official repos, then the RPM Fusion stuff. I simply ran the rpmbuild -bb gstreamer-plugins-bad.spec and took notes on the dependencies. One at a time, I first tried to see if the RHEL 6.0 Beta Yum repo had the item. Sometimes it took a bit of research to find a certain library was part of a package with a totally different name. The dependencies branched out sometimes 5 deep before I got back to main branch. It was about eight hours on a pair of Xterm consoles, after I figured out to install Xterm and the miscellaneous bitmapped fonts of X.org.
BTW, on this release, everything was built under root’s home directory, instead of the traditional /usr/src/redhat. So I kept jumping back and forth between two open Xterms logged in as root, keeping one in the SPECS directory and the other jumping around doing the other work with Wget, RPM commands, etc. Having watched how it was all neatly scripted on FreeBSD to build from source that way (but always finding some critical ports broken) it wasn’t too hard to figure out how to keep track with a notebook, scribbling notes on the various branching dependencies. I really learned a lot, and it was quite doable. I had to hack only one SPEC file to finish (Mplayer), and one package I had to install directly from the FC 12 repo (x264) because of a circular dependence on building ffmpeg.
The reason I went to so much trouble is an idea which struck me the other day. Having learned progressively more about getting what I want by building it myself, why not just create my own DIY-RedHat clone? I know when the final release comes out in September (currently planned) I won’t likely be able to afford the basic support from RedHat. But the SRPMs are always available for updating, so I’ll just keep an eye on those. By then, at least one of the 3rd party repos should be up and ready to update all the other stuff I’m already building.
For the Fedora fans, thanks, but I despise rolling release and want to keep the same core system running for at least three years. Fedora drops previous releases like a hot rock when the new one comes out. I realize that’s pretty much by necessity, but it’s not for me. I’ll keep the RHEL installation and do whatever work is necessary to keep it up to date. If it all breaks down, I can tuck my tail between my legs and switch to CentOS when they finally pick up on 6.0. This way, I at least get a head start on learning the peculiarities.
I’m confused by this statement:
“I despise rolling release and want to keep the same core system running for at least three years.”
It’s self-contradictory. Fedora isn’t a rolling release distro, is it? And if you want to keep the core system for a few years (which assumes “rolling release” I think), why do you despise it?
“Rolling release” is not just the practice of constantly chasing the next new version of applications, but every part of the OS. Upgrading certain items — Firefox, for example — is not rolling release, because core functionality is not changed. But rolling release includes a complete lack of support for previous releases, too. There are several reasons for disliking rolling release, and my issue is failure to support previous releases. Fedora is not in itself rolling release, but the practice of refusing to support previous releases reflects the same planning as rolling release. It’s what some call “punctuated rolling release.”
Compare this with RHEL/CentOS — every release is fully maintained for several years. I wrote quite a few posts about it a while back. Rolling release and punctuated release caters to the developer, reduces the burden of work. Fine, but it skewers the user who simply wants their computer to work, and to keep working, without major renovation every couple of weeks. They also don’t buy new hardware until the current stuff breaks. The vast majority of computer users in this world do not enjoy constant disorientation.