Beta
×

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

Thank you!

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

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

Debian Decides To Adopt Time-Based Release Freezes

Soulskill posted more than 5 years ago | from the regular-intervals dept.

Debian 79

frenchbedroom writes "The ongoing Debconf 9 meeting in Cáceres, Spain has brought a significant change to Debian's project management. The Debian project will now freeze development in December of every odd year, which means we can expect a new Debian release in the spring of every even year, starting with 'Squeeze' in 2010. Until now, development freezing was decided by the Debian release team. From the announcement: 'The project chose December as a suitable freeze date since spring releases proved successful for the releases of Debian GNU/Linux 4.0 (codenamed "Etch") and Debian GNU/Linux 5.0 ("Lenny"). Time-based freezes will allow the Debian Project to blend the predictability of time based releases with its well established policy of feature based releases. The new freeze policy will provide better predictability of releases for users of the Debian distribution, and also allow Debian developers to do better long-term planning. A two-year release cycle will give more time for disruptive changes, reducing inconveniences caused for users. Having predictable freezes should also reduce overall freeze time.' We previously discussed talks between Canonical and the Debian release team about fixed freeze dates."

cancel ×

79 comments

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

Linux: Debian (3, Insightful)

BadAnalogyGuy (945258) | more than 5 years ago | (#28867143)

Two things to note.

First, the small font used for the non-mainpage stories makes me read the story title as "Lesbian decides to adopt time-based release freezes".

Second, limiting an OSS project to a time-based release cycle puts an artificial constraint on the development process. While it might be useful to encourage faster development in some cases, it is just as likely to force a new feature to be dropped at the last minute if it can't make it through the door in time.

I'd rather they stick with feature-based releases which focus on the quality of features rather than trying to force feature development into a specific duration.

Re:Linux: Debian (4, Interesting)

nosfucious (157958) | more than 5 years ago | (#28867203)

And refering to Spring/Winter is too imprecise. It's currently (July) Winter in the Southern Hemisphere.

Try refering to Quarter 1, Quatert 4, etc for times of the year.

However nit picking aside, at least we shall now get some certainty in the releases of (probably) the worlds best distro.

8-)

Re:Linux: Debian (5, Funny)

Anonymous Coward | more than 5 years ago | (#28867363)

a.) It says December, I'm pretty sure December is always in December no matter what hemisphere you're in, which makes it pretty obvious what they mean by Spring.
b.) No one cares about the Southern Hemisphere.

Re:Linux: Debian (2, Funny)

lordandmaker (960504) | more than 5 years ago | (#28867473)

The release in the Southern Hemisphere has an extra six-months of bug squishing.

Re:Linux: Debian (1, Insightful)

Anonymous Coward | more than 5 years ago | (#28870021)

Have you seen the spiders in Australia? I think you guys need the extra 6 months...

Re:Linux: Debian (1)

grub (11606) | more than 5 years ago | (#28869037)


However nit picking aside, at least we shall now get some certainty in the releases of (probably) the worlds best distro.

We already do: OpenBSD comes out in May and November. Not that it's a "distro" but...

Re:Linux: Debian (0)

Anonymous Coward | more than 5 years ago | (#28869079)

Especially now that Canonical is keeping Debian on a short leash...

Re:Linux: Debian (1)

fuzzix (700457) | more than 5 years ago | (#28867311)

I'd rather they stick with feature-based releases which focus on the quality of features rather than trying to force feature development into a specific duration.

You should try Slackware - Pat only releases when ready.

Apt broke on me again this morning (this time during an upgrade). Find myself thinking "Guh, I wish this was Slack" every time that happens.

Re:Linux: Debian (1, Insightful)

Anonymous Coward | more than 5 years ago | (#28867347)

You can always tar/configure/make in Debian just like you can in Slackware.

Re:Linux: Debian (1)

fuzzix (700457) | more than 5 years ago | (#28867481)

You can always tar/configure/make in Debian just like you can in Slackware.

I don't generally build from source...

Re:Linux: Debian (1)

palegray.net (1195047) | more than 5 years ago | (#28877941)

Huh, apt broke on you [again]? Are you running testing?

Re:Linux: Debian (5, Insightful)

TREE (9562) | more than 5 years ago | (#28867427)

No schedule, feature based or time based, will have all upstream developers in sync. Someone will always be developing new stuff and want to squeeze it in.

At least this way, there's a known target that developers can be (made) aware of.

Re:Linux: Debian (2, Insightful)

lenzm (1238440) | more than 5 years ago | (#28867463)

All releases are artificial constraints. There's always new features that could be included.

Re:Linux: Debian (2, Interesting)

noundi (1044080) | more than 5 years ago | (#28867561)

Second, limiting an OSS project to a time-based release cycle puts an artificial constraint on the development process. While it might be useful to encourage faster development in some cases, it is just as likely to force a new feature to be dropped at the last minute if it can't make it through the door in time.

At the same time a release can be delayed for the opposite reason and you end up delaying the entire project due to some packages.

The trick to avoiding your scenario and my scenario is by carefully picking the most appropriate intervals. Not too long between as this will drag out development leaving already stable and wanted features on hold for a longer time than necessary, and not too short leaving unstable features dropped or hurried out. The best way to do this would be to categorize your packages in different priorities, then gathering all the most important packages and calculating a suitable interval spectrum which is then used as the foundation for choosing the exact dates after having reviewed the less critical packages. Of course this won't please "everybody", but there is no solution for that. The only possibility is to please "as many as possible" in relation to their importance. To make it clear I'm personifying software packages when I refer to them as "everybody" and "as many as possible".

Re:Linux: Debian (3, Interesting)

clang_jangle (975789) | more than 5 years ago | (#28867647)

...limiting an OSS project to a time-based release cycle puts an artificial constraint on the development process. While it might be useful to encourage faster development in some cases, it is just as likely to force a new feature to be dropped at the last minute if it can't make it through the door in time.

I definitely agree, however I expect this decision was driven by concerns that Debian's popularity with businesses [debian.org] might be threatened by Ubuntu. Pointy-haired types like to see "regular" release schedules, rather than "we'll release it when it's done".

...the small font used for the non-mainpage stories makes me read the story title as "Lesbian decides to adopt time-based release freezes".

You might want to revisit your browser's font configuration then. I certainly would never depend on the font choices of web designers. :)

Re:Linux: Debian (0)

Mistshadow2k4 (748958) | more than 5 years ago | (#28867965)

First, the small font used for the non-mainpage stories makes me read the story title as "Lesbian decides to adopt time-based release freezes".

Me too! My first thought was, "I guess the lesbians from the porn industry get used up so fast that they want updated versions every couple of weeks or so." Yeah, I could see where that would get annoying to the lesbian developers.

Re:Linux: Debian (1)

tuxgeek (872962) | more than 5 years ago | (#28869181)

"limiting an OSS project to a time-based release cycle puts an artificial constraint on the development process.Agreed
Debian is noted as producing extremely stable packages on a stable distribution. They're outdated by Ubuntu or Fedora standards, but they also don't crash the system frequently with buggy applications.

For Debian to put their distro on a fixed release schedule could limit the effectiveness of their product. I think they should just stick with what has worked for them so far. Maybe just produce a new upgrade release on an annual basis and just stay away from the Ubuntu release model. Once per year should allow enough time to stabilize a cool feature such as KDE 4.2 or the latest kernel technonogies, among other advanced features.

Re:Linux: Debian (1)

FudRucker (866063) | more than 5 years ago | (#28870251)

i agree with the "Once per Year" thing, any more often than once a year is just not necessary...

Re:Linux: Debian (0)

Anonymous Coward | more than 5 years ago | (#28869231)

Second, limiting an OSS project to a time-based release cycle puts an artificial constraint on the development process

Correct. This is why it is a benefit. Without the artificial constraint the release date becomes a topic of controversy and developers inevitably kick the can down the road. Timed releases provide a real point around which contributors may plan; this is absolutely invaluable for a losely bound collection of peers because the date ceases to be a topic of debate.

It is hard to argue with success; Ubuntu uses timed releases and they appear to be doing fairly well, no? Linus imposes arbitrary dates on kernel releases to herd his cats as well.

I'd rather they stick with feature-based releases which focus on the quality

Quality. Yeah. Whatever. Stay away from Debian, Ubuntu or the kernel. They don't want you messing up their releases with your "quality." Your notion of quality is but one factor. Risk is another. Testing time is also important.

Release early, release often. Quality is more function of talent than time.

Re:Linux: Debian (0)

Anonymous Coward | more than 5 years ago | (#28869447)

I'd argue, however, that there's a world of difference between an originating project and a distribution project that's (theoretically) a compilation of work from a substantial number of other projects, which guarantees that upstream schedules (whether time-based or not) won't be synchronous. For distributions, you'll never be "up-to-date", so time-based releases are about as valid as any other approach. I don't see any reasons for it, either, though...

Of course, Debian includes substantial infrastructure (e.g. apt) and tons of patches on all their packages, so they're actually somewhere in between.

Re:Linux: Debian (1)

br00tus (528477) | more than 5 years ago | (#28870005)

As a former Debian user, current Ubuntu (and Gnewsense) user, I say this is completely ridiculous.

I was one of those unfortunate users of Debian 3.0 stable (woody). It was released in July 2002. The next release was (two week shy of) three years after that. Way, way too long. You think a *two year* cycle is too short? Your philosophy leads down the Duke Nukem Forever, Gnu Hurd path. Yes, there is plenty of crap that gets rushed out too fast due to deadlines that make no sense, but on the other end of that is development that goes nowhere and never releases anything. You have to find a happy medium.

Python 2.2 was released in December of 2001. Woody was released in July 2002 and used Python 2.2. Python had released Python 2.3 in July 2003, Python 2.4 in November of 2004, and Python 2.4.1 in March of 2005 - and Debian stable was still Woody, running Python 2.2. From March to June of 2005, you were, aside from security updates, running the 2001 version of Python on your current Debian stable box. It is ridiculous. I was trying to run Python scripts written in 2004 and 2005 and couldn't because they were all based on Python 2.3+, if not 2.4.

One of the reasons Ubuntu got off the ground is because people were tired of stuff like this. I like Debian's commitment to free software, but if you don't deliver a product people will look elsewhere. I can't imagine switching back, I am happier with Gnewsense - Ubuntu with all binary blobs and junk ripped out.

Re:Linux: Debian (2, Insightful)

AlXtreme (223728) | more than 5 years ago | (#28872081)

I like Debian's commitment to free software, but if you don't deliver a product people will look elsewhere.

They did and do deliver a product: a rock-solid stable Linux distribution.

Some people care more about a stable environment (for servers or workstations) than the latest bells and whistles. That, together with the necessary security fixes, makes Debian the best distribution for me hands-down. And if you run Ubuntu or any derivative, you're still running Debian under the hood. Even if you don't need a rock-solid distribution, they allow other groups to give you those bells and whistles you want.

Rather than whine about those 3 years (hell, if you really needed an upgrade you could have tried out testing), be grateful that there are so many people out there that put this distribution together in their spare time and by doing so make your distribution possible.

Re:Linux: Debian (1)

jgrahn (181062) | more than 5 years ago | (#28881369)

I was one of those unfortunate users of Debian 3.0 stable (woody). It was released in July 2002. The next release was (two week shy of) three years after that. [---] From March to June of 2005, you were, aside from security updates, running the 2001 version of Python on your current Debian stable box. It is ridiculous. I was trying to run Python scripts written in 2004 and 2005 and couldn't because they were all based on Python 2.3+, if not 2.4.

Python is a bit of a special case, though. It's a great programming language, but IMHO the Python culture is way too bleeding-edge-oriented. As soon as Guido & co invent some new language construct, Python programmers are too eager to use it immediately, everywhere ...

Re:Linux: Debian (1)

sjames (1099) | more than 5 years ago | (#28895619)

Some Python programmers are like that. Personally, I use Debian as a gauge for which version of Python I program to for the simple reason that it's a great guide to what a stable but not antiquated system will be using. A good thing about Python is that the interpreter itself DOES offer ways to transition smoothly even if some programmers fail to take the hint. Importing from future can be your friend.

Some portion of programmers in ANY language tend to be too bleeding edge. Since they can't express their bleeding edgeness in the language standard itself (much too slowly evolving for them), they do it by insisting on requiring an obscure feature only available in the unstable "use only if you're a masochist" version of a library. I *REALLY* hate that since inevitably it will be a library that practically everything depends on and because of inappropriate internal API and version handling, you'll have to upgrade half of the system to "don't sneeze" level stability. Generally, when that happens I decide it's just not worth that much pain and I choose different software or just do without.

On the few occasions where I really had to have that functionality, I have dug in to the source to see if I could relax the dependencies a bit. The really sad thing is that often enough I could make one or two very minor changes that cost no functionality AT ALL and allow it to be compiled against the stable or oldstable version of the libraries.

Re:Linux: Debian (0)

Anonymous Coward | more than 5 years ago | (#28870187)

they are also changing the name of Debian to Debuntu

Re:Linux: Debian (1)

petermgreen (876956) | more than 5 years ago | (#28870475)

it is just as likely to force a new feature to be dropped at the last minute if it can't make it through the door in time.
The problem is with a project as huge as debian is that there is always some feature that can't make it through the door on time. Sooner or later you have to say enough is enough and it is time to polish up what you have and get a release out the door.

Re:Linux: Debian (1)

Wowsers (1151731) | more than 5 years ago | (#28870825)

...a time-based release cycle puts an artificial constraint on the development process

This I would agree with. Sometimes I install the cooker version of Mandriva (most up to date versions of the next version of Mandriva) to test the packages, testing the install as some Windows users would do (update instead of total wipe). Reporting certain bugs naturally get higher importance to fix, but depending on how many coders work on a particular part of the OS, the fix could take an age to materialise, and sometimes misses the release schedule date.

you are talking about feature freezes (0)

Anonymous Coward | more than 5 years ago | (#28874075)

I really think you got it backwards regarding time based releases.

Your complaints really apply to _any_ sort of feature freeze, whether it's time based or feature based. Even if it is feature based, there will still be more incomplete features that someone wants to include. The only way to prevent a dev from being artificially constrained is to get rid of feature freezes altogether. But, no distro would be able to work with that.

The better way to look at it is to look at what a distro gives to the upstream: bug reports and feedback. If different distros featurefreeze on different versions, then upstream is getting said feedback from multiple distros regarding multiple old versions. Obviously, the more different old versions that people are using, the more confusing and less useful this feedback will be.

The point of time based releases is that they make it easier for distros and projects to synchronize. In this case, instead of upstream having to work with Debian's feature freeze and Ubuntu's feature freeze, they now only have to work with a single Debian/Ubuntu feature freeze. Having less feature freezes to worry about should free up the devs.

So, time based releases actually help, not hinder.

BTW, I recommend Mark Shuttleworth's blog. He has been talking about this issue, and he brings up allot of interesting points. Take care.

Re:you are talking about feature freezes (1)

turbidostato (878842) | more than 5 years ago | (#28922369)

"The better way to look at it is to look at what a distro gives to the upstream: bug reports and feedback. If different distros featurefreeze on different versions, then upstream is getting said feedback from multiple distros regarding multiple old versions. Obviously, the more different old versions that people are using, the more confusing and less useful this feedback will be."

I'd say that's because most upstreamers don't give proper engineering a damn. Since they usually only deal with their own little portion of the software landscape they usually don't pay attention to those "little" issues as segregating delivering bugfixes from new features, feature and bug regressions or simply making clear what they are going to support with regards of stable vs on-development versions.

Distributions, on the other hand, are all about integrating thousands or even tens of thousands of software packages so they simply can't go with "bleeding edge" if only because "bleeding edge" means different things to different software projects. I'd bet that if there's a solid commitment from software project foo about saying "version X.Y is our stable release and so it will be supported at least for X months/years" distributions would gladly use X.Y instead of X.Z on their stable launches; but since there's no "blessed versions" each and every distribution publishes "whatever is current now" which ends up with different distributions using different versions.

Even then, I don't see so many bugs against old versions being managed as they should be: they usually are not accepted or not analysed on the grounds of "use our bleeding edge version bar and see if the bug is still there". They forget that on one hand more obscure bugs will only show on special circumnstances and they are a treasure and on the other that even if it's an old release the bug is still there; they could have a case if they could say: yessir; your bug #12345 affects version 1.2.3 but it's corrected on 1.2.5; as you know, extraversion number means that exclusively bugs are corrected but functionality is unchanged so you can easily drop it out on your environment without worries. Maybe then distributions like Debian wouldn't be so hard on not upgrading programs within the same distribution versions and doing locally their backporting (and probably reinventing the wheel, and probably not by the best fitted individuals).

"Having less feature freezes to worry about should free up the devs."

That's a lost battle and upstreamers wouldn't need to worry about destribution freeze times *at all*: it's neither their bussiness nor anything they can control. What they can do is making the commitment of publishing a stable and supported version of their software and then distributions could use it on their products. It might happen that their glarining new version slips by days to the freeze date of distibution X but that won't worry neither the upstreamers (well, they'll use it on their next release) nor the distribution (am I choosing the "proper" version of this software or will it be a transtional one that will go unsupported in few months or even weeks?).

"I recommend Mark Shuttleworth's blog. He has been talking about this issue, and he brings up allot of interesting points."

I don't follow his blog but from time to time to give it a fast look but on my opinion, while not saying he has not some good ideas, they're not ideas I didn't read before anywhere else and they all seem just a bit too much as those end user "magic recipies" the like of "that many Linux distributions only spread efforts instead of concentrating them; there should be only one distribution". Well, which one then? "The one I happen to use, of course".

Re:Linux: Debian (1)

sjames (1099) | more than 5 years ago | (#28895037)

Any release of an active project will tend to be somewhat arbitrary anyway. There's always something that will be ready in "just a few days". Just a few delays for "just a few days" has a tendency to turn in to never.

One positive aspect of the time based freeze is that it will surprise nobody. If you're a Debian maintainer working on a big new feature, you know right now how long you have before the freeze and can scale appropriately.

So They're Not Relasing Every Tuesday? (0, Offtopic)

filesiteguy (695431) | more than 5 years ago | (#28867169)

I thought Debbie and Ian were releasing patches on Tuesdays. Am I wrong?

Oh, wait, it is *that* company.

Nevermind.

Seriously, I wonder why the ridgid schedule. Wouldn't it be better just to release when things are "ready"?

Re:So They're Not Relasing Every Tuesday? (1)

noundi (1044080) | more than 5 years ago | (#28867641)

Wouldn't it be better just to release when things are "ready"?

Would you want to delay an entire OS due to the newest associated IM not being ready? In other words if you're hungry now, would you care for the larger part of the cookie now or would you rather stay hungry and wait for the whole cookie?

Re:So They're Not Relasing Every Tuesday? (1)

filesiteguy (695431) | more than 5 years ago | (#28870803)

(Ooh, I got an off topic mod for an on-topic question. Love it!)

I wouldn't delay the OS. I was referring to more the other direction. You would want to release when it is ready, even if that is prior to the scheduled date.

I - in a way - use Debian since I've switched from openSUSE to Ubuntu, so I'd be curious if Ubuntu would be affected.

Re:So They're Not Relasing Every Tuesday? (1)

noundi (1044080) | more than 5 years ago | (#28878049)

You would want to release when it is ready, even if that is prior to the scheduled date.

Within most FOSS projects "ready" is a very relative term. Most of us have probably used a lot of good functioning software before it was ready. Take Firefox 3.5 BETA for example. It worked close to as good as 3.0 in terms of stability. The problem with your reasoning is that you treat the project as a whole, which is fine, but never forget that these packages often have independent devs whom don't really care about your cycle at all times. So even if application X will be ready in time, the devs for application X will instantly work on next version, unless you choose the less featured stable. Ubuntu solves this partially by releasing normal and LTS releases.

nobody cares (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#28867199)

Linux is for fat homosexuals.

Previous way (3, Interesting)

sleekware (1109351) | more than 5 years ago | (#28867201)

I've always liked Debian's way of doing their releases, it was unique and worked really well for them for awhile; I hope this new way works out for the best and mutually benefits both Debian and Ubuntu.

I like this (2, Interesting)

tayhimself (791184) | more than 5 years ago | (#28867227)

This is almost like an Ubuntu LTS release? I am very happy with Ubuntu LTS for my servers. I think this is a step in the right direction for debian, but I don't see why I would go with a Debian server as opposed to an Ubuntu one.

Still thank you to the debian team for we depend on their hard work.

Re:I like this (4, Informative)

lordandmaker (960504) | more than 5 years ago | (#28867373)

Er, ish.

Debian Stable is the closest Debian has to an equivalent of Ubuntu's LTS release. Debian Testing's about a Ubuntu 'normal'.

But the two distros work in different ways, the comparison's not that cut-and-dried, since LTS releases are just normal releases with long support times.

Debian Stable is unchanging in featureset for its lifetime, Debian Testing is the testing for the next Stable, and Debian Unstable is where the changes to be tested are made.

As I understand it, Ubuntu 'freezes' a mirror of Debian testing, prettifies it, and releases it as Ubuntu. This is grossly under-representing Ubuntu's contribution, but is sort-of accurate in principle

Re:I like this (1)

zsau (266209) | more than 5 years ago | (#28868459)

Debian Testing is the testing for the next Stable

To be clear, many (most?) packages added to testing aren't expected to go into the next stable. They're added to testing automatically from unstable after no (significant?) bugs have been filed in (usually) ten days. Seeing as packages are added to/from unstable, testers would usually be running unstable. It is more accurate to think of testing as what stable would be, if a new stable was released today.

Re:I like this (2, Informative)

Nursie (632944) | more than 5 years ago | (#28867397)

Well, I likewise don't see why you would go for an ubuntu server over a debian one :)

Ubuntu has a six monthly release cycle with yearly LTS IIRC?

Debian is effectively always LTS, when it's released. When you release every two years and provide patches and updates for the oldstable as well as the stable branch you effectively have a 4 year support cycle anyway.

Also, Ubuntu is *so* x86 and whilst I know this is changing slowly I have three headless ARM based servers running debian right now. Err...
For me, Ubuntu didn't get on very well with my laptop and debian does. YMMV, obviously, and we've strayed out of serverland now. I know Ubuntu has advantages, but debian is my distro of choice.

Re:I like this (0)

Anonymous Coward | more than 5 years ago | (#28867775)

I don't see why I would go with a Debian server as opposed to an Ubuntu one

Simplicity, stability, predictability. Ubuntu is more focused on what runs on top. Debian is more focused on providing a stable core. With Debian it's easier to skip the overhead, right from the get-go.

Ubuntu would be better for a home server, for the casual user. For a production server, you want the standard unix environment, your server applications, and ideally nothing else.

Re:I like this (1)

lordandmaker (960504) | more than 5 years ago | (#28867935)

Ubuntu would be better for a home server, for the casual user. For a production server, you want the standard unix environment, your server applications, and ideally nothing else.

Are they really that different?

I've had poke arounds on Ubuntu servers and they've felt quite familiar, just with some friendlier defaults. But I'm no pro, it's entirely likely that I inadvertently make my Debian boxes similar to Ubuntu ones...

Nothing personal, just a different opinion (4, Insightful)

zsau (266209) | more than 5 years ago | (#28868297)

I run Debian stable on my laptop, and I don't see why I would run Ubuntu instead of Debian. Debian has a larger range of packages and is much more flexible and forgiving if you don't want to run one of the preconfigured subdistros (i.e. Ubuntu/Gnome, Kubuntu, Xubuntu etc.). Plus, having run distributions like Debian/sid or Gentoo, which have continuous updates, I find the reliability you get from a computer which never randomly changes packages is a plus. The six-monthly timetable of Ubuntu is much too short for that; I would've got the bugs ironed out just in time for a new release. There is, as you indicate, the LTS releases: but they're just one of the regular releases and this means you get people pulling in opposite directions (latest and greatest vs good for the whole three/five years). Also, is there some guarantee that you can always upgrade from one LTS release to the next LTS release?

In short, with Debian stable, I know what I'm getting. With Ubuntu, in my mind there's too much uncertainty that I'll have a reliable computer for its lifespan. Even if there isn't any uncertainty, there's no reason to convert. No matter how good Ubuntu is, I can't imagine it being better enough than Debian (on my desktop for my purposes) to warrant converting.

(That said, I would like answers to my questions. Googling "Ubuntu LTS" gives you almost nothing about LTS in general. The one page that's not information about a specific release has almost no content: a paragraph about Ubuntu's normal release schedule, a paragraph about the LTS release schedule, and a paragraph taking you to a list of pages about the beta releases (!) of distributions released a year (!!) or three (!!!) ago. This absence of information, and absence of relevant information, fills me with an absence of confidence, and it's one reason I'm not going to switch my laptop from Debian stable.)

Is this a koan? (1)

XanC (644172) | more than 5 years ago | (#28871005)

...fills me with an absence...

Mind-blowing, man.

Re:Is this a koan? (1)

zsau (266209) | more than 5 years ago | (#28871243)

I have no idea what a koan is, but I didn't type that by accident... I think it's a type of rhetoric.

Re:Nothing personal, just a different opinion (1)

Tubal-Cain (1289912) | more than 5 years ago | (#28876585)

I run Debian stable on my laptop, and I don't see why I would run Ubuntu instead of Debian.

Lack of Ext4 support for existing partitions is what's keeping me on Ubuntu. I'm waiting for the Testing images to support it, but I don't think that'll happen until it gets 2.6.28 [debian.org] . Unless you know another way?

i know nothing about ext4 (1)

zsau (266209) | more than 5 years ago | (#28878341)

No idea at all I'm afraid; it's not something I've ever wondered about. I guess you could manually compile a kernel, but I expect there'd be a bunch of userspace apps you'll also need to installl like an ext4 version of fsck.

Re:Nothing personal, just a different opinion (1)

xiong.chiamiov (871823) | more than 5 years ago | (#28878361)

Every other Ubuntu release is LTS, which means Long-Term Support. As it sounds, it is supported for a longer period of time (I don't know offhand how much longer, but I'm sure you can find out if you look hard enough).

Re:Nothing personal, just a different opinion (1)

zsau (266209) | more than 5 years ago | (#28878547)

Not only is what you said false (there have only been two LTS releases, and there have been two non-LTS since the last one), even if it were true, it has less information than what I contained in my question.

Re:Nothing personal, just a different opinion (1)

xiong.chiamiov (871823) | more than 5 years ago | (#28886321)

Not only is what you said false (there have only been two LTS releases, and there have been two non-LTS since the last one),

You're correct. Upon checking, it's every 2 years, which is every 4 releases.

even if it were true, it has less information than what I contained in my question.

I don't see what else there is to it. There's nothing inherently different about the LTS releases (they aren't tested any more ahead of time or treated any differently than normal releases in any other way, to my knowledge), except for the fact that Canonical will continue supporting them longer. Your original post posed a question (they don't seem to be that different; what is different about them?), which I answered (what you've found is all that differs). I fail to see what the issue is.

Wow, I really need coffee (0)

Anonymous Coward | more than 5 years ago | (#28867349)

First webpage of the day, and I read that as "Lesbian Decides to Abort Time-Based Frozen Embryos"

By the Way - this insane versioning bent (0, Flamebait)

AbbeyRoad (198852) | more than 5 years ago | (#28867447)

Linux distributions LOVE to come up with catchy names for their releases.

But sit down at a random machine and try work out WHAT release of Debian (or Fedora or whatever) you are actually sitting in front of and you can pull your hair out.

How is anyone supposed to remember that "Debian <insert-dumb-release-name-here>" is MORE recent that "Debian <insert-other-dumb-release-name>" ????

I suppose you are going to tell me to check /etc/issue

Oh THAT'S user friendly.

And what if /etc/issue has been emptied "for security reasons".

I can hear the support call already: "Er... Sir, if you can't work out what version of Linux you are running we recommend that you re-install, and also check the Wikipedia entry for Debian. .... Yes that's D-E-B-I-A-N"

I know as a maintainer that at one point "Sarge" was the most important word in your life, but for the USER (that's the person that is actually going to be using the OS you are working on), he doesn't know "Sarge" from "Etch" from "Horcrux".

AND HE DOESN'T CARE EITHER.

-paul

Re:By the Way - this insane versioning bent (5, Informative)

lordandmaker (960504) | more than 5 years ago | (#28867643)

But sit down at a random machine and try work out WHAT release of Debian (or Fedora or whatever) you are actually sitting in front of and you can pull your hair out.

cat /etc/issue
cat /etc/apt/sources.list
cat /etc/lsb_release

Often works. It's by no means ubiquitous, I'm well aware, but it's rarely *that* difficult.

Re:By the Way - this insane versioning bent (4, Informative)

Anonymous Coward | more than 5 years ago | (#28868541)

For Debian based systems:
 
cat /etc/debian_version

Re:By the Way - this insane versioning bent (3, Informative)

arjennienhuis (159927) | more than 5 years ago | (#28869937)

lsb_release -a

Re:By the Way - this insane versioning bent (0)

Anonymous Coward | more than 5 years ago | (#28870055)

Typical Linux user.

When you complain about Linux there is always
a sensible-sounding rebuttel - 9 times out of
10.

But when you need to urgently get something
on Linux to work you can battle with it all
through the night - 9 times out of 10.

Re:By the Way - this insane versioning bent (0)

Anonymous Coward | more than 5 years ago | (#28871629)

% apt-cache policy

Re:By the Way - this insane versioning bent (1)

xiong.chiamiov (871823) | more than 5 years ago | (#28878367)

For Arch: it's Arch. :)

Re:By the Way - this insane versioning bent (1)

ledow (319597) | more than 5 years ago | (#28867827)

This is one of the reasons I like Slackware.... tiny things like this ARE considered:

cat /etc/slackware-version :-)

Re:By the Way - this insane versioning bent (1)

ender- (42944) | more than 5 years ago | (#28868137)

Slackware is hardly alone in this:

Debian:
/etc$ cat /etc/debian_version
5.0.1

Ubuntu:
~$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=8.04
DISTRIB_CODENAME=hardy
DISTRIB_DESCRIPTION="Ubuntu 8.04.3 LTS"

Redhat/Oracle [I assume Fedora/CentOS too?]:
~]$ cat /etc/redhat-release
Enterprise Linux Enterprise Linux Server release 5.2 (Carthage)

Re:By the Way - this insane versioning bent (1)

lumenistan (1165199) | more than 5 years ago | (#28868175)

For the record, in Debian this can also be found in /etc/debian_version as well.

Re:By the Way - this insane versioning bent (0)

Anonymous Coward | more than 5 years ago | (#28869461)

On Debian unstable /etc/debian_version says "squeeze/sid" which is not the most informative of version numbers. At least on Debian stable it says "5.0.2".

Re:By the Way - this insane versioning bent (1)

X0563511 (793323) | more than 5 years ago | (#28870967)

Debian Unstable never has a version number. Ever. It also never 'releases' - things trickle into Testing after so much bug-free life in Unstable. It is Testing which eventually becomes a release and has a version number.

Re:By the Way - this insane versioning bent (2, Informative)

PieSquared (867490) | more than 5 years ago | (#28867889)

Ubuntu does reasonably well with this. They get the catchy name *and* obvious order by coming up with names associated with a letter, in alphabetical order. Jaunty is more recent then Feisty because "J" comes after "F".

And then they also stick the month and year on as the version number, which I thought was a good idea. 9.04 Jaunty is more recent then 7.04 Feisty because "J" comes after "F" and "April 2009" comes after "April 2007".

And finally you get an "about" page that lists both the name and the number.

Re:By the Way - this insane versioning bent (1)

bs7rphb (924322) | more than 5 years ago | (#28867979)

Oh for pity's sake.

Debian: cat /etc/debian_version
Fedora: cat /etc/redhat-release

It's not hard. It's easy. It's one command, for crying out loud. If you can't run one command you've no business using a computer.

Re:By the Way - this insane versioning bent (1)

k8to (9046) | more than 5 years ago | (#28878201)

jrodman@calufrax:~> cat /etc/debian_version
squeeze/sid

Oh that's obvious.

Re:By the Way - this insane versioning bent (1)

bs7rphb (924322) | more than 5 years ago | (#28878271)

user@marvin:~$ cat /etc/debian_version
4.0

Shouldn't be running sid if you don't know what sid is.

Re:By the Way - this insane versioning bent (1)

jgrahn (181062) | more than 5 years ago | (#28881259)

jrodman@calufrax:~> cat /etc/debian_version
squeeze/sid

Oh that's obvious.

salix:~% cat /etc/debian_version
5.0.2
salix:~% ssh tuva cat /etc/debian_version
4.0

It's telling you you're not running a real release at all, but testing or unstable, or whatever it's called (I almost never run anything but stable). Perhaps that file should be clearer ... but if you need that, you probably shouldn't be running anything but a stable Debian release.

Re:By the Way - this insane versioning bent (0)

Anonymous Coward | more than 5 years ago | (#28868005)

or you could try the standard linux way: "lsb_release -d"

or just look at /etc/debian_version

Re:By the Way - this insane versioning bent (5, Funny)

archen (447353) | more than 5 years ago | (#28868045)

Seeing as how debian only releases every century or so, that's not really a problem. The current release is the one you hear about. If it's not that it's the one you vaguely remember. The one before your kids were born, you were in high school, or possibly back when MTV played music videos (or insert some other thing waay back). If it's a version you haven't heard of it's so outdated that only the old long bearded unix sages locked up in corporate server farms programing cobol/fortran remember much about.

Re:By the Way - this insane versioning bent (2, Funny)

zsau (266209) | more than 5 years ago | (#28868705)

You should probably get your centuries looked at, if you're only getting around two years out of them. Mine last a hundred years or so; I gather that's about average.

Re:By the Way - this insane versioning bent (1)

AbbeyRoad (198852) | more than 5 years ago | (#28878783)

Dude, this is a REAL problem not some piece of theory you can stir in your brain and decide if its "true" or not:

Look, there are several major Linux distributions all with weird release names, and

there is categorically no resource on the Internet that lists all the release names, what
OS they correspond with and what release number.

At least with FreeBSD it calls itself "FreeBSD X.Y" so you know -

    a) which distribution it is (i.e. you know its not OpenBSD NetBSD BSDi or some Linux-based thing)
    b) which version of the distribution it is.

Any person using Linux over a long period in time who is NOT interested in the operating system per se gets totally confused and annoyed because all these release names are just one big blur.

-paul

Re:By the Way - this insane versioning bent (1)

VGPowerlord (621254) | more than 5 years ago | (#28868475)

How is anyone supposed to remember that "Debian " is MORE recent that "Debian " ????

Debian releases also have version numbers.

For example, the current stable is Debian 5.0 (codenamed "lenny")... well, actually it's 5.0.2, but the .2 only matters if you're downloading disc images, as the updates are handled through apt.

Re:By the Way - this insane versioning bent (2, Insightful)

Sophacles (24240) | more than 5 years ago | (#28870861)

The debian page itself lists releases by number and code name. So does Mac OS X, of course they are all referred to by code name too, leopard, tiger, etc. The Windows world has it easy, Windows 7 comes after windows 95, as per standard numbering schemes. Don't forget that in number based versioning schemes 2.1 is different than 2.10, and that 2.1 is before 2.9, which in turn is before 2.10. In debian of course you could just replace codenames with stable, testing and unstable and be done with it.

This is only first step (1)

dvh.tosomja (1235032) | more than 5 years ago | (#28868455)

1. Fixed freeze time
---
2. Change it to 3 years
3. Make in-between "small freezes" every six months or so
4. Rename "3 year freeze" to "LTS" to be not confused with "small freezes"
5. Move "smal freezes" to april and october
6. Rename the distribution to something more human, for example some asian, or maybe african word for community, sharing or generosity
7. Profit

end to the phrase (1)

pturing (162145) | more than 5 years ago | (#28870131)

I guess that puts an end to the phrase "when Debian freezes on a regular schedule"

Re:end to the phrase (1)

Cro Magnon (467622) | more than 5 years ago | (#28871153)

Damn, we've lost Duke Nukem AND Debian. The only benchmarks left are flying pigs and a freezing Satan.

Re:end to the phrase (0)

Anonymous Coward | more than 5 years ago | (#28873047)

Swine flu... also, Satan is to be frozen in about one month and released in about 5 months following that, assuming no release critical-bugs stop it.

Too soon (1)

Sam36 (1065410) | more than 5 years ago | (#28871483)

2 years just seems too soon for me. I would rather go for 3 year release cycle.
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?