That's the entire point of this... if it's only once a year it will be extremely painful. The more regular they are the more healthy you will be, both as an individual and as a software company. Companies making regular releases can respond much more quickly to user needs--that is what my company does it the customers are very happy.

Really? I found 14 to be fairly good. I skipped 15, went to 16 and found so many problems that I'm glad 17 came out a scant 10 days after my upgrade. On 17 I haven't had any issues yet aside from some KMail-specific ones related to opening external HTML in messages causing a segfault.
But as far as SuSE goes, yes, I have to agree. I have too many customers who insist on using it, won't upgrade, and so lose all ability to patch one year after release. I feel for them since they can't be easily brought

Maintaining packages in this manner is a lot of work. At the end of the day, most contributors only work on a handful of packages and don't consider the possible breakage of other packages. One or two people end up doing all the cleanup work. This happens in the BSD community all the time. For instance, if you look at the recent issues in FreeBSD when PNG was updated or the new debate about X.org 7.7 coming into the tree. FreeBSD's approach to ports is great when you want up-to-date software, but the maturity found in NetBSD's pkg-src or even OpenBSD's model sounds a bit more like what OpenSUSE is looking for.

I'm not trying to pick on FreeBSD. I use a similar process for MidnightBSD due to limited developer resources. In my case, it usually means I personally have to update packages. That's why we have such outdated versions of Firefox (unbranded of course) and Chrome. Not only do all the other dependancies have to be the right magic versions, but someone has to take the effort to port a rather complex piece of software. Luckily, the Linux folks don't have nearly the trouble as they're a tier 1 platform for most software these days. Still, there are many different choices in linux for near everything and getting your combination to work can be tiresome. Next time you download packages from any open source OS, consider how much work went into that easy experience. Saying thank you can't hurt either.:)

Linux folks don't have nearly the trouble as they're a tier 1 platform for most software these days.

On the positive side, if you know Linux, you have better chances of finding why the piece of software refuses to compile/link.

I'm no distro maintainer, but I do a share of platform porting. In my experience it is actually reliance on GCC (and prehistoric crap inside/usr/include/) which is more of a problem. Only after experiencing all that fun trying to compile open source software using non-GCC compilers (aCC, SunStudio, xlc), I have fully realized what kind of hurdle CLang developers and users have ahead of them.

Maintaining packages in this manner is a lot of work. At the end of the day, most contributors only work on a handful of packages and don't consider the possible breakage of other packages. One or two people end up doing all the cleanup work. This happens in the BSD community all the time. For instance, if you look at the recent issues in FreeBSD when PNG was updated or the new debate about X.org 7.7 coming into the tree. FreeBSD's approach to ports is great when you want up-to-date software, but the maturity found in NetBSD's pkg-src or even OpenBSD's model sounds a bit more like what OpenSUSE is looking for.

The sad thing is that this boring job is done for every distribution separately. Imagine how much developer time would be saved if someone could figure out how to make (tested) packaging work across distributions.

I'm not knocking the OBS, it's a very useful tool, but it really doesn't help much here since making a package that works cross-distribution would involve a lot of manual integration work.

For example I could easily use the OBS to take my Opensuse package for foo and build it on Fedora and ensure it at least builds and is installable. However the real work, integrating it into the Fedora distro and ensuring it works well with and is the right version for the other packages in that distro, is not done by the

Not only do all the other dependancies have to be the right magic versions, but someone has to take the effort to port a rather complex piece of software. Luckily, the Linux folks don't have nearly the trouble as they're a tier 1 platform for most software these days. Still, there are many different choices in linux for near everything and getting your combination to work can be tiresome. Next time you download packages from any open source OS, consider how much work went into that easy experience. Saying thank you can't hurt either.:)

Too many moving targets. Too many artificial dependencies.

I've often found that dependencies are carelessly chosen, then enshrined into the RPMs, when in fact there is no real dependency on having the absolute latest version of some lib or some other package. The package builder or the developer happened to have version 1.35.34-1a installed even thought they USED nothing from that lib or package that was new or fixed since 1.26.0.

Consequently it becomes a mad dash for every maintainer to gather a snapshot

Its a lot easier to use - 10 years ago if for example you double clicked on an AV link you'd just be met with a "Huh?" prompt from the window manager and would have to go find an app that could read it. Similarly most MS Office file formats were a game of chance with the free software around at the time.

Having said that , there does seem to be a tendancy for distro devs to pack in the the latest stuff into a release simply because its available , rather than going for stablity and interoperability with maybe slightly older versions of software.

Having said that , there does seem to be a tendancy for distro devs to pack in the the latest stuff into a release simply because its available , rather than going for stablity and interoperability with maybe slightly older versions of software.

To be fair to them, end users tend to clamor for the latest stuff and tend to consider the presence of older versions a net negative when discussing a distro. On the other hand, a developer is more likely to prefer the cutting edge by nature, and often has a tweaked system that works for them, so tend not to notice that the latest stuff doesn't work properly on a stock version.

There's also the problem that for some applications or tools, the latest stuff is actually better and preferable so should be packe

No matter what the release frequency, you need to carefully choose what goes into a release, and it doesn't sound like that's happening here. It doesn't matter what your release timeline is - you can still run over the deadline if you don't plan carefully or if you allow scope creep. I don't think lengthening the release timeline in SuSE's case would necessarily help anything. In fact, shortening it would likely be more effective. Each time you do a small release, you can refine your estimation skills a

I was a happy OpenSUSE user for several years, but abandoned it after the 12.1 release. My reasons were quality and stability issues that had been on the rise over the last few releases, which culminated in the premature (IMHO) and half-assed transition to systemd in 12.1. That was the last straw and the trigger to embark on another distro-walkabout (I won't say what I ended up switching to, because this isn't about that).

There is a lot to like about OpenSUSE and it's probably still one of the best distributions to use for a nicely integrated and well supported out-of-the-box KDE environment. But the incidence of instability (generally user-facing stuff - the base environment of kernel, toolchain and libs is pretty rock-solid), random bugginess (usually caused by a lone developer or small team marching to their own drummer without regard to their surroundings) and poor integration of interacting components has been creeping up over the last few years. It seems that people in the OpenSUSE development team have taken notice and started to think about the causes and how to address them. Bravo to them for having the insight to notice and the balls to try and address the problem before pushing out a release.

Not that they probably care too much about what I think*, but I'll be watching carefully and may give the next release another chance.

---* The developer community is probably one of the more unconsciously user-hostile developer groups I've encountered in awhile. A fine and dedicated bunch, but they tend to keep to themselves in places apart (mailing lists, IRC) from where the users hang out (forums.opensuse.org). A typical response when a user is baffled about some problem or wants to discuss improvements is the typical "well did you file a bug report" (delivered in an imperious and self-important manner by the a senior forum user or appointed moderator who are just a little too zealous in their developer worship), or the suggestion that users join the mailing lists if they want to be heard because the developers don't use the forums (don't want to be too close to the hoi polloi, after all). Meritocracies do indeed become oligarchies, apparently. http://boingboing.net/2012/06/13/meritocracies-become-oligarchi.html [boingboing.net]

The biggest thing they have fucked up in 12.1 is the power management. I now do get around 15 mins of extra battery backup on my 4 cell Vostro laptop, compared to version 11.2, but the system refuses to gracefully shut down or hibernate most of the times. Plus, the boot up time has gone up by 1 minute.

I still prefer them over Fedora though, which is always shipped with random anaconda bugs. Also openSUSE's software repo setup is a breeze compared to Fedora.

Did you do an update or fresh install? Every time i've tried update, i've had to go back and do a fresh install. The update process doesn;t seem to take into account config changes and delete old config keys/values.

I tried out with a fresh install on a separate partition first. But that was even worse, the system didn't get to hibernate at all. Finally i decided to go for an upgrade, since it didn't make any sense to run an old version for long. True, their upgrade process isn't that good, some old configs get deleted. Also, never try to upgrade with YaST, i.e while being booted in the old version, you are most likely going to end up with a broken system.

Part of the problem with Linux in general, and Suse in particular, is that when you do file a bug report the response is "work on it yourself." I filed bug report once After carefully documenting how to cause a serious problem and filing a bug report detailing the steps to reproduce it. I'm not a developer and didn't want to become one. However, I am a reasonably knowledgeable user. Out of courtesy I spent many hours tracking down the exact sequence of events which would cause the issue, corruption of

Thanks, that illustrates quite well my peripheral point in the footnote about SUSE developers being generally (and somewhat unconciously) user hostile. Treating motivated, willing and helpful participants in your distro experience as nothing more than underperforming developers who just aren't conforming to cultural norms is a symptom of the problem. I could probably sum it up as: the ultimate goal of a distribution is not to be a personal toy for developers to amuse themselves, but rather to be a tool t

I'm not disappointed in a slower release cycle. It should improve the quality of each release.

I think so too. I've been using openSUSE since it was SuSE Linux Professional and, before that, just S.u.S.E. Linux. They had an approximately annual release schedule for the newer, pre-Novell, versions and didn't try to stuff in every single newest thing going. I like to think this gave them the time to make sure that the vast majority of what they did ship worked well.

Unfortunately, a combination of changing to the "me-too" scheduling of releases (IIRC, the original discussion of the release schedule w

Suits me too!
I recently tried fedora 17... I spend almost one afternoon to understand why the heck the xsane on the F17 could not recognize the scanner part
of my multifunction laser/scanner (samsung scx-3200) , (on OpenSUSE and Kubuntu, it was a 5min task to edit a file into the/etc/sane.d/ )
then I finally re-complied the 3.4 kernel and 'played' with the/proc/bus/usb access properties. then EVERYTIME I booted the darn system I got errors from this abomination called SELinux, which finally deactivated

Really. Over 5 years ago? That's all you've got? And OpenSUSE is a community driven OS from what I can observe, though Novell employees do contribute. You should really be ranting about SLES if you want to make this about the behavior of corporations.