Debian 6.0 "Squeeze" Frozen 202
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.""
Re:Debian GNU/kFreeBSD (Score:1, Interesting)
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)
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)
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)
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.
Sounds like good news to me! (Score:5, Interesting)
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.
Re:Took long enough _ (Score:3, 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.
Re:Debian? (Score:4, 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.
Re:Debian? (Score:0, Interesting)
Re:sweet! (Score:4, Interesting)
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)
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)
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)
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.
Re:Took long enough _ (Score:3, Interesting)
And, on the mailing list the next day: http://lists.debian.org/debian-devel-announce/2009/07/msg00001.html [debian.org]
And, following that consultation: http://lists.debian.org/debian-devel-announce/2009/10/msg00002.html [debian.org]
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)
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).