Fedora 18 Release Slips Another Week 68
An anonymous reader writes "The next major release of the Fedora Project's GNU/Linux distribution (named Spherical Cow) was originally scheduled for November 16th. However, an ambitious set of new features has resulted in the project slipping way past its scheduled release. It had fallen three weeks behind before even producing an alpha release and nine weeks behind by the time the beta release was produced. A major redesign in the distribution installer seems to have resulted in the largest percentage of bugs blocking its release. The set-back marks the first time since 2005 in which there was only one major Fedora release during a calendar year instead of two. Currently, the distribution is scheduled for release on January 15th."
It doesn't matter. (Score:1)
I got tired a long time ago with the fast update cycle that Fedora uses. I've moved on the CentOS because of it. I need a stable workstation. Fedora is all well and good if you want to play with the bleeding edge, but I can't afford that on my systems anymore. I'll probably play with it in a VM to see what's up (or live CD it) but that's about it.
Re:It doesn't matter. (Score:5, Insightful)
And no one (sane) hates you for that. Fedora isn't a one-size-fits-all distro, nor do they ever want to be one.
Re:It doesn't matter. (Score:4, Interesting)
if you want to be able to use anaconda when cent7 comes out, you'll need to start practicing with fedora 18 asap.
Judging by how well Centos tend to do with updates, I wouldn't expect to see Centos 7 for a good few years. This is why we switched to using Scientific Linux some time ago...
Re:It doesn't matter. (Score:5, Informative)
Re: (Score:2)
Centos reworked the build process significantly after the 6.0 release. The 6.2 and 6.3 releases were out 14 and 18 days after the upstream release. SL was somewhat behind after that (72d and 48 days respectively). Source: Wikipedia
Centos have never been especially good with timely security updates either though, and the developers tend to be downright abusive on the mailing lists.
Quick Enough for Me... and for Free (Score:2)
I run a CentOS 6.3 desktop. My experience has been that updates, security and otherwise, have been released rather quickly after their upstream release, in about 1-3 days. I wouldn't expect quicker from anything done by a little batch of part-time volunteers.
Dunno about the mood of the developers; I don't frequent the lists. I've found, tho, that a lot of developers don't know how to deal with users, in person or otherwise.
Re: (Score:2)
I thought the catch with SL is that it doesn't guarantee compatibility in the way that CentOS does. Has that changed?
Re: (Score:3)
If only there was a distro that separated stuff into stable, testing and unstable taxonomies. You could even have a cutting edge experimental branch that could possibly break everything.
Re: (Score:2)
Fedora is all well and good if you want to play with the bleeding edge
Well, yes, that's what it's for, isn't it?
Re: (Score:2)
Fedora is all well and good if you want to play with the bleeding edge
Well, yes, that's what it's for, isn't it?
If you get the Release Candidates yes, however the final release normally is quite stable and IMHO every bit as good and reliable as the other distros. In fact I actually use Fedora as my primary OS (all others are virtualized) professionally.
I normally don't recommend an upgrade when going from one major release to another (ie, 16 to 17 to 18) but a fresh install which actually is quicker to do if you separate your personal data from the operating system and note down any necessary configurations that w
Re: (Score:3)
Have you taken a look at scientific linux?
https://www.scientificlinux.org/ [scientificlinux.org]
It's like CentOS, but is supported with a budget by big-name laboratories.
Re: (Score:2)
CentOS: Good & Aging; Anaconda: Not Good, F18 (Score:3)
I run CentOS as my desktop and it's great. That's what happens when Red Hat takes a good Fedora release and debugs and polishes it for several years.
However, there's no doubt that, at its core, CentOS is aging. At some point, I fully expect to move elsewhere because I will want be able to run what I want to run.
On Fedora 18: I've installed and played with several of the alpha, beta and test candidates. Other than the new Anaconda, this looks like a very nice release. The new Anaconda design, at present,
ROTFL (Score:3)
There is some really delicious irony to a project released named "Spherical Cow" finding that assumptions made in planning were not correct :)
Re: (Score:1)
Re: (Score:2)
I think a cow would better be moddled by an upside down pear shape.... that is... if it wasn't a frictionless point mass.
rngd? (Score:2, Interesting)
It's odd that rngd is an 'ambitious new feature. It's been around for years and has never been deployed right.
Three things are wrong
1 - It's not on by default
2 - When you turn it on, the command line options are wrong, so it silently fails.
3 - When you fix the command line options, it barely feeds in entropy during boot time because the wakeup threshold in the kernel is set too low, so you get the boot time entropy starvation problem, even though you have an entropy source and rngd running.
Also, if they don
Re: (Score:3)
I just took a look at Jeff Garzik's notes and it says it has the RdRand extensions, so my expectations are raised a little. Yay. /usr/lib/system/system/rngd.service, change
Here's what I do on FC17..
1) Install the RdRand enabled rngd
2) At the command line, type systemctl enable rngd.service
3) In
Re: (Score:2)
Actually the problem is in three places, which I listed above.
Re: (Score:2)
"The problem is almost 100% the new installer that basically is not all that different from the old one."
Er. It is hugely, massively different from the old one. It's virtually an entire new code base.
Re: (Score:3)
It's odd that rngd is an 'ambitious new feature.
You need to fix your English parser. An ambitious set of new features != a set of ambitious new features.
Re: (Score:2)
This is true, I hang my head in shame and fully expect to be cast into grammar purgatory on my death. It's still broken in FC17 though.
That's fine by me (Score:2)
Re: (Score:3)
6 months is way too short of a time to iron out bugs plus insert new features
Fedora has become an experimental technology preview platform. It exists for end users to iron out the bugs.
systemd (Score:2, Interesting)
Porting from sysVinit init scripts to systemd unit files.
It is not just the new installer, the conversion to systemd is also only at 70% complete. From their Release 18 Feature List. [fedoraproject.org] I am still using Fedora 16 at home as I had no real reason to move to 17 yet and will probably skip it. I am not entirely sure I want systemd instead of sys v init though and might do a review of the choices out there such as arch. I have used Fedora exclusively on the machine since early 2010 ever since the open source ATI drivers came along. Over all it has been a nice eco system.
Re: (Score:2)
Arch defaults to systemd now also. So if you don't like systems Arch is out.
Re: (Score:3)
This is an interesting, albeit long read. I must say, it does wonders for those with an SSD.
http://0pointer.de/blog/projects/systemd.html [0pointer.de]
Re: (Score:2)
Fedora has been using systemd for several releases now. You're using it, if you're using F16. The feature is for the conversion of service configuration scripts shipped with Fedora from SysV format to systemd-native format, not for actually changing the daemon.
"Features?" (Score:3)
Re: (Score:2)
Yes that's what distros do. They incorporate other stuff. Fedora is very cutting edge - its the place for new stuff.
Re: (Score:3)
"Which are unique to Fedora that would compel one to chose it over one of the other distributions"
That's not really the point of Fedora features. Almost nothing is 'unique to Fedora' because that's not what we want with Fedora. We _want_ other distros to adopt the stuff that originates in Fedora and at RH.
"and I hope we are past the point of talking about installers"
Why would you hope that? The capabilities and interface of the installer are one of the major differentiators between distributions.
The major f
It must be waiting on (Score:2, Funny)
Comment removed (Score:3)
Re: (Score:3)
sysv-to-systemd is not blocking release. If you want to know what's blocking release, what you want to look at is the Release Blockers:
http://qa.fedoraproject.org/blockerbugs/milestone/18/final/buglist [fedoraproject.org]
I feel like Fedora 18 is a bust (Score:5, Insightful)
They should never have merged in the new Anaconda in the state its in. It is not production ready. It is basically impossible to create a new LV or btrfs subvolume and install into it. So you are left with installing into a real partition. And on most of my computers I'm using btrfs or LVM and I've given them the whole HD, so that's not really an option.
Additionally, the UI for selecting where to install into is so confusing that I cannot say with confidence that the install isn't going to wipe out any existing partitions.
The old UI was kind of fiddly, and perhaps it was a bit opaque to newer users since it required some detailed knowledge of what a partition was and how it relates to a physical hard-drive, and LVM volume group or a btrfs volume. But at least it worked and you could make it do what you wanted.
Perhaps this new UI will be a lot better in the end. All I know is that merging the work into mainline Anaconda at this stage of its development was a huge mistake. It means that it will be much harder to go back to the old one should the new UI not be ready in time, or prove to be not-constructible.
I consider it basic software engineer to never count on a given feature that isn't done (to the point of having had at least some testing) to be available on release. You don't let your salespeople sell it. And you don't announce it. This is something I've always had a lot of respect for Google for. They rarely announce things until they're actually done. Software engineering is too unpredictable to do it any other way.
Re: (Score:2)
It felt like they are chasing Ubuntu's installation experience but failing.
-- Fedora user since Red Hat 4
Re: (Score:1)
Production ready? Who in their right mind uses Fedora in a enterprise environment? Fedora is, and always will be, a test platform for tech that will later go into RHEL and eventually the so-called Gnome OS. I'd never use it for a production system if my job depended on it (which it does).
Re: (Score:2)
I have a very different standard for 'production ready' for Fedora and RHEL because you're correct. But 'production ready' for Fedora does, at the very least, mean feature complete and minimally tested.
Re:I feel like Fedora 18 is a bust (Score:4, Interesting)
They should never have merged in the new Anaconda in the state its in.
This looks to me like a failure of release management. Look at the "Contingency Plan" [fedoraproject.org] for the new anaconda UI. They basically said, "we don't have one" and the feature got accepted anyway. So, here we are today.
I don't blame the anaconda guys for finding out that the problem was harder than they thought. That happens.
But process is an important part of what makes Fedora Fedora - if anaconda is "too big to fail" then the process is broken, and Fedora is broken.
I hope the management team has realized that next time somebody says, "we can't have a contingency plan because of X," they respond, "we then you need to re-factor X so you can have a contingency plan."
Re: (Score:3)
I don't blame the anaconda guys for finding out that the problem was harder than they thought. That happens.
Exactly! I really appreciate the work they're doing. But the people managing the release as a whole should've known better than to do it the way they did.
Re: (Score:2)
Re: (Score:2)
"It is basically impossible to create a new LV or btrfs subvolume and install into it."
Um. No it isn't. Specific bug references, please?
Re: (Score:2)
FWIW - I just did a fresh install of F18 to LVM, then installed over the top of that, shrinking the LV that was mounted as / in the first install and creating a new LV within the same VG to be mounted as / in the new install. Worked fine. New install boots, the old LV still exists, can be mounted and contains the old install.
Re: (Score:2)
Bug 860677 [redhat.com]
I've been watching and trying right along. The last time I tried was with TC 3. I still couldn't make heads or tails of the partitioning GUI, and it still seemed like it was going to erase everything instead of installing into a new partition.
Admittedly, I've been trying this on a VM which I've used btrfs for everything. So it doesn't test LVM. Maybe that works now. Unfortunately, all the systems I use LVM for are (for me) mission critical. Though I don't suppose there's any harm in firing up th
Re: (Score:2)
I haven't tried it with btrfs. subvol support isn't entirely complete, it's true. This hardly represents a regression, though, as there was _no_ interactive support for btrfs in f17, we just dropped it out of the installer entirely for that release. Implementing anything close to 'full' btrfs support is a very big job, because it's got so many damn features - it's like writing support for LVM, RAID and a couple of other storage technologies, from the ground up, all at once...
But yes, it definitely works for
Re: (Score:2)
"I consider it basic software engineer to never count on a given feature that isn't done (to the point of having had at least some testing) to be available on release. You don't let your salespeople sell it. And you don't announce it. This is something I've always had a lot of respect for Google for. They rarely announce things until they're actually done. "
This is impossible if you are an open, public project. We can hardly work on a Fedora release with a new installer UI in secret. If we don't make some k
Re: (Score:2)
This is impossible if you are an open, public project. We can hardly work on a Fedora release with a new installer UI in secret. If we don't make some kind of effort to put out controlled messaging about the new installer UI, the result won't be that no-one knows about it until we're ready, the result will be that instead of controlled, accurate information being released, random, often inaccurate information will show up. Probably as a result of Phoronix taking public mailing list threads wildly out of context.
For open, public projects you do not merge new features into the mainline until they are reasonably baked. Yeah, people will learn about them far in advance, and that's just great. But you don't announce that they will be part of a release until they're done.
That code should never have been merged. It was not done. You should've limped along with the old Anaconda for Fedora 18 (which I know would've been something of a blow since you'd been hoping to have it in 17 if I'm not mistaken) and not merged the new
Re: (Score:2)
The problem with that is that it's a very difficult call to make. It's pretty much _always_ the case that something isn't done. At some point, you _need_ to have the New Shiny in main where everyone is paying attention to it and testing it and hacking on. You can only get so much work and testing done on a major component in a side branch.
Personally I think it might possibly have worked better to put off the merge till F19 or schedule a longer F18 cycle, but at the same time, I don't think you can reasonabl
Re: (Score:2)
also note that the anaconda team is small. If we'd gone ahead with F18 with oldUI, very little work would have been done on newUI between F18 Alpha and Final, because the anaconda team would inevitably have got sucked into the usual round of blocker fix work. So it might have resulted in newUI being delayed not to F19, but to F20...etc...etc...every release we went with oldUI made a _significant_ dent in work on newUI.
Re: (Score:2)
I asked a dev why the new Anaconda UI wasn't developed separately and then rolled into the next available release whenever it was ready. The answer: Installers have to be developed in conjunction with whatever it is that they're installing. The requirements and dependencies are such that going it alone won't work.
That makes sense. But, I think some fundamental UI design commitments were made early on that are biting them now. Particularly the manual partitioning interface. I find it just plain difficult