Slashdot Mirror
Debian GNU/Linux 5.0 "Lenny" Released
Alexander "Tolimar" Reichle-Schmehl writes "The Debian Project is pleased to announce the official release of Debian GNU/Linux version 5.0 (codenamed Lenny) after 22 months of constant development. With 12 supported computer architectures, more than 23,000 packages built from over 12,000 source packages and 63 languages for the new graphical installer, this release sets new records, once again. Software available in 5.0 includes Linux 2.6.26, KDE 3.5.10, Gnome 2.22.2, X.Org 7.3, OpenOffice.org 2.4.1, GIMP 2.4.7, Iceweasel 3.0.6, Apache 2.2.9, Xen 3.2.1 and GCC 4.3.2. Other notable features are X autoconfiguring itself, full read-write support for NTFS, Java programs in the main repository and a single Blu-Ray disc installation media. You can get the ISOs via bittorrent. The Debian Project also wishes to announce that this release is dedicated to Thiemo Seufer, a Debian Developer who died on December 26th, 2008 in a tragic car accident. As a valuable member of the Debian Project, he will be sorely missed."
Still KDE 3.5 - so perhaps this will be the KDE user's distro of choice?
Need an ISP in South Africa?
Good to see that in the time of bleeding edge releases-every-6-months distros there's still a choice that actually allows you to get work done.
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
Etch just looked longer because *a lot* of improvements to the GNU/Linux was being made during that time in terms of the kernel hardware support and the desktop stuff, and whoever was using Debian stable during that time couldn't take advantage of those developments.
They always had the option to go "testing", which is surprisingly stable, compared to other GNU/Linux distros or, God forbid, Windows. The only downside is that the security patches usually come first to the stable release.
Don't forget the 'best' install out there: NetInstall. Unless you actually want to download 31 CDs or 5 DVDs worth of stuff. The best part about Debian is the mix and match of installing what I want. I honestly can't fathom trying to download 20Gigs of stuff just to make a desktop unless I plan on installing in middle of nowhere.
Screenshots of Debian? I can't think of anything more useless. You might as well try taking photos of life-forms there's such a huge range. No-one but me has a computer that looks+works the way mine does. (Albeit I've changed the feel more than the look, so any non-Gnome Crux screenshot will be reasonably close.)
Look out!
Unstable is unstable in the sense of changes happening semi-frequently, which you may not want on your production servers. But if your primary problem with Debian stable is that it doesn't get new software often enough, then presumably changes happening semi-frequently is precisely what you do want. And it gets bugfixes and security fixes first.
Despite the name, it's not where totally crazy experimental stuff that is more-likely-broken-than-not happens. There's a separate area, aptly named "experimental", for those packages. For example, the xf86->xorg change was staged in experimental for several months before being pushed to unstable after getting put into pretty good shape. OpenOffice 3 is undergoing a similar process currently, and will presumably be in good shape by the time it gets into unstable.
There is admittedly sometimes breakage in unstable, usually of specific packages, just because it's the newest widely used distribution: something'll never get to testing if it breaks in unstable. You can avoid even that, unless you really are the first person ever to encounter a particular bug, by using apt-listbugs to warn you of packages with major bugs filed against them, and delay upgrading those.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
I really wish people would stop with this bullshit. You mention Adobe - GIMP doesn't even compare to Photoshop. Technical perfection is useless if it doesn't give people enough of what it wants.
Now that this is out of the way, grats to the Debian team for a fine release.
will there ever be a way to watch blue-ray movies legally on a Linux computer? ... it is simlply a major *effort* for the average user to ignore or work around all these problems.
I have been using Linux on my desktop for years now, but I am getting increasingly frustrated with the lack of drivers for all the things that get more and more "normal" in the Windows world: synchronizing mobile phones, loading maps into a GPS device, playing Blue-ray disks, operating TV-cards, security devices (e.g. chip-card readers) and other special hardware.
So it is not only a lack of game playing software or professional graphics software like Photoshop
And it seems for some of these problems there are major legal or other obstacles which I cannot see getting solved in the future.
Opinions?
unfortunately FHS is ambigous on the issues..
http://www.pathname.com/fhs/pub/fhs-2.3.html#LIBESSENTIALSHAREDLIBRARIESANDKERN
> The /lib directory contains those shared library images needed to boot the system and run the commands in the root filesystem, ie. by binaries in /bin and /sbin
Thus, if your /bin contains amd64 binaries needed to boot the system, you should put the amd64 libs in /lib.
FHS is built on assumption that the 32bit userland is the default and only selected binaries (databases, and others who really need 64bit pointers) are 64-bit - which is true for the older 64bit archs.
but lib64 is stupid idea in the first place.
It should be more generic: /usr/lib/$(arch)/
Thus you could support as many 32 and 64bit architectures as your cpu (and kernel) supports (and the rest via emulation).
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=387446
That's how things look like on YOUR side. Now put yourself in the role of a maintainer of a mirror. Bandwidth costs money, and mirroring a Linux distro usually is something you do voluntarily.
I don't want to give Microsoft free defense or anything, but that's because Windows XP was getting better over that time and still ran all the new software. Debian Sarge stayed trapped in antiquity for eons and was helplessly behind the times. I think that was the time when the community decided that Debian was a server OS, and that someone else would have to provide a desktop Debian.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
It is not going to be in the archives because it would waste a huge amount of space. You may build it yourself using jigdo.
So what you're saying is that they are doing their best to prevent it?
(Maybe the thing has changed substantially, but last time I tried to use jigdo I actually ended up using a different Linux in protest.)
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
The bug was introduced September 2006 and fixed in May 2008. I think there were many very troubling issues relating to this bug that everyone who is works on and relies on OSS should be concerned about. The main point, in my view, is the lack of process. This is a bug that was introduced by the downstream packagers of OpenSSL. So, the distro supplies something that you think is OpenSSL, but in reality it isn't. It's the downstream packagers' version of OpenSSL. I'm afraid any trust evaporates at that point.
Ever heard of doing apt-get after a minimal install? This isn't windoze where you have to take everything or nothing.
Run and catch, run and catch, the lamb is caught in the blackberry patch.
``I wonder what the fetishism is with Debian stable ...''
It's one of the few releases for which a real effort is made to get all show-stopping bugs out one way or another. That's an enormous feat for a distribution that includes not only a complete operating system, but also more application software than any distribution I've compared it to.
Sadly, both etch and lenny have been released with known release critical bugs. These bugs have not affected me, but I am still concerned that Debian is inching away from "release only when ready" towards "release with bugs if necessary to make the release date". I don't want that to happen; there are enough distributions that do this already!
Please correct me if I got my facts wrong.
> > One would think so. After all, proprietary operating systems
> > sometimes go twice that long between service packs.
> But they aren't tied to the software they run so tightly.
Debian isn't that way because of anything Debian does wrong. It's that way because when application developers put out a new version of anything for Linux, they typically make it *require* the absolute latest version of every library it uses, which effectively means it won't run on an operating system that's more than a couple of months old.
It isn't just that there aren't ready-to-install packages. You can't install the latest Firefox on Debian etch even if you're willing to go to the trouble to compile it yourself, because it requires a newer version of GTK than the one in Debian. Bear in mind, GTK is the main widget set, the thing used to draw windows and scrollbars and checkboxes and so on in the graphical operating environment (Gnome). That's NOT something you're ever going to upgrade independently of the operating system (and even if you wanted to, you generally can't because the new version of GTK probably requires the absolute latest versions of twelve other things, and so on; when you get to the end of the chain, you probably find out that libc or something requires a more recent kernel than your system is based on). New versions of applications *SHOULD* support three-year-old versions of GTK. But they almost never do.
And if it's not GTK it's libc or glibc or some other basic part of the platform API. Again, new versions of applications *SHOULD* support three-year-old versions of these libraries, but the almost never do. I don't happen to know which library is (or which libraries are) the holdup for Subversion, but if it were possible to just compile it for etch, somebody would have done so, and the package would be available -- probably not from the official Debian etch repositories, but from backports or somewhere. If it's not available at all for Debian stable, it's almost certainly because it won't compile, because it requires a hyper-recent version of some library or another. And that's NOT the platform or distribution's fault. That's the application developer's fault.
Now, when the curmudgeonly sysadmin insists on running oldstable for months and months after the new stable release comes out, that's arguably a different matter. In that case, you don't necessarily expect new versions of application software to work. Although, on other platforms (e.g., Windows, or Mac OS X for that matter), you still would.
Cut that out, or I will ship you to Norilsk in a box.
The Debian developer asked on the openssl-dev list about his patch. He even pointed out the potential problem with his patch, but was unsure about its entire ramification. He was seeking guidance about it from the openssl developers and was told to go ahead it if it helps with debugging. If the openssl developer, who is the most knowledgeable about the code he works on, had bothered for more than a second to think about the potential problem with the patch, and had communicated his concerns to the Debian developer, the whole thing could have been avoided. Openssl developers screwed up by not giving proper guidance, period. They are just as culpable.
Openssl developers screwed up by not giving proper guidance, period.
It is not the job of the OpenSSL developers to babysit Debian people that don't know what the fuck they are doing. And its especially not Debian jobs to fiddle in code that they don't have a clue about. If the Debian people think their patch is useful, they should have submitted it upstream for proper review and wait till it got applied to the upstream branch, not casually asking on the mailing list and then just moving ahead with applying a debugging hack to a production software.
All that aside however, the very simple fact that this patch never got a proper review from other Debian people nicely illustrates that security in Debian is something that mostly works by blind luck, not by well thought out procedure.
Debian testing is far more stable than Ubuntu and is regularly updated.
Debian testing and Ubuntu are both based on Debian unstable. It takes a while for testing to become "debian stable", and it also takes a while before Ubuntu becomes a "release". Moreover, it takes a while for an Ubuntu LTS release to get better - but if you give Ubuntu LTS some time to mature, it will prove to be extremely solid (this is what happened with Hardy), while still delivering relatively recent packages.
Save your wrists today - switch to Dvorak
Generally speaking, it's a good idea to use the nicknames in your /etc/apt/sources.list, rather than the generic names. So use "lenny," "squeeze," "sid," rather than "stable," "testing," "unstable." That way you won't be surprised by a release.
Though, really, Debian releases are so few and far between, it's a pretty infrequent "surprise."
Check the release notes in advance of upgrading to be aware of potential issues. If you just change your current list from "stable" to "etch," you won't have any of the new stable flowing into your system. Etch will be supported with security updates for another year.
"No live organism can continue for long to exist sanely under conditions of absolute reality;..."
Ubuntu is derived from the Debian unstable branch. You should be glad Debian is going strong, as what Ubuntu adds is minimal (but still very useful and needed, don't get me wrong).
Then why didn't they say something to that effect instead of giving faulty advice?
The OpenSSL are equally at fault, period.