A Review of Fedora 8, on the PowerPC
by Terrell Prudé, Jr.
November 28, 2007
- Who I am, and why I'm a good person to write this
- Why another review? There are already a bunch!
- The test hardware
- Installation
- How's that sound?
- Adding new software
- I want my DVD!
- Leaving me hangin'...and a very "yummy" surprise
- Things I miss
- So why do this? Why not just run Fedora on x86?
- 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
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.
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.
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.
And how to fix it:
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.
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?
Yes, it's using CPU.
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
