Lenny has landed!
After almost two years of work since the release of Etch, the Debian team has finally released Debian 5.0 "Lenny" to the world - their tenth major release. When we spoke to Steve McIntyre, the Debian Project Leader, he said "we basically decided that if we were happy that stuff looks and is legal, as in there isn't any source missing or anything like that, then screw it - we'll go with that." To find out what he was talking about and see our initial views on the new release, read on...
Debian 5.0 is here! Let's see what goodies await us inside...
What's new in Lenny
For people who somehow missed Toy Story 1 and 2, Lenny is a pair of binoculars with feet, so let's take a closer look at what Debian 5.0 offers...
- SELinux is installed as standard for new systems. If you're upgrading from Etch, you need to run the command "aptitude install selinux-basics" as root. Note that while SELinux is installed, it's not enabled by default - for that you should follow these instructions.
- Iceweasel (Firefox) and Icedove (Thunderbird) have jumped versions from 2.0 to 3.0 and 1.5 to 2.0 respectively, which will make a lot of people happy.
- Debian can now officially run live. Ubuntu was by no means the first distro to do this, but it certainly created a lot of impetus behind live distribution. Now Debian 5.0 follows suit by offering live images for x86 and x86-64 architectures through its live-helper tool that anyone can use to create live images. See the Debian Live! page for more information.
- Java is finally in Debian, thanks to IcedTea and OpenJDK 6. To get started, install either the openjdk-6-jre or openjdk-6-jdk packages.
- Debian 5.0 ships with kernel 2.6.26, which is a mere 0.0.2 behind the mainline version, and also includes NTFS-3g and support for KVM.
- X.org 7.3 uses hardware autoconfiguration as standard for a wide selection of hardware.
- Lenny also brings great support for the most popular netbooks, with the Eee PC getting its own package bundle of ACPI scripts out of the box - see the eeepc-acpi-scripts package for more information.
- Support for 32-bit SPARC has gone, but ARM EABI ("armel") is in.
- And there's lots more - nearly three quarters of all software packages in Etch have been upgraded, and Lenny includes over 7700 all-new packages, taking the total package count past 23,000.
The Debian 5.0 desktop is a blend of Gnome 2.20 and Gnome 2.22.
Firefox Iceweasel 3.0.6 is included as standard.
When you boot into the Lenny desktop, the most immediately noticeable thing is that it's now based off a Gnome 2.22/2.20 blend. Most of the desktop is .22, which means you get Cheese, Vinagre, Sabayon, GVFS/GIO, a syntax-highlighted Gedit (at last!) and a fairly up-to-date Evolution, but no Telepathy, Ekiga 3.0 or other features from the latest 2.24 release. The handful of programs that come from Gnome 2.20 includes, most importantly, Nautilus, which means it still relies upon the older Gnome-VFS subsystem.
You also won't find OpenOffice.org 3.0 here, because Lenny has been in package freeze for so long. And the same goes for KDE 4.x, despite hints from Mark Brockschmidt that it might be possible - but he also said he wanted to release Lenny in September last year, so clearly KDE 4.x wasn't too likely! Still, lots of people prefer KDE 3.5.10 to KDE 4.1, so this is no big problem. Mono languishes back in 1.9.1 (which at least includes support for most of the 2.0 goodness).
Gnome's Add/Remove Applications program is now the standard GUI front-end for software installation, with Synaptic also available under the System > Administration menu. This should mean that any newer Linux users who are familiar only with Ubuntu should find it easy to switch over to Debian and get a taste for stability.
Logging into Debian 5.0 - will you be next?
Not everyone is happy
We talked to Warren Woodford (pictured), founder and lead developer of MEPIS Linux, to ask him what Lenny means to MEPIS, a distro that previously based itself off Ubuntu but eventually moved upstream to Debian. He had this to say:
"As technology changes faster and faster, the Debian release cycle needs to adapt. For example, as the Lenny freeze was starting, it took a lot of effort in the community to switch Lenny from a 2.6.25 kernel to 2.6.26. Then as the freeze extended, when Adrian Bunk reported that 2.6.27 was a Long Term Support kernel, due to policies, it was impossible to switch Lenny to 2.6.27. This means that Lenny is releasing with a kernel that is not targeted for LTS - but it could have been."
Woodford described one possible solution as having "more consideration of the future needs of users and less knee-jerk reaction that the freeze is total and permanent," adding, "maybe Debian needs to have a light freeze or a frost at first. At least, I urge that they try harder to anticipate and adapt to important upstream changes."
Thanks to ever-varying release cycle length of the Debian project, some versions have almost felt out of date as soon as they were released - with 3.1 ("Sarge") being a particularly notable example due to its three-year development. But Lenny is the opposite end of the scale: with a great new kernel, huge desktop updates powered by Firefox 3 and Gnome 2.22, Debian stable has never felt so cutting-edge, and yet you know that millions of hours of work have gone into making it the kind of rock-solid stable that Debian is famous for.
Debian 5.0 might look great for new users on the surface, but let's not forget the things that advanced users want to - encrypted LVM really is just a click away now.
This release seems to provide the perfect blend of recent-enough software and legendary stability that we're already seeing some ex-Debian users - people who had switched to Ubuntu after being tempted by higher version numbers and extra glitz - move back towards Debian for the first time in years. While the lack of some key applications such as OpenOffice.org 3.0 is likely to make this release date quickly, it's ultimately just a version number: 3.0 didn't introduce a whole lot of interesting new features, so it's easy to favour reliability in this case.
Perhaps surprisingly, the features that excite us most are the inclusion of a great out-of-the-box experience for many netbook users plus support for the relatively recent Linux port to ARM EABI - which brings with it a massive boost in performance for floating-point calculations. Combined, this makes Debian a powerhouse for low-power, low-footprint devices, which will in turn provide an excellent foundation for Debian spin-offs such as Ubuntu and MEPIS.
With over 64 DVD images of packages across all its architectures, Debian offers more choice, more flexibility and more features than any other Linux distro out there. We think Debian 5.0's recent software and long-term maturity is going to make it easy for a lot of users of other distros to look over the fence and consider switching.
Interview with the DPL
Yesterday we travelled to meet up with Steve McIntyre, the Debian Project Leader, and he talked us through the release slips, supporting multiple architectures, binary blobs and new plans for the next big Debian release: Squeeze.
TuxRadar: All being well, Lenny is going to be released tomorrow. September was the original release plan though, so what happened?
Steve McIntyre: Basically, for the last couple of releases, for Etch and for Lenny, the plan has been all along to aim for 18 months, but it may go to 24. We expect that releases may slip - after all, we're volunteers working on this. If we claim that we're aiming for 18 months but we ship in under 24, everybody's happy.
The problem is, possibly, too many people focused specifically on the 18 month mark which is why we all saw the stories about September. There was an unfortunate mistake where a couple of the release updates went out that just said September, with no qualification. That's where it went wrong.
We're actually shipping in 22 months this time. Obviously we'd all like to be closer to the beginning of the window, but we're still very much within what we aimed for. We're happy.
TR: But have you ever considered a Gnome-like approach to releasing - that is, always release after 6 or 12 months, and stick steadfastly to that?
SM: So far within Debian we're happy with the 'release when it's ready' approach. We like to do stable releases, it's very important for us and to our users, but we want to make sure that it's right. We can aim for a particular date, but unless we get a lot of buy-in and know for a fact that it's going to be ready, we'll happily let it slip another couple of months and make sure it's good.
TR: For Lenny+1 do you and the developers have any plans to change the release process?
SM: For Squeeze I think we're going to do a similar thing. We don't know the full set of goals yet, but we're still going to be aiming for 18 to 24 months.
TR: Do old or esoteric architectures hold back development in any way?
SM: For most of our architectures it's really not an issue. We may end up dropping a couple of architectures for Squeeze anyway, but that'll just be because we're struggling to find people to work on them. In terms of performance, they're all well up to scratch - they can all run just about everything that we have.
You'd be surprised; we even have people who want to run numerical simulation stuff on ARM processors. It might sound a really silly thing to do, but it's really useful. So we don't know what our users are going to want, necessarily, so we aim to give them everything on everything.
TR: Is the MIPS port going to continue since the sad death of the lead developer [Thiemo Seufer]?
SM: Absolutely - Thiemo is going to be missed, he was a good friend and he actually worked for MIPS UK for a while. We're going to miss his driving force behind the port, because he was passionate about it. Other people have stepped up; we'll have to see how it goes. I don't know at this point whether there'll be enough effort but I certainly hope so.
TR: But has there been a particular instance where supporting a lesser-used architecture has held back, say, a release candidate?
SM: Well, we don't tend to have problems with release candidates because we make sure we accommodate them. It only takes a couple of days to make sure that all the architectures are in sync. We've got enough machines doing the building.
About the only time where the slow architectures can cause an issue is with security updates - at that point you really are waiting for one machine to do one build. But in that particular case, we've already decided in the last few years that we'll announce the common updates for the common architectures and we'll let the others catch up as and when. People seem happy with that.
TR: What's the current situation with 'binary blobs' [binary-only firmware files for hardware] in Lenny?
SM: What we find, each time we get towards a release, is that there are bits and pieces of software which are in the operating system - in our archives - which don't quite meet our free software requirements. We have a document, the Debian Free Software Guidelines, which tells us exactly what will fit and what won't fit.
Unfortunately, as we get towards the end of a cycle, it's sod's law and we start finding things that don't quite meet those guidelines but are really, really important to people. The most recent example in Lenny is binary blobs in the kernel which are not free software as far as we can tell; we don't necessarily have the source for them. We don't even know if there is source for them - they could well be things that people have written directly in assembly!
We don't like having to ship with some of these things, but equally we don't want to have to delay the release, and potentially spend another six months fixing this kind of stuff...
TR: How could you 'fix' it though? Rewriting this firmware code?
SM: Exactly, that's one of these options. What we want to do, ideally, is make sure that every single thing that we ship is free - it's in our social contract and what we aim to do. But we're not quite perfect yet. To fix it we could just just remove support for those particular bits of hardware, but unfortunately it's more and more common that hardware designers, for the sake of a dollar per motherboard, don't put the flash onboard to hold the driver.
So if you want your network card to work on a lot of, say, common 1U/2U server boxes that a lot of manufacturers ship, you need to upload the firmware onto the network card before you can use it. Now of course that's not very much use for lots of people. 100% free software is wonderful and we all want to get there, but 100% free software that doesn't run on your hardware is a little bit less useful.
TR: It's a very tough decision - who makes it? What's the line between a binary blob being bad for the free software goals but being really useful for users?
SM: In a case like that we have to look at the particular licensing on the firmware. If we clearly can't distribute it then it's never going to go. If we're absolutely certain that there should be source attached, and therefore the licence means we can't ship, we won't.
We had a big general resolution just before Lenny where we basically decided that if we were happy that stuff looks and is legal, as in there isn't any source missing or anything like that, then screw it - we'll go with that. There's a limit on what we can do, and there's always going to be some of the firmware that actually will stay in non-free, and to be honest it's a really big issue.
It caused a huge... I'd hesitate to call it a flame war, but it was a very heated discussion. We'll end up coming back to it again after Lenny. My own idea is, I'd like to see a separate firmware section in the archive, for places where we can and will explicitly warn people: 'look, these bits are not as free as we'd like, but the chances are you're not going to be able to work without them'.
So we'll be able to put those on the CDs and DVDs, but we won't have to expose people to the rest of the non-free stuff. In the background, we're working with a lot of the people who are producing the hardware; a couple of our kernel team people have been mailing hardware developers and talking to the engineers, if nothing else just to at least clarify the licences so we know what's coming, and obviously to produce the source.
If we have the source, and even if we don't know enough about the hardware to do anything with it, there's no guarantee that somebody else can't.
The next major Debian release has been named "Squeeze" after this little guy.
To read a full review of Debian 5.0 and to hear more from Steve about his relationship with Canonical, his goals to improve communications with Debian and whether he wants to run for DPL again, look out for the full interview in an upcoming issue of Linux Format magazine.