Slashdot Mirror

← Back to Stories (view on slashdot.org)

Debian 6.0 "Squeeze" Frozen

Posted by timothy on from the declaring-it-squozen dept.

edesio writes with a snippet from debian-news.net, trumpeting an announcement from the ongoing DebConf10 in NYC: "Debian's release managers have announced a major step in the development cycle of the upcoming stable release Debian 6.0 'Squeeze': Debian 'Squeeze' has now been frozen. In consequence this means that no more new features will be added and all work will now be concentrated on polishing Debian 'Squeeze' to achieve the quality Debian stable releases are known for. The upcoming release will use Linux 2.6.32 as its default kernel in the installer and on all Linux architectures.""

59 of 202 comments (clear)

  1. sweet! by Anonymous Coward · · Score: 2, Insightful

    its just sad Ubuntu gets all the publicity when they just reap the benefits of Debian's hard work.
    Debian all the way!

    1. Re:sweet! by keatonguy · · Score: 5, Insightful

      What a terrible attitude to have. The Open Source community is about shared effort for shared gain, not personal recognition. No matter the distribution that gets all the 'spotlight', it's Linux that reaps the reward, and the more ground Linux gains the better off everyone with a PC is.

      --
      If you aren't angry, you aren't paying attention.
    2. Re:sweet! by tpwch · · Score: 5, Insightful

      Thats not exactly true. A lot of stuff Ubuntu does/fixes gets sent back to Debian. Its a mutual relationship that they both benefit from. The same is true for many other debian-based distributions. And hey, its open source, the people who makes Debian want others to reap their benefits.

      --
      Posted by a Debian GNU/Linux user
    3. Re:sweet! by FuckingNickName · · Score: 3, Interesting

      The Open Source community is about shared effort for shared gain, not personal recognition.

      Have you spent a moment in the "Open Source community"? The majority of contributions to Linux are from profit-making corporations. Most of the remainder take glory in advertising their contributions for CV and geek cred. Certain projects are so cliquish that a friendly attitude (read "sucking up") to the core team is a far better way of being welcomed as a contributor than technical expertise.

      My original post included specific project examples, but since the most political organisations also have the most time to loudly whine at their detractors, I thought I'd remove them. I can think of at least one major open source Unix distribution the central developers of which seem to deliberately so poorly document their work that getting up to sufficient speed on what they do to make a positive contribution requires mentorship.

      FWIW, Debian as a whole doesn't suffer so much from this problem. I guess because it doesn't attract the glamour-seekers, nor does it consider itself elite. If politics is a hindrance there, it's more about idealism than personal power struggles.

    4. Re:sweet! by ShecoDu · · Score: 5, Interesting

      And ubuntu's community has to spend time dealing with the newbies, that's a huge weight off of debian's shoulders, it's a symbiotic relationship.

    5. Re:sweet! by blair1q · · Score: 2, Insightful

      I don't get why anyone is surprised that doing things with people turns political.

    6. Re:sweet! by mat128 · · Score: 4, Informative

      Mod this guy as informative! Having worked with Ubuntu developers on some bugs, I can say that non-Ubuntu specific fixes are sent upstream where they get commited.

    7. Re:sweet! by blair1q · · Score: 3, Insightful

      Pretty much this. And just because everything is somewhat political, it doesn't mean every venture is as bad as every other

      True that. I'm pretty sure Thomas Jefferson knew what politics was when he made it the basis of our political system...on purpose...as though it was going to solve problems we used to and no longer have.

      Like women and unlike wine, all man's endeavours grow more wrought with bitterness over time.

      Depends on your time scale and your skill in choosing either one.

    8. Re:sweet! by Nimey · · Score: 4, Insightful

      Having a friendly attitude != sucking up, necessarily.

      I had to learn this the hard way, back when, so pay heed: politeness is a social lubricant. It gets in the areas where different peoples' rough edges would otherwise rub and create friction, and it costs nothing to be polite.

      For example, a few months ago I opened a bug report with $LIBRE_PROJECT asking for help making a Windows build, or whether they'd be kind enough to start releasing Windows builds of the stable tree, rather than an occasional build from an unstable branch. After a bit of back and forth - the guys who weren't involved in making the Windows build were a bit rude - they eventually pointed me to the non-obvious way of compiling their code, and eventually their Windows guy started releasing regular semi-stable builds (the Win build isn't quite there yet).

      A little politeness as social lubricant, and I might have helped some other poor schmuck who wanted a free Windows program that does what $PROJECT does.

      --
      Hail Eris, full of mischief...

      E pluribus sanguinem
    9. Re:sweet! by http · · Score: 2, Informative

      This is a mistaken view. Even if Ubuntu support was always effective, there is no weight taken off Debian. Every community has to deal with noobs.

      In the real world (specifically, the irc support channels), there's a chronic problem: a fresh Ubuntu user realizes that they're not getting help in #ubuntu, so they come to #debian, because, well, Ubuntu is based on Debian, so you #debian people know how to fix my problem, right? right? Much time is lost trying to help them when their problem is particular to Ubuntu before they accidentally let "Lynx" or "Meerkat" slip out. It's so chronic that there are bot factoids to explain why we can't help them if they are not actually running Debian.

      Of course, not all Ubuntu users experience this, but they probably stay with Ubuntu.

      --
      If opportunity came disguised as temptation, one knock would be enough.
      3^2 * 67^1 * 977^1
    10. Re:sweet! by buchner.johannes · · Score: 3, Informative

      The Open Source community is about shared effort for shared gain, not personal recognition.

      Have you spent a moment in the "Open Source community"? The majority of contributions to Linux are from profit-making corporations.

      Not true for the Linux Kernel. Most of the contributions to Linux come from individuals without a company. After that are unknown contributers. Then companies.
      http://www.linuxfoundation.org/sites/main/files/publications/linuxkerneldevelopment.pdf

      --
      NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
    11. Re:sweet! by buchner.johannes · · Score: 3, Interesting

      We discussed what Ubuntu gives back here: http://tech.slashdot.org/story/10/08/01/0326208/First-GNOME-Census-Results

      If you want to see some Ubuntu criticism, search for Greg Kroah-Hartman Linux Plumbers Keynote, where he explains why distributions based on other distributions aren't really helping development.

      --
      NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
    12. Re:sweet! by icebraining · · Score: 2, Informative

      One of the projects to accomplish that is Utnubu.

      --
      Dilbert RSS feed
    13. Re:sweet! by Menacer · · Score: 5, Informative

      Individuals without a company and contributors with unknown affiliation add more to the Linux kernel than any _individual_ company, but that does not negate the statement that "the majority of contributions to Linux are from profit-making corporations". Red Hat, Novell, and IBM together make more Linux kernel contributions than all of the unaffiliated and unknown-affiliation contributors combined.

      The document you appears to have misread even includes this sentence: "It is worth noting that, even if one assumes that all of the 'unknown' contributors were working on their own time, over 70% of all kernel development is demonstrably done by developers who are being paid for their work."

    14. Re:sweet! by tyrione · · Score: 3, Informative

      Morton works at Google, Viro pops up as basically an alias: http://en.wikipedia.org/wiki/User:Niels_Olson/Al_Viro, Miller works at Red Hat, Baechle at MIPS, etc.. You just gave a list of Corporations and actual top developers all working for those corporations. Thanks for reinforcing the prior fact that the bulk of the kernel code is paid directly or indirectly by corporations.

    15. Re:sweet! by dirtyhippie · · Score: 2, Funny

      In the real world (specifically, the irc support channels)

      You lost me right there :)

    16. Re:sweet! by DarkIye · · Score: 2, Insightful

      You're right. That's always come quite naturally to me, so I've got a history of being surprised at how nice people are in spheres where I've been told by others the only way to get ahead is to 'suck up' or be someone's bitch in an unspecified but theoretically humiliating way.

      --
      To prevent this day from getting worse, I'll just read ERROR as GOOD TH
    17. Re:sweet! by micheas · · Score: 2, Insightful

      I guess because it doesn't attract the glamour-seekers, nor does it consider itself elite.

      I think that Debian suffers from a different form of elitism; the elitism that says "if we release something thats broken to stable we won't fix it because its *STABLE*"

      The problem, as I've seen it over the last 10 years as a Debian sysadmin, is that Debian is not run as a business; it doesn't have customers, it has users.

      If you want to use Debian in enterprise you NEED a really good engineering team; its really risky to use Debian in the small/medium business eg with sole-sysadmin because when Debian release something thats broken it STAYS broken and you need an internal engineering team to fix, patch and maintain the fixes.

      This is why I am encouraging my employer to go with Redhat instead; because Redhat is run as a BUSINESS, they understand the needs of business. For Redhat you are not just a user, you are a CUSTOMER and that actually counts for something.

      You might look at the php disaster in RHEL 5.x

      Basically, Rackspace is pleading with Redhat to compile pcre with unicode support, and Redhat seems to be saying wait until RHEL 6

      php in RHEL is so far behind that many open source and closed source php applications do not support the ancient version of php in RHEL because of the known security issues. (yes Redhat claims to have backported security fixes, but that does not mean that the latest versions of your software support the version of php in RHEL that php does not support.

      Of course some of this is the fault of the php project, but still, I think you are suffering from a grass is greener on the other side of the fence syndrome.

      Personally, I am leaning to Debian SID and Fedora as my preferred distributions for running web apps. FreeBSD upgrades without console access are not well supported so I am not a big fan of using it on leased servers, but otherwise it is easy to keep the application stack up to date. I don't dislike gentoo, but it has never "felt right" which I guess is just personal work habits or which OS you learned on or some other non-objective thing.

      --
      Work bio at MMWD
    18. Re:sweet! by TheRaven64 · · Score: 2, Interesting

      FreeBSD upgrades without console access are not well supported so I am not a big fan of using it on leased servers

      I'm not sure what you mean by this. I took a FreeBSD machine through every release between 4.7 and 6.2 without console access doing source updates. The newer freebsd-update tool makes it even easier - just run a single command and do a binary update. I don't think I've ever updated a FreeBSD system in a way that could not be done via SSH. What is the 'supported' update process that does require console access? It doesn't seem to be either of the ones that I found in the FreeBSD Handbook...

      OpenBSD recommends booting from the install CD and doing the update from there, but I've never had any problems doing the update the long way - they provide a list of commands to type, you just run them. I used to have a colocated Mac Mini running OpenBSD, and I took that all the way from 3.7 to 4.4 without any console access. Each update took a few minutes and two reboots (only one required in practice, but two may be required in theory, and it's worth an extra thirty seconds of downtime to avoid needing some remote hands time with a technician in the colo), and this was with the 'not recommended' procedure.

      --
      I am TheRaven on Soylent News
    19. Re:sweet! by TheRaven64 · · Score: 2, Funny

      Is Greg Kroah-Hartman in some kind of competition with Ulrich Drepper to see which one of them can alienate more of the Free Software community?

      --
      I am TheRaven on Soylent News
    20. Re:sweet! by micheas · · Score: 3, Informative

      I have had about a 95% success rate for doing upgrades without console access.

      Which sort of sucks that one out of 20 times the server just goes away.

      The only supported upgrade is if you do it in single user mode. Although this seems to be understood to not be a completely realistic assumption by the FreeBSD team, so this may change.

      --
      Work bio at MMWD
    21. Re:sweet! by ThePhilips · · Score: 2, Interesting

      The majority of contributions to Linux are from profit-making corporations.

      Does anybody still remember the times when corporations were like "we just hire people so that they concentrating on what they already do full time"?

      I can think of at least one major open source Unix distribution the central developers of which seem to deliberately so poorly document their work that getting up to sufficient speed on what they do to make a positive contribution requires mentorship.

      RedHat? That never was a secret really. And they were first to break the mold of "people do what they already do" to "we pay money so we say what you do".

      Though I'm not sure what you mean by the mentorship. RedHat doesn't hire developers that easily. They spare themselves mentoring newhires by always trying to hire people who are already experts in the piece of software. That also gives them greater (often full) control over the project. Two birds with a single stone, but can easily ruin the OSS side of the project. The end result that contributing to the RedHat or Fedora is pretty much impossible task.

      Debian as a whole doesn't suffer so much from this problem. I guess because it doesn't attract the glamour-seekers, nor does it consider itself elite.

      Because they are not for-profit organization which is actually made of people who like to do what they do.

      --
      All hope abandon ye who enter here.
    22. Re:sweet! by jonadab · · Score: 2, Insightful

      > its just sad Ubuntu gets all the publicity when
      > they just reap the benefits of Debian's hard work.

      Whose fault is that?

      Ubuntu arguably exists, or certainly became as popular as it is, because the Debian people went into some kind of coma or something and completely stopped producing stable releases for several years.

      At a time when cutting-edge distros were all moving to Linux 2.6 and conservative distributions and ones that hadn't been updated lately were still using 2.4.x, the Debian installer was asking users if they wanted to try the "new" 2.2 kernel, which might not be totally ready for prime time yet, or stick with the tried and true 2.0 kernel.

      Other packages were similarly ancient. If you wanted to install an application that wasn't included in the distribution, or a newer version of some key application, well that was just too bad, because there was no way anything would compile against libraries that old. Reasonable people had pretty much given up on Debian. The word "stable" became a joke. Debian wasn't just stable -- it was of purely historical interest.

      Ubuntu came out with an actual release, and people flocked to it, for obvious reasons. Then *another* Ubuntu release came out, and *more* people moved to it. The rest, as they say, is history.

      Some of us moved back to Debian when sarge finally came out, but we half expected to end up moving back to Ubuntu, because we didn't really expect the next release to come out in a reasonable timeframe. After the experience we'd just had, we were pretty jaded. The next release (etch) was a little slow in coming too, so some of us were pretty nervous for a while about whether we'd be able to stay with Debian. It wasn't until Lenny came out that I was able to really settle down as a Debian user.

      So you might say this news that Squeeze has frozen is "welcome news".

      --
      Cut that out, or I will ship you to Norilsk in a box.
    23. Re:sweet! by cp.tar · · Score: 3, Interesting

      I really wonder why some people seem to hate the notion of companies paying developers to work on Linux.

      Yes, Linux is an excellent example of how successful open source development can be. Especially in the sense GNU HURD isn’t.

      The fact that most development comes from various companies should be counted as a success of Linux.
      I mean, think about it. Unlike other operating systems, developed either by monopolists or by relatively small communities, Linux is now a result of joint effort of both numerous independent programmers and several large companies. All scratching their own itches, all working on making Linux better, all sharing their improvements with everybody else.
      This is also the greatest success of GNU: without the GPL, there would have been no strong incentive for everyone to share their improvements (even though it would be a good long-term strategy; the modern corporate world is more interested in quarterly statements, it seems).

      --
      Ignore this signature. By order.
    24. Re:sweet! by petermgreen · · Score: 3, Informative

      At a time when cutting-edge distros were all moving to Linux 2.6 and conservative distributions and ones that hadn't been updated lately were still using 2.4.x, the Debian installer was asking users if they wanted to try the "new" 2.2 kernel, which might not be totally ready for prime time yet, or stick with the tried and true 2.0 kernel.
      You exagerate. When 2.6 first came out the current version of debian stable was woody which offered either 2.2 or 2.4.

      Still I agree that debians longest release cycle ever came at about the worst possible time.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
  2. A frozen squeeze by Culture20 · · Score: 4, Funny

    is called a slushy, smoothy, orange julius, or a lemon shakeup.

  3. Debian GNU/kFreeBSD by John+Hasler · · Score: 5, Informative

    Note the bit about "Linux architectures." Squeeze will include GNU/kFreeBSD: Debian running on top of a FreeBSD kernel.

    --
    Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
    1. Re:Debian GNU/kFreeBSD by onefriedrice · · Score: 3, Informative

      Anyway I would probably prefer the reverse: uFreeBSD/Linux + ports. But porting the ports collection would be a major hindrance.

      So what you're looking for is something like Gentoo. It doesn't have the BSD userland, but it does have Portage which is comparable to ports but with even better package management tools (in my opinion).

      --
      This author takes full ownership and responsibility for the unpopular opinions outlined above.
    2. Re:Debian GNU/kFreeBSD by phoenix_rizzen · · Score: 3, Informative

      Which includes native support for ZFS, along with a zfs-utils package to go along with it.

  4. Not just Linux... by 0100010001010011 · · Score: 2, Informative

    GNU/kFreeBSD was supposed to be released with Squeeze. Nexenta is nice, but the package repository is severely limited.

    ZFS, Jails, OpenBSD packet filtering. Oh My!

    Even DebianMultimedia project already has kFreeBSD repositories available.

    1. Re:Not just Linux... by Randle_Revar · · Score: 3, Informative

      >don't call it FreeBSD.

      that's why its kFreeBSD (notice the "k")
      anyway, what else would you call it?

      --
      Climate Progress - Hell and High Water
    2. Re:Not just Linux... by afabbro · · Score: 2, Insightful

      My big problem with this is that FreeBSD is an operating system, kernel + userland. If you are just using the Kernel and not the userland, don't call it FreeBSD.

      No, we should call it GNU/FreeBSD.

      (ducks)

      --
      Advice: on VPS providers
    3. Re:Not just Linux... by TheRaven64 · · Score: 2, Informative

      Hardly surprising about Debian Multimedia, as the FreeBSD kernel actually has a sound subsystem that doesn't suck (i.e. OSS 4 interfaces, in-kernel low-latency mixing, per-channel volume controls, and so on). It makes me chortle slightly whenever anyone mentions pain with PortAudio or whatever this week's sound daemon of choice is on Linux. When writing code to play sound on FreeBSD, I just open /dev/dsp[W] and write audio data there, maybe with a couple of ioctl()s to set the sample rate, volume, and number of channels. With Linux, I need to link in a 1MB+ library that provides a set of interfaces that are much more complicated than the kernel interfaces and then hope that they don't change next week.

      Unfortunately for developers, Debian GNU/kFreeBSD uses GNU libc, rather than FreeBSD libc, so you get all of the fun of working with a libc written by someone who can't read the C standard (see unistd.h and its use of reserved identifiers for inline function parameters) and requires a huge mess of -D flags to compile POSIX / SUS code.

      --
      I am TheRaven on Soylent News
    4. Re:Not just Linux... by TheRaven64 · · Score: 3, Interesting

      Well duh! Of course libc uses reserved identifiers for those. If it used non-reserved identifiers, it would conflict with valid user code.

      Nope, sorry, not true. Parameter names never conflict with identifiers in any other scope. Identifiers beginning with an underscore are reserved for the 'implementation,' which can be interpreted as including the libc as well as the compiler, however the GNU C standard reserves ones starting with a double underscore for the compiler, yet unistd.h (and other headers in glibc) are littered with parameters starting with double underscores. In particular, the __block parameter name means that you have to do hacky work-arounds if you want to compile code using blocks on a GNU platform. Meanwhile, this code work out of the box with any other libc implementation.

      It requires one or more of the macros that, according to POSIX / SUS, the code needs to define.

      Which would be fine, except that the glibc man pages don't say which functions are from which standard, so you need to hunt around looking for every symbol. If a function comes from 4BSD but was later adopted by POSIX and SUS, what do you define? If you define the POSIX macro, then you may find that you've suddenly hidden a load of other things that were working correctly. There are some really fun cases where no combination of the public macros expose all of the features that you want and you need to define some of the glibc internal ones.

      On other platforms, the macros work in a much more sane way. Everything the libc supports is exposed by default, but if you are writing portable code then you can define a specific set of standard macros and it will disallow anything not in those standards.

      --
      I am TheRaven on Soylent News
  5. Re:Took long enough _ by tpwch · · Score: 5, Informative

    Debians policy is always that fixing problems takes priority over release schedules. They don't release a half-finished product. They'll wait years if its required to get things the way they want it.

    --
    Posted by a Debian GNU/Linux user
  6. Re:Took long enough _ by al3k · · Score: 2, Insightful

    Debian operates under the "It's done when it's done" philosphy. I usually just disregard deadlines when they mention them

  7. Debian? by timeOday · · Score: 2, Informative
    That's, like, Ubuntu for poor people, right?

    Just kidding. I like debian but switched to Ubuntu years ago seeking more up-to-date packages. But I find all the config files etc in Ubuntu a little hard to work with (providing simplicity for the user makes things more complex behind the scenes, which isn't good if you like to fiddle around behind the scenes). Is debian any more up-to-date these days?

    1. Re:Debian? by John+Hasler · · Score: 2, Insightful

      > Is debian any more up-to-date these days?

      Since Ubuntu is derived from Debian, Debian necessarily has always been more "up-to-date" than Ubuntu.

      --
      Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
    2. Re:Debian? by tpwch · · Score: 4, Informative

      Compared to a few years ago, yes, debian is a lot more up to date. I'd recommend running testing, or unstable if you know what you're doing. Stable doesn't get updated after release except for critical fixes like security updates (which is the way its supposed to be, so you can throw it on a server and not have to worry about a future update breaking things), but debians testing and unstable quality is higher than the stable of most distros.

      --
      Posted by a Debian GNU/Linux user
    3. Re:Debian? by tpwch · · Score: 3, Informative

      Most of the time when ubuntu needs to update a package they first check if debian has an updated version, and most of the time it has. And if you compare the package count of the distros debians is higher. It happens, but is pretty rare, that ubuntu adds some package that debian doesn't have for some reason. You've probably come across a few of those. You shouldn't be running experimental. Things that gets put in experimental are things that are known to be very likely to break stuff. Its mean for debian developers and people who want to help test things and report bugs only. And even they don't install all of experimental, just the packages they want to test. Chances are you didn't run experimental unless you know a lot about how the package system works, as you have to specifically specify that you want stuff from experimental when you install or update a package, just adding it to the repos doesn't do it. Its pretty unlikely that you got a system working with no problems if you really did install all of experimental.

      --
      Posted by a Debian GNU/Linux user
    4. Re:Debian? by iYk6 · · Score: 2, Interesting

      Is debian any more up-to-date these days?

      I use and prefer Debian Stable, but if you place a high value on the latest packages, then Debian Stable is not for you, and never will be. I have used Debian Testing for a couple of years or so, and I have tried Ubuntu a few times, and from what I have seen, Debian Testing is slightly more up to date and more stable than Ubuntu. I agree that Debian is easier to configure.

    5. Re:Debian? by petermgreen · · Score: 4, Informative

      While ubuntu is derived from debian that doesn't stop them from packaging newer stuff than in debian. The big name stuff is often newer in ubuntu's development versions than in sid. More obscure stuff will generally be either at the same versions or newer in sid than in ubuntus development version.

      Debian and ubuntu have very different release cycles. Ubuntu makes a release every 6 months and releases are prepared one at a time. This fast turnaround means more up to date software at relase time but also means little time for things to settle and bugs to get rooted out. Ubuntu won't delay a release unless there is a cripping issue with a package they consider particulally important.

      Debian's release cycles on the other hand are generally on the order of two years these days and they tend to spend a large amount of time at the end of that release letting things stabilise and working on the bug count.

      Things got particularlly bad a few years back. The sarge development cycle was debians longest ever and it came at a time when linux in general was improving a lot for the desktop but it still gets annoying near the end of a cycle.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    6. Re:Debian? by swillden · · Score: 5, Informative

      Is debian any more up-to-date these days?

      Debian is always as up-to-date as you want it to be. It's just a question of which version you run.

      Debian "stable" goes in cycles. Shortly after a release, it's fairly up to date. As time goes on, working towards the next release, packages get a little dated because they are intentionally not updated. Security and bug fixes are applied but no upgrades or new features -- this is why they call it "stable", because it doesn't change.

      Debian "testing" is a less cyclical and tends to stay fairly up to date all the time. The exception is during a freeze, like the one we just started. Since the current testing is being morphed into a new stable, it has just stopped receiving updates, and won't start again until the new stable version is released.

      Debian "unstable" is always quite up to date. All new features and packages are introduced in unstable first. Don't let the name confuse you -- it's about as reliable as most distributions' released versions. It's "unstable" in the sense that it gets constant updates, which means that things are always changing. Every once in a blue moon, a change will actually seriously break something for a day or so. Maybe once every 3-4 years in my experience.

      Debian "experimental" is more of a layer on top of "unstable", and it is what it sounds like: experimental. The Bleeding Edge.

      In addition to those versions, you can mix-n-match a bit by running stable plus backports. That allows you to keep a very stable, consistent base platform, and just pull in newer versions of particular packages, as needed.

      I switched from Debian to Ubuntu three years ago, but I'm very seriously considering switching back. My theory was that Ubuntu LTS releases were roughly equivalent to Debian stable, and that regular Ubuntu was somewhere between testing and unstable. The second half of that works out sort of okay, but using Ubuntu LTS as an alternative to Debian stable is a bad choice. The upgrade path from one LTS release to the next is horribly painful, because you have to upgrade to each intermediate release. And, in practice, I find the every-six-months big-bang upgrades more intrusive and problematic than the continual, incremental upgrades on Debian testing or unstable.

      All in all, after giving Ubuntu a good try, I think I'm going back to Debian stable on my server, Debian stable+backports on my laptop and Debian unstable on my desktop.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    7. Re:Debian? by petermgreen · · Score: 3, Interesting

      Most of the time when ubuntu needs to update a package they first check if debian has an updated version, and most of the time it has.
      That's probablly true for the more minor stuff but the big name stuff like glibc, gnome, kde etc is often newer in ubuntu's development version than in debian unstable and sometimes newer than even experimental.

      as you have to specifically specify that you want stuff from experimental when you install or update a package
      You can pin the whole of experimental at the same level as unstable and therefore cause apt to install stuff from it automatically (you can even pin it higher but thats a bad idea because often older versions get left in experimental after unstable is updated). I've done it in a chroot but never tried it on an independent system.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    8. Re:Debian? by Tubal-Cain · · Score: 3, Funny

      The man pages are a much more effective resource.

    9. Re:Debian? by radish · · Score: 5, Informative

      The upgrade path from one LTS release to the next is horribly painful, because you have to upgrade to each intermediate release.

      That's only true for non-LTS releases. You can go from one LTS to the next and skip the intermediate releases.

      --

      ---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"

    10. Re:Debian? by icebraining · · Score: 2, Informative

      You didn't spend much time searching, have you?

      You are running Debian stable, because you prefer the stable Debian tree. It runs great, there is just one problem: the software is a little bit outdated compared to other distributions. That is where backports come in.

      Backports are recompiled packages from testing (mostly) and unstable (in a few cases only, e.g. security updates), so they will run without new libraries (wherever it is possible) on a stable Debian distribution. I recommend you to pick out single backports which fits your needs, and not to use all backports available here.

      http://backports.org/

      --
      Dilbert RSS feed
    11. Re:Debian? by swillden · · Score: 3, Informative

      Rather than using apt-pinning to pull packages from testing/unstable into stable, I'd suggest using it to pull packages from the backports repositories. That way you'll get newer software that's built against the stable versions of the supporting libraries.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
  8. Re:Took long enough _ by Timothy+Brownawell · · Score: 2, Informative
    http://www.debian.org/News/2009/20090729

    The Debian project has decided to adopt a new policy of time-based development freezes for future releases, on a two-year cycle. Freezes will from now on happen in the December of every odd year, which means that releases will from now on happen sometime in the first half of every even year. To that effect the next freeze will happen in December 2009, with a release expected in spring 2010.

  9. To the "unstable" user (badumtish), the freeze by GeekDork · · Score: 2, Insightful

    means 6 months of retro computing.

    I wish they'd just cut the bull and focus on unstable and testing.

    --

    Fight hunger. Filet a politician and send him to a 3rd world country of your choice.

    1. Re:To the "unstable" user (badumtish), the freeze by at_slashdot · · Score: 2, Insightful

      Why don't you use Ubuntu, that's what they focus on. Some people who like Debian bitch about Ubuntu that is this or that, but they should realize that Ubuntu is protecting Debian from people like you who want to make it less stable and more experimental.

      --
      "It is our choices, Harry, that show what we truly are, far more than our abilities." -- Prof. Dumbledore
    2. Re:To the "unstable" user (badumtish), the freeze by couchslug · · Score: 4, Insightful

      "I wish they'd just cut the bull and focus on unstable and testing."

      Why should they sacrifice QUALITY in order to do that, when you can just run Unstable, Testing, or another distro?

      --
      "This post is an artistic work of fiction and falsehood. Only a fool would take anything posted here as fact."
  10. Re:Took long enough _ by petermgreen · · Score: 5, Informative

    Well the first announced freeze date for squeeze was part of an unpopular plan to sync up with ubuntu by having a very short release cycle. That was abandoned pretty quickly (unfortunately after that)

    Asside from that there afaict are a couple of reasons to delay the freeze.

    A big reason is what are referred to as transitions. A transition is a group of package updates (usually a new major version of a library and the various updates and rebuilds associated with it) that need to move from unstable to testing at the same time to leave testing in a consistent state (unstable is allowed to be in an inconsistant state, testing isn't). The release planners will have a set of transitions that they really want to get in for a given release, transitions can easilly get held up by build failures and other rc bugs and they don't want to do too many at the same time because then they become intertangled leaving the release team with one big transition which is even harder to make migrate.

    Also they want to pick a good time to freeze. Freezing the application level stuff while there are still big issues to fix in core package won't affect the release date much while it will mean releasing with older versions of the application level stuff (which is the stuff that is most visible to users and often the stuff that needs the most security updates).

    --
    note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
  11. Sounds like good news to me! by FridayBob · · Score: 4, Interesting

    In mid June I set up my latest server based on Squeeze with the expectation that it would go stable this summer. For a while I thought perhaps I had jumped the gun and would be stuck with a relatively unstable system for a longer period, but I guess not.

    In particular, I'm happy with Squeeze because I could use it to get my Kerberos-OpenLDAP-OpenAFS system working on both the file server and workstations. Not that I've ever use any FOSS other than Debian for my server, but after my attempts failed to get the latest Ubuntu client to run the necessary client software for this (unfortunately) uncommon, but very capable distributed file system, I suspected the same Debian version for the workstation represented my best chance of success. And sure enough: it worked straight away! Ubuntu may have certain benefits, but it seems that if you want a desktop system that is a little out of the ordinary, Debian is still your best bet.

  12. Re:Took long enough _ by John+Hasler · · Score: 2, Interesting

    > What's the point of slipping a freeze date?

    To get the rc bug count down to a manageable level and to complete complex package transitions such as major library upgrades.

    --
    Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
  13. Re:Version numbering... by radish · · Score: 3, Informative

    Well for Ubuntu they're both numbered and named. The numbers are year.month (e.g. 9.10 is October 2009) and therefore go up in the expected manner. For the names, they're alphabetical (or at least have been for the last 5 years), so Intrepid came before Jaunty, which was followed by Karmic.

    https://wiki.ubuntu.com/DevelopmentCodeNames

    --

    ---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"

  14. Re:Version numbering... by petermgreen · · Score: 2, Informative

    Debian code names don't really have much structure to them other than all being toy story characters and it seems recently getting into the more obscure ones.

    With the exception of some very early releases (horay and warty) ubuntu codenames have going in alphabetical order breezy->dapper->edgy->feisty->gutsy->hardy->intrepid->jaunty->karmic->lucid->maverick

    --
    note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
  15. Re:hda support? by gringer · · Score: 3, Informative

    Less then a few months ago a kernel update in squeeze changed ide addressing from hda to sda. Bricking my debian boot sequence.

    The recommended route is using uuid now, for example in /etc/fstab:

    UUID=3e036498-60fb-44a9-a3d1-205a3ffaeb7d swap swap defaults 0 0

    or something like this in grub:

    linux /vmlinuz-2.6.32-3-686 root=UUID=903040df-e1af-4c1e-86e3-c954a30ce948 ro

    You can also change the udev rules (/etc/udev/rules.d/) to rewrite particular drives as whatever you want, but who knows how long udev rewriting will be around?

    FWIW, my laptop is using sdXY naming for partitions, but I think it's always been like that based on the comments in my fstab.

    --
    Ask me about repetitive DNA
  16. Re:Took long enough _ by julesh · · Score: 2, Interesting

    http://www.debian.org/News/2009/20090729

            The Debian project has decided to adopt a new policy of time-based development freezes for future releases, on a two-year cycle. Freezes will from now on happen in the December of every odd year, which means that releases will from now on happen sometime in the first half of every even year. To that effect the next freeze will happen in December 2009, with a release expected in spring 2010.

    And, on the mailing list the next day: http://lists.debian.org/debian-devel-announce/2009/07/msg00001.html

    Based on feedback of the community on the plan to freeze in December
    2009 and the ambituous Release Goals we set for ourselves, we are
    revisiting the decision to freeze December 2009.

    We'll be consulting all key teams within Debian to see how their plans
    and schedules can fit into a new timeline. Before the end of August we
    hope to have finished this process of consultation and be able to
    present the new plan to you.

    And, following that consultation: http://lists.debian.org/debian-devel-announce/2009/10/msg00002.html

    Proposing a new freeze date is not easy. Taking into account all of
    the feedback we have received, both online (by e-mail, IRC) as well as
    in person, and some challenging release goals we have set for ourselves,
    we propose freezing in March 2010.

    So, yes, the release team did propose a December date. The proposal lasted about a day before being dismissed, and was replaced with one in March. Admittedly, this isn't far off the 6 months the OP suggested this was late by.

    OTOH, I'd suggest they're still on track to be able to meet their primary original goal, releasing to stable on a two year cycle (i.e. squeeze to be released on or around 26 June 2012), so slipping a few months in the feature freeze for the release is hardly a major problem.