This post provides my current views on openSUSE-LEAP currently at v.42.1.
I originally composed a version of this as a reply to an openSUSE user’s questions, and decided to modify it slightly and make it into a ‘blog post’.
This is the 1st of 2 parts.
This is my thinking as to the logic and discussions that lead to openSUSE LEAP-42.1. It is not original thinking but rather it comes from reading many posts of many other people far more knowledgeable and far more experienced than. I take no credit for any assessment that is correct, although I do accept the blame for wrong descriptions/wrong assessments.
I should note also, that the following is my private view. It is not an official ‘openSUSE forum’ view’, nor is it an ‘openSUSE community’ nor the official view of anyone from SUSE-GmbH associated with LEAP. Rather it IS my own, albeit I hope my view is not too inaccurate wrt the actual state of things.
In writing this, I note that the openSUSE forums are not now and never have been the area where such participation nor influential discussion on the direction of openSUSE takes place. The direction of openSUSE has always been outside the mandate of the openSUSE forum. Fortunately the area for participation (the mailing lists) is open to each and every openSUSE user if they wish to participate. And such participation is nominally encouraged.
This blog entry is writing assuming those reading know the differences between
- the nominal openSUSE,
- the Tumbleweed offshoot, and
- the two SuSE GmbH SLE variants: SUSE Linux Enterprise Desktop (SLED) and SUSE Linux Enterprise Server (SLES).
What factors lead to the LEAP creation ?
My assessment is that SuSE GmBH (ie SUSE Nuremberg), without whom there would be no openSUSE (at least not now without significant openSUSE changes), were struggling to keep the many applications configured and packaged for SLED and SLES (commonly referred to as SLE). They needed applications packaged for subsequent releases and service packs, but there was a massive amount of work involved. Further, with openSUSE evolving into two separate moderately stable areas: Tumbleweed and plain openSUSE it was becoming increasingly more difficult for SuSE GmBH to repackage SLE applications. Note I am referring to applications and not the core Operating System.
My understanding is as time goes by, the vast majority of openSUSE packaged applications are less and less packaged by SuSE GmbH but rather are more and more packaged by an increasing number of volunteer openSUSE packagers. For the production of SLE, the SuSE GmbH packagers needed to repackage all applicable SLE applications, trying to convert (to SLE) not just the SuSE-GmbH openSUSE packagers techniques (to SLE) but also convert the openSUSE community packaging techniques to SLE. This processes can be difficult and time consuming for SuSE-GmbH.
Further, as the distance in code changes from SLE in relation to Tumbleweed and even openSUSE grew, especially as the two distanced themselves from the last SLE release, meant it was becoming more and more difficult for SuSE GmbH to re-package for SLE the very same packages that had been previously successfully packaged for openSUSE and Tumbleweed. I believe this was especially evident in the desktop specifics of applications (ie KDE, Gnome, Xfce, LXDE, etc … ). It was possibly becoming critical for SuSE GmbH. Ultimately, with no SLE applications packaged there would be no SLE. SLE provides SuSE GmbH income. Without SLE there would be no income for SuSE GmbH Nuremberg. With no SuSE GmbH Nuremberg contribution to openSUSE/Tumbleweed, there would be no GNU/Linux operating system core packaging and thus no openSUSE nor Tumbleweed.
Hence a proposal was made by SuSE-GmbH to try and increase the synergy between openSUSE and SLE that would benefit both SuSE-GmbH and benefit the openSUSE community.
Now one of the criticisms against openSUSE has been that while Tumbleweed does a reasonable job of having more up to date packages (and hence coming closer to the ‘cutting edge’) , that openSUSE with its slightly older packages does NOT in the view of some very conservative users does not fully succeed in being the very stable release that these same very conservative user types would like. Further there has been significant criticism on openSUSE that its 18-month life is far too short. That life has varied a number of times over the past few releases, provoking further the dissatisfaction of some in the openSUSE community wrt that short lifetime.
Thus the synergy proposal was for openSUSE and SLE to come closer together. For openSUSE this would mean openSUSE to adopt the SLE ‘core operating system’ packages. For SLE this would mean SLE would adopt the openSUSE community packaged applications.
There were criticism on this, as SLE tends to work well with old hardware but not so good with new cutting edge hardware. Hence it was agreed more effort would be made on SLE to give it a newer kernel, to maintain the kernel, and also some other compromises made between both SLE and openSUSE community for a successful merge. But the advantages with this new synergy approach were:
- less duplication in packaging, with SuSE-GmBH mostly packaging the core operating system applications for openSUSE
- less duplication in package, with openSUSE community packaging of many applications for openSUSE LEAP now will also run on SLE (due to significant SLE/LEAP commonality with no significant SuSE-GmBH repackaging required)
- with common core operating system openSUSE gets a longer lifetime than 18-months, but gets the 36-months lifetime of SLE
- while openSUSE (with this variant of openSUSE to be called LEAP) may not be as close to the ‘cutting hardware edge’ as before (although some measures were taken to mitigate this), many concerns wrt new hardware and the need for ‘cutting edge’ drivers would be covered by openSUSE Tumbleweed.
LEAP v.42.1 name/version selection
So as noted it was decided to call the openSUSE variant “LEAP”. There was MASSIVE discussion on that name. One popular name was ‘OAK’ but instead “LEAP” won out. Because this ‘merge’ meant something for both SLE and LEAP, there were also massive discussions on the version number. In the end there was a decision to go with version 42.1. Not everyone agreed, but time was wasting, and no one had a version # approach that satisfied all users, so 42.1 was a compromise.
Myself ? I’m not a big fan of 42.1 but frankly, for me, a version number is just a version number. Its not something for me to lose sleep over. While I contribute to openSUSE, many people contribute much much more than myself. Those doing the massive amount of work with this activity, were mostly all in favour of 42.1 … and most important, for certain I was and I still am still in favour of keeping those people (who do most of the work) motivated to continue working. My view is th vast number of those who were opposed to 42.1 do much much less work on openSUSE than those who wanted 42.1. Thus 42.1 made sense to me, from a motivation perspective.
KDE Desktop in LEAP
The KDE Desktop has changed a bit in LEAP. I’ve reads some comment it appears to be a failed effort to copy off the Mac.
Well, wrt the KDE desktop and the Mac – I do not use Mac – I never have – so I can not comment on any synergy nor commonality in appearance there.
I have thou have encountered KDE and Gnome variants of SLE at the office, and my perspective is what we see now in LEAP KDE is the effect of the merge with SLE. I think that is the one of the driving factors.
KDE is still KDE, and one can still tune it to make it more glossy. Also, another important factor here is the timing of LEAP (ie November 2015), as the LEAP KDE is no longer the old KDE4 (as support on KDE4 is stopping, if not stopped already). Note there needs to be 3-years support of what ever KDE version is chosen. One can not get 3 years support on a desktop whose support has stopped. So rather in LEAP for KDE it is KDE-5 (often referred to as Plasma-5). Possibly it is Plasma-5 that has flat style that some don’t like.
So my view is what we see today wrt the LEAP KDE desktop is due to Plasma-5 and SLE merge. Each of which (SLE Merge and move to Plasma-5) I think are logical decisions.
I have installed LEAP with KDE desktop on two PCs thus far: a friend of my wife’s (who has NEVER used a computer in her life before) and on a test PC of mine. I find LEAP KDE Plasma 5 is not as stable as I would like, as I can (somewhat unreliably) reproduce a KDE-5 freezes (black screen with mouse still functioning, on PCs with both radeon and nvidia hardware) but I believe that there are bug reports on such.
Frankly, I quietly (to myself) expected far far more hiccups with the SLE/openSUSE merge for the version LEAP variant (ie in 42.1). I expected far less stability in LEAP (than what was previous in both SLE and in openSUSE). I had thought that the change was simply too big and the implementation time ambitious.
The very fact that SuSE-GmbH were hard pressed with a high work load with SLE packaging applications, pretty much convinced me there would be struggles with the first issue of LEAP, as the move to merge openSUSE and SLE was massive.
It reads now that my (quiet) prediction was mostly not accurate. LEAP was achieved better than I expected due to the combined SuSE-GmbH and openSUSE community efforts. This was the synergy that SuSE-GmbH and the openSUSE community wanted, and I think it speaks well for the future for openSUSE. LEAP-42.1 being created so quick, proved the synergy approach worked.
… to be continued with part-2 …