LWN: Comments on "Between Fedora 12 and 13"

RHEL6

antus — 2010-04-13T05:08:26+00:00

Keeping kernel 2.6.18 as a base (read the same API) does have its advantages in the some commercial places. One of the suckiest thing about Fedora for me personally is running binary nvidia drivers which break often when new kernels come out.

By contrast, we maintain a commercial telephony IVR based on RHEL3. Its still in production, still works, and the company that owns it has no interest to update, with the exception of security updates. Due to redhat maintaining the same kernel release I was able to install yum on this machine, "yum update" over 600 packages (including the kernel), reboot and have the machine come straight back up, and start taking phone calls even without rebuilding the proprietry drivers for the IVR hardware.

A lot of purists will hate that, but in an unbiased world where you just want it to work (enterprise), it can be a major plus.

Even so we are running RHEL 3, 4 and 5 systems now and Im looking forward to RHEL6 for new installs. The old ones wont be updated so long as they still serve their purpose.

RHEL6 - Fedora speculation

jroysdon — 2010-01-30T22:45:42+00:00

I've done a bit of my own speculation as to RHEL6 to Fedora versioning. I tend to agree with another poster here, and based on the evidence I site, that RHEL6 will be based on F12 and/or a hybrid of F12 w/F13 refreshes.

RHEL6

jengelh — 2009-12-19T11:00:40+00:00

Yeah. It's so much not 2.6.18 that most things that are designed to compile with a genuine 2.6.18 will outright fail.

3D overload

daenzer — 2009-12-16T19:03:57+00:00

> The ES1000 has no 3D capability.

Actually, at least initially the 3D hardware was there, just not validated during production (probably that's cheaper than actually removing the hardware). So with luck it might work at least to some degree, but if it breaks you get to keep both pieces. The X.Org radeon driver currently disables all functionality using 3D hardware by default on these cards but it can be enabled via xorg.conf options for giggles (the extremely low video memory bandwidth probably precludes any non-trivial 3D usage anyway).

Between Fedora 12 and 13

rahulsundaram — 2009-12-14T05:26:10+00:00

It is fairly easy. As an example of custom Fedora Remix, feel free to take a look at

http://omega.dgplug.org/11/Live/i686/Omega-11-i686-Live.ks

Since the alternative kernels you are talking about is part of a repository, you can simply point to it within a kickstart file. Third party repositories usually have the repository files as part of foo-release that needs to be added to the kickstart file and software updater will be able to pick up updates easily. Gobuntu doesn't actually exist anymore btw and Fedora Project is unlikely to be interested in maintaining any kernel variants.

Between Fedora 12 and 13

vonbrand — 2009-12-14T00:53:37+00:00

Since there are probably (idiotic) software patents covering everything from linked lists to writing "Hello, world!", there just isn't a viable Linux distribution (or any other operating system, for that matter) that isn't patent encumbered.

Between Fedora 12 and 13

Xnux — 2009-12-13T19:59:07+00:00

I suppose what I am interested in doing is creating a version of Fedora that replaces the default Linux kernel with the Freed-ora version of the Linux-libre kernel (which can be found at http://www.fsfla.org/download/linux-libre/freed-ora/F-12/) and removes any software specifically affected by patents (e.g., Mono and its dependencies, MP3 playback, DVD CSS, etc.). That way, when I actually burn this custom distro to a Live CD, it does not contain any non-free or patent-encumbered software.

How easy would it be for an intermediate Linux user like myself to do this?
When a new version of Linux-libre comes out (there is a new version for each Fedora release), would I have to manually update the kernel each time, or can I configure Software Update to do this?
Is there any way I can convince the Fedora team to maintain a 100% free Fedora version à la Gobuntu? I know that is a lot to ask, but it seems like that would be a lot easier than hacking Fedora myself, plus it would make a lot of disgruntles gNewSense/Trisquel/BLAG users happy.

Thank you for your help.

Between Fedora 12 and 13

Xnux — 2009-12-13T19:46:36+00:00

I'm not suggesting that we just drop all non-free firmware and ship that to everyone. Obviously, that would cause a huge amount of hardware to fail. I want a version of Fedora with no non-free firmware mostly for my own purposes, because I have hardware that can run on only free firmware and I do not desire to download proprietary firmware onto the CD that will install Fedora only to avoid using said firmware.

Projects like this already exist (e.g., gNewSense, Trisquel, BLAG, Freed-ora, Freed-ebian, etc.), but they are usually woefully behind the current releases of the distributions that they are based on (which are usually Debian/Ubuntu or Fedora). I want a distribution that combines Fedora's recent software packages and gNewSense's 100% software without having to settle for an out-of-date distribution (for example, gNewSense is still based on Ubuntu LTS, which is 8.04 Hardy Heron).

Between Fedora 12 and 13

AdamW — 2009-12-13T18:08:50+00:00

"If nothing else, the sound is usually muted at boot, and you can no longer sanely get to a mixer to fix that. "

Eh? What? There's one on the panel like always. If you right-click it, there's a 'mute' checkbox. Hard to think how that could get much easier. gnome-volume-control is right there in the menus like it's always been. Sure, it's a rather different app since F11, but it still has a mute button. Not quite sure what you're talking about.

But yeah, audio is often muted at boot. I filed a bug for my case and Lennart looked into it a bit, then it seemed to magically stop happening while we were debugging it, but it happens again with F12 final live images. Oh well. It's not hard to unmute it, once.

Two Python versions

AdamW — 2009-12-13T18:06:11+00:00

"I'm still not convinced it's workable"

That's odd, seeing as how Mandriva had python 2.4 and python 2.5 parallel installed for multiple releases. Hell, it _still_ has python 2.4 available in Mandriva 2010, alongside 2.6. I'm not aware of it ever having blown up the world in all that time.

Between Fedora 12 and 13

AdamW — 2009-12-13T18:03:44+00:00

Oh, and we did 'take a look at it': Ben Skeggs is RH/Fedora's nouveau developer. If you can't get logs, there's nothing we can do to tell what's going wrong. You could boot to runlevel 3 and try startx manually.

Between Fedora 12 and 13

AdamW — 2009-12-13T18:02:07+00:00

"Can they really have that many other critical X bugs that they haven't been able to look at it in a month?"

Yes.

http://bugz.fedoraproject.org/xorg-x11-drv-intel
http://bugz.fedoraproject.org/xorg-x11-drv-ati
http://bugz.fedoraproject.org/xorg-x11-drv-nouveau

Graphics development is hard. This is nothing specific to Fedora, all distros have this many graphics bugs, more or less.

Between Fedora 12 and 13

AdamW — 2009-12-13T18:00:24+00:00

Jef: you'll note that 'enough 3D for actually-important things like composited window managers' is in the priority list. It's the highest priority besides 'getting the card working at all'. The future of GNOME is gnome-shell, so RH needs at least that much '3D' functionality to work on all major cards. That's the main reason we hired Ben Skeggs.

And...heh, Canonical. That was a good one.

Between Fedora 12 and 13

rahulsundaram — 2009-12-13T09:37:57+00:00

Fedora's licensing policies are far more strict than other mainstream distributions and firmware policy is called a "Exception" for good reasons. Fedora Project will continue to replace firmware with more free equivalents whenever possible. We were afaik, the first distribution to include the free and open source reverse engineered Broadcom firmware by default.

I am not sure what you want to do with alternative kernels but building such a image is fairly easy.

http://fedoraproject.org/wiki/How_to_create_and_use_a_Liv...

If you need further help, you are free to post to the Fedora list or even contact me directly.

Between Fedora 12 and 13

dlang — 2009-12-13T03:08:42+00:00

while I wouldlove to see opensourced firmware, I really don't understand why people try to get firmware blobs removed from the kernel.

non-trivial hardware will not operate without firmware period.

that firmware may be in ROM on the chip.

it may be in flash on the card that requires special hardware to modify

it may be in flash on the card that can be replaced through the driver or other software when plugged in normally

it may be loaded at startup time from the driver.

in all four cases it can be a binary blob that I cannot modify.

in the fourth case I at least have the option of selecting which firmware blob (and there for which feature/api set that the vendor offers) I want to use. It is the most free of the four options.

yes it would be even better if it was opensource with full internal documentation of how the device was put togeather, but while that is something to strive for I don't see how arguing that devices that use firmware installed by the driver is worse than devices that have the same firmware in flash that requires a windows-only program to update makes sense.

Between Fedora 12 and 13

Xnux — 2009-12-13T00:55:09+00:00

My knowledge of how firmware works isn't that great, but I'm not arguing that we shouldn't have binary firmware. I'm saying that all firmware should be made open source. That way, anybody in the Fedora community could contribute source code, not just the copyright holders. Even if the copyright holders do contribute patches to firmware now, that doesn't mean the code will be high quality. Look at nVidia's nv driver--it is mediocre at best, and doesn't even provide 3D support.

I suppose I was under the assumption that blob = proprietary, but maybe I'm wrong. In any case, Fedora should not be content with redistributable-but-closed-source firmware--we need to work on providing open source firmware for different computer hardware as quickly as possible.

Between Fedora 12 and 13

dlang — 2009-12-12T19:16:06+00:00

firmware needs to be updated at the rate of hardware changes/bugs, not at the rate of OS/application development.

the firmware provides an Interface that the OS then uses to manipulate the hardware. If the hardware doesn't change there isn't much need for the firmware to change.

remember that if a particular card doesn't have a firmware blob in the kernel, that doesn't mean that there isn't firmware, it just means that the firmware is in flash or ROM on the card, which is even slower to update.

so why are you willing to use a device that you can't update over one where you (or your linux distro) can pick which version of released firmware you are going to run on the device?

Between Fedora 12 and 13

Xnux — 2009-12-12T04:31:29+00:00

I am aware of Fedora's licensing policies for binary firmware. Still, I don't believe that Fedora is being stringent enough. Even if a piece of firmware is redistributable, the community is at the mercy of the firmware copyright holder to provide updates, which probably won't happen at the rapid rate of Fedora's open source programs.

I understand that firmware helps make the distro available on more hardware, but I don't want that firmware on the kernel by default. The Freed-ora project (related to Linux-libre) provides such a firmware-less kernel for Fedora, but I don't have nearly enough technical expertise to bundle it with Fedora myself. That's why I hope the Fedora developers work on phasing out binary blobs by default.

Between Fedora 12 and 13

leoc — 2009-12-11T21:21:30+00:00

Yes, but once they are loaded you have access to the instruction set of the CPU, unlike say with NVIDIA video cards that hide everything behind the closed driver.

Between Fedora 12 and 13

damentz — 2009-12-11T17:04:09+00:00

Who says RHEL needs to be based off a version of Fedora? They just pick software that is better than what they were using in the previous version of RHEL.

Fedora is a testing ground for new features, not the new RHEL core packages.

Between Fedora 12 and 13

rahulsundaram — 2009-12-11T06:27:07+00:00

Refer to

http://fedoraproject.org/wiki/Licensing#Binary_Firmware

Between Fedora 12 and 13

Xnux — 2009-12-10T15:03:46+00:00

There is only one reason that a Fedora update would interest me: if they finally removed all of the binary blobs in the Linux kernel and replaced it with Linux-libre. I have never found a good, actively-updated 100% free distro (gNewSense isn't updated at all). If Fedora is committed to free software, they should make the change.

Depends

fatrat — 2009-12-10T14:52:25+00:00

A quote that made my day ;)

Between Fedora 12 and 13

Tet — 2009-12-09T18:28:19+00:00

Bug 533030

3D overload

numasan — 2009-12-06T01:23:30+00:00

"Who cares about 3D? "

Well, I and a whole industry do. I guess you don't watch "blockbuster" movies if you feel nauseated by Compiz, but +90% of all visual effects in big budget movies are created (not just rendered) on Linux, and great OpenGL acceleration is very much needed. Right now Nvidia is King with their proprietary driver, and will be for some time yet.

As others have stated 3D is not only for games and Compiz (which I don't use). Perhaps you could couple CAD and DCC together, but with a modern graphics card and Blender you have the tools to create without it being "exclusively highend-only". Unfortunately the open source stack is not yet capable or stable for this task. I personally hope that 3D will get a lot more attention, especially for serious work. What good is a "multi-teraFLOP" GPU when it can only drive wobbly windows?

About Fedora12, we are currently running F10 on our graphics workstations albeit very customized. I'm planning to evaluate F12 soonish but have thought about looking for another distro... F10 is working decently for us though.

3D overload

tialaramex — 2009-12-05T01:29:30+00:00

I once ran X on the ES1000, and X recognized it as a Radeon 7000 or somesuch. We have free accelerated 3D drivers for the Radeon 7000. IIRC I even tried 3D, and it worked.

I guess everybody has their memory play tricks on them sometimes. The ES1000 has no 3D capability. If you don't believe me you might read ATI's specifications for it, or the source of the free driver you're talking about.

unlucky numbers

giraffedata — 2009-12-05T01:26:25+00:00

My Chinese colleagues take lucky and unlucky numbers far more seriously than Americans do

That's my experience too.

Chinese American business people nearly wet themselves back when "888" was introduced as a toll-free telephone area code.

If you don't know Mandarin but listen to Mandarin TV a lot (as I do, due to my Chinese roommate), the most common phrase you hear is "yi ba ba ba," which appears at the end of most commercials and means "1-888".

Depends

nix — 2009-12-05T00:24:05+00:00

"The [Fedorans] did everything in threes."

Between Fedora 12 and 13

nix — 2009-12-04T22:39:45+00:00

Um, CPUs already contain secret proprietary magic uploadable binary blobs.
Neither AMD nor Intel publicise the format of their CPU microcode.

Between Fedora 12 and 13

jspaleta — 2009-12-04T21:49:45+00:00

bug number?

-jef

Depends

Tet — 2009-12-04T21:37:23+00:00

For me, F-12 is a major regression

Heh. For me it's the total opposite. It's a huge step forward. F10 and F11 were dire releases, and I was seriously thinking of looking elsewhere. But F12 is the best release for a while, and is enough to keep me on Fedora for now. Yes, there are problems. KMS doesn't work, and audio doesn't work out of the box. But I can get it to the point where I can do the basics (read my email, surf the web, print, listen to music) with only minor hiccoughs. With F10 and F11, I couldn't get that far, no matter how much effort I put in. I'm starting to think Fedora works in cycles of threes. FC6 was great, F9 was OK and F12 is looking good for me. I just hope I don't have to wait until F15 to get another decent one.

Between Fedora 12 and 13

Tet — 2009-12-04T21:31:08+00:00

Dave was nice enough to layout what the priorities are for Red Hat staffed manhours when it comes to video driver development work

Yes. But that is also somewhat worrying, given that I reported a complete failure a month ago (as in X is completely unusable -- it crashes reliably at startup), and nothing's come of that yet. Can they really have that many other critical X bugs that they haven't been able to look at it in a month?

Between Fedora 12 and 13

Tet — 2009-12-04T21:27:37+00:00

it pretty much works for everyone now.

Surely you jest. I often feel that pulseaudio has an undeserved reputation for being problematic. However, at the same time, I can't remember the last time I saw a modern Linux install have working sound right off the bat. If nothing else, the sound is usually muted at boot, and you can no longer sanely get to a mixer to fix that.

Fedora a beta for RHEL?

misiu_mp — 2009-12-04T19:32:37+00:00

No, debian unstable is perpetual beta of debian stable.
Ubuntu is just perpetual beta.
(evil me)

Between Fedora 12 and 13

leoc — 2009-12-04T17:35:09+00:00

I am no expert, but it seems to me that if/when the graphics functions do move into the CPU, it would by necessity have to be much more open than the situation we have now.

For example, how could ATI/AMD could keep its video technology a "secret" without hindering the CPU as a result? Would you have to load a "proprietary blob" to be able to run anything on it under Linux?

Between Fedora 12 and 13

SimonKagstrom — 2009-12-04T10:28:10+00:00

Now that you mention it, Microsofts decision to skip Office 13 and go for Office 14 instead doesn't sound like a very wise move :-).

Maybe they should jump directly to Office 18 instead!

RHEL lifecylce

sbergman27 — 2009-12-03T23:33:32+00:00

"""
Maybe that is the crux of the subscription model, you have to do what your customers want
"""

Then if they've decided to change policy, they need to at least stop continuing to actively
advertise 18-24 month release cycles in their *current* sales material. Even if they are not
ready to actually announce a change yet. Unless they think their customers *want* to be
decieved.

RHEL lifecylce

kragil — 2009-12-03T22:33:59+00:00

Well, there is a whole ecosystem around RHEL, which RH probably wants to preserve. More frequent releases would demand faster certification from Oracle, IBM, SAP etc. Which is very unlikely. They mostly only certify new products. Customers would be unhappy.
Yearly releases would only work if RH would provide the whole stack, but for most people they don't. I think they want to get there, but so far ..

I think most customers are happy with RHEL5 and are only willing to switch for compelling features. So if a 2 year update cyle won't offer those RH will adopt a longer cycle, which is what has happened I guess.

IMO this is RH new release policy:

"Gather enough features that would compel our customers to switch and that we can't realistically backport and then release.(and adapt lifetime of products accordingly. 8 or 9 years max)"

Maybe that is the crux of the subscription model, you have to do what your customers want (I know how strange that sounds.)

RHEL lifecylce

sbergman27 — 2009-12-03T21:23:03+00:00

I think you are right about the incursion of feature-based thinking. Once a time-based
release cycle gets long enough, I starts getting harder to decide to release without some
highly desired feature. Because you know you are going to have to live with that for two
years. Of course, over the course of the extended release cycle, new things arise that you
come to think of as "must have". And you sure don't want to release without those.

Debian learned this lesson with the Sarge development cycle. The Linux kernel devs
learned this with the 2.5.x development cycle.

And the solution, in both cases, has been *more frequent releases*. And it is a solution
which has worked pretty well. I certainly don't mean that Red Hat needs to go to the usual
6 month release cycle. (Which is too rapid for any distro, IMO. Personally, I think Gnome,
KDE, Xorg, and most distros should target 9 months. But that's another post.) But RH could
benefit from dropping their 18-24 month target to 12-18 months.

With a 12-18 month release cycle, they could afford to go ahead and release the
improvements that are ready... and let the rest wait another 12 months, or so. It wouldn't
be so painful to release without everything on the current list of desired features. And 12-18
months is still long enough to preserve good QA.

It would, however, leave them with more releases to support simultaneously. Such is life, I
guess.

RHEL6

sbergman27 — 2009-12-03T20:59:20+00:00

"""
It is possible that Red Hat thinks supporting four releases at once was too much, and has
decided, but not yet announced, that it will release RHEL less frequently,
"""

The proper way to have made that change would have been to make it effective for RHEL7.
They had already promised 18-24 month releases to RHEL5 customers. And, in fact, are still
claiming an 18-24 month release cycle in their current sales literature. Even as they blithely
disregard it:

http://www.redhat.com/f/pdf/rhel/rhel5_overview.pdf