Slashdot Mirror
Fedora Core 2 Schedule Up
An anonymous reader writes "The Fedora website has posted a schedule for their second release. " Now that the 2.6 Kernel is out, I imagine all the major distributions will have updates relatively soon.
← Back to Stories (view on slashdot.org)
enters freeze. then we can get a system that uses all the features of 2.6 to their max.
I am the Alpha and the Omega-3
Personally I hope other distros don't change their release schedules around the new kernel. I think it would be foolish for a distro to release a product running on 2.6.0 as default. Best to stick with the 2.4.x series and have the 2.6.x series available as an unsupported extra to avoid any nasty surprises.
Hence if the next release of a distro was to be built on 2.4.x with 2.6 development kernel included, there is likely no need for a change in release schedule.
---
Any man who can drive safely while kissing a pretty girl is simply not giving the kiss the attention it deserves. -- AE
I think /. should replace the RedHat logo since there is a clear distinction between the Fedora product and RedHat's primary branded offering, and this would also recognize the community of non-RedHat employees contributing to Fedora.
There will be unofficial updates for testing, but the big boys will holding off for months. Doesn't anyone remember the pain and suffering of 2.4.0-2.4.12? Linus and co ripped out, and replaced the vm code twice in the 2.4.0 to 2.4.11 time frame.
Red Hat didn't release a 2.4 kernel untill 2.4.7, and pretty much everyone considered it broken. Sure gentoo and the rest of the bleeding edge are already running 2.6.
IANALBIPOOGL (I am not a Lawyer, but I play one on GrokLaw.)
The biggest glibc change is moving to the NPTL threading system. Red Hat has already done so with Fedora 1, now it'll be interesting to see if and how other distros manage to take advantage of all the testing done by RH. Also, you can be quite sure any further changes needed for Fedora 2 will be made in time to glibc, as Red Hat is the defacto primary developer of said system these days.
I had the same problems with the 2-year release cycle. I'm convinced this is due to the core OS being held back from release while every random application with a critical bug is stabilized (the tail wagging the dog), and the apps should be decoupled a bit. That is, something like how FreeBSD does it with a solid core, and the add-ons in ports which is a separate tree.
From the review linked above, Libranet looks like it would be the best option for my purposes (from a technical standpoint, anyway - it even has XFree86 4.3!). It's $64 for the "Home/Small Office" version.. It looks like there are some non-free components included, though.
Sure you don't want to use it for a long term server, but plenty of people find Fedora stable enough for desktop use. Look at Mandrake, a lot of people use it and don't complain about stability even though they are notorious for being bleeding edge and doing things like ship RC packages.
I don't think its either fair or accurate to just call Fedora unstable, because it isn't. A lot of really smart people put it together and test it and they don't go out of their way to just blindly ship the latest package X just because its out there. For all the talk of "Bleeding Edge" Fedora's bleeding edge is a lot less sharp then some people like to claim.
If you wanna get rich, you know that payback is a bitch
contrary to what the Debian fanatics will tell you, the testing/unstable versions are unusable for serious business.
Maybe I'm one of the aforementioned fanatics, but I've been using unstable for serious software development for about two years now. There are only two "problems" I have with it, and neither of them has anything to do with reliability. For that matter, neither of them has anything to do with Debian, per se, they're problems that arise from being "non-standard".
The first problem is package formats. Most commercial software comes packaged for Red Hat and only for Red Hat. Alien, which is a utility that repackages .rpm files as .debs, works 90% of the time, but the other 10% can be a huge pain. For example, I was doing some embedded development about a year ago, using the MontaVista distribution (which provides a Linux kernel and libraries for the target platform, plus cross-compilation development tools). Alien didn't work. Luckily, I noticed that one of the MontaVista developers is also a Debian developer and I e-mailed him (I'd love to give him a public plug here, but I don't recall his name). He was very helpful and told me how to tell the Debian installation of rpm to create the needed database and even gave me a little .rpm file that faked the needed dependencies. Not ideal, since I now have two package management systems on my machine, neither of which knows about the other, but it works. I recently installed DB/2 by just using rpm directly.
The second problem is that, contrary to what people usually think when Debian is brought up, my software is often too new. Unstable nearly always has the latest released versions of everything, and even a few late pre-releases. Particularly since Debian unstable moved to glibc 2.3, I've found that a lot of binary-only software that was compiled against older libs doesn't run right. For example, DB/2 comes with a little graphical installer written in Java, and the installation CDs include a JVM that is used to run it. The included JVM segfaults on my box, and the installer didn't seem to like running in a Sun 1.4.1 JVM. No big deal, though, because the non-GUI installer is a shell script that invokes rpm, and it worked fine.
So, IMO, if you're willing to accept being a second-class citizen because you're not using "the" commercial distro, Debian unstable is a fantastic platform for desktop use and software development. Debian stable is great for servers. Testing is sometimes the best of all worlds, but is a bit dangerous since it doesn't always get security patches very quickly.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
I'm not that old either, but I have a piece of core memory lying around here somewhere that someone gave to me and I also can Google, and I can assure you - the ferrite donuts (cores) don't move.
I think this calls for a plonk! and an STFW.
It's electromagnetic changes, silly -- just like today's RAM, only much much much bigger and with stranger problems. (Like core heating due to the resistance of the wires and other fun stuff.)
+++OK ATH