Not convinced by rolling releases | Hacker News Reader

Not convinced by rolling releases

markshuttleworth.com

49 pointspavs20 comments

There's a middle ground that's kind of lost in this argument: create a 'rolling' distribution and cut-and-stabilize LTS releases from it. This is kind of how I treat 'testing' in Debian and I've only seen a problem once in 5 years. If you want stability and consistency, use an LTS release. If you want more recent software, use the 'rolling' release. While this is mentioned in TFA ("edge"), it's glossed over.

Just to echo this, I do much the same with Slackware. I use -current on some machines. Every time a release is pending, work on -current slows down (or does it ramp up?) and it is stablised.

It's essentially a development release rather than being explicitly labelled "rolling" (and, in fact, its use as a day-to-day distribution is generally considered A Bad Thing if you're not a Slackware developer/tester). It just happens to have the bonus of also being a pretty bleeding-edge, yet stable rolling release.

So, it's possible to achieve both a rolling release and "stable", versioned releases.

Slackware-current is basically as stable as Fedora is at any given time so it's hard to really discourage its use.

Honestly, Slackware is almost a RHEL/Fedora type ecosystem when just taking about official packages. Slackware-current gets new stuff, Slackware releases only get bug fixes, and not too many of them at that.

I'm not sure I agree with that comparison. Slackware-current will become the next stable release once all of the kinks have been worked out. Is RHEL ever really a snapshot of Fedora?

> Is RHEL ever really a snapshot of Fedora?

Basically yes, Fedora is Red Hat getting free testing of features and when it's time to create a new RHEL release, they grab a Fedora release, set it in stone and work from that.

http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux

Red Hat Linux 6.2 → Red Hat Linux 6.2E

Red Hat Linux 7.2 → Red Hat Enterprise Linux 2.1

Red Hat Linux 10 beta 1 → Red Hat Enterprise Linux 3

Fedora Core 3 → Red Hat Enterprise Linux 4

Fedora Core 6 → Red Hat Enterprise Linux 5

Fedora 12, 13 → Red Hat Enterprise Linux 6

From the same article:

RHEL trees are forked off the Fedora repository, and released after a substantial stabilization and quality assurance effort.

Which adds a quote from the Fedora Project:

Red Hat Enterprise Linux is a commercial enterprise operating system and has its own set of test phases including alpha and beta releases which are separate and distinct from Fedora development.

And on that page[1] it states that RHEL6 is based on a "Mix of Fedora 12 Fedora 13 and several modifications".

Sorry to be pedantic, but that's significantly different than the Slackware model. Maybe it's just PTSD; I fled from RH in the old days onto the path that led to Slackware, so any comparison makes me touchy.

[1] https://fedoraproject.org/wiki/Red_Hat_Enterprise_Linux?rd=R...

Most of it made sense until:

    But if we want to get beyond being a platform for
    hobbyists, we need to accelerate the work on Unity to 
    keep up with Android, Chrome, Windows and Apple. And 
    that’s more important than taking care of the needs of 
    those who don’t share our goal of a free software norm.

Who is he talking about there? Aren't many of the complaints coming from people who are thinking that Ubuntu's heading towards a less free(dom) direction?

Probably about those dissatisfied that Canonical develops its own DE (and now its own X replacement) instead of developing on top of what's out there and with the rest of the community. They just don't wait for the rest and do what they feel is appropriate for the popularity of Ubuntu (and therefore Linux). If one likes it or not basically depends on one's political stance on this issue.

> They just don't wait for the rest and do what they feel is appropriate for the popularity of Ubuntu (and therefore Linux)

The word "Linux" doesn't even appear anywhere on their home page [1] or "About Ubuntu" page [2]. "GNU" probably never did and "free" appears only in the "cheaper than Windows" context.

Nowadays Canonical basically takes a bunch of community and FSF projects, patches them internally to their liking and ships with custom frontend without giving much credit to the original authors. "Developed by the amazing Ubuntu community of open source experts".

They are as much about promotion of Linux and FOSS as Apple is about promotion of BSD Unix. Please stop spreading disinformation.

[1] http://www.ubuntu.com/

[2] http://www.ubuntu.com/ubuntu

> They are as much about promotion of Linux and FOSS as Apple is about promotion of BSD Unix.

strawman. I said popularity, not promotion.

> Canonical basically takes a bunch of community and FSF projects, patches them internally to their liking and ships with custom

just like most devs take a bunch of opensource projects, customize them, and ship them to their customers, only for money? that's the nature of the license - other people can use it these ways. it's annoying when bypassers are more concerned and noisy about this than said parties.

> Please stop spreading disinformation.

as I said, it's political. let's agree to disagree.

sent from my debian.

I think he's talking about the "I have Ubuntu set up in some obscure configuration exactly the way I like it, now please never break anything" people. The "leet" users. For every leet hacker he sacrifices, Shuttleworth is expecting to gain 10 normal users.

Heh, I fall somewhere into that group in that I think Unity is terrible. That said, I do basically agree with most everything that he says in the article. No one is ever going to get exactly what they want in a project as large as Ubuntu. That's why there's Mint :D

Time will tell whether the Unity gamble was worth it. Personally I don't think they will be able to keep up with Apple/Android/Microsoft in Mobile, but I thought those companies were leaving a bit of a void in the PC power user field that Ubuntu could have run wild in. We'll see if he's right, but I think ubuntu will only ever grab the 'hobbyists' in the mobile market, his dreams of major market-share across PC/mobile/tablet are pipe-dreams IMO. And for each person like me that moves on, I just don't see there being 10 others that will now fill in behind me.

Nice piece by Mark. As someone who is used to "version" I too am somewhat off put by the rolling release concept. My challenge is how to say what is true, for example this javascript will run in Chrome for all Chrome > build xyz? It was simpler (not saying better, just simpler) to V2.5 or later supports this.

>for example this javascript will run in Chrome for all Chrome > build xyz? It was simpler (not saying better, just simpler) to V2.5 or later supports this

On a related note, a few years ago I went from assigning version numbers to the releases of some of my projects to simple date-based versions (e.g., "version 20130307"). One of the reasons I switched to using dates is that beyond v1.0 it's often hard to assign versions to software in a meaningful fashion (is our next release a "v3.0" or a "v2.1"?); that is especially true if your software isn't of the commercial variety where a major version increase hinges on the question of "is this substantially different to charge an upgrade fee of $N for?". One exception to this naming rule is that I assign low numerical versions (e.g., "v0.03") to early code to indicate its quality.

What would you say about this practice vs. build numbers or traditional version numbers?

Edit: To clarify, I don't think this alone constitutes going rolling release.

Overall, I found it pleasant to not have to think about version numbering. Release dates also seem to be easier to remember and interpret than mere build numbers (a half-forgotten date like "201207..." is easier to pin down than "build 12573... something")

Use http://semver.org/ it provide clear semantics on how to increase version numbers.

Well, I've grown up with semantic version numbers. In those there was a document somewhere that described exactly what the version numbers "meant" in terms of compatibility. So

Major.minor,sub-minor

was the most common, the policy there was :

* major number change, may have incompatible changes with APIs. Applications depending on a major number won't be compatible with the previous version of the library.

* minor number change, changes by 'addition' only, no changes to existing code necessary, backward compatibility testing advised.

* sub-minor number change. No semantic changes, bugs and other defects fixed, some workarounds may no longer be needed.

With rolling releases it seems the only safe thing you can assume is that no earlier release is compatible and later releases are probably compatible. That seems like a step backward.

>> If you’ve done what you want for Ubuntu, then move on. That’s normal – there’s no need to poison the well behind you just because you want to try something else.

If only we could apply that to everything we use.

"Comments are closed."

The mailing list thread is better suited for discussion.

https://lists.ubuntu.com/archives/ubuntu-devel/2013-February...

Ubuntu in a nutshell.

Reply on news.ycombinator.com