Slashdot Mirror
Fedora 18 Release Slips Another Week
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."
There is some really delicious irony to a project released named "Spherical Cow" finding that assumptions made in planning were not correct :)
"I opened my eyes, and everything went dark again"
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.
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
ExecStart=/usr/local/sbin/rngd –f
To
ExecStart=/usr/local/sbin/rngd –W 4096 –t 1 –f –n 0
To make it not fail, fill the buffer and have a 1 second interval) /etc/sysctl.conf change kernel random pool refill threshold
4) In
to something sensisble
kernel.random.write_wakeup_threshold = 3072
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Personally, I think 6 months is way too short of a time to iron out bugs plus insert new features (and then fix those bugs). As we've seen with Ubuntu, the bugs don't get fixed until at least 1-3 months after release. Slackware, for instance, does yearly releases and that seems to work well for them. The openSuSE guys are also considering (although not officially) yearly releases after the QA problems they had with getting 12.2 ready.
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.
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. 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.
"but money is the God of Algiers & Mahomet their prophet." - Rich. O'Bryen June 8th 1786
I'll grant that my glance was cursory but much of that list just appears to be "making other shit thats been around for a while work on Fedora.XX" Which are unique to Fedora that would compel one to chose it over one of the other distributions (and I hope we are past the point of talking about installers)? This is not a troll, the same question could probably be asked of most Linux distros but as a front page /. post makes Fedora 18 delay seem important I ask about it.
The new blackberry 10 integration.
The installer UI, and sysv to systemd are things that need to get completed. As of about a week ago i posted a systemd service for slim that hopefully with this deadline extension will get included in the image as opposed to zero-day updates.
Good people go to bed earlier.
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.
Need a Python, C++, Unix, Linux develop
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.
Have you taken a look at scientific linux?
https://www.scientificlinux.org/
It's like CentOS, but is supported with a budget by big-name laboratories.
this signature has been removed due to a DMCA takedown notice
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...
http://blog.nexusuk.org
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
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, does not present an obvious workflow. I.e., the first few times I used it I wasn't sure what I was supposed to click on or do next. Manual/custom partitioning has been a real quagmire. The new design is the kind of app that really needs little bubbles of explanatory text that pop up when you cursor over them. For starters. (An installer is a complex application, with intimate links to the distribution it installs, yet it needs the capacity to be quickly adapted to new releases. So, I'll cut them a lot of slack.)
Anyway, I've never understood why Fedora commits itself to the 6-month cycle, unless there are internal Red Hat requirements. At the least, have the deadline, but keep it internal only. Why set yourself up for public basing when you don't meet an artificial schedule?
-- Slashdot: When Public Access TV Says "No"