LWN: Comments on "Rebasing openSUSE"

Rebasing openSUSE

Wol — Mon, 06 Jul 2015 19:55:48 +0000

> With the move to Tumbleweed, I personally I would have decided to abandon the "stable" releases.

Unfortunately, last time I looked, various CRITICAL (for me, at least) packages are NOT supported on Tumbleweed. Like VirtualBox. I do not want to be debugging a crashed VirtualBox over the phone with an elderly relative who doesn't listen and anticipates the commands you are NOT going to give.

Cheers,
Wol

Rebasing openSUSE

sysrich — Sat, 04 Jul 2015 08:55:03 +0000

> And I have yet to find a search for a given file (e.g. "what provides /usr/lib64/libXt.so.6").

zypper wp [Filename]

> It seems like this article is describing a situation where the future release schedules are unclear, though. https://en.opensuse.org/Lifetime seems to have some historic (EOL) dates, which seem to indicate somewhere between half a year to a year per release.

At the time of writing this article was correct. We've since announced that the first release of 'openSUSE 42' will be in November: https://news.opensuse.org/2015/06/26/work-begins-on-total...

Future releases will be aligned with SLE service packs and major releases. That would mean I'd expect at least one minor release of openSUSE 42.x in 2016.

Rebasing openSUSE

jospoortvliet — Fri, 03 Jul 2015 18:36:03 +0000

I know the deviant folks like to think so but debian doesn't have so many more packages than other distributions - openSUSE maintains over 7K for many current releases and architectures thanks to efficient processes and tools. And, as debian splits packages more than most rpm distros do, the difference isn't more than a few hundred actually useful applications perhaps. (i admit I didn't count either though)

In any case - my point: good processes can make less ppl do more. The github model of pull request is pretty much how openSUSE works with packaging and it is very powerful. Combined with the automated building and testing - well, tumbleweed shows the result...

Rebasing openSUSE

jospoortvliet — Fri, 03 Jul 2015 18:29:11 +0000

There are two things which are very different and important here . And I say this because you pointed out that the theory can be good bit practice doesn't work. Well, in openSUSE it does for two reasons. One is OBS. I think you can't overestimate how important tools can be in enforcing processes and transparency. The second reason is company culture at suse - it is, in general, not the kind of place where a manager micro-manages people. Unlike red hat which seems a bit top heavy and over managed if you ask me.

Rebasing openSUSE

Mook — Fri, 03 Jul 2015 08:08:46 +0000

(I'm on guest timing, hopefully this means I'm not disturbing people with somewhat offtopic stuff)

If you can figure out the package name, looking at the package search site can give you an idea of what versions packages are at for the various releases:

http://software.opensuse.org/package/kernel-desktop

However, that won't tell you very much on future release schedules. And I have yet to find a search for a given file (e.g. "what provides /usr/lib64/libXt.so.6").

It seems like this article is describing a situation where the future release schedules are unclear, though. https://en.opensuse.org/Lifetime seems to have some historic (EOL) dates, which seem to indicate somewhere between half a year to a year per release.

Rebasing openSUSE

johannbg — Wed, 01 Jul 2015 21:35:41 +0000

The KDE community in Fedora ( which today exist of mixed match of employees and contributors ) is very strong active and self-sufficient has always ( like anything community has produced ) has had to fight for it's existence and inclusion and presence ( With the WG's they got thrown aside and told to come up with their own "product" as opposed to be part of the "workstation" product and they just got lucky they did not just end up as an "spin" which arguably is the community name for "product" just without all the bells and whistle as second glass citizens never get those ).

The project should have evolved into a different direction during the golden era of Fedora ( FC6/F7 ) from a community driven projects perspective but Red Hat ensured it was kept in it's place so it would not venture off to far away from it ( and at the same time stamped on Greg DeKoingsberg legacy which I think had moved to doing other things at that time).

Today Fedora has evolved entirely into becoming Red Hat's internal distribution ( just without the name, perhaps it always was and I was just to blind to see it ) and grown so fat it has collapsed under it's own weight.

Sad but true.

Rebasing openSUSE

einar — Wed, 01 Jul 2015 19:12:29 +0000

> for example, the fact that openSUSE has KDE as it's default desktop (and half a dozen other desktops as well)

And to add on that (mainly for others as sysrich obviously knows ;): the KDE software packages maintainers are from the community: no one is from SUSE, so far (there are some SUSE employees that have access, however the work is done by the community members). Disclaimer: I'm one of said team.

Rebasing openSUSE

sysrich — Mon, 29 Jun 2015 20:42:53 +0000

I think you're adding meaning to my words that I certainly didn't intend. By 'maintainer' I meant just that "someone who helps maintain a package". There's no concept of 'ownership' in openSUSE. The default assumption is any maintainer would like more additional maintainers helping them. Everyone has access to send Submit Requests for any Package anywhere in our Build Service. No one has to prove anything or do anything before contributing to openSUSE, the barrier to entry couldn't be any lower, and no packages are only able to be worked on by SUSE employees

Let me give you a nice simple real world example of how this works from the last year. systemd

systemd is arguably the most important package after the Kernel in our distribution now. systemd in openSUSE was maintained by a single guy, hired by SUSE, who's day job was maintaining systemd in SLE. He did a fine job, but he basically kept the openSUSE systemd package in perfect sync with the SLE systemd package, slow moving, heavily laden with backported patches. It worked, it was nice, but a number of other volunteers in the community didn't like it. They thought they could do better, and wanted to have the version of systemd tracking upstream better, with patches being rebased or dropped more aggressively.

Initially, this was discussed on the mailinglist. The maintainer of systemd defended his position and refused to change his ways. He wanted to do his work his way, which is his right. At this point, you could have been mistaken that this situation was 'proof' that SUSE are just like Red Hat and exert 'control' over openSUSE

But, we're not. The community volunteers submitted updated packages, with the patches rebased and the unneeded ones dropped. The work the SUSE Maintainer would never do, nor want to do, was done by the community, and the submitted changes were accepted, because there was no good reason not to.

Now we have both community Maintainers and the SUSE Maintainer working together on the openSUSE package. They both have equal rights to the package, no one is in 'control', they're trusted to work on it together.

And the benefit to SUSE? The one SUSE maintainer now has less work to do looking after openSUSE because he's sharing the load with other volunteers. That's more time for other SUSE stuff. SUSE are going to need an updated version of systemd for SLE someday, and when they do, having one they know works well in openSUSE Tumbleweed (a snapshot of which will be the base of SLE 13 someday) is a great starting point that would save a heck of a lot of work for the one guy they have doing it..

Less work, more productivity, ability to keep up with faster moving tech.. is it so hard to see the benefits with this model? :)

Rebasing openSUSE

anselm — Mon, 29 Jun 2015 14:47:35 +0000

In Debian you have more than a thousand package maintainers and several tens of thousands of packages. In this context it makes more sense to try to get people to feel personally responsible for individual packages (either as individual maintainers or as part of a team sharing in the maintenance of the package or a group of related packages) than to try to get everyone to be responsible for everything, which is a concept that doesn't really scale to a Debian-sized distribution. After all, people who are not officially in charge of a package are always free to contribute to that package's development by sending patches or being otherwise helpful. It is still a good idea to have one maintainer (or close-knit group of maintainers) who acts as gatekeeper to the package – and if somebody pops up who takes an active interest in a package, taking that person on as a co-maintainer for the package (with or without direct upload privileges) may well be a reasonable idea.

Given the considerable size of Debian, the approach seems to be working reasonably well (occasional examples to the contrary notwithstanding). Co-maintainership or team maintainership are always options – Debian supports such teams with mailing lists, Wiki pages, and similar infrastructure –, and there is a defined procedure for “non-maintainer uploads” as well as for the adoption of orphaned packages to deal with inactive or MIA developers.

Rebasing openSUSE

johannbg — Mon, 29 Jun 2015 14:04:40 +0000

I would argue that this does not work well for Debian for example for reason that lead to [1] as well as for Fedora due to wide variety of other reasons.

What I mention above just takes the process one step higher than individual or a group of individuals behind a component by putting the maintainership in the hands of the entire collective and removes any virtual barriers that has been set in place due to lack of trust and the ability to point fingers to an individual that is contributing his or hers free time to maintain a component ( it's not like you can force individuals that are contributing on their own free time to fix things anyway so what's the point? ).

Often these are individuals that have absolutely no idea what they are doing ( but manage to stumble their way through package review request ) and vanish after a period of time since they did not realize what they where getting themselves into, with bug reports and other distribution maintenance obligations become too overwhelming or too time consuming for them.

With the entire collective as an backend, those individuals that dont know what they are doing but are willing to learn and contribute could do so at their own pace with *any* component ( which prevents things becoming to overwhelming ) safely knowing that they had the entire collective to fallback on encase other obligation would take up their free time.

Effectively their contributed time would just be added to the pool of available contribution time to maintain all of the components that make up the distribution.

And without the ownership barriers and the access permission that follows, an targeted approach that taps into the available contribution resources could be made.

Something like this week we are going to be focusing all available resources going over and fix any issues that are spesific to X
( For example in Fedora you would have to be a proven packagers to be able to do this, otherwise you are just filing bug reports which just increases the workload on those existing "owners" and delay inclusion of fix as opposed to be able to fix it yourself and immediately as you feel the need to scratch that itch )

By the way distribution development for the most part is exclusive to infrastructure development since developers working on components they maintain do their work for the most part upstream so somewhere along the line people started calling package maintainers, developers when in fact they are just package maintainers ( or historically developers used to be the only ones that maintained the component they developed in downstream distribution, which is not the case anymore ) which is bit misleading and arguably wrong thing to do ( on numerous occasion I came across package maintainers in Fedora that did not even know how to debug the component they allegedly maintained or where in any contact with the upstream of that component ).

1. https://lists.debian.org/debian-ctte/2015/06/msg00012.html

Rebasing openSUSE

anselm — Mon, 29 Jun 2015 13:01:22 +0000

This model ( from my perspective ) is old and outdated

Seems to work for Debian, though. Although to be fair many of the “someones” are in fact teams of developers now as opposed to individuals. The basic principle that a developer or group of developers must take responsibility for a package for that package to be part of the distribution still remains.

Rebasing openSUSE

johannbg — Mon, 29 Jun 2015 12:34:17 +0000

"Ownership model? Packages have to be maintained by someone or else they wont be in the distribution any more."

This model ( from my perspective ) is old and outdated and is one way for corporate to ensure dominance in projects and is for example how Red Hat ensures it's dominance over the components that make up RHEL in Fedora ( I have encountered an package maintainer that had to talk to his RH manager before he committed a change to the component he maintained and other cases where maintainers kept components hostage due to some internal dispute within Red Hat or disagreement with their co-workers, etc ) and arguably is the wrong approach in a community of volunteers ( but most certainly is necessary to kept things under corporate control ).

The more open approach to this is to have every accepted component maintained by the collective which is made up of individuals that have been granted commit rights, which might be granted after period of sane pull requests or whatever other process the community comes up with for commits approval.

That pull request would be send for review to the collective that has commit rights for review as opposed to the single individual ( or few individuals ) that "own the component", with the life time of accepted component in the distribution be bound to it's upstream maintenance or removed based on request for removal for whatever reason, ( which probably would require collective approval of some sort before being done ).

Bottom line

Simpler access model and level of trust ( you either have commit access or you dont )
Less infrastructure overhead ( for example you would not have to run around find a ( new ) maintainer for component that has already been accepted )
No single individual or group of individuals ( employee(s) or otherwise ) can own a component, which prevents corporate misuse as I described here above or for example disputes like are happening with the aptitude maintenances in Debian taking place in the community.
Natural progression of components maintainership as in the individual that contribs most of his time ( either freely or paid ) to a single component effectively becomes the "owner" of said component for the duration of his commitment ( and by owner I mean he would most likely become the one to review and commit either his own changes or someone else's or revert them if need be ).
No obligation bound to a single component ( for example you dont have to have "own" a package before you can start contributing to package maintenance )
Individual can contribute and commit freely to whatever component they see fit based on their interest and time.
Faster uptake of system wide,system approved changes
etc.

This would not require much change if adopted in opensuse based on what I have read so far about package maintenance and at the same time I noticed opensuse is much more open and less prone to corporate misuses compared to fedora so of lesser evils individuals are better of contributing to opensuse community than to fedora.

Which just leaves the question how bound is opensuse to the suse distribution and it's direction ( fedora is being forced to take the same direction as RHEL and if the community ventures in alternative direction than what Red Hat wants, it simply yanks the chain and it in the process back into it's place as second class citizens).

What does suse consider return of investment from it's community alternative?

Rebasing openSUSE

sysrich — Sun, 28 Jun 2015 21:38:15 +0000

Ownership model? Packages have to be maintained by someone or else they wont be in the distribution any more.

We don't have an equivalent of FESCo.
Contributors (regardless of who they work for) decide the implementation of new features by doing it, in a very meritocratic, 'those who do decide' kind of way.

Obviously, to work properly, this requires people to talk to each other, so for example, a new package or major feature should be discussed on the opensuse-factory mailinglist before being implemented, but it's all done in a very collaborative fashion. (eg https://en.opensuse.org/openSUSE:How_to_contribute_to_Fac... )

If there's technical conflicts (eg. Feature A from Contributor W would break Feature B from Contributors X,Y,Z) the parties involved are supposed to talk to each other and figure out a way that makes them both happy.
If that doesn't work, the Board are there as our escalation point, conflict resolution body and decision-makers of last resort, but we're much more likely to try and tackle the problem on a 'personal' level (getting the Contributors to figure it out between them) than a 'technical' one (taking the decision away from those doing the work). The approach isn't without it's flaws, but it's serving us pretty well and I think stands up nicely compared to what I see in some other Projects.

Regarding our infrastructure: Much of our Infrastructure is hosted at SUSE, but we have policies in place for both volunteers helping administer the SUSE-hosted-openSUSE infrastructure and for volunteer-hosted-infrastructure, which can (probably should, it's a nice service) also have SUSE monitoring and help administer it (to stop Bus Factor=1 issues). They share a combined ticketing system at admin@opensuse.org where tickets are raised and our admins fix them.

So yeah, sorry if this is sounding like a corporate sales pitch, I'm trying not to, this is just how we do things in openSUSE..

Rebasing openSUSE

johannbg — Sun, 28 Jun 2015 20:42:51 +0000

That's pretty similar corporate sales pitch as has been said and advertised in Fedora however the reality is quite different how things operate.

What's the ownership model of the components in OpenSuse? Does OpenSuse have an equivalent of FESCo? Who own and control the infrastructure? These are the questions people should asking themselves not strictly be looking at an governance structure of an project.

I personally fail to see how there can exist independent, community led distribution with a corporate backing since in the end of the day no matter which company it is, all of those companies will protect their investment and all of those corporates will expect return from investment one way or in one form or another ( It's just an basic obligation to it's shareholders ) and I'm pretty sure if I start looking deep into how opensuse operates I will quickly discover how Suse polices the community ( just like Red Hat polices Fedora) and how it gets back it's investment but maybe I'm wrong and opensuse is the first...

Rebasing openSUSE

sysrich — Sun, 28 Jun 2015 15:59:59 +0000

> how Red Hat operates and misuses it, that they can expect that Suse does same or similar things with OpenSuse ( And Canonical with Ubuntu )

I think it's really unfair to lump SUSE and their relationship with openSUSE in the same box as RedHat/Fedora and Canoncial/Ubuntu. I understand it's easy comparisons to make, but SUSE make huge efforts to be different in this area and to enable openSUSE to be an independent, community led, project.

As an example, openSUSE has it's own Governance structure (the Board). With the exception of the Chairman position (which SUSE appoint), all of the seats are elected by the community. Even with the Chairman, no organisation (not even SUSE) can have more than 50% of the seats on the Board.

The currently appointed Chairman (me) is an openSUSE contributor for 10 years, a lot longer than I've been a SUSE employee, and previously an elected Board member, so I'm afraid I don't think I would qualify for any standing in the Open Source Evil Corporate Dictator rankings.

Besides that one guaranteed position on openSUSE's Board, SUSE have no direct 'levers of power' over the openSUSE Project. There's no Steering groups, Managers in charge, or other roles imposed on the openSUSE Project.
No role in the Project is restricted to ONLY SUSE employees. SUSE employees are peers in the openSUSE Project, contributing on equal footing as everyone else, with no automatic or additional standing or power over non-SUSE contributors.
Sure, there's lots of very important roles which SUSE employees currently do a lot of the heavy lifting in openSUSE, but it's often out of necessity and it's never done in a way to exclude others from contributing (in fact, often quite the opposite, with lots of time spent trying to encourage others to join in.. eg http://yast.github.io/contributing.html )

We now have a proud history of the openSUSE community leading in directions which differ from SUSE's, for example, the fact that openSUSE has KDE as it's default desktop (and half a dozen other desktops as well) when SUSE only ship GNOME in their Enterprise distribution.

Hope this clears up a few misconceptions out there :)

Rebasing openSUSE

johannbg — Sun, 28 Jun 2015 10:09:43 +0000

Or Suse stop putting any effort into OpenSuse and put all it's effort into Fedora since Red Hat employees seem to be claiming that Red Hat maintains 70% of what makes up (open)Suse distribution already ( Atleast that's one of Red Hat's sales pitch over Suse ).

Arguably all rpm based community driven distribution should be merged into one since those distributions are more or less just separated on a philosophical level. ( That is if you want to be pragmatic about this things but in reality that's not going to happen.)

Today after have spent 8 years or so of my life contributing to Fedora under the assumption that it actually was a community driven distribution ( which it's not ) I explain to users when asked if they should install it, how Red Hat operates and misuses it, that they can expect that Suse does same or similar things with OpenSuse ( And Canonical with Ubuntu ) and if they intend on contributing back, their volunteering time would be best spent being contributed to Mageia ( or Debian ) since it's genuinely driven by an community or they should contribute directly upstream.

Rebasing openSUSE

rahulsundaram — Sat, 27 Jun 2015 19:36:27 +0000

I would be very wary of equating any collection of ip address stats with number of users. Fedora explicitly doesn't do that. Community distributions just cannot claim any specific number of users. If you have a per system subscription model, you can accurately judge the number of subscriptions but any one system could be serving multiple users.

Rebasing openSUSE

einar — Sat, 27 Jun 2015 19:28:03 +0000

As an openSUSE contributor (volounteer), I find such statements borderline offensive...

Rebasing openSUSE

jospoortvliet — Sat, 27 Jun 2015 18:58:37 +0000

It has been a few years, but the last time there were comparable statistics between openSUSE and fedora, openSUSE had three times the users. Does that mean fedora should stop and RH should put its efforts in openSUSE?

Rebasing openSUSE

jschrod — Sat, 27 Jun 2015 11:35:05 +0000

> Of the numerous Linux-based customers we have, most of which are in the UK, Italy,
> Germany, France, etc, exactly zero use OpenSUSE. Most use Debian, RHEL or CentOS.

Well, I wouldn't expect a company to use openSUSE; I would expect them to use SLES. Just as I wouldn't expect them to use Fedora.

Our customers in finance use RHEL, SLES is more found at our customers in public service and logistics. Nobody uses Debian, support contracts are hard to come by. If OpenSUSE is used, it's at the admin workstation of somebody who looks after their SLES servers. Thus, empiric experience can be different. ;-) It probably depends very much on the business area and the company's context.

Rebasing openSUSE

johannbg — Fri, 26 Jun 2015 12:15:22 +0000

Here in Iceland there are way more Fedora users then Opensuse ones however the most used distros are Debian,Ubuntu,Linux Mint ( followed by Arch on an fast uptake at the expense of Fedora ) on desktops with CentOS on servers

Ironically I have met with both RHEL representatives as well as an Suse "Territory Manager", both coming from Denmark, both where completely out of sync with what has been happening in the upstream distributions they base their distribution on ( Fedora/OpenSuse ) and what's happening in the Linux ecosystem general. The RHEL representative was just bragging how RH builts and maintaines 70% packages that make up the Suse distribution and the Suse one was just praising and preaching Suse on power ( which on these parts most people just stick with AIX on power ).

Debian,Ubuntu has starting getting closer to take the lead on the server market over CentOS and RHEL due to be the favourite distribution among uni students as well as those so called partners Red Hat has here have been announcing courses for the past two years but cancelling them each and everytime leaving the existing RHCSA+ stuck certified on their previous release < 6 ( With Red Hat now suddenly removing it's certification from certified individual if the RHEL distro has EOLed, sucks to be you if you where certified on RHEL < 4 *puff* your certification history has been wiped out of existence. Red Hat should give those that handle those courses and training materal the certification of ignorance for that decision ) with people/companies dropping RHEL and moving to CentOS completely or to Debian/Ubuntu instead.

At one point we thought about partnering up ourselves as well as start holding those training courses to compete with that company they are partnered with but then we looked at how Red Hat setup their partner program as well as their training part and laughed ourselves shitless and amazed ourselves that companies actually participated in their partner program ( you are literally pouring money down the drain with little to no return of that investment ) and after I left the Fedora project and explained to the upper management how Red Hat operated there was not even a point of bothering with it for the sake of competition and ( small ) market share.

Here Suse lost all the foothold they had when they "partnered" with M$ back in the day ( they where head to head with Red Hat, with market shares at that time ) and has not recovered since.

I would expect that the only solid foothold (Open)Suse has in EU is in Germany.

Rebasing openSUSE

ringerc — Fri, 26 Jun 2015 09:01:28 +0000

Australia, actually, but I work for a UK/EU company.

Of the numerous Linux-based customers we have, most of which are in the UK, Italy, Germany, France, etc, exactly zero use OpenSUSE. Most use Debian, RHEL or CentOS.

Perhaps that's just bad luck, or perhaps it's to do with people who use PostgreSQL too.

Rebasing openSUSE

niner — Fri, 26 Jun 2015 08:41:48 +0000

From a European perspective, one has to wonder if Fedora may even be counted as one of the major distributions.

Rebasing openSUSE

jschrod — Thu, 25 Jun 2015 21:57:28 +0000

> The only thing I've ever found remotely interesting about OpenSUSE or SLES has been its IBM System Z support.

OBS?!
YAST?!
Balance between going forward (Fedora) and being rusty (Debian), without introducing stuff like Unity (Ubuntu)?

From a European perspective, (open)SUSE *is* on of the major distributions. If you live in the US, you might see it differently -- but, if that's the case, that would be rather insular.

Rebasing openSUSE

johannbg — Thu, 25 Jun 2015 08:04:23 +0000

The sole purpose of Fedora Server WG is to push for early adoption of Red Hat's cockpit project and expectation of each WG having their own lifecycle will never happen since a) The individuals pushing for the changed distribution model to match Red Hat business model did not take that into account when thinking of it b) The ( shared ) Fedora infrastructure is not capable of sustaining such model ( in it's current form ) and c) Last but not least the maintainers wont be accepting adding that additional maintenance load upon themselves ( at least that was the feedback I got when I served on the ServerWG and asked several maintainers about LTS )

Yeah sure Red Hat could twist their employees arm and force them to do so for the components they control in the distribution but that will move Fedora back into core vs rest ( or Red Hat vs Community ) model which those Red Hat employees driving the WG effort have claimed they are not doing or trying to do.

Arguably the entire concept of LTS is outdated altogether or at least out of place with ( allegedly ) community driven distributions such as Fedora.

Rebasing openSUSE

ESRI — Wed, 24 Jun 2015 15:33:14 +0000

Are you aware of the Fedora Server initiative? I've lost track of what their lifecycle goals are, but remember that at least initially, providing something a bit less glacial than EL but more stable than Fedora was their goal...

Rebasing openSUSE

niner — Mon, 22 Jun 2015 16:17:56 +0000

If you really need the latest kernel, you can use the Kernel:HEAD repository: http://download.opensuse.org/repositories/Kernel:/HEAD/st...

Currently featuring 4.1-rc8 but will be updated within days of a kernel (-rc) release.
On a side note: I've been running these rc kernels for years now, updating frequently and only have run into very few and minor issues.

Rebasing openSUSE

rakoenig — Mon, 22 Jun 2015 13:15:44 +0000

Thank you for the article Jonathan. So if I understand it correctly we will have that Tumbleweed thing which is a rolling release, but what about the future of the openSUSE distribution as we know it? Last week I was looking desperately for some roadmap that gives me an idea when to excpect openSUSE 13.3 (or 42) or whatwver, but I couldn't find any on their web pages. Without your article I wouldn't even have found the pages about Tumbleweed, there is no hint when looking on opensuse.org.

What I'm also missing is a sort of version information for core components like the kernel. Ok, if I look at http://download.opensuse.org/tumbleweed/repo/oss I can see the version, but I would really like to have an idea on when to expect a version with a specific kernel version. Background of this is that I'm currently testing Intel Skylake hardware and not even the 4.1 kernel that was released today is fully supporting it, there are still patches missing that I only find in the drm-intel-nightly builds from freedesktop.org. So I guess full Skylake support will have to wait until kernel 4.2, but hardware will be available for order whenever Intel launches the platform. And then users that want to buy new Skylake hardware will run into trouble if there is no distribution that has a kernel (or driver updates) that support this hardware.

Rebasing openSUSE

Xiol — Mon, 22 Jun 2015 11:58:31 +0000

OpenSUSE / SLES is very popular in Europe, especially Germany. Many more people use it than you realise.

Rebasing openSUSE

lmb — Mon, 22 Jun 2015 08:25:29 +0000

It's not so much a question of what is missing technically. (That's mainly updated packages in some areas, and I'm trying to make progress on the HA and Ceph packages there.) It's also a question of positioning and where the openSUSE Community puts their efforts. With the move to Tumbleweed, I personally I would have decided to abandon the "stable" releases. And not created something like 42.

Rebasing openSUSE

miska — Mon, 22 Jun 2015 05:05:20 +0000

Well, Tumbleweed is meant to be latest and greatest but despite of that, it is heavily tested although automatically. If you are missing some test, all of them are on github and for continuous deployment, zypper dup works. I'm personally using Tumbleweed on my server without any problems. But I would be interested in hearing what do you think is missing. Doing heavy manual testing is not feasible, automatic one is there, tooling - I don't see anything missing, but might be that you have some special requirements.

Rebasing openSUSE

miska — Mon, 22 Jun 2015 04:40:37 +0000

Like openSUSE :-P

Rebasing openSUSE

miska — Mon, 22 Jun 2015 04:39:27 +0000

As mentioned on cited mailing list, SLE kernel 3.12 is heavily patched with quite some features and mainly HW support backported, so although version number is lower, in some areas it might even have more features than 3.16.

Rebasing openSUSE

rahulsundaram — Sun, 21 Jun 2015 19:31:08 +0000

That is what openSUSE is doing. There will be no more stable releases of openSUSE in its current form.

Rebasing openSUSE

dowdle — Sun, 21 Jun 2015 13:21:24 +0000

"lose"? Who said anything about losing anything?

Rebasing openSUSE

niner — Sun, 21 Jun 2015 13:09:29 +0000

What about stopping trolling and actually helping work on one of the distributions?

LWN.net is one of the very few places on the internet where the comments are actually worth reading. Please keep it that way.

Rebasing openSUSE

eru — Sun, 21 Jun 2015 08:38:43 +0000

One openSUSE advantage is yast, which provides consistent gui for system management in a desktop-agnostic way. It still has even a text menu front-end which other big distros have dropped.

Rebasing openSUSE

raven667 — Sun, 21 Jun 2015 07:17:24 +0000

Actually come to think of it that sounds kind of awesome.

Rebasing openSUSE

ringerc — Sun, 21 Jun 2015 06:48:02 +0000

I tend to agree - "we" as a community waste such massive efforts on duplicating things.

The only thing I've ever found remotely interesting about OpenSUSE or SLES has been its IBM System Z support. Fedora/RHEL, Debian and Ubuntu do the job just fine.

(For that matter, I'd love to see just a single package manager too...)

Rebasing openSUSE

rahulsundaram — Sun, 21 Jun 2015 01:13:10 +0000

Would you prefer to lose the Fedora regular releases in favor of CentOS + some updates and a more regulated Rawhide?