Fedora 8 Logo

A Review of Fedora 8, on the PowerPC

by Terrell Prudé, Jr.
November 28, 2007

  1. Who I am, and why I'm a good person to write this
  2. Why another review?  There are already a bunch!
  3. The test hardware
  4. Installation
  5. How's that sound?
  6. Adding new software
  7. I want my DVD!
  8. Leaving me hangin'...and a very "yummy" surprise
  9. Things I miss
  10. So why do this?  Why not just run Fedora on x86?
  11. Would I recommend Fedora/PPC for the home user?

Who I am, and why I'm a good person to write this

I'm a Free Software user and very occasional bug-fixer.  I am a member of the Free Software Foundation since January 2007.  I am a former MCSE.  I've been using Red Hat Linux since 1999.  Over the years since, I've used and administered many distributions, including several versions of Fedora Core (now called simply "Fedora") and all four versions of Red Hat Enterprise Linux.  Therefore, I believe I'm well equipped to take on a review of a Fedora release.

Why another review?  There are already a bunch!

Quite correct.  But how many of those reviews have been on non-x86-based systems? 

Having heard much--nearly all of it positive--about the Fedora Project's latest offering, Fedora 8, I decided to change direction somewhat and review this GNU/Linux distribution on a Power Macintosh G4.  Remember, the Fedora distribution is officially supported on, as of this version, three processing architectures:  x86 (32-bit), x86-64 (also known as AMD64), and PowerPC. 

What inspired this idea is my experience with another distribution I tried last year, Edubuntu GNU/Linux Edgy Eft.  This distribution did show differences in the state of the packages' functionality in several cases when going to PowerPC.  I wanted to see if the maintainers of Fedora were consistent with their distribution.

Also, while I've never really liked any version of Mac OS, I have always liked Apple's PowerPC hardware.  It has proved durable, well designed, and--for the mid-towers, at least--easy to expand.  My (severely upgraded) Power Mac G3 Blue & White, which runs Yellow Dog Linux, is still one of my favorite machines to use.

The test hardware

Power Macintosh G4 Gigabit Ethernet
PowerLogix twin 1.3GHz PowerPC 7455 upgrade
1GB DRAM
80GB EIDE hard disk (originally 20GB)
ATI Rage128 video with 16MB video RAM


Image showing lspci output

Installation

I downloaded the PowerPC DVD ISO image via BitTorrent, to go easy on the download mirrors.  After burning it to a DVD-ROM via standard GNU/Linux utilities (growisofs), I did the install on the Power Mac, just to see if it would install.  Originally, the Power Mac had the 20GB stock hard disk from Apple.  I chose to wipe all partitions, not just the Linux partitions, as a test.  Then, in addition to the default GNOME desktop, I also selected KDE and the development tools.

A little over an hour later, the installation was complete.  I rebooted the box, and sure enough, there was yaboot, and Fedora 8 booted right up, giving me a very cool looking login screen.  While I haven't yet tried Fedora 8 on x86 boxes, this is similar to my experience with previous Fedora versions.  So far, so good.  GNOME came up, a little applet came up telling me, "Updates available!", and I let it do so.  Afterwards, I rebooted, things came up fine, and it seemed that all was good.

Screenshot of getting security patches

Screenshot telling us we need to reboot after a kernel update


I noted with satisfaction how easy all of this is for the "newbie" GNU/Linux user.  It was indeed so easy, even a Mac OS X user could do it.  :-)

Based on that success, I then decided, OK, let's do the install "for real".  By that, I mean doing the installation as if I'm going to actually use this thing as my "daily driver" box, and yes, that is my intention.  Fortunately, I had a spare 80GB disk, which, since I store all my data on a 1TB NAS, is more than enough for Fedora.  While hardly the latest-greatest hard disk anymore, it is also a lot faster than the 20GB dinosaur that was in there before.

I then put the installation DVD in and did the install.  Again, so far, so good.  I went through and carefully chose the packages that I wanted.  Being a long-time Red Hat user, this was pretty easy for me to choose.  This hard disk, it turns out, had an existing ReiserFS partition on it, from when I swapped it out of my AMD Athlon box last year for a 160GB model.  This time, during the disk partitioning, I chose, "Remove all Linux partitions" and selected a custom layout.  I chose the following for my partitions:


/dev/hda1
Apple Bootstrap
1MB
/dev/hda2
/boot
100MB
/dev/hda3
/  (root)
10GB
/dev/hda4
Extended Partition
70GB
/dev/hda5
Swap
512MB
/dev/hda6
/tmp
1GB
/dev/hda7
/var
6GB
/dev/hda8
/home
57GB (the rest)


The installation went just peachy, and I happily rebooted, looking forward to using that twin-turbo Power Mac G4 with Fedora 8.

HOWEVER...

I was in for a small and subtle--but very important--surprise!  It turns out that this 80GB hard disk that I grabbed came out of an IBM-compatible box.  And remember, yes, it already had partitions on it before I blew them away and repartitioned it as above.  The Mac-savvy among you will notice that /dev/hda1 was the Apple Bootstrap partition...and that a Mac won't boot with that configuration!  I had to discover that.  It seems that partition tables are done somewhat differently on Linux/PPC than on Linux/x86.

After making Google my friend for about half an hour, I learned that the "msdos" disklabel (that's "partition table" for us x86 users) does not work on a Macintosh, and that I needed to put on a new "mac" disklabel.  Of course, since this is the partition table, that means you get to repartition that disk.  Google also revealed that, apparently on Macs, the first partition on the disk (/dev/hda1, in our case here) actually represents the entire disk drive.  Thus, that Apple Bootstrap partition really needed to be /dev/hda2.  This is similar to--but not exactly--how Sun boxes and the BSD's reserve the third partition to represent "the entire disk."  Also, like the BSD's, Macs don't use an "Extended Partition" like x86 boxes do.  Due to the way disks are partitioned, "Extended Partitions" like in the x86 world are not needed.  Basically, everything looks--to x86 users--like everything's a primary partition.  Just go with it; that's how it's done on Macs.  It works.

To make a new Mac-friendly disk label, I booted the DVD into rescue mode ("linux rescue" at the boot prompt).  Then I ran "parted /dev/hda" and typed "mklabel mac" at the parted prompt, which actually does the disklabeling.  I then rebooted and repeated the install, partitioning the disk according to this table:

/dev/hda2
Apple Bootstrap
1MB
/dev/hda3
/boot
100MB
/dev/hda4
/  (root)
10GB
/dev/hda5
Swap
512MB
/dev/hda6
/tmp
1GB
/dev/hda7
/var
6GB
/dev/hda8
/home
57GB (the rest)


The major differences are that we start our partitioning at /dev/hda2, and there is no "Extended Partition."  From here, the installation, and the subsequent reboot/security updates, went smoothly.  Note that this is only a problem for hard disks that have already been partitioned in x86 boxes.  If it's the hard disk that came in your Mac, you'll never see this issue come up.

When it's all said and done, my desktop is the beautiful work of art you see below.

Screenshot of my lovely desktop

How's that sound?

I found one glitch with regard to sound.  I wasn't getting any.  When I'd run KDE, I'd get the screen saying that /dev/dsp could not be found.  I tried logging in using GNOME; no sound there, either.  Some investigation showed that, for whatever reason, the sound card drivers apparently weren't getting loaded at boot time.  Using the "Soundcard Detection" tool that comes with Fedora, I simply reloaded the drivers (it's a click of a button).  Sure enough, sound started working perfectly, both in GNOME and KDE.  Unfortunately, it seems that you have to do this every time you reboot the box.  Despite that it's an easy, fairly quick workaround, the user still shouldn't have to be doing that.  It's a minor annoyance.

Screenshot of why there's no sound


And how to fix it:

Screenshot showing how to load the drivers

Adding new software

After logging back in, naturally I wanted to install some other software.  There's an "Add/Remove Programs" option in the menus.  It's the same program that gets run at installation time to select which packages you want to (or don't want to) install, and the program itself is called "Pirut".  I used this "Pirut" to select a bunch of software, close to 400MB worth, to install.  That includes KOffice, OpenOffice.org Base, Maelstrom, Quake 3, Fedora Directory Server, MySQL, PostgreSQL, a couple of LDAP clients, and some other stuff.  Now, I've done similar things with yum before, at the command line, and things have Just Worked (TM).  I've also done this kind of thing with Debian/Ubuntu's excellent Synaptic program, as well as the command-line "apt-get" program.  Again, everything Just Worked (TM).

It took about 16 hours to actually download all this stuff.  My guess is that the mirror sites were slow, and that makes sense, because Fedora 8 is still at the time of this writing very new.  It also coincides with my virtually nil CPU usage.  As for DRAM, Pirut showed just 17.8% memory usage.  However, during the download, Pirut did appear to "hang" for a little while more than once, which Yum does not do (I use Yum on my CentOS x86 machine).  This is simply an issue of confidence inspiration and end-user reassurance, not an indiciation that Pirut doesn't work.

Screenshot showing Pirut asking for the installation DVD


I want my DVD!

Yes, I would actually like to watch DVD's, and that includes my legally purchased copies of "The Matrix Reloaded" and "My Cousin Vinny."  Due to the MPAA's SCO-like behaviour and the ridiculous Digital Millenium Copyright Act (DMCA), no distribution sold in the United States can legally include this ability.  Fortunately, though, the software does exist.  There are two ways to do it:  install libdvdcss or install MPlayer.  I chose both, and both work.

I downloaded the source code for both libdvdcss, and a simple

  ./configure --prefix=/usr
  make
  su root
  make install

at a terminal window got me DVD playback capability.  That's all there is to it.  Really.

With MPlayer, it was similar:

  ./configure
  make
  su root
  make install

and I had DVD playback capability.  Full instructions for how to do this with MPlayer are available elsewhere on my Web site, over here.

Leaving me hangin'...and a very "yummy" surprise

However, I did run into a glitch with the computer locking up.  The screen would suddenly go blank, and the keyboard and mouse would become unresponsive, requiring a power cycle.  This is not good when you're planning to use the box as your daily driver.  I narrowed it down to the OpenGL screen savers that I was using.  I simply changed to the "Bumps" screen saver (not OpenGL-based), and the problem went away.  As this is an older Mac, I suspect the video board needs replacing; I just don't happen to have a spare one for Macs handy right now.  But this is an easy fix and certainly not the operating system's fault.

One such system lock-up occurred while adding a bunch of other programs with YumEx, my preferred GUI software management tool on Red Hat-like systems.  The reason for this was so that I could compare Pirut and YumEx on the same system.  YumEx had already downloaded the slightly over 300MB of new software that I had requested and was just over halfway finished actually installing it all.  Then, the OpenGL screen saver that I had chosen came on, and the box was locked cold.  Screeching halt.  None of the programs that I had requested were low-level system stuff (e. g. kernel or glibc), so I wasn't too worried about the system booting.  However, I was still concerned that I might now have a somewhat corrupted system or at least a corrupted RPM database.

I fired up YumEx, expecting to see problems.  I got a rather pleasant surprise instead.

Apparently YumEx keeps some sort of transaction logs!  The first thing YumEx did after coming up was show me a message about "retrieving transaction logs" or something to that effect.  Then, the hard disk started grinding...and grinding...and grinding.  The system slowed down to a level only seen from Arctic glaciers.  The mouse movement was very jerky and slow.  I tried clicking on the "Konsole" icon to start up a terminal; wasn't happening.  But the system did not hang; jerky or not, the mouse pointer still responded.  Sure enough, an hour or so later, the system responsiveness came back, and that Konsole window popped right up.  YumEx had finished completing the previously interrupted updates.

Impressed, I did a little Web surfing with Konqueror and Firefox, loaded OpenOffice.org, and loaded all the KOffice applications, Everything worked.  I rebooted, just as a paranoia step and fired up those apps again.  Everything still worked.

BIG, MAJOR kudos to the Yum and YumEx development teams for this kind of resume/recovery.  This is even better than Synaptic!  Since Fedora is a test-bed for Red Hat Enterprise Linux (RHEL), I sure do hope Red Hat puts this into RHEL as soon as possible!  This is really good stuff.  Had a system lock-up occurred during, say, an equivalent update/install on Windows XP or Vista, I know from experience that we'd be looking at a reinstall of the whole system.

Things I miss

Yes, there are some things I miss here, none of which have to do with Fedora itself.  Rather, they're consequences of running GNU/Linux or any other Free Software operating system on a non-x86 processor.

Certain proprietary codecs are a problem.  This is a well known issue.  The reason for this is that, being closed/proprietary, they're generally not just Windows-only, but also x86-only.  One of the apps that I use a lot is MPlayer, especially for transcoding stuff from proprietary formats like Windows Media and QuickTime over to Ogg Theora/Vorbis.  I do this because not only is Ogg Theora/Vorbis a truly Free format, it is also just plain good from a technical standpoint.  The "codec pack" that comes with MPlayer contains x86-only binaries for transcoding WMV and QuickTime to something else.  So, I'll continue to use my Debian/x86 system for that.

No working Flash player.  Flash video playback has traditionally been problematic on Free Software platforms.  That's because Adobe/Macromedia likes to keep their multimedia formats closed.  Fortunately, there is a Free Software Flash player, called Gnash, which comes with Fedora.  Unfortunately, it didn't work.  I tried www.vw.com, www.honda.co.uk, and www.youtube.com.  Nothing.  No errors, no "you must download Flash" messages--just blankness where there should've been streaming Flash video.  There was an update today (28 November 2007) that included a new Gnash, and I hoped that might fix the issue.  Sadly, it didn't; still no working Flash video after the update.  However, those same three sites came up for me just fine on my x86 K12LTSP (CentOS) box running Adobe's own (and x86-only) Flash player for GNU/Linux.  Some Googling revealed that the latest CVS pull of Gnash might work.  Now, I could do that, since I'm pretty geeky.  After all, I'm running GNU/Linux on a Power Macintosh!  However, the version in the Yum repositories is supposed to work...otherwise, why is it there?

Screenshot showing Gnash not actually playing video


Yes, it's using CPU.

Screenshot showing Gnash using CPU nonetheless


Video boards cost more for Power Macs.  This is an "economy of scale" issue.  It turns out that not only does Apple require its own disklabel format, it also requires special "Mac versions" of video boards.  You can't just grab that nice, cheap Radeon board from your x86 box, pop it into your Power Mac, and expect things to work.  There are video board BIOS differences.  Back in the Matrox Millenium days, I converted my Millenium PCI board from x86 mode to Mac mode, and you had to basically re-flash the video board with a Mac-friendly BIOS.  Matrox provided a tool to do this.  But, to my knowledge, you cannot do that with many of today's video boards.

So why do this?  Why not just run Fedora on x86?

Good question, given the "things I miss" section, above.  Here are my answers for why I choose to do so.

PowerPC is an officially supported platform.  Yep, the Fedora Project officially supports the PowerPC platform.  I have several Power Macs, and I need a good Free Software operating system for them.  Apple's PowerPC hardware was (with few exceptions) generally well made.  And no, I have no desire to run Mac OS X on them.

Security.  Virtually all worms, viruses, and Trojan Horse programs are binaries compiled for Microsoft Windows on x86 processors.  I am completely immune to such garbage in not one, but two ways.  Not only do I run GNU/Linux, I am also running a totally different CPU architecture.  Some very, very smart computer scientists have shown before that it is possible to get such binaries to run on GNU/Linux on x86.  Yes, it's even possible to get them to run on PowerPC chips.  However, to do so is the rough equivalent of swapping out the transmission in your car.  In short, not gonna happen in actual practice unless you're near to Mark Russinovich's or Linus Torvalds's level, and you do it on purpose.  So, this is a very secure way to compute while remaining functional.

I get everything I need, and enough of what I want.  What I need for this box is to do the standard stuff that you do in an office--Web surfing, office productivity, play a few addictive games, back my stuff up to a USB drive, etc.  I get all that and more.  OK, so I can't play Windows Media.  That's not a need.  It's a "nice to have," but as I said, my Athlon running Debian/x86 does that, and I immediately transcode to Ogg Theora/Vorbis anyway.  Thus, such videos ultimately play just fine on the Fedora/PPC box.  As for Flash, yeah, that'd be nice, but again, it's not a need

Because I can.  I'm a geek, and I simply enjoy trying it out.

Would I recommend Fedora/PPC for the home user?

Two things are stopping me from recommending Fedora/PPC to a typical home user, and that's 1.) the aforementioned sound card driver "minor annoyance," and 2.) the current state of the Gnash player.  This second reason is really the killer.  YouTube is simply too popular now, and everything in there is in Flash.  Whether their decision on format was the best one is debatable, and I'd suggest that Ogg Theora would've been a better choice, since there were and are Ogg players for virtually every operating system in existence.  But they chose what they chose.  So, for that specific reason, I have to say...not yet.

That said, if the Gnash player in the Fedora/PPC repositories gets updated with one that works, then my answer would change to "most definitely."  I've used Red Hat Linux since 1999, and I've always found it among the easiest GNU/Linux distributions to use.  This Fedora 8, regardless of CPU architecture, continues that tradition and is damned slick.  When you're using it, you don't know or care which processor architecture you're on, and that's a Good Thing (TM).  My Dad or Mom, neither of whom are anything resembling computer geeks, would actually find Fedora 8's user interface a pleasure to use.

The security aspect of Fedora/PPC for home users deserves special mention.  The end user gets two built-in levels of protection from virtually every virus/worm out there in the world.  There's a whole lot to be said for that, especially for novice computer users.

For those who want YouTube viewing capability today, then I could easily suggest Fedora/x86.  The positive reviews of Fedora 8 are pretty much correct; it is indeed a very slick distribution that I like a lot.  Of course, that could be extended to pretty much any general-purpose GNU/Linux distribution for x86, as they're all quite easy to use.  But Fedora's crash-recovery with Yum was really what got me saying, "Wow...."

Overall, I'm pretty pleased with Fedora/PPC, despite the two unexpected glitches I ran into.  It's slick, it's got a lot of advantages, and I hope that they get the Gnash issue fixed as soon as possible.  From what I can see, that's the only remaining missing piece for which there isn't an easy workaround.


Copyright (C) Terrell Prudé, Jr.
Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.

Back to homepage


Use OpenOffice.org    GNU GPL v3    Powered by ApacheOpenBSD--Free, Functional, and Secure    K-12 Linux Terminal Server Project