Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

OpenSUSE To Offer a Rolling Release Repository

timothy posted more than 3 years ago | from the distinguish-from-nightly-builds dept.

SuSE 72

dkd903 writes "While the rumors of Ubuntu moving to a rolling release have been brought to a halt, another major Linux distribution is looking to provide a rolling release. In a message to the opensuse-project mailing list, openSUSE developer Greg Kroah-Hartman announced a new project – openSUSE Tumbleweed. OpenSUSE Tumbleweed will provide a rolling release for those openSUSE users who wishes to have a rolling release. It will essentially be a repo containing the latest stable versions of the applications."

cancel ×

72 comments

Sorry! There are no comments related to the filter you selected.

Linux Mint Debian (3, Informative)

future assassin (639396) | more than 3 years ago | (#34444868)

For those who want a Debian based distro Linux Mint Debian will be a rolling release. http://blog.linuxmint.com/?p=1527 [linuxmint.com]

Re:Linux Mint Debian (1)

0100010001010011 (652467) | more than 3 years ago | (#34445328)

What's wrong with "Debian"?

Re:Linux Mint Debian (1)

RotateLeftByte (797477) | more than 3 years ago | (#34445426)

nowt, if debian is your thing. For me? nope. I don't get along with it but many of my friends do. A lot of them have returned to the Debian fold after dabbling with Ubuntu and they've decided that they don't like the way Canonical is going. But that is decidedly off topic.

I'm firmly in the Fedora/RHEL/CentOS Camp. Mainly because all the commercial S/W I use in my day job just works on RHEL/CentOS and can be made to work on Fedora with a little effort. But hey, choice is what FOSS is all about.

Re:Linux Mint Debian (1)

aztracker1 (702135) | more than 3 years ago | (#34445432)

Figuring out which download to actually get for the current rolling ("unstable") since it isn't marked as (Beta|Edge|Unstable), it's marked as sid? (I don't even know what the right one is now)... then the installer itself is a PITA without any good walkthroughs on getting it up and running in the first place... then there's figuring out which packages are needed for even a fairly stock Gnome desktop.... Don't get me wrong, I'd love to run straight Debian over Ubuntu, or Mint... just too many hoops to jump through before you even get to a working desktop. I don't mind hiccups after at a workable OS, usually there's people actively working on the problem... Nobody seems to be working on improving the download process on the Debian website (If I had someone to answer those first questions, and access, I could help with this), or improving the installer...

Re:Linux Mint Debian (1)

dbcad7 (771464) | more than 3 years ago | (#34445702)

Not sure what your talking about.. go here.. http://distrowatch.com/table.php?distribution=debian [distrowatch.com] newest to the left.. oldest to the right.. I haven't found Debian any more difficult to install than Ubuntu.. but that's me. For a day to day system, testing has usually been very good.. unstable ?.. well the name says it all.. I know lots of people like to live on that edge, but I prefer not to... All that said, I do like Debian, but I haven't used it as my main OS for awhile.. not because of the difficulties you had, but mostly because of the whole Firefox thing.. Debian had Iceweasel, and it was giving me too much greif.. and that's why I switched.. It's probably all sorted out now.. I'll probably get a wild hair again someday to redo my OS, and I'll probably go back to Debian first.. but for now, am just plugging happily away in Xubuntu.

Re:Linux Mint Debian (1)

aztracker1 (702135) | more than 3 years ago | (#34457466)

Okay, so my first mistake was going to the debian website to download debian? I guess testin is what I want, not unstable, my bad... Again, clearly defining which version to grab, and how to partition your drive, should be a big focus on the debian site, it isn't... it isn't clear to a debian noob at all, and your reply really drives this point home.

Re:Linux Mint Debian (1)

dbcad7 (771464) | more than 3 years ago | (#34466686)

http://www.debian.org/releases/stable/i386/apas03.html.en [debian.org] ... If you'll also notice on the distrowatch link.. the default desktop is Gnome you don't really have to do much as far as selecting packages, it will install it. Partitioning can be intimidating for "noobs", but that is the same thing you face with Windows.. If you notice in the Install instructions above there is auto partitioning as well.

Re:Linux Mint Debian (0)

Anonymous Coward | more than 3 years ago | (#34445780)

I thought it was apt-get install gnome-desktop... :/

Re:Linux Mint Debian (1)

GPLHost-Thomas (1330431) | more than 3 years ago | (#34447948)

On the installer simply tick:
[ * ] Desktop environment

If the computer is already installed, do "apt-get install gnome" and everything is installed. What's so fu*king hard here?

Re:Linux Mint Debian (1)

aztracker1 (702135) | more than 3 years ago | (#34457492)

Fair enough... my far greater issue is even figuring out the right version to get, which is where their website fails first and foremost, before getting that far.

Re:Linux Mint Debian (1)

Raenex (947668) | more than 3 years ago | (#34450148)

Figuring out which download to actually get for the current rolling ("unstable")

Debian Testing is the "rolling" release. That's what Linux Mint is based on -- which is just Testing with a different installer thrown on top. Unstable is free to break shit, so it's not going to be used as a basis for a desktop distribution with any assurance of quality control.

Re:Linux Mint Debian (1)

aztracker1 (702135) | more than 3 years ago | (#34457478)

Again, the point is even determining that... from the debian website' homepage, where would I click to find that out?

Re:Linux Mint Debian (1)

future assassin (639396) | more than 3 years ago | (#34445816)

Nothing but whats wrong with say Mint Debian with a nice graphical install and improvements for non power users who just want a nice system ready to go.

11 years ago I could sit there for hours at a time trying to figure out how to set up partitions/apache/mysql on Slackware/Debian for a home server, these days I don't have that luxury and I want somethings to be done for me.

Re:Linux Mint Debian (1)

dirkdodgers (1642627) | more than 3 years ago | (#34448352)

I recommend giving Debian a try again next time you're setting up a server since it sounds like you may not have in a while. Of the items you mention, there is now a graphical installer, the installer will produce a sane partitioning scheme for you if you don't want to override the defaults, and apache/mysql setup is straightforward unless you're talking about a distribution-specific configuration GUI.

Re:Linux Mint Debian (0)

Anonymous Coward | more than 3 years ago | (#34445506)

Hate to break the news to you, but Debian is already rolling release.

Re:Linux Mint Debian (0)

Anonymous Coward | more than 3 years ago | (#34450012)

"Hate to break the news to you, but Debian is already rolling release."

No, it isnt'.

Debian produces one product: "Debian Stable" and in order to produce it, it uses some developing tools, like "Debian Testing" and "Debian Unstable".

Maybe you can consider "Debian Unstable" being a rolling release, but "Debian Unstable" is not "Debian" but a tool that Debian uses to develop its product, "Debian Stable" which is *not* a rolling release.

A certain irony. (-1, Troll)

James_Duncan8181 (588316) | more than 3 years ago | (#34444890)

There is a certain irony in SUSE calling a repository tumbleweed, given their recent market share stats.

Re:A certain irony. (3, Insightful)

Ash-Fox (726320) | more than 3 years ago | (#34445098)

There is a certain irony in SUSE calling a repository tumbleweed, given their recent market share stats.

Please provide reliable market share statistics, I can't find any.

Re:A certain irony. (4, Informative)

rubycodez (864176) | more than 3 years ago | (#34445488)

any stats will be very rough estimates and completely depend on what B.S. methodology you wish to use. I took distrowatches distro popularity page, took the top 23 which included everything I care about, and normalized Ubuntu 10%
Mint 8.6
Fedora 8.6
openSUSE 6.7
Debian 6.4
Sabayon 5.1
PCLinuxOS 4.3
Arch 4.1
Ultimate 3.5
CentOS 3.5
Puppy 3.5
Mandriva 3.2
MEPIS 3.1
Red Hat 3.0
Unity 2.8
Slackware 2.8
Chakra 2.7
Macpup 2.6
Tiny Core 2.5
Pinguy 2.4
BackTrack 2.2
FreeBSD 2.2
Gentoo 2.1

Re:A certain irony. (3, Informative)

rubycodez (864176) | more than 3 years ago | (#34445502)

should have mentioned that's hit for last month (not the 12 month column they also have), and kept the FreeBSD in there for relative comparison purposes, since I care about BSD though not that particular one.

Re:A certain irony. (1)

Ash-Fox (726320) | more than 3 years ago | (#34450002)

any stats will be very rough estimates and completely depend on what B.S. methodology you wish to use. I took distrowatches distro popularity page, took the top 23 which included everything I care about, and normalized Ubuntu 10%

Honestly, the method distrowatch uses is hardly accurate or representitive of marketshare:

It is a light-hearted way of looking at popularity of distribution. Since each distribution has its own page, I though it would be fun to track the number of visitors viewing individual distribution pages. The HPD figure represents hits per day by unique visitors; as determined by the visitor's IP address. This prevents those readers, not disciplined enough, from rigging the results by re-loading the pages multiple times. The idea is to identify which distributions attract most attention and to rank them accordingly. Admittedly, the page clicks by themselves may not always reflect the popularity correctly, but they should, over time, provide an indication about what is hot among the readers frequenting these pages.

Re:A certain irony. (1)

rubycodez (864176) | more than 3 years ago | (#34454594)

well, that "B.S." I referred to sure doesn't stand for Bona Fide Scientific. It stands for very expensive high quality cattle feed, after it's been processed by the bull.

Excellent idea (4, Interesting)

msobkow (48369) | more than 3 years ago | (#34444892)

What I like about rolling releases is you get to deal with application incompatabilities one at a time as they come up, rather than having to spend a week or few all at once when upgrading a distro.

I think it's also probably better for security, as you get the latest patches for the software. (I know the security patches get applied to downlevel releases as well by distributors, but that seems so cumbersome compared to following the application's software releases.)

Re:Excellent idea (1)

aztracker1 (702135) | more than 3 years ago | (#34445440)

My biggest problem is the handful of things that have to be rebuilt upon a new kernel release (namely VMWare)... It doesn't happen often enough that I always remember the proper command (I think it's vmware-reconfigure.pl)... and happens enough that I remember that I need to do it... especially when my VMs don't come up on my server.

Re:Excellent idea (1)

msobkow (48369) | more than 3 years ago | (#34445840)

I agree, as I have to maintain the production packages of our in-house applications. Dependency checking isn't all it's cracked up to be, at least not yet.

What's needed is a way to register an application for automatic rebuild when one of it's dependencies change.

Re:Excellent idea (0)

Anonymous Coward | more than 3 years ago | (#34451142)

Both the open source and proprietary versions of VirtualBox use DKMS to do this automatically for users, so I would imagine it is possible for others to do so as well.

Re:Excellent idea (0)

Anonymous Coward | more than 3 years ago | (#34445706)

but that seems so cumbersome

Whatever is 'seems' like to you, for the user this is what it amounts to:

# apt-get dist-upgrade
# reboot

The contemporary model secures distro supported software NOW, before exploits appear. Patching stable stuff means distros react quickly because they need to regression test very little. Upstream vendors can't be relied upon and will never be part of this process beyond tossing patches over the fence. Upstream may insist holes be fixed by adopting new major releases regardless to how much delay will be incurred. Users rely on grown-ups employed by distribution vendors to overcome this.

Tumbleweed isn't going to be popular because it doesn't address the problems of the bulk of actual users. Most users want some very limited subset of software at or near the bleeding edge. A developer may need the latest point release of gcc to progress on some application. A hosting service may need a new feature found only in the latest Apache. The other x,000s of packages need to 'just work,' which includes remaining secure by incorporating distro security patches as they appear.

The fact that Tumbleweed won't be popular doesn't mean it's bad or wrong. There is a segment of users to whom it will appeal, and it may be worthwhile for SUSE to attract them. The rest will continue as they do now, supplementing stable distro releases with upstream software either built from source or supplied by third party repositories.

Re:Excellent idea (0)

Anonymous Coward | more than 3 years ago | (#34445860)

Unless you're using an incredibly broken distro, an upgrade should take about half an hour, not a week.

Re:Excellent idea (0)

Anonymous Coward | more than 3 years ago | (#34446528)

Yeah? Tell that to Gentoo users.

Oh, wait....

Re:Excellent idea (1)

turbidostato (878842) | more than 3 years ago | (#34450046)

"What I like about rolling releases is you get to deal with application incompatabilities one at a time as they come up"

Only if you can dedicate time each and every day to support efforts and you can afford not knowing when your system will be down for maintenance. Most people neither can nor want to afford that.

"rather than having to spend a week or few all at once when upgrading a distro."

False disyuntive. My experience with Debian (Woody, Sarge, Etch, Lenny) is that it takes me about four hours to calmly upgrade from one to the next, so it's either taking care of problems each and every day, not knowing when something will break, or about four hours about each two years.

"I think it's also probably better for security, as you get the latest patches for the software."

Almost no developer follows sounded software promotion practices, so you end up with security patches *and* new bugs at the same time. Not to talk about integration-related problems.

Re:Excellent idea (1)

evilviper (135110) | more than 3 years ago | (#34452900)

you get to deal with application incompatabilities one at a time as they come up, rather than having to spend a week or few all at once when upgrading a distro.

Sounds like a complete nightmare to me... Install one server and everything works fine, then install the server next to it the next day, and its broken and wont work... the hell with that!

I know the security patches get applied to downlevel releases as well by distributors, but that seems so cumbersome compared to following the application's software releases.

Wow... so you really WANT to be unable to install a bugfix, because unrelated changes to the package break things? That's utterly insane.

The lack of intelligent responses here must just be because of the weekend. /. Has been getting steadily worse, but I hope it didn't suddenly get this bad...

Greg Kroah-Hartman (1)

Wonko the Sane (25252) | more than 3 years ago | (#34444896)

Just how many distributions does he develop for? He's a openSUSE developer and a Gentoo developer, are there any others?

Re:Greg Kroah-Hartman (1)

Zocalo (252965) | more than 3 years ago | (#34445478)

Isn't this kind of an irrelevant question to ask about most open source developers? Unless they are only working on some very distro specific tools anyway, and even then there's always a chance that it will be used in a fork or derivative distro. You might as well ask how many distros Linus develops for...

What's the fascination with "rolling releases"? (1)

Anonymous Coward | more than 3 years ago | (#34444914)

Seriously. I *like* to know I'm running a specific release that is fixed for a while so that I know what I'm dealing with if I run into problems, and so that if it's working fine I can *stay* on that release for a while. I also prefer not to run a release that is on the bleeding edge.

"Rolling release" looks like a sure recipe for support/dependency hell.

I'm assuming there are some positive reasons for it. What are they?

Re:What's the fascination with "rolling releases"? (2)

bfree (113420) | more than 3 years ago | (#34444976)

Support for new hardware. New features. Easier to contribute to development. Less obsolete versions of software. No need to wait months or years (or resort to compiling) to see stable released improvements on your system.

That's the advantages in it's own right, there's a load more if you start to compare it to the reality of most "stable" distributions. For example, nothing forced in to make some arbitrary freeze, things appear as they are ready.

Too much emphasis on the latest & greatest (1)

RotateLeftByte (797477) | more than 3 years ago | (#34445480)

At the moment, most Linux systems (Apart from embedded) are Servers.
This is ideal for LTS versions. i.e. Ubuntu LTS, RHEL, SLES etc.

My biggest gripe is that producers of apps that are targetted for use on Servers seem to always want the latest & greatest versions of dependent packages such as PHP and not the versions that are supported on LTS Distros.

UH? Why?
A rolling release won't solve this. It will probably make it worse as the stable base provided by SLES/RHEL etc is suddenly not so stable anymore. Now do you know when a server may upgrade from one version of PHP to another? you don't.
At least with a release like RHEL, you know the version of the base platform for each release and that between releases (Eg 5.3 & 5.4) the PHP version won't change apart from bugfixes.

Rolling releases IMHO is a big thumbs down. It's going to give me more problems in the long run. I'm now less likely to go with SUSE than before.

Re:Too much emphasis on the latest & greatest (0)

Anonymous Coward | more than 3 years ago | (#34447380)

RTFA. repo!=distro.

Re:Too much emphasis on the latest & greatest (0)

Anonymous Coward | more than 3 years ago | (#34447858)

Well since you mentioned PHP, things like the inclusion of namespaces and libICU dramatically cut down the amount and complexity of code that we have to support so it makes sense for us to target newer releases. From a commercial POV, we generally get paid for services around the software we write. Support, hosting, customization etc... so usually the version differences aren't an issue. Either it's someone else's problem ( the sysadmin that gets told to 'make it work') or it's running on our infrastructure which has those versions( via a paid support contract with our linux vendor ).

The only people who seem to have a problem with it are j-random users who don't partake in development or the sysadmin who gets told to make it work. If your the sysadmin, I'm sorry. I know packaging is a PITA. We don't do it unless it makes the code better.

If you're j-random user who isn't a developer... sucks to be you.

Re:What's the fascination with "rolling releases"? (3, Interesting)

Anonymous Coward | more than 3 years ago | (#34445504)

> Support for new hardware.

Removal of old, but still used hardware.

> New features.

More unneeded and unwanted API changes.

> Easier to contribute to development.

Harder to develop own applications for a faster movin target.

> Less obsolete versions of software.

More forced upgrades, more forced training costs, less bug fixes for older, but mission critical versions.

> No need to wait months or years to see stable released improvements on your system.

No way to avoid bad "improvements".

All in all, for commercial usage and development, this makes the situation even less predicatble and manageable than it is now. The target now moves even faster.

As somebody else already said, it is crucial for the Linux ecosystem to stop bundling applications and the base systems, and to unpredictably couple application updates to system updates. This unpredictability and instability is killing Linux in the enterprise. It needs a stable, very stable base companies can develop for without fear that they'll obsolete in 5 years or having to adapt to wild unpredictable API changes every 6 months.

Linux software may be "stable" in terems of performance, but it is the exact opposite in terms of development and long term planing, and this is killing it in the industry.

Re:What's the fascination with "rolling releases"? (0)

Anonymous Coward | more than 3 years ago | (#34446044)

If only there were some kind of Linux Standard Base.

Oh, there is one. It just no-one gives a shit about it. It's much more fun to re-write the init system again (sysvinit -> upstart -> systemd).

Re:What's the fascination with "rolling releases"? (1)

Beelzebud (1361137) | more than 3 years ago | (#34446436)

So then don't use a rolling release, if it doesn't suit your needs! Those of us running desktop systems, can still have our fun, right?

Re:What's the fascination with "rolling releases"? (0)

Anonymous Coward | more than 3 years ago | (#34449624)

You'll then have to have your fun without a lot of commercial software offerings, because the too fast moving Linux target is too expensive to develop for in comparison to Windows and OS X. If you want compenies to invest into your patform, make it more stable. If you dont care, you can have your fun, but your platform wont move away from the 1-2% maeket share it has been staying on for 15 years now.

Re:What's the fascination with "rolling releases"? (1)

Kjella (173770) | more than 3 years ago | (#34450038)

Removal of old, but still used hardware.

Not on the time scales we're talking here, if you're doing biannual or rolling releases has very little impact on driver removal. That depends far more on whether the upsteam project (kernel or userspace drivers) are doing API changes and whether there is a maintainer for that driver.

More unneeded and unwanted API changes.

Unless you mean UI changes, people don't work much with APIs. That's more for the next point.

Harder to develop own applications for a faster movin target.

Libraries like Qt, Gtk etc. usually take great care to be backwards compatible.

More forced upgrades, more forced training costs, less bug fixes for older, but mission critical versions.

At least if we compare biannual versus rolling releases you get pretty much only security fixes anyway, I don't think rolling releases are any direct competitor to RHEL/SLES/Ubuntu LTS releases you should use for mission critical applications.

No way to avoid bad "improvements".

It's not easy to pin an old version through a distro version upgrade either.

As somebody else already said, it is crucial for the Linux ecosystem to stop bundling applications and the base systems, and to unpredictably couple application updates to system updates. This unpredictability and instability is killing Linux in the enterprise. It needs a stable, very stable base companies can develop for without fear that they'll obsolete in 5 years or having to adapt to wild unpredictable API changes every 6 months.

It's been a long, long time since I've heard of something like a bad kernel version. The problem is more that application upgrades trigger other application upgrades, not so much the whole system. That actually has the potential to be better with rolling releases or increased availability of backports, not worse.

Linux software may be "stable" in terems of performance, but it is the exact opposite in terms of development and long term planing, and this is killing it in the industry.

All development is unstable. If you're trying to run your business on the most bleeding edge of software, you will suffer. With open source you can go beyond releases into RCs and betas and alphas and experimental code, but you're a fool if you do so and expect stability.

Basically it comes down to this, users have conflicting goals. On the one side, they want to get product fixes and features as soon as they are "ready". At the same time they don't want experimental code that is not "ready". Taking a "snapshot" of all applications and libraries at the same time is the easiest, you just polish it up and call it ready even though you caught them in the middle of a big development cycle. Unstable rolling systems just apply this simple formula often. Rolling stable releases can, if executed well, be better than this. They pick stable versions for each package individually, never taking more or less randomly timed snapshots (at least random relative to the project's development cycle). The downside is that it takes a lot more work to determine the "right" time. They have to deal with libraries making changes where some applications are ready and others aren't. It's more complicated and if done poorly it could turn out worse. But the idea is not bad.

Re:What's the fascination with "rolling releases"? (2)

westyvw (653833) | more than 3 years ago | (#34445002)

Think about the software versions. If it were windows, you could have the latest application as soon as it came out if you wanted to, it isnt tied to the distrobution. Since most people use the packages supplied by thier distro rather than rolling their own, a rolling release means that you can get the newer software while avoiding dependency hell because the package maintainers already took care of that for you.

I kept rolling along with Debian Sid for years, and even though during major changes (such as KDE 3 to 4) it can be trying, it works pretty well. And its fun to get new software on a daily basis.

Re:What's the fascination with "rolling releases"? (2)

ToasterMonkey (467067) | more than 3 years ago | (#34448350)

Think about the software versions. If it were windows, you could have the latest application as soon as it came out if you wanted to, it isnt tied to the distrobution. Since most people use the packages supplied by thier distro rather than rolling their own, a rolling release means that you can get the newer software while avoiding dependency hell because the package maintainers already took care of that for you.

I kept rolling along with Debian Sid for years, and even though during major changes (such as KDE 3 to 4) it can be trying, it works pretty well. And its fun to get new software on a daily basis.

Microsoft achieves that by not attempting to bundle every possible 3rd party software under the sun with their OS. The core Windows software does remain stable for years, with minor changes in service packs and major changes in new releases.

This is something I wish a Linux distro would do. Not rolling the entire damned thing, just get non essential software out of the damned repo. Make a decree that essential software will be included in the base OS, and other can go into the extras bin repo for sake of convenience. Anything in the extras bin can depend only on thing included with the base OS. Install ALL base OS packages by default. Update the base OS once a year. Encourage industry wide minimum, if not exact, software revisions for "Core Linux".

BAM, I FIXED LINUX.

Ok, truth is, we already pretty much have that. Try to install git on CentOS. Your options are Windows, Mac, and Source. Oh.. RPMs hidden over there. But they have dependencies specific to Fedora. While the Windows and Mac installers just work. Git. Try EPEL. Yay, git 1.5, only two minor revisions behind! Why are binary installs so current for Windows and Mac, but not RHEL? The 1.7 source compiles just fine on Cent 5.5. But no RPM. That's just scratching the surface of the problem though. There is no attempt to maintain stable binary compatibility in Linux, and when people try (RedHat) the OSS community craps all over it (GIT, others). "minimum, if not exact, software revisions" MIGHT pass, but it's silly. Just maintain binary compatibility.

Until that happens, there will be no Linux distro with a stable core, and latest non-essentials. Personally, I vote with my wallet, some things are worth paying for, and some clearly aren't - using "free" as an excuse.

The "put _everything_ in the same repo with intertwined dependencies" kludge exists only because someone has taken a strong stance against binary stability, and most the OSS community looks up to him. If better software repositories are worth more to you than compiling crap for fun, there are options outside of Linux.

Re:What's the fascination with "rolling releases"? (0)

Anonymous Coward | more than 3 years ago | (#34451588)

Um, to respond to everybody, including you, with a single response:

IT'S CALLED LSB DIPSHITS!

Re:What's the fascination with "rolling releases"? (1)

evilviper (135110) | more than 3 years ago | (#34452816)

This is something I wish a Linux distro would do. Not rolling the entire damned thing, just get non essential software out of the damned repo.

and that's different from a minimal OS install (that every Linux distro is capable of) how? Its not like the distro guys are trying to FORCE you to use the firefox packages they provide. If you want to get it some harder way, go right ahead.

Anything in the extras bin can depend only on thing included with the base OS.

Now that sounds like a damn nightmare! Do you really mean that you want every KDE application out there packaged with statically compiled libs? Talk about massive and unnecessary bloat...

BAM, I FIXED LINUX.

AFAICT, all you've done is impose the limitations of Windows on Linux, where it's unecessary and senseless.

Oh.. RPMs hidden over there. But they have dependencies specific to Fedora.

That's admittedly bad, but that's entirely the fault of the packager. There are plenty of groups releasing a single RPM and DEB that will work on any release of the OS. It simply takes a bit more work... Your proposal of making packagers work even harder isn't going to fix this, its going to ensure you NEVER see Linux packages provided.

Why are binary installs so current for Windows and Mac, but not RHEL? The 1.7 source compiles just fine on Cent 5.5. But no RPM.

People don't buy RHEL for the sake of getting someone to package the latest software for you... they buy it because it gives you a stable platform where apllications and scripts wont break when one package is updated. AND because RedHat puts a substantial ammount of additional testing and code auditing into what they release.

If you don't want that, and instead want the latest releases as soon as they appear, you should have installed Fedora instead. The fact that you're using CentOS must mean you actually want some of the features you're now advocating getting rid of.

That's just scratching the surface of the problem though. There is no attempt to maintain stable binary compatibility in Linux ... Just maintain binary compatibility.

Binary compatibilty in Linux is pretty good, actually. Its only kernel modules where binary compatibilty is routinely broken. Some kernel interfaces occasionally change, breaking user apps tightly integrated with the kernel, but that's about it, and I see that happen on the order of a decade or so, not often at all... Glibc changes can be taken care of by installing compat packages, and even that's usually only needed because the developer uses some private or deprecated call that's later removed.

I've had to migrate dozens of binary-only programs to work on much newer versions of Linux without significant trouble, and where there are problems, its because of something like the path to X11 fonts or similar changing, which wouldn't be resolved by static compiles.

Have you tried downloading Firefox binaries lately? No? They work fine, despite your above claims. And the fact that you haven't is just proof that even you find using your distros package repo more convenient than doing things the uncontrolled Windows way... Of course I don't hear about antivirus and spyware removal for Linux, so, maybe the Windows way isn't too much of a panacea after all.

Re:What's the fascination with "rolling releases"? (5, Insightful)

Requiem18th (742389) | more than 3 years ago | (#34445116)

I have to admit however that this is an issue of virtually all linux distros.

They confuse system software with user software

Ideally the system software should be fixed for a period to serve as a platform for developers, while user software would be constantly upgraded.

But alas, until this confusion is cleared you have to choose between having a stable platform or updated user software.

Rolling releases make horrible targets for 3rd party developers, specially shrink wrap software vendors.

On the other hand it is not true as you say that you don't know what release you are running or that you can't stay on that release.

When you are on a rolling distro you are effectively staying on a fixed and well know platform known as the current release . That's all you have to know when you ask for help in forums so it's not like you are lost in a limbo.

Re:What's the fascination with "rolling releases"? (1)

Moderator (189749) | more than 3 years ago | (#34445138)

I have to admit however that this is an issue of virtually all linux distros.

They confuse system software with user software

Ideally the system software should be fixed for a period to serve as a platform for developers, while user software would be constantly upgraded.

But alas, until this confusion is cleared you have to choose between having a stable platform or updated user software.

This confusion was cleared a long time ago in BSD land: /usr for system software, /usr/local for everything added on.

Re:What's the fascination with "rolling releases"? (3, Informative)

TheRaven64 (641858) | more than 3 years ago | (#34445214)

Yup, and in BSD land it works well. You update the system periodically, either just tracking security updates or updating to get new features, and you update third-party software independently. With FreeBSD, you have a choice of following the cutting edge branch (-CURRENT), which is not recommended for anyone except developers, the mostly-tested (-STABLE) branch, which is fine for people who want to play with new stuff, or a release branch (-RELENG) that has had some extra testing and generally only incorporates bug fixes between releases. Each port / package is flagged with the versions of the base system that it supports and can be updated individually. You never need to upgrade the kernel or core userland to get a new version of something like KDE or GNOME (unless it actually depends on a newer feature in the base system, which is very rare).

The problem for Linux distributions is that everything is a third-party package, aside from some distro-specific management tools. Most of the time, these tools are relatively unimportant - you can easily work without them. It gets even worse when you try to do back-ports, because some things like glibc and Linux are very closely tied - for example, the RHEL kernel contains a couple of back-ported system calls that don't have the their glibc wrappers, so you can only get at them by making the system call directly, rather than via the libc interface.

Re:What's the fascination with "rolling releases"? (1)

r3verse (1202031) | more than 3 years ago | (#34445298)

Right now all I can think of is penguins facing down at high noon, silence punctuated only by the creak of flexing pocket protectors and the swish of the aforementioned knotted weeds as they sail by.

Yes. Sanity has departed me.

Re:What's the fascination with "rolling releases"? (1)

Steve Max (1235710) | more than 3 years ago | (#34446580)

Slackware gets this right on their -current rolling branch (or at least they used to get it right). Keep the system as stable as possible, and give users the most recent user-facing software. Heck, they are still using LILO: if it ain't broke, don't fix it!

Re:What's the fascination with "rolling releases"? (1)

the_womble (580291) | more than 3 years ago | (#34462908)

Surely a backports repo does exactly that?

Re:What's the fascination with "rolling releases"? (1)

Requiem18th (742389) | more than 3 years ago | (#34464772)

How do backports help shrink wrap vendors on a rolling release? No no no, rolling releases are more of a FOSS thing, meaning FOSS software always runs better than prepackaged ones because they are also constantly updated.

Re:What's the fascination with "rolling releases"? (0)

Anonymous Coward | more than 3 years ago | (#34445284)

Almost anything else seems better than churning out releases twice a year - that ridiculous schedule leaves about 2 or 3 months to actually do useful development, and the rest of the time for "testing", which appears to achieve nothing based on the number of bugs anyone can find in the release. This means everyone has gotten bored of release N and shifted focus to N+1 before N has even been released.

But with a rolling release, how are you going to have a huge party twice a year, and tell the world you've just released the best version since the last one, again?

Also, Linux makes you gay.

Re:What's the fascination with "rolling releases"? (1)

icebike (68054) | more than 3 years ago | (#34445644)

Seriously. I *like* to know I'm running a specific release that is fixed for a while so that I know what I'm dealing with if I run into problems, and so that if it's working fine I can *stay* on that release for a while. I also prefer not to run a release that is on the bleeding edge.

"Rolling release" looks like a sure recipe for support/dependency hell.

I'm assuming there are some positive reasons for it. What are they?

Well actually, my take is that a rolling release is designed to prevent running bleeding edge and dependency hell. That is the whole theory behind it.

In theory it should be less disruptive to replace AND TEST and Distribute one package at a time, rather than the current "blow it all away and start over" every 6 to 18 months with a new cute animal name.

Of course the devil is in the details and the execution.

If they let package maintainers push their latest package into the rolling release as Greg Kroah-Hartman seemed to suggest it will be bleeding edge all over again.

Very nice (1)

Barefoot Monkey (1657313) | more than 3 years ago | (#34445092)

This is a great option for those who would want such a thing. And, upon further consideration, I think that I might just be such a person. Having each appliation synched to its own release schedule rather than to the operating system's sounds is very practical. Also, I like the name.

Re:Very nice (1)

houghi (78078) | more than 3 years ago | (#34445258)

With upgrades for me it is "If it ain't broke, don't fix it" and openSUSE already does the security updates. I seldom have the need to have the latest version.

However choice is a great thing. Many people will use it, because they want to have the last version (rightfully or not is another discussion) so good for them.

Gentoo? (3, Informative)

ajclements (1529359) | more than 3 years ago | (#34445106)

This is basically what Gentoo does. The only numbered releases they have are the annualish install discs. And if you go with the minimal install, even that doesn't draw much from the install medium, you download all the current packages.

Move to a service pack style system. (-1)

Anonymous Coward | more than 3 years ago | (#34445158)

Make a final base release and just use service packs that fix bugs and major new hardware support once every year. It works for 90% of operating system market share.

Packman? (1)

chickenrob (696532) | more than 3 years ago | (#34445246)

Does anyone know if packman will have repositories that go along with tumbleweed?

Er... (0)

grasshoppa (657393) | more than 3 years ago | (#34445320)

Awesome news, too bad we're talking about Suse.

I'll use WindowsME, thanks.

Maybe they're just trying to generate buzz... (0)

Just Brew It! (636086) | more than 3 years ago | (#34445330)

...in an attempt to demonstrate that they're still relevant, now that they've been acquired by a company that nobody's heard of.

Re:Maybe they're just trying to generate buzz... (1)

int69h (60728) | more than 3 years ago | (#34445486)

It was maintained by a company that nobody had heard of for longer than it was by Novell. Somehow I'm sure they'll get by.

Re:Maybe they're just trying to generate buzz... (1)

Just Brew It! (636086) | more than 3 years ago | (#34445566)

Maybe some of the people on the project are not satisfied with just "getting by".

Re:Maybe they're just trying to generate buzz... (0)

Anonymous Coward | more than 3 years ago | (#34449534)

I'm sure Microsoft has heard of the company that bought them.

Tumbleweed is for ghost towns (1)

Nighttime (231023) | more than 3 years ago | (#34446656)

Fedora has a rolling, rolling, rolling release called rawhide.

the more things change (1)

epine (68316) | more than 3 years ago | (#34448336)

The whole model is still too distribution centric, and not making enough allowance for the difference between one user and another. We all have our own set of mission critical applications. Sometimes a critical application needs to be stable above all else, even if it's long out of date. Sometimes it must be the last major release, even if the release has many problems. Sometimes you need both, and a way to control which is the default and which is the sandbox.

If I'm working with a bleeding edge C++ compiler release and it messes up my code generation, I'm prepared to hunt that down and deal with it. I'll probably A/B against another compiler that recently worked.

There are features on my desktop that are huge benefits for my productivity. At the same time, if my X desktop goes flaky, I don't have the tip of my fingers skillset (or the interest) to bug hunt. It's not my bag. Other people can do dogfood duty before I sign up.

On another front, if my IM client baked out, I might not miss it for a month or more. I know people who wouldn't last five minutes without their buddy list.

The conflict arises when a tool you've marked for aggressive update needs to drag in something unproven you've marked for maximal stability. This needs to be resolved by the user. Tentative updates with rollback points would be nice.

In my view, this entire debate is worthless until it's centered more around the requirements of the user, and less around distribution politics.

People will say "it's too big of a nightmare to have everyone upgrading on selective fronts". The same argument was put forward about template header libraries in C++. Everyone will combine the components differently! It will be a debugging nightmare!

Actually, no. The extra design rigour involved in making the components fit together in the first place more than compensates for combinatorial deployment. There is pain, but it's not that pain.

It's ugly in practice because it takes C++ into territory where the tools struggle to produce meaningful diagnostics. Concepts would have mitigated this in part, but it was ambitious, and it risked imposing bureaucracy, so Stroustrup wisely raised a red flag late in the day. Meanwhile, new compilers such as clang are coming down the pike that flounder less badly on obvious typos.

I don't think migration to heterogeneous updates will be painless. But I think the pain involved pertains to a real problem, one well worth solving. In the long run, debugging likely gets easier, because there is more variance from one user to another in installed components to correlate against. When two people report the same weird ass bug, they won't have a Zesty Zaphod identical to ten million other users.

It just takes a different mindset to treat combinatorics as an asset rather than a liability. The ground changes under our feet in more ways than we appreciate. The recent adoption of PEG parsers is a good example. No ambiguity, linear time. Why not twenty years ago? For the packrat parser, memory consumption is a constant multiple of the input stream. Has anyone looked at the backflips in TeX to avoid memory consumption linear to input size? In the 1980s, this was a no fly zone.

Will we ever trust the dependency graph enough to give the user his due? It can't be harder than unwinding the C preprocessor in C++ refactoring tools.

Poor choice of a name (2)

kimvette (919543) | more than 3 years ago | (#34448580)

Given the situation that SUSE is in right now (being spun off of Novell, with its future in question) naming a distribution after a weed often depicted in popular media as a sign of a deserted down is not the best choice.

Why not just say "OpenSUSE/SUSE users who want the latest and greatest apps can enable the 'Factory' repository?"

Re:Poor choice of a name (1)

NoseyNick (19946) | more than 3 years ago | (#34453990)

I was going to ask the same question, but read TFA and realised this isn't quite the same as "OpenSUSE Factory", it's more like a kind of "OpenSUSE Factory Stable".

We haven't had so much "rolling" ... (1)

Rambo Tribble (1273454) | more than 3 years ago | (#34450510)

... since "Rawhide" went off the air. Okay, let's all sing along now ...

Avoiding incompatibilities (0)

Anonymous Coward | more than 3 years ago | (#34452124)

I may be a complete fool and totally ignorant in software engineering but... since disk space is usually not an issue... why not going back to statically linked applications in order to avoid incompatibilities?

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>