It's Not Time for OSS Release Cycle Synchronization

Bakkies Botha writes "Ars Technica weighs in with some detailed analysis on the controversial issue of open source release cycle synchronization. Ars explains how time-based release cycles work and takes a close look at how the release management strategy suggested by Ubuntu founder Mark Shuttleworth would impact open source software projects. Ars concludes that Shuttleworth's proposal isn't currently viable and argues that the BFDL is overstating the potential to simplify development with better version control tools. Ars also examines a counter-proposal offered by KDE developer Aaron Seigo and explains how it enables users to get the same benefits of synchronization without disrupting upstream development."

Comments

Counter-proposal?

[Tribbin]

Ars also examines a counter-proposal offered by KDE.

Do you expect us to read the article? Or do you provide a summary of the proposal?

Re:Counter-proposal?

[RiotingPacifist]

Basically its a very long post, but the gist of what I read was why dont you just build it yourself instead of asking us to to drop nicely packaged tars on your doorstep.

Re:Counter-proposal?

[xenocide2]

That cuts both ways. If you change the package, you're not reflecting some crazy will of the developer or making them look bad etc. If you don't upgrade it often enough, the developer (and some users) get angry that you're still shipping old code of theirs. If you just ship upstream releases 0day, shit breaks. I just witnessed a package in universe complain that Hardy didn't ship their latest version, even though it was basically a surprise release well after FeatureFreeze and a week or so before the FinalFreeze. Nevermind that their first cut at the release totally broke the program and they had to release a version bump a day later. Many upstreams are terrible at release management, and distributions are valuable because they do that work.

Bottom line is if you want the distro to help you, understand the distro first.

Re:Counter-proposal?

[RiotingPacifist]

just witnessed a package in universe complain that Hardy didn't ship their latest version, even though it was basically a surprise release well after FeatureFreeze and a week or so before the FinalFreeze. Nevermind that their first cut at the release totally broke the program and they had to release a version bump a day later. Many upstreams are terrible at release management, and distributions are valuable because they do that work But his suggestion gets rid of that all together, once every release cycle of the distro they take whatever code they want from the upstreams and stick it in the distro. I suppose this will annoy some power hungry upstreams, but for a lot of other projects saves them the hastle of releasing so they can get on with coding.

Re:Counter-proposal?

[xenocide2]

A lot of upstreams don't want to support anything but the latest release, and apparently get annoyed when people file bugs at sourceforge for stable releases. Normally they should just ignore outdated releases but more seem to be getting angry that Ubuntu is so slow to pick up changes. Fundamentally, I think many advanced users and developers hate stable release cycles and would rather see a Debian unstable process. I'm not sure how well this works for library transitions. Probably pretty bad.

if I was in charge of a FOSS project

[FudRucker]

I would release when it was ready, not when some stupid release cycle rolled around, that is what everyone does not need is some schedule to pressure developers to release before a product is ready...

Re:if I was in charge of a FOSS project

[maxume]

The idea of the schedule is not to encourage a premature release, but to encourage a sufficiently attainable definition of "ready" such that a release eventually happens.

Re:if I was in charge of a FOSS project

[InlawBiker]

There really isn't a perfect way to release Linux distributions. With timed releases components are prioritized quickly, but some stuff gets left out. With feature-based releases you have to wait until some number of components are ready so the release date is a mystery.

I think it's great the way it is: each distro has their own method, you can pick the one that's right for you. It's the ultimate in technical Darwinism.

Re:if I was in charge of a FOSS project

[trolltalk.com]

The idea of the schedule is not to encourage a premature release, but to encourage a sufficiently attainable definition of "ready" such that a release eventually happens.

Best definition: "It'll be ready when it's ready."

This is the same truth, whether you're talking about open or closed-source, free/libre or proprietary software.

Trying to alter this basic truth results in death marches, bad, bug-ridden software, disaffected developers, dissatisfied users, and "we'll fix that in the next release" bullsh*t.

Re:if I was in charge of a FOSS project

[maxume]

Sure, but you can at least prioritize certain features, which is then essentially a schedule, and you might as well release features once they are ready (because, as you say, they are ready).

Re:if I was in charge of a FOSS project

[RiotingPacifist]

OFC not specifying a schedule leads to e17, hurd, etc

Re:if I was in charge of a FOSS project

[ceejayoz]

Given the number of "is Linux ready for the desktop?" discussion threads, I'm pretty glad they don't follow your advice on releases.

Depending on who you ask, a project as complicated and large as a Linux distribution release might never be ready. Hence periodic release dates, which seem to be working just fine for Ubuntu.

Re:if I was in charge of a FOSS project

[Anonymous Coward]

While specifying a schedule gives us Ubuntu 8.04, KDE 4.0, etc.

Your point?

Re:if I was in charge of a FOSS project

[Uncle Focker]

That those pieces of software are actually released and usable.

Re:if I was in charge of a FOSS project

[Cal Paterson]

The idea isn't to encourage a premature release, but that is often the effect, especially in Ubuntu. Number of times Ubuntu randomly decides to freeze on a bad version of a program without properly thinking about it...

Re:if I was in charge of a FOSS project

[RiotingPacifist]

Booting into on Kubuntu 8.10 ( KDE4.0 remix) a lot more reliable & easier, than e17 on hurd.

Your point?

Re:if I was in charge of a FOSS project

[compro01]

for a suitable value of usable. both have a fairly sizable collection of issues.

Re:if I was in charge of a FOSS project

[Uncle Focker]

And the amount of usability versus development time far eclipses Hurd by many magnitudes. KDE4 was especially a clusterfuck, but in comparison to the usability of Hurd after 24 years, they're in totally different ballparks.

Re:if I was in charge of a FOSS project

[TimSSG]

Shuttleworth's proposal makes perfect sense for the Linux Distros that just repackage the upstream work. But, it does not make sense for the Distros that do a lot of original work. Tim S

Re:if I was in charge of a FOSS project

[mysticgoat]

Trying to alter this basic truth results in death marches, bad, bug-ridden software, disaffected developers, dissatisfied users, and "we'll fix that in the next release" bullsh*t.

If there were Godwin Awards, parent post would be a contender...

When there is a set release date, responsible developers will keep it in mind and change plans as the freeze approaches: things that are unlikely to be finished are put off to the next release; efforts are concentrated on bullet proofing what can done. Developers that can't or won't take on this kind of responsible change of focus are going to produce crappy software no matter what (irresponsible behavior is a quality of the developer that affects everything he touches; it is not an attribute of blocks of code).

Maybe there should be Godwin Awards...

Re:if I was in charge of a FOSS project

[fistfullast33l]

that is what everyone does not need is some schedule to pressure developers to release before a product is ready...

True, not to mention that most of the developers are doing it in their own spare time, the large exception being the Linux kernel and a handful of developers in organizations such as Mozilla, IBM, RedHat, and Novell. As a user who shies from the mainstream - I use E17, Pidgin, and Audacious just to name a few apps - and uses programs that are only supported by volunteers and those who work in their spare time I just don't see a release cycle helping these kind of applications. Will Ubuntu stop supporting these if they force this kind of release cycle?

One of my favorite things to do each week (I'm a total nerd) is run 'emerge world' and I feel like with a release cycle you're going to get caught into a constant cycle of upgrading to the latest and greatest version via reinstall ala Windows and OSX. Everytime Apple or Microsoft releases a new version, particularly Microsoft, I find myself reformatting and starting over. The beauty of Linux right now is that you don't have to do that frequently.

Re:if I was in charge of a FOSS project

[firewrought]

It'll be ready when it's ready.... Trying to alter this basic truth results in death marches, bad, bug-ridden software, disaffected developers, dissatisfied users, and "we'll fix that in the next release" bullsh*t.

If you're landscaping your yard, you can take as long as you want and spend as much money as you want. If someone else is landscaping your yard, you become much more interested in how long it will take and how much it will cost: giving them your credit card and letting them keep a running tab is not an option.

Similarly, if you're doing leisure or volunteering programming, you can tell the world "It'll be ready when it's ready." Much of Open Source falls under this umbrella. Most of the business world does not. The professional programmer enforces up-front and on-going trade-offs between features, quality, and schedule risk. When they can't or won't (sometimes due to politics), then you get the bad stuff you mention. One way or another though, schedules are a business necessity.

I suspect that, even for volunteer programming, schedules can be useful. Deadlines force you to think about where you want to be by the time the deadline rolls around. They give you a goal. They force you to cut unneeded features and focus on the core strengths/concepts of your product.

Likewise, the lack of a schedule--especially the "It'll be ready when it's ready." attitude--can be severely damaging. If you haven't hammered out a detailed plan of what you want to accomplish and you've left it all open-ended, you can get lost spending lots of time choosing a programming language or gold-plating a feature that nobody will use. Is this why there are so many defunct OSS projects on SourceForge? I bet it's part of the reason... most software their has no business driver to give them momentum.

Re:if I was in charge of a FOSS project

[CastrTroy]

Yes, planning for releases at certain periodic intervals is a good idea. However, those dates should not be set in stone. If the planned release date is December 25, and something comes up, and the release has to be held back a couple weeks, then it should be held back. Obviously you should have a release date, with a corresponding featureset in mind, but that doesn't mean that release dates should be carved in stone.

Re:if I was in charge of a FOSS project

[trolltalk.com]

Given the number of "is Linux ready for the desktop?" discussion threads, I'm pretty glad they don't follow your advice on releases.

Depending on who you ask, a project as complicated and large as a Linux distribution release might never be ready. Hence periodic release dates, which seem to be working just fine for Ubuntu.

Last I looked Ubuntu is based on Debian, so your example is actually a counter-example of what you want to prove. Debian has a philosophy of "release it when it's ready" that hasn't, afaict, changed. That's why Ubuntu, ertc., base themselves on Debian. Less of a moving target, etc.

Re:if I was in charge of a FOSS project

[trolltalk.com]

Trying to alter this basic truth results in death marches, bad, bug-ridden software, disaffected developers, dissatisfied users, and "we'll fix that in the next release" bullsh*t.

If there were Godwin Awards, parent post would be a contender...

When there is a set release date, responsible developers will keep it in mind and change plans as the freeze approaches: things that are unlikely to be finished are put off to the next release; efforts are concentrated on bullet proofing what can done. Developers that can't or won't take on this kind of responsible change of focus are going to produce crappy software no matter what (irresponsible behavior is a quality of the developer that affects everything he touches; it is not an attribute of blocks of code).

Maybe there should be Godwin Awards...

so rather than make a reasonable spec, and sticking with it, you're proposing we continue the "design-by-the-arse" that's been going on for decades, where we stick in every feature that someone pulls out of their rear end, then, as the release date approaches, start cutting features willy-nilly? Really, pulling out half-baked features isn't just a question of removing a few source files. There ARE interactions.

And I for one welcome our Godwin Awards overlords.

Re:if I was in charge of a FOSS project

[SanityInAnarchy]

When there is a set release date, responsible developers will keep it in mind and change plans as the freeze approaches: things that are unlikely to be finished are put off to the next release; efforts are concentrated on bullet proofing what can done. That's a very well and good phase that every project should go through, when it's ready, and not before. I understand and appreciate Ubuntu's six-month schedule, with countdowns and everything, but it does hurt certain things -- puts off major features for six months, when they might be finished in a few days, for example.

Take Wine. Who wants to bet that there will be a 1.0 release before Ubuntu 8.10 comes out?

Or, put another way, if I'm running a tiny solo project, I might have a stable release every few days. But for, say, the Linux kernel -- remember the 2.5 development? How much was changed since 2.4? A feature freeze too early would've hurt, not helped -- sometimes, you just need to hack on an unstable branch for a few years before you get something release-worthy.

And yes, there was a feature freeze. After which, it still would've been hurt by a set release date -- after a feature freeze, the release comes when you can no longer break it, and not before. Maybe once you attain that, it's worth holding off for some set amount of time, but it'd be pretty stupid to say "Well, this release candidate seems pretty bulletproof, but let's wait another month until the new Ubuntu comes out."

Now, for a composite project like Ubuntu, I can see having a fixed amount of time before a feature freeze, but after that freeze, I think "when it's done" is far, far better than "when the 'days left' counter reaches zero."

And I think it still hurts, for the parts that do amount to actual development, and not simply selection of packages -- look at upstart. Yes, we're using it now, but mostly as a wrapper for old-fashioned init.d and rc?.d behavior. If Ubuntu wanted to provide proper event.d scripts for everything currently done in init.d, that would take more than six months, I'm guessing.

Maybe there should be Godwin Awards... Don't encourage them! That would be the ultimate troll-feeding!

Re:if I was in charge of a FOSS project

[SanityInAnarchy]

The professional programmer enforces up-front and on-going trade-offs between features, quality, and schedule risk. This is one of the advantages, I think, of software-as-a-service, in any form. For a web app, we can actually add new features when they're done -- it's not as though we're going to lose money by putting them off.

I suspect that, even for volunteer programming, schedules can be useful. Deadlines force you to think about where you want to be by the time the deadline rolls around. They give you a goal. And different deadlines make sense for different projects. And lockstep deadlines are harmful.

Likewise, the lack of a schedule--especially the "It'll be ready when it's ready." attitude--can be severely damaging. If you haven't hammered out a detailed plan of what you want to accomplish and you've left it all open-ended Those are orthogonal.

If I was running a large project, I'd probably do this: Feature freeze on a fixed date. Release when all outstanding bugs against the "frozen" version are resolved. If you've got a big enough community, call that a release candidate, and give people a week to find more issues with it before releasing.

Re:if I was in charge of a FOSS project

[Eponymous Bastard]

[if I was in charge of a FOSS project] I would release when it was ready, not when some stupid release cycle rolled around, that is what everyone does not need is some schedule to pressure developers to release before a product is ready... When what is ready?

Most OSS projects have a whole lot of developers working on multiple features independently of each other. There is always at least one outstanding feature someone is working on. Even when a project gets labeled 1.0 people don't usually stop working and implementing new things

Release management is about two things:
- When to release
- What to release

Basically, you can work out around what date you want to release and figure out which big features will be ready for and merge those into a mainline and tell new things to hold off until release. Or the other possibility is to figure out which features you want in a version and then tell everyone else to hold off until those are stable.

If you have a distro schedule, you can still apply both of these. You can shoot for a couple months before and decide on which features will be ready. Or you can choose your features and then tell the distro whether it looks like it'll be ready or not. In this last case the distro still has a choice of whether to go with the last release or release a beta version (RedHat's GCC 2.96, Ubuntu's Firefox 3 Beta), and can make an informed decision by watching the projects and figuring out how close they are to release.

Re:if I was in charge of a FOSS project

[mysticgoat]

The bane of software design since the days of Fortran is that significant projects involve a hell of lot of blue-sky design. Basically, unless you are simply re-implementing something that has already been done, you can have no idea what parts are going to flow easily, and what parts are going to be total bitches. When you are doing something new and different, you cannot possibly know what is reasonable.

Twenty years ago when I was closer to the development end of the industry, the common sense was that completing the last 10% of a project would require 90% of the time. I think things are much better now, due to better concepts about encapsulation among other things, but the underlying basis remains: when you don't know what you are doing, you WILL make costly mistakes that cause serious delays.

That's what has driven modular design and then object oriented design. Build things so that you can limit interdependencies and prune out stuff that isn't yet working right. When some core object cannot be brought in on time, replace dependent objects with ones that provide the minimal necessary function, and plan to make things oh so much better in a later upgrade.

Good software is never completed. Good software is in a continuous upgrade cycle. A regular upgrade cycle with the various freeze points that go along with it models this very well, and encourages productivity.

Re:if I was in charge of a FOSS project

[Anarke_Incarnate]

I hope you mean the 2.6 kernel changes from 2.4. 2.5 was the unstable branch.

Re:if I was in charge of a FOSS project

[SanityInAnarchy]

I mean 2.5, precisely because it was the unstable branch. The very notion of a long-term unstable branch spanning years would seem to go against the idea that we could pick any kind of synchronized release schedule that would hold for every project.

Re:if I was in charge of a FOSS project

[Requiem18th]

You are seriously confusing the oppressive nature of deadlines with the more laid back nature of open source periodic releases.

  If you fail to meet a deadline you get fired, your product gets trashed, your company gets sued etcetera.

  In the case of a distribution like Ubuntu, the only thing that happens if you miss the freeze date is that your application ships with the same features than last Ubuntu version, hardly a punishment at all.

  The question here is what do you want them to do, because they aren't going to do anything to you at all. So you want them to package a more recent version of your software? They will do it, with one condition, they need a stable version before the freeze date. I'd like to finish there with "and that's it" but I've something left to say.

  There are essentially two ways to add features to an application, You can either throw a bunch of stubs and let them grow into maturity over a long time or you can concentrate on one individual feature before moving to the next. Both work, the difference is that with the later method, you always have something exiting to release, with the former method your software is for all practical purposes unmaintained for a long period of time, because you never release a stable version. And of course then you release and take the world by surprise but meanwhile you'll have lost some of your user base to some other project.

  In conclusion, if you can't possibly make a decent release on time then by all means ignore the freeze date. All I'm saying is that if you think you can release something decent, get it ready before the feature freeze and it will appear in the last Ubuntu release, for free.

Re:if I was in charge of a FOSS project

[grumbel]

Best definition: "It'll be ready when it's ready." Which in the case of a distribution would be never. With thousands of software projects packaged into a distribution you reach never a point where every single one of them is ready and if you don't have at least a little bit of synchronization you end up with a distribution that is bleeding edge in some areas and outdated in others. With six month release cycles this is much less of a problem of course then with Debian's endless spans of time between new releases, but it can still be really annoying if you are stuck with a buggy piece of software for six month that is already fixed upstream just because the new upstream released missed the distributions release by a few days.

In the end however I don't think synchronization is the solution, it is the workaround. I think we simple should start to abandon the idea to get a whole distribution "stable" at some random point in time, instead isolate some core components and make sure that they are stable, but leave everything else to be updated as soon as upstream makes a new release. There is no reason why a new SuperTux release for example should have to wait for six month to be shipped to the user, it should get shipped as soon as its ready and with the current way distributions work that just doesn't really work.

PS: It would of course be nice if distributions would adopt the idea to have different versions of the same package installed at the same time, since the forced upgrade to a new version that you get today, is really one of the main reasons why we have that mess in the first place.

Re:if I was in charge of a FOSS project

[richlv]

actually, there's a quite neat approach. set some release date in future and just declare "what's ready at that point gets released, other features can be developed after that point in time".
and i believe that's a quite nice approach, especially for stable branches.

Re:if I was in charge of a FOSS project

[trolltalk.com]

If you fail to meet a deadline you get fired, your product gets trashed, your company gets sued etcetera.

... but in real life, if you fail to meet a deadline, you get to say "I told you so!", everyone else gets desperate, finally decides to allocate some of the resources you've been asked for, drop the stupid features that should have never been included in the first place, and you get back to the code face with a more doable project. After all, if they need it, they need it. They'll wait.

Why do you think we say "There's never enough time to do it right, but there's always enough time to do it over" and "fast, good, cheap - pick any two"?

Re:if I was in charge of a FOSS project

[trolltalk.com]

When something is "ready" is determined by the distro. They include whatever packages they think are "ready enough." For different distros, there are different values of "ready enough."

Some want "bleeding edge", some want "stable as a rock", some want "stable w. maintenance fixes only", some want "main trunk." The idea of forcing any sort of synchronization, when no 2 distros have the exact same definition of "ready enough" is just plain stupid. I'm glad to see that others are finally giving this idea the shit-canning it deserves.

Re:if I was in charge of a FOSS project

[trolltalk.com]

It'll be ready when it's ready.... Trying to alter this basic truth results in death marches, bad, bug-ridden software, disaffected developers, dissatisfied users, and "we'll fix that in the next release" bullsh*t.

If you're landscaping your yard, you can take as long as you want and spend as much money as you want. If someone else is landscaping your yard, you become much more interested in how long it will take and how much it will cost: giving them your credit card and letting them keep a running tab is not an option.

There's a big difference between landscaping a yard and coding. Is this the new "bad car analogy?" :-)

Deadlines force you to think about where you want to be by the time the deadline rolls around. They give you a goal. They force you to cut unneeded features and focus on the core strengths/concepts of your product.

Unfortunately, the people who set the deadlines also continually sabotage them by throwing in new feature requests, redefining the projects' goals, mis-allocating resources, not allowing enough planning time because they want to see some code or a prototype ASAP (that last one is a real pitch, because in their minds, it's "almost done" when they see the first crude proto ... after all, "now all you have to do is add a few features ...: AGGGH!!!)

Everyone wants to cut back on documentation, initial planning, etc., to "get things moving really fast!" Why? Because they have an unrealistic deadline, and want to skip things they think are impeding "getting the code written." Like sitting around with a stack of index cards and blocking out all the entities, attributes, relationships, etc. Like documentation. Like having people write up exactly what they want, then reviewing it with the people who are going to actually write the code. Like prioritization of each feature into "must have," "should have," or "be nice to have" because everything, in SOME person's mind, is a "must have."

Sometimes you need to be a little Hitler, and knife people's individual "must have" babies. Or a Kodos. Nobody wants to triage features, but it has to be done eventually in almost all projects.

And yes, I'll accept my Godwin Award.

Translation of Seigo's suggestion

[InlawBiker]

"Why don't you quite whining and help us develop and release the software you're re-packaging and trying to make money from."

This was a good article. The Internet was actually useful today.

Imho

[Joseph1337]

The benefits aren`t worth it. Look at Vista and KDE4, they were released too soon and look what happened - you got half of the promised features and half of the stability

Re:Imho

[mysticgoat]

Did I really see "Vista" and "KDE" linked by an "AND" operator???

Remarkable! Possibly a first!!

Re:Imho

[Knuckles]

Vista has the remarkable property of being released years too late and still too soon at the same time.

DFDL i think you meant BDFL - EOM

[RiotingPacifist]

EOM

A lot of buzz

[bsDaemon]

When I first read of Shuttleworth's proposal, I figured that it might be easier to start the sync project among the community distributions which feed into the commercial ones. However, thinking further, there seems to be more issues involved and I'm starting to think that it might not be that great of an idea, or terribly important.

the Linux-based wing of the f/oss community in particular is reaching a point where they finally have a large swath of people who are merely "end users," and whose biggest gripes aren't about some flaw in some obscure patch to imblib (for example), but are "i can't play dvds out of the box, so linux is t3h gay."

For whatever reason, people have decided that a holy quest to "destroy Microsoft" and encourage wide-spread adoption of gnu/linux-based operating systems would be totally awesome. Ubuntu is geared at those "new recruits," with large amounts of hand-holding and media support. Mint is even better with its media support, but completely lacks dev tools if you install from the live image -- seriously, what sort of *nix system thinks you don't need a C compiler by default and makes you go looking for it in the repositories?

Trying to sync up Red Hat or SuSE who have more or less gotten out of the consumer market and are targeting professional users - developers, engineers, etc - in the workplace environment with some candy-for-kids distro is frankly a little weird.

The goal seems to be to increase homogeny across distributions - however, homogeny between ubuntu and rhel? quite frankly, why?

The systems are targeted at different sets of people with different requirements and philosophies. Holding off on releasing Red Hat until Ubuntu is ready, which requires KDE and GNOME to sync up (more or less) sounds a little ridiculous and over-the-top.

If FreeBSD were to wait until something they were trying to adopt from OpenBSD were ready, certain individuals with well known personality flaws very well might pull some sort of stunt just to make the others look bad. Given how high emotions seem to run between KDE and GNOME people, I wouldn't be surprised if one did something to spite the other, which then filtered down to Ubuntu and RH getting the shaft and looking dumb.

The "community" is a whole lot bigger than it was 10-15 years ago, a bit colder and less friendly to boot. I have serious doubts that in the current climate this could be pulled off, even if something were to be gained by all parties -- which again, I don't think is the case anymore.

Just my $0.02; your exchange rate my vary.

Re:A lot of buzz

[jedidiah]

I would like to add a "me too".

Linux serves a number of distinct interests. Different components and distributions target
different users. It's GOOD that there is a great degree of diversity. A little chaos is
inevitable here. Mark's focus here should not be on some grand design. He should be focusing
on Ubuntu. He also shouldn't be expecting anyone else to adjust to his whims.

Perhaps he needs to be more flexible and adapt more to the upstream software maintainers (or
help more).

He certainly shouldn't be getting distracted by the likes of RHEL or SLES.

He needs to avoid the sorts of black eyes that come from not properly testing
massive fundemental changes to how the desktop works. He needs to focus on not
pissing off current users and scaring away the new ones. He needs to continue
to be the shiny happy face transplated on top of Debian.

Re:A lot of buzz

[garett_spencley]

"seriously, what sort of *nix system thinks you don't need a C compiler by default and makes you go looking for it in the repositories?"

One that targets non-developer desktop users ? Or even servers ?

As a sysadmin one of the many tasks I do to vanilla installs is to either uninstall the dev tools or restrict them to a particular group. Many exploits automatically download source for their rootkits or trojans etc. and compile it on the machine. Not having dev tools available to the user that the web server is running under, for example, makes these types of attacks more difficult and helps limit what an attacker can do if he does gain access (imagine a scenario where the attacker has no shell but can tell the web server to execute commands ... a simple 'wget' and 'make' later and he has himself a back door that gives him shell access as the web server user).

In other words, if you have no pressing need for dev tools then it's wiser not to have them installed. If you're a developer then you can easily add them via the repositories.

Re:A lot of buzz

[Anonymous Coward]

Trying to sync up Red Hat or SuSE who have more or less gotten out of the consumer market and are targeting professional users - developers, engineers, etc - in the workplace environment with some candy-for-kids distro is frankly a little weird. If some distributions use a common set of libraries and applications then why shouldn't they be interested in better synchronization with upstream development? It doesn't matter who the distribution is targeted at.

The goal seems to be to increase homogeny across distributions - however, homogeny between ubuntu and rhel? quite frankly, why? Take a C compiler as an example. Are you suggesting that Ubuntu and Red Hat would want different versions of the C compiler on the basis of their users? I don't see the advantage of heterogeneity here.

The systems are targeted at different sets of people with different requirements and philosophies. Holding off on releasing Red Hat until Ubuntu is ready, which requires KDE and GNOME to sync up (more or less) sounds a little ridiculous and over-the-top. Good thing no one suggested that then. If Ubuntu misses the release date, why would Red Hat wait? The whole point of synchronizing release dates is so that there is a common timeline. Since Ubuntu is not upstream from Red Hat, there would be no logical reason for Red Hat to delay (unless both delays are caused by a serious problem upstream).

Re:A lot of buzz

[Anonymous Coward]

Given how high emotions seem to run between KDE and GNOME people...

This hasn't been the case for nearly a decade, not since both sides realized that neither was going to get rich and powerful and that there wasn't much to fight over.

Re:A lot of buzz

[bsDaemon]

"seriously, what sort of *nix system thinks you don't need a C compiler by default and makes you go looking for it in the repositories?"

One that targets non-developer desktop users ? Or even servers ? Ok for servers -- but as to non-developers, it just sort of goes back to another point - what good is *BSD, GNU/*, etc, really and practically, to those who are not interested in doing UNIX-y things. I could type documents, browse the web, and hang out on AIM just fine in Windows.

Maybe its just because of how I got into this all. I switched to FreeBSD in the 8th grade because I wanted to do C programing. I used X so I could run several term windows and a web browser. I didn't do it because I "hated Microsoft" or whatever have you.

When I was in high school I thought nothing of emailing back and forth with Ken Thompson and Denis Ritchie. It didn't occur to me that I shouldn't talk to them. If I had a question, I asked, and I always got a response. Hell, one time I sent Ken Thompson an email containing merely "syn syn enq" and got a response of "ack."

Jordan Hubbard used to hang out IRC on occasion, when he was in charge of the FreeBSD core team.

I didn't know anyone who used the system that didn't at least shell script. No one was just sitting around doing nothing.

Its not so much that way anymore. It boggles my mind that someone would merely want to "use" Linux or BSD to do basic PC things. I mean, I enjoy doing those things as well, but I also have my little projects and experiments.

so, if I don't get it, then I guess I just don't get it, but I guess it is how they say, "BSD is for people who love UNIX; Linux is for people who hate Windows."

Re:A lot of buzz

[MMC Monster]

I think that syncing release cycles make sense for RHEL and other distributions that don't release often.

With Ubuntu, who cares? They release twice a year and have backports for things they miss.

Also, with the Ubuntu LTS releases patches are made to deal with security issues. You don't necessarily want an application that was just released a month earlier.

Re:A lot of buzz

[Kjella]

seriously, what sort of *nix system thinks you don't need a C compiler by default and makes you go looking for it in the repositories? Uhh... a system that you USE? My car came with an instruction manual, not a mechanic's manual and tools. Compiling code others have compiled before is a total waste of time (sorry gentoo), I haven't got any clue why my home server, my htpc, my desktop or my laptop should possibly need a compiler unless I happen to be a developer. Particularly not the boxes I set up for my parents which they're happily using but would have as much use for a compiler as an ERP system.

The goal seems to be to increase homogeny across distributions - however, homogeny between ubuntu and rhel? quite frankly, why? - Stronger competition on distro features, not just "free" features they got from upstream
- Less support costs, they probably share a lot of packages in the backend
- Better consistency of software quality (all have the same release window to plan for)

Holding off on releasing Red Hat until Ubuntu is ready, which requires KDE and GNOME to sync up (more or less) sounds a little ridiculous and over-the-top. It's a bit of circular reasoning going on in the article, it for example pulls out Ubuntu 8.04s pulseaudio configuration issues - try reversing the question, if pulseaudio knew that was the release window would they have worked much harder to hit it? Or just really miss it and get it really well done for the next release? I'm pretty sure they aren't doing it just for their own amusement and would like it to be included in distros as well.

Sure, things don't always go after plan and some projects would miss deadline windows and such. But compare that to the alternative, "when it's ready" basicly means they'll release all over the place and a distro would be an odd mix of old and new. If all projects knew this was the window I'm pretty sure most would manage to hit it. I think the "anti-synching" argument is rather poor because it's better to try to plan a scope than not making any plans at all. Seriously, the same applies inside a project and I assume you'd like all parts to have "releasable" code at the same time? Not easy if noone knows when it needs to be so.

I do think it's a bad idea, but not for any of the reasons you mention. I think this big break-and-release cycle will just lead to poorly tested software and a huge number of bugs after the synched release, since almost everyone will be waiting for that. I can deal with some new software on my distro, others can deal with some new software on their distros - but I think dealing with all new software would be an exercise in frustration, even with so many testing it.

Re:A lot of buzz

[MooseMuffin]

I could type documents, browse the web, and hang out on AIM just fine in Windows. You've got that backwards. If those are the things someone uses their computer for, why would they pay for Windows?

Re:A lot of buzz

[pjt33]

seriously, what sort of *nix system thinks you don't need a C compiler by default and makes you go looking for it in the repositories? I don't need a C compiler as long as the repositories are sufficiently up-to-date that the drivers work for my hardware. What sort of distro insists that you install software that you don't want or need?

Re:A lot of buzz

[RiotingPacifist]

seriously, what sort of *nix system thinks you don't need a C compiler by default and makes you go looking for it in the repositories? I'm a python developer you insensitive clod!

Re:A lot of buzz

[Uncle Focker]

Ok for servers -- but as to non-developers, it just sort of goes back to another point - what good is *BSD, GNU/*, etc, really and practically, to those who are not interested in doing UNIX-y things. I could type documents, browse the web, and hang out on AIM just fine in Windows. Because Linux/BSDs/Unix aren't OSes for elitists only? Why should someone be excluded because they aren't a code hacker? And people wonder why the "year of the Linux desktop" never comes when such attitudes are the ones prevailing.

Re:A lot of buzz

[RiotingPacifist]

Hell KDE developers are even thinking like GNOME developers now:
"Users are not designers"
"Its not at least an option, its at most an option..."
are not uncommon around KDE mailing lists

Re:A lot of buzz

[Anonymous Coward]

to have your crappy 15$ usb2 4ports add on card just work without an headache, to install program with a click cause you liked the description and the screenshot on the internet (since package manager or any tools in any linux wont help you in your choice you are on the internet anyays to choose your program. getting back to the package manager and seacrch AGAIN for soementhing you HAD to look on the internet on the first place is dumb)
And to use something you can have help with cause your neighbour also use it.
Choice is good when you can actually make an intelligent one.
With such fragmentation, you CANNOT make a good choice with linux.
Because you don't have the time to evaluate all of them you NEVER know if your choice is the right one.
Too many choices are not good, contrary to the stupid meme here.
That is not limited to Linux by the way; but in your everedy life.
People don't have enough knowledge to choose a linux distro anyway , so they would choose a product of average; and that product would be Windows.
I can do a secured AP with linux for free....
Or I can use the graphical manager that comes with my wifi card.
People choose second solution and the hell with it it just works; cause you cant do it in linux without being a linux admin cause no nerd has the idea to simply make a simple interface to configure a simple Access Point on a regular distribution.
They wait what...that I pay a nerd to do it ? hell I would...but then again who do I choose...

Re:A lot of buzz

[LWATCDR]

Yes there are Linux Users out there. My wife uses Linux to do digital scarp booking. There are a large number of women using GIMP to do digital scrap booking. Oh her scrap booking forums you will see them talking about how everybody should use Firefox as well... Yes women with kids that have never written a single line of code use FOSS. Some of them are now moving to Linux. The reason is they don't want Vista, they are tired of the problems they have with Windows, and Macs are too expensive. Even then some users have moved to macs.
The first step to trying something new is often dissatisfaction with what you have.

As to BSD vs Linux. I have installed BSD and it worked but I didn't really do much with it. Right now for a desktop or even most servers BSD doesn't offer enough befit over Linux to make me want to switch. But that is just for me.

Re:A lot of buzz

[value_added]

so, if I don't get it, then I guess I just don't get it, but I guess it is how they say, "BSD is for people who love UNIX; Linux is for people who hate Windows."

I agree with your sentiments, but it's worth pointing out that the small chimp that wandered into the room way back when has since grown and become 800 lb. gorilla with a proclivity for throwing chairs.

There's social, economic and political concerns today that didn't exist back then. Those issues need to be addressed, especially given the fact that we live in a world where computing and the internet in general is increasingly becoming part of everyone's lives, and what affects one group may affect everyoone. The first step usually takes the form of advocacy.

So if that advocacy is reactionary, and results in the unfortunate combination of a "Microsoft Haters Unite" slogan combined with a "It has to be just like Windows to compete" strategy, then so be it. It can't be any worse than the situation today where some, myself included, rue their once-cherished notion that making computers easier to use so everyone could use them would be A Good Thing.

I can understand why it may boggle your mind that that someone would merely want to "use" Linux or BSD to do basic PC things, but those PC things are increasingly becoming everyday things. To take a trivial example, I'm perfectly happy living in a terminal-based FreeBSD world, but there's not a day that goes by where someone doesn't send me a link to a YouTube video and I have to stop and think why I'm so annoyed, and who, if anyone, is to blame.

Life is political.

Re:A lot of buzz

[idiotnot]

He needs to avoid the sorts of black eyes that come from not properly testing massive fundemental changes to how the desktop works.

Which is what happens sometimes when you're feeding off the development branch of any project.

He needs to focus on not pissing off current users and scaring away the new ones.

And a six-month release cycle does nothing to meet either of those goals, when your repository depends so much on what's going on upstream. But OpenBSD releases every six months, too! Yes, and they control the toolchain, the c library, the kernel, etc. etc. And while some attention is paid to the software contained in the ports collection, it's not the primary focus. Furthermore, the code base is relatively stable (okay, so it's disgustingly stable, and I feel like it's 1994 all over again when I use OpenBSD), and it's not like things break hard between most releases.

He needs to continue to be the shiny happy face transplated on top of Debian.

I'm not so sure that Ubuntu is, or has, helped matters at all. Debian, RedHat, and SuSE do help, however, by somewhat stabilizing the platform, making it appropriate for mainstream (read: corporate) use. Windows XP is nearly ubiquitous, and it's almost seven years old now. Even Apple has gotten out of the near-yearly release cycle with OS X.

Six months is just too small a window to put out anything that resembles a quality product for the desktop. And making matters worse, the security cycle is only a grand total of eighteen months for anything other than the LTS releases.

Lately, for people wanting to try things out, I've been recommending Fedora for desktop use, and either Debian (though I am pissed....after spending probably half a day regenerating keys on my boxes), or CentOS.

Re:A lot of buzz

[BrianGKUAC]

You just verified his quote... "BSD is for people who love UNIX; Linux is for people who hate Windows."

Re:A lot of buzz

[bsDaemon]

The underlying philosophies that lead to the design and implementation of UNIX and similar systems are quite different from those that lead to the development of Windows, the original Mac, and systems like that.

If all I wanted to do was basic, every day tasks, Win2k or XP would be more than sufficient. I wouldn't need anything else. Application availability would not be an issue.

People complain that Photoshop and such aren't available for Linux, BSD, Solaris, whatever. But we have plenty of computer algebra systems, 3d polotters, modelers and CAD systems, physics simulators, etc.

We have the tools needed for collaborative development and scaleable deployment of computing systems to serve in scientific, engineering and infrastructure roles. That's what UNIX was about.

BSD UNIX was chosen during DARPANET days because of its TCP/IP implimentation, but also because it was portable enough to provide source-compatability across hardware achitectures, from minicomputers to mainframes.

It wasn't supposed to be "for grandma." Stallman and the FSF, with their evangelistic, holy-war approach to software may have confused the issue. "free software for everyone! information wants to be free!"

If the reason you want grandma to run unix is because you're sick of having to clean spyware off of her system, frankly it very well may be overkill. It's like using an elephant gun to hunt a squirrel.

But, as I said, I may be missing the point because I didn't switch to "get away from" windows. I adopted the system when i was barely a teenager because I wanted to do things that it provided me the tools for. Perhaps that's why I don't lament the lack of Photoshop or games.

However, it seems to me that if people want to come to a *nix system, they should take the time to learn how and why things are the way they are. I can see no benefit from trying to make the system more like windows, because it will just cause confusion and frustration.

Re:A lot of buzz

[fast turtle]

What sort of distro insists that you install software that you don't want or need? Answer: any prepackaged binary distro.

AFAIK: the only types that give "you" the end user the ability to decide what optional dependencies will be installed are source code based such as Gentoo or LFS. Otherwise you are stuck with some one else's decisions in regard to optional dependencies.

Re:A lot of buzz

[Uncle Focker]

If all I wanted to do was basic, every day tasks, Win2k or XP would be more than sufficient. I wouldn't need anything else. Application availability would not be an issue. But what if one wants a free OS to do all those things? Why should they have to have Windows? Why do you get so bothered over someone using your 1337 OS to do only simple tasks?

It wasn't supposed to be "for grandma." Stallman and the FSF, with their evangelistic, holy-war approach to software may have confused the issue. "free software for everyone! information wants to be free!" I don't really care who you've deemed it "for". My grandma uses Ubuntu just fine to do what she needs and saved herself a few hundred dollars over having to buy Windows.

If the reason you want grandma to run unix is because you're sick of having to clean spyware off of her system, frankly it very well may be overkill. It's like using an elephant gun to hunt a squirrel. No, I had it installed on the Dell machine she bought because it saved her money and it can do everything she needs.

However, it seems to me that if people want to come to a *nix system, they should take the time to learn how and why things are the way they are. I can see no benefit from trying to make the system more like windows, because it will just cause confusion and frustration. Why should they have to? I've never understood this attitude where one has to become a power user or one is banned from using .

Re:A lot of buzz

[Uncle Focker]

Why is asking why someone should have to pay for an OS just because they want to do simple tasks mean they hate Windows? If nothing, I find it completely asinine his statement that someone should have to pay 200+ dollars for an OS when all they want to do is browse the web and do email. This type of snobbery where you have to become a Linux kernel hacker or you need to GTFO, needs to fucking die already.

Re:A lot of buzz

[bsDaemon]

Its not about being "banned from using" -- its about the right tool for the job. Widnows isn't /terrible/, except maybe from an engineering standpoint. Vista may be terrible, but that's not the point. Win2k pro and XP pro are pretty unobtrusive.

Why is it that "the right tool for the job" only seems to apply between linux distros around here. if I were saying 'use a mac,' then I might get modded up for it, too though.

Look at it this way -- if I need to apply baseboard molding to the wall in my house, I /could/ use a nail gun, but a hammer would do just fine.

I would whole-heartedly endorse an operating system designed from scratch to serve the needs of plain ol' users. However, trying to take a model of operation and then bend it and break it into something it wasn't meant to be under the guise of "but it /can/ be all things to all people" seems a tad misguided to me, perhaps even lazy.

Of course, maybe its just that the implementations so far just seem to fall short.

Re:A lot of buzz

[Knuckles]

what sort of *nix system thinks you don't need a C compiler by default and makes you go looking for it in the repositories? Every security manual recommends leaving compilers off the system unless absolutely needed. And you make it sound as if "looking in the repositories" was some kind of horrendous chore.

Re:A lot of buzz

[bsDaemon]

When I assume something is there, because it always has been, and then its not, it pisses me off. Was adding it hard? No. Should I have had to do it? No.

Oh well. lesson learned and applied.

Re:A lot of buzz

[Uncle Focker]

Its not about being "banned from using" -- its about the right tool for the job. And a free OS that does everything she needs is the right tool for the job.

Widnows isn't /terrible/, except maybe from an engineering standpoint. I never made any such pronouncements on the quality of Windows.

Vista may be terrible, but that's not the point. Win2k pro and XP pro are pretty unobtrusive. And they also cost more money for some people than it's worth when a free OS can do everything they need.

Why is it that "the right tool for the job" only seems to apply between linux distros around here. if I were saying 'use a mac,' then I might get modded up for it, too though. Why is it that you care what some random person uses to do what they want?

Look at it this way -- if I need to apply baseboard molding to the wall in my house, I /could/ use a nail gun, but a hammer would do just fine. Yeah, and if all a person wants to do is browse the web and read email, why should they spend a few hundred dollars for an OS that they don't need?

I would whole-heartedly endorse an operating system designed from scratch to serve the needs of plain ol' users. However, trying to take a model of operation and then bend it and break it into something it wasn't meant to be under the guise of "but it /can/ be all things to all people" seems a tad misguided to me, perhaps even lazy. What is being bent and broken in Linux to do basic tasks like read email and browse webpages? You've still yet to explain exactly why anyone should not use Linux other than your snobby attitude that they either have to be a power user or they need to GTFO.

Of course, maybe its just that the implementations so far just seem to fall short. Fall short of what? With Ubuntu most regular users can do all the basic tasks they need. Not everyone uses BSD or Linux to do kernel hacking and code development nor should that be a requirement for usage. Seriously, get over yourself. You're not cool and 1337 cause you use a *nix OS and you can stop trying to force people away because they don't share your snobbiness.

Re:A lot of buzz

[xenocide2]

The problem Shuttleworth is addressing is upstream packages that are out of date. They have random or at least highly unpredictable release schedules that don't seem to work well for anyone. By suggesting a specific date for releases, Shuttleworth is attempting to shift a small burden to upstream to relieve a much larger strain in Ubuntu. Once the Freezes are past, it takes significant work to backport a bugfix patch to the feature frozen package. I think Shuttleworth's case would be greatly helped if he could point to a smallish project and how exactly it synchronizes with Ubuntu. I suspect his goal is KDE however, so a more general "this is healthy" essay is all we'll get.

Strategically, if upstreams were to do this on Ubuntu's cycle, Ubuntu would essentially be the Open Source release engineers, and many more upstreams would be invested in Ubuntu's release process. Some people recognize this and ask why they should follow Ubuntu over their own distro of choice, to which Shuttleworth said if any two distros could agree on a date, Canonical would follow suit.

Re:A lot of buzz

[SanityInAnarchy]

For whatever reason, people have decided that a holy quest to "destroy Microsoft" and encourage wide-spread adoption of gnu/linux-based operating systems would be totally awesome. Mostly for the reason that if this did happen, we wouldn't have to deal with Microsoft.

Simple example: I have to know how to setup and use Samba, so I can share files with Windows. If Linux was the majority, it would be Microsoft who would have to implement a decent NFS (or ssh) client instead.

Mint is even better with its media support, but completely lacks dev tools if you install from the live image -- seriously, what sort of *nix system thinks you don't need a C compiler by default and makes you go looking for it in the repositories? A smart one?

I remember loving Gentoo because of this kind of thing -- nothing preinstalled except the bare minimum to boot, get a commandline, and run the package manager. After that, it's up to you to grab the rest. I've done the same with minimal Debian installations -- it's awesome.

I would much rather be able to type "sudo apt-get install gcc" than have the machine assume I'm a C programmer. Even better, on Ubuntu, I just type "gcc" or "make", and if it's not installed, the error message tells me exactly what command to type to install it from the package manager.

The systems are targeted at different sets of people with different requirements and philosophies. Holding off on releasing Red Hat until Ubuntu is ready, which requires KDE and GNOME to sync up (more or less) sounds a little ridiculous and over-the-top. That, I agree with.

Re:A lot of buzz

[bsDaemon]

I don't want to be cool or l33t. I'm not being a snob. But the crux of your argument seems to hinge on not wanting to pay for anything.

Most people don't build a computer, they buy it. It come with Windows on it, pre-configured to run with the hardware, and they don't mess with it any farther than that.

Take a look, for instance, at this computer at CompUSA. Even assuming that I don't mail in the rebate, I'm not likely to come out of the store with those same parts for any substantial savings. Windows is more or less "free" at that point.

Even given the economic argument, I'm still not buying it. Then again, people around here do seem to enjoy getting things for free as in beer. Can't say I don't enjoy free stuff, just that I'm not going to make some sort of stand on it and try and evangelize the crap out of it.

If people want to use it, I'm sure they'll find it on their own. I'm not a salesman, and I'm sure as hell not an evangelist. When I was a teenager, sure. But you know what, no one really seemed to give a shit that MS had crappy business practices or shoddy software, or that BSD and Linux were more solid or "free" or "open source" or anything else -- except for some people.

There were a few kids in high school that used linux because "m$ sux0rz." They were the same ones obsessed with "swordfish," "the matrix," "antitrust," and films of that nature. They were the ones that wanted to be bad-ass h4x0rz and 1337. they also had no friends.

I'm just saying that I can't see a compelling reason for average users to up and swap OSs for basic tasks, when they had one that was alright for it in the first place. I don't know anyone who's ever actually bought Windows to put on a computer, so Linux doesn't seem like a cost-saving thing for me.

Re:A lot of buzz

[ZephyrXero]

I think this whole silly idea is the result of there still being confusion about the difference between a "distro" and an operating system. Sure...you can get technical all you want, but by the modern/common definition of an OS today, Red Hat and Debian are two completely different operating systems that just happen to be built off alot of the same components and have some similarities. Now, something like Ubuntu could be called a distro of Debian, but never a "Linux distro" because there is no such operating system as Linux. It's just the kernel, it's only a component of an OS. The term: "distribution" invokes the mental concept of a set of packages preinstalled and possibly even preconfigured for a particular OS. Just for example, if there were "Windows Distros" one might imagine there being a "MS Core" distro, which is basically what you get with a standard XP install...but then somebody named Bob put's out "Bob's Windows Distro" which comes with Firefox, VLC and Open Office preinstalled. That is what the term distro implies, not an entirely different OS which is binary incapable with other OSes of the same family. Linux is not an OS, simply a family of similar OSes. Apparently some distro devs and Mark Shuttleworth are still ignorant to this.

Just like the parent implied in his/her post... People don't look at FreeBSD and OpenBSD and assume they're just different "distros" of the same OS...no they're two completely seperate entities that share a few similarities here and there.

There's no since at all in syncing up the Linux family of operating systems when you stop improperly calling them "distros".

@MarkS:
Stop calling it "Ubuntu Linux"... you can call it "Ubuntu Debian" or just plain ol' "Ubuntu"... and then this whole thing won't be a problem anymore. You're not looking for developers and users to get behind "Linux" as much as you want them buying/developing for Ubuntu. This is the only way it will ever work with the mainstream market. Even though free (as in price), Ubuntu is a product, but Linux never will be.

</twoCents>

PS: I think the main problem that really inspired the idea is that not all the different open source projects line up as neatly/easily with Ubuntu as Gnome and it's subprojects...plain and simple ;)

Re:A lot of buzz

[Knuckles]

Why are you (who can change it easily) more important to cater for than other users who are better off without a compiler?

Re:A lot of buzz

[Anonymous Coward]

Yes there are Linux Users out there. My wife uses Linux to do digital scarp booking. There are a large number of women using GIMP to do digital scrap booking. Oh her scrap booking forums you will see them talking about how everybody should use Firefox as well... sounds like the typical internet effect where a couple people on a forum convince themselves they are a mass movement

Re:A lot of buzz

[VGPowerlord]

Also, with the Ubuntu LTS releases patches are made to deal with security issues. You don't necessarily want an application that was just released a month earlier.

Or beta software... yet Firefox 3 beta 5, both a beta and less than a month old at the time of the LTS release, is in the LTS release. Whoops!

Re:A lot of buzz

[obsolete1349]

"a simple 'wget' and 'make' later and he has himself a back door" And a simple 'wget' of a binary already compiled and he has his back door. Isn't that how they do it on Windows?

Re:A lot of buzz

[garett_spencley]

It would have to be compiled specifically for that machine, or network tools can be limited to a specific group as well.

When I harden filesystem permissions I lock down /sbin and /usr/sbin to remove the read and executable bit from the directory and also to remove read and exec bit from all binaries that aren't required by normal users (it's really lame how many user tools end up in sbin) then I limit dev tools and network tools to specific groups. So ping, wget, ftp, ssh, telnet etc. is all restricted as well as compilers, interpreters etc. (except bash for obvious reasons). I also restrict system diagnostic tools like uptime, ps, who, last etc.

And anything that isn't absolutely required gets uninstalled. Usually dev tools are required though for compiling new versions of php etc.

Re:A lot of buzz

[turbidostato]

"If some distributions use a common set of libraries and applications then why shouldn't they be interested in better synchronization with upstream development? It doesn't matter who the distribution is targeted at."

This would be perfect. If Ubuntu and Red Hat CEOs meet and decide they'll cooperate to, say, offer the same version of glibc or Gnome, so be it, that would a matter between Ubuntu and Red Hat. But this is not, and can't be, a "Linux issue" as Sutthelworth tries to make it appear.

On the other hand, to those that say what a fantastic thing it would be for all Linux distributions to somehow merge into one (common package managers, common desktops, common launch dates, etc.) I propose a little mental experiment: think for a moment you are Red Hat's CEO (or any other distribution for that matter). Well, I'm Red Hat CEO now, what a wonderful thing it would be if we had the same package manager, desktop, launch dates... than Novell's Suse in order to ease user's experience and interchangeability. Hummm... wait a minute, if we are *so* interchangeable with Suse, why the hell would people take Red Hat over Suse? What would be our market advantage? All I can think of is being cheaper than them, maybe offer more for less (which is just another for being "cheaper"), and so exactly Novell's CEO would think; we would end up on a decreasing profit margins war till one would buy the other -or more probably a more profitable company would take us both out of the market. Hummm... I'm a worthable CEO, so I think I'll stick with being *different* and then use all my experience, knowledge and tools -marketing, price, technical excelence, market partition... to make my difference into bussiness advantage. And so will think Novell's CEO, and so the worlds keeps running.

It could go two ways

[Phyrexicaid]

Either the greater collaboration would find bugs like the Debian ssh fiasco quicker,
or every Linux distribution would be affected by the same bug.

Re:It could go two ways

[RiotingPacifist]

That's irrelevant the debian fiasco was some developer deliberately changing some code to integrate it into debian better, distro synchronisation would happen above that level, only fixes to actual upstream code would be synchronised, not integration tweaks.

Not only a development issue

[houghi]

It is also very much a marketing issue. Especialy those companies (Novell and RedHat) who sell their distributions. There is no financial reason for them to adopt to somebody elses time line.

Software development is always a process. This means that there will always be differences in speed for different reasons. Next you will be wanting that KDE, GNOME and XFCE bring out a new release at certain points in time. What about browsers?

What if KDE or GNOME is delayed, would that mean the whole world has to wait? I would say, release early, release often.

With all the things that is going on, what would be nice is a 'current' release all the time. So not so much version based, but much more date based. meaning no matter when I download something, I will get the latest (stable) version of whatever is available, without the need of waiting for the rest of the distro to be ready.

I am aware that that is more wishful thinking, yet so is Mark's idea and mine is better.

Re:Not only a development issue

[RiotingPacifist]

meet debian lenny (testing)

Re:Not only a development issue

[Anonymous Coward]

welcome to the rolling releases world

Re:Not only a development issue

[Anonymous Coward]

With all the things that is going on, what would be nice is a 'current' release all the time. So not so much version based, but much more date based. meaning no matter when I download something, I will get the latest (stable) version of whatever is available, without the need of waiting for the rest of the distro to be ready. ummm, it's called a "rolling release" distro, and there a quite a few around. Arch Linux is my favourite. I will never go back to a schedule release distro.

Re:Not only a development issue

[Anonymous Coward]

Which is not stable _all the time_. It's called testing for a reason. ;)

If it ain't broke...

[file_reaper]

...then why fix it? No seriously, is there something really wrong with the way distro's are released today? Or is this just for Ubuntu to add another check to the "we invented that here" list. Plus there are the excellent points made in the above post "A lot of buzz" by bsDaemon.

Re:If it ain't broke...

[maxume]

Please turn in your pine-needle hat.

Oh wow!

[Anonymous Coward]

A counter-proposal by Aaron Seigo? The guy behind Plasma, and the man most directly responsible for the total fucking up of the KDE 4 release cycle? KDE 4 is in shambles because of his ideas about release management. He was still adding basic features to Plasma after KDE 4.0 was already tagged a release candidate. The guy is a loon when it comes to release management. I'd rather have Ballmer dictate open-source release management than Seigo.

Re:Oh wow!

[lbbros]

And how does an ad hominem contribute to the discussion, let alone be "interesting"?

All I see..

[AlterRNow]

is that it will mean 3 ( or more? ) distros being released at the same time, thinning out the potential test-bed. People will either have to start looking at only one distro or provide late reviews of the new distros.

What do they do if one isn't ready? Delay the others? If not, surely it would go 'out of sync'..?

As someone else said. Distros will ( and should in my opinion ) do whatever they want to do, pertaining to their configuration, release cycle, whatever..

2008

[hansamurai]

And here I thought that 2008 was the year of Linux release cycle synchronization on the desktop.

Sync would please ISVs

[HighOrbit]

I think syncing the major distro's would be a boon to Linux overall. It would make support easier for third party vendors and ISVs, which might induce them to release more major Linux applications. For instance, Oracle or Adobe whould know that a particular version of their product would only have to support a certain kernel (altough each distro has patches) and a certain version of Gnome and/or KDE as opposed to ten different point-releases of kernel,KDE, and Gnome. The would know which versions of the Gnu utililities they can expect to support.

Anything that makes it easier to for major software vendors to release and support software makes Linux stronger.

Re:Sync would please ISVs

[dbcad7]

Point releases are no big show stopper.. Firefox and Open office seem to deal with it just fine. Now it's true that they distribute software through the distro repositories... but there is know reason for major vendors not to work with the major distros and distribute through repositories as well. (And yes I am including commercial apps)

Way To Go Aaron

[mpapet]

Shuttleworth's idea is designed to further Ubuntu at the expense of the projects packaged therein. Specifically, he's trying to shift quite a bit of the release work onto the projects he packages.

Aaron's post is a must-read for anyone vaguely interested in the topic. In particular,
It is not overly dramatic to say that if we make Free software development overly sterile via choice of process, there will be a commensurate diminishment in participation and momentum. I interpret that as Aaron recognizing the corrosive effect on the entire dev community by adopting Shuttleworth's scheme.

Better still, Aaron offers constructive alternatives. It's really nice to read and should be a template for most blogging.

Someone please explain why Shuttleworth's idea hasn't been swatted down the day he posted it.

Today's lesson: Learn to disagree without personal attacks and offer viable alternatives.

Re:Way To Go Aaron

[Uncle Focker]

Yeah, Aaron did a bang up job with the release of KDE4... oh wait. Considering that major clusterfuck, I almost died laughing reading his rebuttal to Shuttleworth.

Re:Way To Go Aaron

[lazy_nihilist]

Shuttleworth has a done a great job with Ubuntu. I think his latest idea about synchronizing releases is a good one myself. But as always, I might not be right. The best thing this has done is we have come up with a discussion on how to make release proccesses better for the improvement of the whole Free Software Community.

As you said, we should learn to disagree without personal attacks and offer viable alternatives. Now that Aaron Seigo has provided an alternative view, we can discuss that as well and try to improve the overall process. If we can do that properly I see this only benifitting the FOSS Community.

Re:Way To Go Aaron

[Eponymous Bastard]

Did you even read the articles?

Shuttleworth is saying that if the distros synchronized, upstream developers would have better information about release cycles and could chose whether to target a particular release with their new features or not (essentially, when to branch for release and focus on stabilization). If it's not ready, then it's not ready and just shoot for 6 months later.

This guy Aaron makes a good point in that this shifts work upstream, but I don't agree that this is disruptive. Aaron's great idea? Have the distributors basically go into each and every project and make and manage the release branches themselves! Imagine someone else coming into your project and going "We're branching here because I said so". Gee, not very good with people is he?

If the distros synchronize, upstream can just ignore it if they feel like. There isn't really much of a downside. If you do chose to synchronize you can still have features released when they are ready, but deployments (releases/tarballs) happening on schedule. It's just a matter of which branches you merge.

On Ars' theory that big changes are prevented by a branch and merge, timed release approach, GCC has used a 3-stage (major change, improvement, stabilization) release cycle since GCC 3.1 in 2001. Rather large changes have been done since then until the 4.4 branch in development. Granted, Mark Mitchel has done a superb job at release management (i.e. cat herding) and recently had 3 more people join in in this job.

Even Linus does this fairly often (change too big, goes in next version so we can push this one out the door)

At best, distros could help with consulting and advising on this job, but the release planning and management must come from within each community. His point about shifting work is good, and release management for big, flaship projects could be provided by people from each company (as I'm sure redhat et al have people working on each project anyway), but big projects probably have something like it established anyway.

I'm still not seeing the downside to synchronized but ignorable schedules downstream.

Aaron Seigo's proposal

[Anonymous Coward]

Aaron Seigo proposed that instead of the major Linux distros synchronizing their releases, they should all immediately release whatever they have planned for the release after next. Release early, release often!

Therefore, Fedora should release Fedora 11, Suse should release OpenSuse 13, and Ubuntu can release 9.04. Of course these releases would be a shamble of hastily jumbled together alpha software and would barely function, but this way KDE4 would fit right in!

Emperor's New Clothes

[Anonymous Coward]

That is a pausible explanation for letting the idea fly more than 24 hours. Many "kids" pointed the absurdity time ago, even if things like FF3 version in a LTS was not a demostration enough that if things are going to be enforced by calendar, you keep the mess under your full responsability when other things slip, or just do not want to follow you, as they did not command you to package their code. Luckly a developer with some weight pointed the flaws anyway.

This would make yesterday's lesson: learn to propose things that are viable, then earn and keep leadership by example, not by force. His plan sounded a lot like "follow my plan because I started Ubuntu and I say so". Sadly, OSS do not have to follow such plans.

An inordinately difficult problem to solve

[KeithH]

Release synchronization is an issue that I deal with on a daily basis a work. We have multiple huge telecom products that share common code. It's a tough problem.

Currently, each Linux distribution has a difficult enough time coordinating the contents of their own release. They expend much effort attempting to avoid applying custom patches. They want to be as "stock" as possible and as current as possible with-out incurring some new dependency that will break another package. Meanwhile, code owners are invariably trying to be as bleeding edge as possible.

The proposal to synchronize distribution releases ignores the fact that the real problem is the independence of their constituent packages.

At the end of the day, the proposal will add another dependency and a big one at that. You will wind up with each distribution being asked to "hold on and wait" while the others try to bring their own packages up to the most current release - and that's not necessarily a good thing.

Some releases will want to be more bleeding edge while others will insist on sticking with the well-tested versions of their packages.

All-in-all, it's a nice but impractical idea.

Meh...

[ZarathustraDK]

I can understand why you'd want synchronicity when you're working with a project as big as Ubuntu.

But still, for the overall health of Open Source software, running asynchronous is more beneficial, as errors spotted in one major distro will urge the next major distro in line to pay attention to this particular problem.

It'd suck big time if all major distros committed the same mistake, and would have to wait 5-6 months to correct them, giving companies like MS ample time to astroturf/FUD in their favor. Best leave this one alone Mark.

Prime example:

[SanityInAnarchy]

See KDE4.

KDE 4.0 is missing roughly 80-90% of the features in KDE3. I'm told they still exist in config files somewhere... undocumented. May as well be in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying "Beware of the Leopard".

I'm told KDE 4.1 will have all the features KDE3 did, all wrapped up in nice GUI checkboxes so us mortals can use them. Which would make it up to the standards of a dot-0 release.

Re:Prime example:

[Anonymous Coward]

Your estimate of the number of missing features is 80-90% ignorant. There are actually more features in KDE4 than in KDE3, what there wasn't in 4.0 were some highly visible features or GUI configuration for them in *plasma*.

Re:Prime example:

[SanityInAnarchy]

There are actually more features in KDE4 than in KDE3 From a user perspective, no there weren't. There were no docs pointing me to config files, and there were pretty close to zero options for configuring things.

I realize there were some new features in 4 that weren't in 3, but you also managed to drop a lot of pretty basic features from 3.

what there wasn't in 4.0 were some highly visible features or GUI configuration for them in *plasma*. Oh, where do I start...

I ran a Wine app at some point -- possibly long gone now -- it installed icons for itself on the "desktop". On every boot, Plasma creates those icons. I can click the red X to remove them, but they'll only be back at the next login.

I did find an option to shrink the panel. Problem is, once it gets small enough, the K menu button actually wraps around and appears at the top of the screen. This causes a few other interesting problems.

Where's my keystroke to open the K menu? I like the new K menu as, say, an alternative to Katapult, along with alt+F2. But without a keyboard shortcut to open it (which even Windows has), it's useless. There was a similar lack of keyboard shortcuts elsewhere in KDE4, leading me to use the mouse far more than I should.

I could go on...

In short, it wasn't ready. Calling it a dot-0 release, and then telling us things will be ready in 4.1 or 4.2, is a very Microsoft thing to do, and is an insult to other projects which actually have all the functionality ready by the beta.

And calling me ignorant for not knowing things that only a developer could know doesn't help.

That explains it...

[SanityInAnarchy]

So this is where we got the horror that is the KDE4 Panel.

Re:That explains it...

[RiotingPacifist]

In fairness the panel wont be finished till 4.2 at earliest, atm they're doing a lot of cool backend stuff. Atm its just small details they dont like giving you control over, i just hope it doesnt get to the point where somebody has to make fun-kde.

because they did such a great job

[colonel crayon]

It's hard to support a release-timing proposal from either Shuttleworth, whose company released a bug-riddled Long Term Support release, or Seigo, whose project just released a desktop environment that is almost unusable.