I've had a few days now to get through the expected upgrade teething
troubles, use FC5 for my normal tasks, and watch my non-techie wife
Cathy use FC5 for *her* normal tasks. I've been a Red Hat/Fedora user
and contributor for more than a decade now, since before 2.0 and
*well* before I became famous enough to show up in Red Hat's corporate
timeline :-). I've taken some time to reflect on FC5 and the trends
of the last decade, and where I think Fedora and Red Hat need to go in
the future to achieve the dreams they were founded on.
Let me start with some good things. I thought Fedora was in
desperately bad shape in the FC3/FC4 period, and as some of you know I
raised hell about it, threatening to jump very publicly to another
distribution and orphan several Fedora-related HOWTOs in the process.
I'm delighted to be able to report that much of what pushed me very
near to giving up on Fedora has been fixed.
Good thing the first: Maintainence of the core repositories is no
longer a disgraceful, poorly-documented shambles. Because of this, yum
is at last fulfilling the promise of (almost) friction-free upgrading
over the net. Such problems as I've encountered with FC5 upgrades
have been due to upstream bugs, not egregious fuckups in the Fedora
infrastructure. This had...ahem...not previously always been the case.
Good thing the second: this time around, I can ignore RPMForge. While
those guys have done excellent work and performed a valuable function
by keeping Fedora on its toes, one of the things I really, *really*
wanted as a sysadmin was to be able to point my yum at official Fedora
repos plus one (1) repo for Damned Things like proprietary codecs, and
be done. In FC5, core plus extras plus livna does as good a job as
core plus half-a-dozen RPMForge repos used to.
Good thing the third: it's clear from the devel-list traffic that the
submission pathway for new packages has got most if not all of the
process issues shaken out of it. I had meant to get more directly
involved in that, there are four or five things I want to package and
submit myself, but higher-priority tasks ate my bandwidth. One of my
resolutions for 2006 is to make time for those submissions.
Good thing the fourth: A combination of increased polish in various
distro components and significant upstream developments (one biggie
being OpenOffice 2.0) has, to my observation, inched FC across an
important functional threshold. My wife can use it with as little
pain as Windows now, rather than merely tolerating the crap because
she believes in what the Linux community is trying to do. This is
significant, because she's *not a geek*; she's a lawyer. She is,
in fact, perfectly representative of the kind of forward-looking
professional in non-technology fields that we must have on our
side if we're to take Linux all the places we want it to go.
Take a moment to savor these good things. Because the news is by no
means all good. We've come a long, long way, baby -- but having got
past some of the serious blocking issues, we now get to face a new set
of them. And at least one old issue everyone has been ducking...
First, a relatively minor issue that is nevertheless quite annoying.
It's the Fedora distribution art, the images in Anaconda and the
Fedora-customized graphics in the admin tools and elsewhere. It has
never been much better than mediocre, and in FC5 it hits a new low
with backgrounds that look like a Teletubby hocked loogies into a
dish full of soap scum. And whose bright idea, I have to wonder, was
it to abandon the attractive and recognizable Fedora icon for
something that's...not a fedora?
Cripes. By comparison, even the original BlueCurve was superior. And
original BlueCurve wasn't much to cheer about compared to the
decorative art on a Windows or (especially) a Mac -- acceptable, but
not a competitive plus, not something that would actually attract
users. The FedoraBubbles stuff is bland and tacky goo that I expect
will repel them.
Now that we've gotten past some of the key blockers on the functional
level, it's time to worry more about fit-and-finish issues like these.
Mediocre art, workmanlike images that convey information without
being ugly, is good enough for a niche product aimed at techies. If
we want Fedora -- and for that matter Linux in general -- to break out
of that niche, we have to make it *look* like we want it to.
That means high-quality art, art that makes people actually *want* to
look at the screen because it's a significant aesthetic experience.
Which, right now, we ain't got.
But the art problem pales compared to the issue that everyone has been
ducking, which is Fedora's support for DVDs and proprietary audio and
video and web-streaming formats and Java applets. That is to say, its
crummy-to-nonexistent-to-actually-toxic support. The tools in FC5
weren't better than they were in FC3/FC4; after installing the
critical bits from livna, they were *worse*. Totem tossed its cookies
with a cryptic pop-up error; xine white-screened under one card and
actually crashed my X under another!
It's 2006, people. The Web is fifteen years old. Even non-techies
have had a decade to form expectations about what constitutes a base
level of functionality. We don't have a prayer -- not a hope, not a
snowball's chance in a supernova -- of becoming competitive for
home and business-desktop use without delivering to those
Those expectations include, without any doubt, multimedia playback,
web streaming, and never seeing the broken-puzzle-piece icon in
Firefox more than once per media type (if that often). When those
expectations are violated, it's not the content provider who gets
blamed for shipping a proprietary format. The customer interprets
that kind of failure as a bug in the client, *and the customer is
right*. All the idealism in the world about Ogg and Theora and
whatnot will not change this.
Let's start with the basics. For a consumer OS to be unable to play
MP3s and handle podcasts is just plain not acceptable, not in the
world after iTunes. Red Hat/Fedora's duck-and-cover on this would be
understandable if the Fraunhofer patents blocked decoders, but
Fraunhofer itself has only dunned for royalties on *encoders* -- thus
Red Hat/Fedora has ceded to Fraunhofer rights it has never claimed.
I know at least one fairly influential kernel developer who threw out
Red Hat/Fedora in disgust over this. When he asked me straight up how
I could defend what he bluntly called 'corporate cowardice', I didn't
feel like I had a good answer. And I still don't. In return for all
the free development work they get, it does seem to me that it's part
of Red Hat's job to shoulder risks like these -- and that Red Hat
hasn't held up its end.
AVI. Quicktime. ASF. MPEG. DVD playback. Flash. Java. These are
*not optional* in 2006, any more than the ability to read Microsoft
Word files in a word processor is optional; if we try to treat them
that way, consumers will blow Linux off. Evangelizing for SVG and Ogg
and Theora may change this someday (I hope it will, anyway), but if
that transition were going to happen soon enough to make supporting
proprietary formats unnecessary *we'd already be past it now*.
So. For each format, we have one of three choices:
1. We can end-run the patent restrictions on the technology (say,
by developing outside the U.S. and distributing through overseas sites
that are wink-wink-nudge-nudge unconnected with Fedora/Red hat).
2. We can put real resources into developing a decoder implementation
the blocking patents don't cover, and accept the risk that the
patent-holders will launch harassment lawsuits anyway as a cost of
3. We can buy the rights to the technologies we want as a straight
commercial transaction from the patent-holder.
The community is already pursuing (1) for some formats. If Red Hat,
which likes to see itself as the market leader and senior commercial
distributor, isn't willing to take a swing at (2) or (3) for the
others, then I have to wonder what the hell having commercial Linux
distributors is actually good for.
If solving the multimedia problem takes having Red Hat sell a
plugins-and-drivers disk for each spin of FC, full of proprietary crap
that it negotiated rights for, that sucks -- but better that than
never getting any traction on the desktop because we got too caught up
in our own idealism to meet actual consumer needs.
And if Red Hat's answer is "we don't want the desktop", then my answer
back is "shame on you for forgetting where you came from!", and it
really would be time for those of us who care about the future of Linux to
find a commercial partner with more ambition and more guts.
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
"This country, with its institutions, belongs to the people who inhabit it.
Whenever they shall grow weary of the existing government, they can exercise
their constitutional right of amending it or their revolutionary right to
dismember it or overthrow it." -- Abraham Lincoln, 4 April 1861
I've prepared vim-7 prerelease packages, they are available from http://people.redhat.com/karsten/
Most prominent new features are gvim with windows in multiple tab pages (:help tabpage),
spell checking (:help spell) and omni-completion (:help new-omni-completion).
A description of the new features of vim-7 is available with :help version7
Please report any problems in bugzilla and make sure to mention the package version
Learn. Network. Experience open source.
Red Hat Summit Nashville | May 30 - June 2, 2006
Learn more: http://www.redhat.com/promo/summit/
I'm really enjoying using FC5. Tomboy is a great tool for jotting
down ideas. I actually put together this email using a few tomboy
notes. I have a few suggestions -- that you can take or leave -- that
I wanted to share to help out with 'Fedora's way forward'. :) Here
1) A welcome to Fedora (or RHEL) tutorial for new accounts and even
maybe a tips section everytime you log in. DAC would be a really good
topic for new users.
2) Have a place in Preferences set up for the two or three available
Javas (Sun's and the OSS ones). Then when you have installed Sun's
Java you have a place to switch back to the old one, and vice versa.
(Question: Is a compiled Azureus the same if it's based on Sun or
3) I have a question on codecs. Is it possible to get all OSS codecs
these days based on the GStreamer plugin system? I think the whole
audio/video codec problem would go away if there was a GStreamer Codec
management system where OSS codecs would be there by default and then
the user would go out and get all the proprietary GStreamer codecs
he/she is missing. It should be simple to look at a Fedora system,
and say "alright, got those ones, but missing these ones (like
mp3/avi). And I can figure out where to get them." And this
presupposes a future where there are only Gstreamer codecs.
4) Since Firefox is one of the most important pieces of the Linux OS
these days, it would be great to have all of the alphas, betas and RCs
available in update-testing. That would allow some users to test
Firefox for bugs over an extended period of time before 2.0 or 3.0
comes out. Obviously, under some guidance from Fedora with all the
patches they put into it.
5) An updating system (maybe using deltarpms or smartrpms) that could
compete with the updating system available on Windows XP and OS/X.
Smaller updates are really needed.
That's all! Back to testing out FC5. And Thanks!
> Well, Fraunhofer has this page:
> Which links to :
> Which definitely shows royalty fees for decoders.
It does. I stand corrected.
The page says $50K one time flat fee for a decoder. Is there any good
reason Red Hat shouldn't simply buy that license for some outfit with
a track record, like the lame developers? MP3 problem solved,
relatively cheaply (e.g., less than half the annual cost ofjust one
additional full-time coder).
Yes, I know feeding patent parasites is unpleasant. But we come back to
the central question here: do we want ideological purity at the expense of
victory, or do we want actual victory so that *we* get to effectively set
the terms of software development in the future?
I know which side of that question *I* come down on...
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
I was running rawhide updated to March 10. Went on vacation, yesterday
did a full upgrade to fc5. Used yum to get updates released. Now X
won't start. I think it's some sort of xfs problem.
with gnome, I get the fedora bubble logo, then a black screen, alt-f1
gets me the console, which shows:
waiting for X server to shut down FreeFontPath: FPE "unix/7100" refcount
is 2, should be 1, fixing
gnome_segv2: segfault at 0000000000xxxxxxxx .........
kde also won't start. The console shows:
xset: bad font path element (#76), .......
and syslog shows kded, ksplash, kcminit, and ksmserver segfaulting.
I've restarted xfs ( no errors in syslog ). I've rebooted.
Do I need to do some mkfontdir voodoo in each font directory? What did
the upgrade change? I've seen no similar problems posted, so I assume
it's a rawhide->fc5 issue.
Hello Docs, Devel and Marketing,
I would like to take a snapshot of the Release Notes Beats on the Wiki
to be used as an errata release for the web on Tuesday, April 4, 2006 at
23:59 UTC, we will clean up and push to translation on Thursday, April
6, 2006 giving translation a week to get as many languages available to
us over the following week.
One question I have for Development is can we then roll these new
updated release notes and translations in to a package update for our
The web and maybe package errata would be available on Friday, April 15,
Robert 'Bob' Jensen <docs-list(a)fedoralinks.org>
Fedora Documentation Projects
I am trying to build kernel modules on a standard install
of Fedora Core 5 GA. I did select the development block
However there do not seem to be any kernel sources available
to build kernel modules.
I tried yum and did a yum look for kernel-source and it came
up with nothing.
Where do I get enough of the kernel source to do compiles
of kernel driver modules?
I'm tasked to write a front end for an instrumentation application for
"that other operating system" ;) and I'd like to use GUI controls that are
cross-platform portable for an eventual Linux port. What would the list
recommend? I essentially need something that resembles the front panel of
an oscilloscope, along with some dial indicators and knobs. I've also been
thinking about making it web-accessible, so perhaps a Java-based solution
would be suitable.