LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||
DistributionsFedora and LVMThose following the progress of the Fedora 18 development cycle cannot have failed to notice that the rework of Anaconda, the distribution's installer, is not going as smoothly as one might have liked. Complaints are common, and there is a real risk that installer problems will end up being what users remember about this release. Given that, it may seem surprising that the Fedora developers intend to change one of the fundamental decisions made by the developers of the new installer.The logical volume manager (LVM) sits above the block layer, providing abstract storage devices that can be resized, encrypted, and more. In the absence of explicit instructions to the contrary, Anaconda has installed systems using LVM for many years. LVM adds some flexibility to an installed system and supports a number of official Fedora features, but it has the potential to confuse users who are not prepared for the addition of a layer of indirection over their disk partitions. It also irritates users who know they don't need LVM and would rather not see another layer of software in the block I/O path. Grumbling about the use of LVM in Fedora is not uncommon. The new installer changes the default; unless the user asks for LVM explicitly, current F18 testing releases will install directly onto disk partitions and leave LVM out of the picture. How that change came to be is not entirely clear; it does not seem that there was much, if any discussion in the Fedora development community first. That did finally begin, though, on October 25, when Adam Williamson filed a Fedora bug asking that the change be reverted so that Fedora would, once again, install and use LVM by default. That discussion got off to a bit of a rough start; arguably, Adam's phrasing did not help matters:
It's kind of hard to really swing the 'LVM annoys people' argument
too. Well, it _does_, but not for very good reason. That argument
boils down to 'catering to idiots': the people who say they're
annoyed by LVM as default are people who know raw partitioning,
don't understand LVM, and are resisting change.
In the end, though, the real arguments in favor of changing Anaconda to restore LVM-by-default came to the fore; there are several of them. The first of these is that a number of advertised Fedora features depend on LVM; a user who does without LVM will end up without the ability to use System Storage Manager, resize filesystems, migrate filesystems across disk, and more. Thus, Ric Wheeler said, turning LVM off by default constitutes a regression that needs to be reverted. There is also the little problem that Fedora's documentation is written with the assumption that LVM is in use. Turning LVM off obsoletes that documentation without fixing it. Quality documentation is hard enough to come by as it is; causing what documentation exists to become inaccurate without (as LVM proponents see it) a proper justification just makes things worse to no good end. Also relevant is that the current plan is for Fedora to switch to Btrfs during the Fedora 19 development cycle. Given that, making a fundamental change to the Fedora storage stack now makes little sense to many developers. It will just add churn to a system that is going away anyway, leaving one Fedora release with a storage setup that differs from all the others. That has the potential to confuse users and increase the amount of work the Fedora storage developers have to put into supporting the F18 release. Even if the Btrfs transition is delayed to F20 (an outrageously shocking and unpredictable course of events, but one might as well ponder even highly unlikely scenarios), a case could be made that it might be better not to perturb the existing stack unnecessarily in the meantime. Finally, it has been pointed out that the change to Anaconda returning it to the pre-F18 default is quite small; it is really just changing the default value of a checkbox on an installer screen. All of the code for installing over LVM — code that has been used for many releases — is still there and working as well as ever. So the change should be safe and should not be cause for yet another slip in the Fedora 18 schedule. Arguments for leaving the default as it is (and, thus, continuing to install without LVM) usually start with the fact that it is quite late in the F18 development cycle; unnecessary changes — even small and seemingly safe changes — should be avoided if possible. That is doubly true for the installer, which has had trouble stabilizing as it is. Rather than revisit established decisions, it is said, it would be better to focus on fixing the known problems and getting a solid release out the door. Beyond that, some developers question the value of LVM. Fedora developer "drago01" asked:
Resizing partitions isn't that common and not the primary use of
LVM (you can do it without it and most users won't). It is still
pretty much useless (as in the extra features won't be used) for
the average desktop / laptop installs. For most users all it does
is slowing down the boot process (we should stop adding crap to the
default boot process because someone might need it on some obscure
case).
LVM has been fingered in the past for slowing down the boot process; indeed, it has been called out as one of the chief offenders. Discussion in the bug report suggests that LVM's dependency on udev-settle, which is the real cause of boot-time delays, has been significantly reduced, to the point that many or most installations no longer need it. But, if boot time is a prime concern, the addition of another service to set up in the boot path is unlikely to help the situation. Finally, opponents argue that LVM is confusing to relatively unsophisticated users who will end up being unable to manage their systems properly. It is an added level of abstraction that makes things harder without bringing any significant new value. It would be better, they argue, to behave like many other distributions and just install directly onto disk partitions by default. The Fedora Engineering Steering Committee (FESCO) took up this issue and brought it to a vote on October 30. Full consensus was not to be found there either, but, in the end, FESCO voted in favor of the change back to the pre-F18 default. So, unless something gets derailed somewhere, the Fedora 18 will, like its predecessors, install and use LVM by default.
Brief items Distribution quotes of the week
In the Linux space what the games people seem to be doing now is
realising that they should just replace "Linux" with "Ubuntu" and they'll
cover all the general end user bases, and the techie oriented distros
will work out themselves how to to make it work 8)
-- Alan Cox
If you don't like the rules feel free to whine, beg, and plead to QA,
the council, $DIETY, or your mother, but follow the rules until
they're changed. There is always room for mistakes, but big projects
don't work when everybody just does whatever they feel like doing.
-- Rich Freeman
Should we just skip F18? (like seriously).
-- Dave Airlie
Yocto 1.3 "danny" ReleasedVersion 1.3 of the Yocto embedded distribution builder is out. It features a new terminal-based interface, a lot of usability improvements, a number of upgraded components, and over 500 bug fixes.
Linaro ARMv8 Downloads Now AvailableLinaro has announced the release of ARMv8 images. "The ARMv8 architecture offers 64-bit computing for ARM SoCs. ARM and Linaro have been hard at work to enable opensource software for the new AArch64 execution state and for the new A64 instruction set and Linaro is making early ARMv8 images available to interested developers. While hardware isn’t available for purchase, ARM offers a free of charge ARMv8 virtual platform called “Foundation model” which allows booting Linaro’s GNU/Linux images." (Thanks to Riku Voipio)
Distribution News Debian GNU/Linux DebConf13 sponsors wantedDebConf13 is scheduled to take place in Switzerland next year. Sponsors are needed to make it happen. "After DebConf12's great success we are working to secure the next DebConf in Switzerland. We are now contacting sponsors from all over the world and we would like to ask all Debian contributors to inform us about any useful connections they know or have, which could result in sponsorship for DebConf13."
Red Hat Enterprise Linux Red Hat Enterprise Linux Extended Update Support 6.0 1-Month EOL NoticeRed Hat has announced a 1 month notice for Red Hat Enterprise Linux Extended Update Support Add-On (EUS) 6.0. "In accordance with the Red Hat Enterprise Linux Errata Support Policy, the Extended Update Support for Red Hat Enterprise Linux 6.0 will end on 30th November, 2012."
Ubuntu family Ubuntu 11.04 (Natty Narwhal) end-of-lifeUbuntu 11.04 (Natty Narwhal) reached the end of support on October 28. "The supported upgrade path from Ubuntu 11.04 is via Ubuntu 11.10 (Oneiric Ocelot)."
New Distributions sposkpatsposkpat (Single Purpose Operating System: KPatience) is a new distribution based on Debian 6.0 and KDE's kpat. It runs in RAM as a full-screen solitaire card game with no distractions, not even a clock. The website notes: "Playing solitaire games helps you to greatly improve your attention span and enhance the ability to concentrate."
Newsletters and articles of interest Distribution newsletters
Garrett: A detailed technical description of ShimMatthew Garrett describes Shim, the first stage bootloader used to support Secure Boot. "handle_image() is the real meat of Shim. First it has to examine the header data in read_header(), copying the relevant bits into a context structure that will be used later. Some basic sanity checks on the binary are also performed here. If we're running in secure mode (ie, Secure Boot is enabled and we haven't been toggled into insecure mode) we then need to verify that the binary matches the signature and hasn't been blacklisted."
Ubuntu: No more alphas, just one beta (The H)The H reports on a change in the Ubuntu 13.04 release process. There will not be any 13.04 alpha releases. "With there only being one beta and one final release of an Ubuntu version, the archive of code will now only be frozen late in the development cycle. This change could also allow for the introduction of Mark Shuttleworth's "Ta-da" features quite late in the development cycle, though currently it is unclear how they will be integrated into the tree; there could be a parallel testing effort for a version with those features included or if the features could be added earlier in the cycle to allow their testing to begin sooner."
Page editor: Rebecca Sobol |
|||||||||||||