By Jake Edge
August 7, 2013
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.
Comments (6 posted)
Brief items
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
Comments (none posted)
Jean-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!
Comments (28 posted)
Distribution News
openSUSE
YaST, 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."
Comments (none posted)
Newsletters and articles of interest
Comments (none posted)
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."
Comments (none posted)
Page editor: Rebecca Sobol
Next page: Development>>
