LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||
DistributionsChanges brewing for openSUSE?For some time now, openSUSE has been searching for its identity. It is not alone in that, as Fedora and others have also wrestled with many of the same questions. Some of the recent discussions were largely inspired by SUSE VP of Engineering Ralf Flaxa's keynote [YouTube] at the recently concluded openSUSE conference—though many of the ideas have been floating around for years. Since then, discussion is ongoing regarding the future and plans for the distribution and its offshoots: Factory, Tumbleweed, and Evergreen. One of the problems for openSUSE right now is that the work that goes into Tumbleweed, a rolling release, is not necessarily aligned with what is going on in Factory, which is where the development for the next version happens (much like Fedora's Rawhide). Packages may be updated in Tumbleweed (or available from the openSUSE Build Service), but not be the same as what is being developed for Factory, and thus for the next openSUSE. Getting those efforts in better alignment would be one step in the right direction. There is also the belief that openSUSE is not well-targeted and tries to be too many things to too many different kinds of users. For example, the current eight-month release cycle is too frequent for some, but too slow for others. Similarly, the 18-month support cycle for each release is either too short or far longer than many users are interested in. As openSUSE community manager Jos Poortvliet put it on his blog: "openSUSE is well known for doing everything a bit - making everybody a little happy, but nobody REALLY happy." Flaxa offered more help for openSUSE from the SUSE Linux Enterprise (SLE) team, but also noted that he was not there to mandate anything. OpenSUSE has been working on transparent community governance for some time, and SUSE wants to see that continue, he said. The conclusion of his keynote was based around suggestions from SUSE, not mandates, or even requests. Many of the suggestions parallel the problems that Poortvliet and others have been bringing up (e.g. quality, life cycle, release integration, etc.). Flaxa said that SUSE is pleased with openSUSE and plans to continue its investment in it. But, he said, there is a gap between the users served by openSUSE and those served by SLE. One suggestion he had was to try to bridge that gap, such that there was a smoother path, not just for users moving to SLE, but also for SLE users to be able to use openSUSE more effectively. SUSE is also interested in seeing a more community-oriented openSUSE as its governance broadens. The roots of some of these issues go back at least three years to the openSUSE strategy discussions of 2010. While a strategy was determined in 2011, it didn't really change things that much. In many ways, openSUSE is running in third place behind Ubuntu and Fedora. Users who want user-friendliness tend to turn to Ubuntu, while those looking for the cutting edge (or nearly so) look to Fedora. But even if a particular focus can be settled on in terms of the kinds of users the distribution will target, there are some technical barriers to overcome. Some of those barriers and possible solutions were discussed back in June 2012 once it became clear that the 12.2 release would have to be delayed. More recently, openSUSE board member Robert Schweikert opened a discussion on "Fiddling with our development model" on the opensuse-factory mailing list. He clearly noted that the ideas were his, "NOT board intervention", however. Schweikert sees problems with the current "push model" where a new component like GCC can enter Factory and break lots of other packages. There are only a few people from the release team working to resolve those kinds of problems, so Factory (or the staging portion of Factory) can be broken for a long time. That problem led Schweikert to propose breaking the distribution up into "components", each of which has a clearly defined set of dependencies. Multiple versions of a component might be supported at any given time, and the other components' teams would decide when to switch to a new version of a component it is dependent on. That way a change to a dependency wouldn't immediately be able to break any packages dependent on it as there would be no forced upgrade (at least until distribution release time neared). There were a number of posters disagreeing with Schweikert's approach, but his post did spark a discussion that the distribution needs to have, at least according to Poortvliet. An alternative that has evidently been suggested by Stephan "Coolo" Kulow is to separate the packages in Factory into "rings". Poortvliet mentions the idea in his blog post above, as well as in an earlier one. Basically, the core of the OS, the kernel and minimum needed to boot would be ring 0, while build tools and utilities would be in ring 1, ring 2 would have desktops and their development frameworks, and, finally, user applications would live in ring 3. The rings could be supported for different lengths of time, and could be updated separately. So one could keep the core and desktop stable, but update the applications frequently, for example. So far, the rings idea hasn't really been discussed on the mailing list, but based on the comments on Poortvliet's posts, it may be more popular than Schweikert's idea. In the final analysis, though, the question is much bigger than just a technical one. Poortvliet put it this way:
The issue with all the above scenarios is that while we can technically do
them (some are harder than others, of course) the choice doesn't just
depend on what we can do but also on what we should do. That makes the
discussion a lot more interesting. We have to fix some things in our
process, adjust to reality, that is clear. But do we want to shift
direction, too? What is our real goal?
That, in some ways, takes the distribution full circle, back to the 2010/2011 strategy discussions and vote. It is not an easy problem to solve. There are lots of people involved, each with their own personal idea of what the distribution is "for". As we have seen, other distributions have struggled with the same thing. Even Ubuntu, which seems to have the clearest grasp on who its audience is, went through a long discussion of switching to rolling release model recently. In all of those cases, the distributions in question have been struggling to better serve their users—openSUSE is following that same path.
Brief items Distribution quote of the week
This may be obvious to the average otaku, but not so much to
$debian_user who is trying to choose between the many Twitter clients we
have.
-- Ben Hutchings
Jean-Baptiste Quéru quits AOSPJean-Baptiste Quéru, the developer behind the successful development of the Android Open Source Project, has announced that he is leaving that project. "There's no point being the maintainer of an Operating System that can't boot to the home screen on its flagship device for lack of GPU support, especially when I'm getting the blame for something that I don't have authority to fix myself and that I had anticipated and escalated more than 6 months ahead." According to Android and Me, the new Nexus 7 tablet was the straw that broke the camel's back.Many thanks to JBQ for the work he has done for AOSP!
Distribution News openSUSE YaST in Ruby integrated into FactoryYaST, the openSUSE configuration tool has been converted from YCP to Ruby. "we are proud to announce that we just reached the main goal of the YCP Killer project: we did the final conversion of YaST codebase from YCP to Ruby and integrated the result into Factory (which means YaST in Ruby will be part of openSUSE 13.1 M4). At the same time, YaST version was officially increased to 3.0.0."
Newsletters and articles of interest Distribution newsletters
UberStudent Pushes Users to the Head of the Class (LinuxInsider)LinuxInsider reviews UberStudent. "UberStudent, developed by education specialist Stephen Ewen, is a Linux distro that delivers tools for learning task completion and academic success, targeting advanced secondary and higher education students. However, it goes beyond that. I have been using UberStudent because its tools set and features array are neatly packaged in well-designed menus. While my student learning days are long gone, some of these specialty applications are very useful for note taking, task planning, and project organization for the non-school things I do."
Page editor: Rebecca Sobol |
|||||||||||||