Forgot your password?
typodupeerror
Debian Operating Systems Upgrades Linux

Debian 6.0 "Squeeze" Frozen 202

Posted by timothy
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.""
This discussion has been archived. No new comments can be posted.

Debian 6.0 "Squeeze" Frozen

Comments Filter:
  • by Anonymous Coward on Friday August 06, 2010 @07:05PM (#33169780)
    It's funny that Debian was always my favorate Linux distribution upon returning from the FreeBSD world, and now I find the best of both worlds... combined.

    Anyway I would probably prefer the reverse: uFreeBSD/Linux + ports. But porting the ports collection would be a major hindrance.
  • Re:Debian? (Score:3, Interesting)

    by iYk6 (1425255) on Friday August 06, 2010 @07:32PM (#33170026)

    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.

  • Re:sweet! (Score:3, Interesting)

    by FuckingNickName (1362625) on Friday August 06, 2010 @07:35PM (#33170064) Journal

    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.

  • Re:sweet! (Score:5, Interesting)

    by ShecoDu (447850) on Friday August 06, 2010 @07:36PM (#33170078) Homepage

    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.

  • by FridayBob (619244) on Friday August 06, 2010 @07:56PM (#33170222) Homepage
    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.
  • by John Hasler (414242) on Friday August 06, 2010 @07:56PM (#33170230) Homepage

    > 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.

  • Re:Debian? (Score:4, Interesting)

    by petermgreen (876956) <plugwashNO@SPAMp10link.net> on Friday August 06, 2010 @08:01PM (#33170256) Homepage

    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.

  • Re:Debian? (Score:0, Interesting)

    by Sam36 (1065410) on Friday August 06, 2010 @09:12PM (#33170760)
    You have it the other way around. Debian is ahead of ubuntu. You are probably referring to debian-stable, which is mainly for servers. I have been using debian-testing for about 4 years now. I have never had to do any kind of update cycle/reinstall. It is always up to date. http://christi.ath.cx/ubuntu_vs_debian.html [christi.ath.cx]
  • Re:sweet! (Score:4, Interesting)

    by buchner.johannes (1139593) on Friday August 06, 2010 @10:42PM (#33171188) Homepage Journal

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

    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.

  • Re:sweet! (Score:3, Interesting)

    by TheRaven64 (641858) on Saturday August 07, 2010 @05:30AM (#33172228) Journal

    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.

  • Re:Not just Linux... (Score:4, Interesting)

    by TheRaven64 (641858) on Saturday August 07, 2010 @07:27AM (#33172544) Journal

    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.

  • Re:sweet! (Score:3, Interesting)

    by ThePhilips (752041) on Saturday August 07, 2010 @07:29AM (#33172552) Homepage Journal

    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.

  • by julesh (229690) on Saturday August 07, 2010 @07:47AM (#33172590)

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

            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 [debian.org]

    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 [debian.org]

    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.

  • Re:sweet! (Score:4, Interesting)

    by cp.tar (871488) <cp.tar.bz2@gmail.com> on Saturday August 07, 2010 @10:48AM (#33173456) Journal

    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).

Everything that can be invented has been invented. -- Charles Duell, Director of U.S. Patent Office, 1899

Working...