OpenSuse’s great leap backward

Also in today’s open source roundup: Linux Mint 18.2 will be code named Sonya, and a long term review of the Google Pixel phone

back flip jump cloud
Rory3822 (CC0)

OpenSuse’s great leap backward

OpenSuse has been around for quite a long time, and it’s one of the better known Linux distributions. But recently there’s been quite a controversy brewing over OpenSuse’s change in version numbers. A writer at delved into the controversy and had some interesting thoughts to share.

Note: is a subscription site but this article is free to read thanks to a subscriber. You can get a free one month trial subscription to

Jonathan Corbet reports for

…the discussion around the version number for the next major OpenSuse Leap release has gone on for hundreds of sometimes vitriolic messages. While this change is controversial, the OpenSuse board hopes that it will lead to more rational versioning in the long term — but the world has a way of interfering with such plans.

OpenSuse Leap is an interesting hybrid distribution; its core packages come from the slow-and-stable Suse Linux Enterprise (SLE) release, but those packages are replaced or supplemented by much newer software where desired. The current (and only) OpenSuse Leap release was originally based on SLE 12 and OpenSuse 13.1. The project had an immediate problem in that it needed to come up with a version number for this new distribution; in the end, it did what any of us would have done and chose 42. The current release is OpenSuse Leap 42.2.

Eventually even an enterprise distribution gets around to a new major release; that is expected to happen with SLE sometime in 2018. A new SLE release will have a new version number, of course. The working expectation on the OpenSuse side was that the next SLE would be SLE 13, and that OpenSuse leap would, continuing with the SLE+30 formula, release OpenSuse Leap 43 based on that release.

But, as OpenSuse board chair Richard Brown recently noted, plans can change. In its wisdom, Suse management decided that the next SLE release would not be SLE 13; it seems that SLE 15 has greater market appeal. The reasons behind the decision have not escaped the smoke-filled room in which it was made, but it has been speculated that the purpose was to avoid the number 13, which is seen as being unlucky in many parts. Similarly, 14 contains a 4, an ill-starred number in parts of Asia, so it was out of the running. 15, being a triangular, hexagonal, and pentatope number (among other things), was the obvious choice.

More at

The article at caught the attention of Linux redditors and they shared their thoughts about OpenSuse’s great leap backward:

Minimim: “This article is a riot, but if I may talk seriously about it for a second, this problem of version numbers going backwards happens often enough that Debian has created a mechanism to deal with it.”

MixedCase: “Found the same in Arch the other day: a variable called "epoch" in each PKGBUILD that defaults to 0. If openSuSE was a package, its epoch would be bumped by 1 (by convention) and its version changed from 42.2 to 15, and it will be properly recognized as a newer version by pacman.”

Cbmuser: “Maintainers try to avoid epochs these days because you will never ever get rid of them again. Thus, for minor mistakes version numbers like "1.7.1really1.6.5-2" are more popular than epochs as after 1.7.2 or newer is released in this case, you can go back to normal versioning.”

Pdp10: “For a moment I was worried that we might have a backward leap-second on our hands. That would be a problematic situation unless smeared. Given known geophysics, we're unlikely to have to worry about it, though.

New versions of the network time protocol NTP have incorporated a field advising of a leap-second, so that machines don't necessarily need to update their tzdata to find this out and stay in sync. It seems like the Suse online package managers could communicate version leaps in a similar way. ;)”

Introvertedtwit: “Serious question amid this arithmophobia: One of the things I thought Canonical got right was the way it uses version numbers which are based on release dates, but it doesn't seem very widespread. Since version numbers are largely arbitrary or even invisible anyways, why not use a system that completely avoids this kind of issue?”

142Staircases: “Ubuntu's system works well with regularly scheduled releases, but I imagine would get messy if there are multiple releases per month, or even just an inconsistent release schedule.”

Pinkunicornsftw69: “I can't wait for marketing minded devs at debian deciding that stretch should be renumbered to debian 69.”

Barkappara: “I literally laughed out loud for most of the piece. Thanks for writing this :-)”

More at Reddit

Linux Mint 18.2 will be code named Sonya

The Linux Mint developers are hard at work on their upcoming releases. Version 18.2 will be code named Sonya, and the choice of the name is in remembrance of the wife of one of the Linux Mint developers.

Clem reports on the Linux Mint Blog:

Linux Mint 18.2 will also have a very meaningful codename and a special place in the heart of one of our developers.

I would like to address my support and my deepest sympathy to Michael Webster, one of our friends within the development team, for the loss of his wife Sonya.

I can’t think of anything more painful than losing a loved one. We feel a lot of fraternity and sadness after what happened.

It is an honor for us to be able to commemorate her name.

Farewell Sonya and to you Michael, it is a real pleasure and privilege to be developing with you. I hope you do well.

More at Linux Mint Blog

A long term review of the Google Pixel phone

The Google Pixel phone has been out for a while now, and a writer at Android Police recently did a very interesting long term review. Is the Google Pixel worth buying? Not exactly according to the reviewer.

David Ruddock reports for Android Police:

In the nearly seven years I've been doing this, I have never used an Android phone that has held up so well to the tortures of time. The Pixel XL feels nearly as smooth as the day I began using it six months ago. Android glides along with best-in-class touch latency and a responsiveness that feels immediate (if not manic) and satisfying. It's not just performance, either. My battery life remains largely predictable, too, and largely very good. The camera continues to impress with its swift launches and ease of use, and it produces the most consistently excellent results of any smartphone camera I have ever used. HDR+ is easily, for me, the best smartphone camera feature out there. Oh, and even if the fingerprint scanner is a bit slow compared to some, at least the damn thing is easy to reach and reads consistently.

Is the XL worth $770 to pick up today? I don't really think so, let alone $870 for the 128GB version we all actually want. And honestly, I have a hard time seeing the point of the smaller 5" model at $650 right now, that just feels like lunacy. The XL offers better battery life and is far from "big phone" status in terms of actual usability - it's really the only one of the two that warrants consideration, in my opinion. With that, let's dive in to the details.

…for all its problems and limited availability, the last six months I've used the Pixel have utterly proven to me that Google is capable of building a smartphone that, from a user experience standpoint, rises above the competition. Google's unmatched ability to optimize the way Android and the underlying phone parts interact is very much a reason I love this phone so much. A smartphone should get out of its own way when you use it - it should be an effortless canvas upon which your fingers and eyes naturally engage and interact. That means it should be fast. It should be consistent. And it should just feel right to use. I know that some of these things don't really translate well into concrete assessments, but there's something about the Pixel that really just works for me so well. It's as close to my ideal smartphone as I've ever been.

I'm hoping that Google smoothes over some of the rough edges not just with the phone, but with the whole experience of buying and owning it. Why is is to hard to buy a Pixel? It's positively ridiculous just how bad Google has been at keeping this phone in stock. I also think it's hard to ignore that in 2017, the Pixel's design language and overall look and feel are clearly behind the competition. This looks like yesterday's smartphone, and even on the day it was announced it was kind of hard to really fall in love with in an aesthetic sense. At best, it's just kind of boring.

More at Android Police

Did you miss a roundup? Check the Eye On Open home page to get caught up with the latest news about open source and Linux.

Copyright © 2017 IDG Communications, Inc.

How to choose a low-code development platform