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.""
Debian GNU/kFreeBSD (Score:5, Informative)
Not just Linux... (Score:3, Informative)
GNU/kFreeBSD was supposed to be released with Squeeze. Nexenta [nexenta.org] is nice, but the package repository is severely limited.
ZFS, Jails, OpenBSD packet filtering. Oh My!
Even DebianMultimedia [debian-multimedia.org] project already has kFreeBSD repositories available.
Re:Took long enough _ (Score:5, Informative)
Debian? (Score:3, Informative)
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?
Re:Took long enough _ (Score:3, Informative)
Re:Debian? (Score:5, Informative)
Re:Debian? (Score:4, Informative)
Re:Debian? (Score:5, 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.
Re:Debian? (Score:1, Informative)
Its pretty unlikely that you got a system working with no problems if you really did install all of experimental.
Yes, the system was installed as unstable, and everything desktop related was experimental. This used to be the only effective way to get a working KDE4.0 install running on Debian. Ubuntu had much better desktop support all around, and openSUSE was leagues ahead of Debian for KDE. But that was a long time ago.
Re:Debian? (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.
Re:Took long enough _ (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).
Re:Debian GNU/kFreeBSD (Score:4, 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).
Re:Not just Linux... (Score:4, Informative)
>don't call it FreeBSD.
that's why its kFreeBSD (notice the "k")
anyway, what else would you call it?
Re:sweet! (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.
Re:Debian? (Score:5, Informative)
That's only true for non-LTS releases. You can go from one LTS to the next and skip the intermediate releases [ubuntu.com].
Re:Version numbering... (Score:4, 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 [ubuntu.com]
Re:Version numbering... (Score:3, 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
Re:hda support? (Score:4, 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.
Re:sweet! (Score:3, 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.
Re:sweet! (Score:4, 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 [linuxfoundation.org]
Re:sweet! (Score:3, Informative)
One of the projects to accomplish that is Utnubu [debian.org].
Re:Debian? (Score:3, Informative)
You didn't spend much time searching, have you?
http://backports.org/
Re:Debian GNU/kFreeBSD (Score:4, Informative)
Which includes native support for ZFS, along with a zfs-utils package to go along with it.
Re:sweet! (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."
Re:sweet! (Score:4, Informative)
Re:Debian? (Score:4, Informative)
Re:sweet! (Score:4, 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.
Re:Not just Linux... (Score:3, 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.
Re:sweet! (Score:4, 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.