Debian 4.0 'Etch' Released

An anonymous reader writes "Earlier today we discussed the possibility that Debian Etch might be released soon. Well, according to debian.org, it has already happened. Etch has been released: 'The Debian Project is pleased to announce the official release of Debian GNU/Linux version 4.0, codenamed etch, after 21 months of constant development. Debian GNU/Linux is a free operating system which supports a total of eleven processor architectures and includes the KDE, GNOME and Xfce desktop environments. It also features cryptographic software and compatibility with the FHS v2.3 and software developed for version 3.1 of the LSB.'"

Comments

Yay!

[Compact Dick]

I still remember my Woody days *sniff*

Re:Yay!

[wuputah]

Don't worry, you can still get a woody with etch.

*ducks*

Disclaimer: I am not responsible for any loss of employment or productivity by clicking on any link in this post.

Re:Yay!

[Stephen Tennant]

My first woody was a memorable experience.

Re:Yay!

[Anonymous Coward]

I hear they've got pills for that nowadays.

Re:Yay!

[MarkRose]

Certainly better than that slink-y I had in the late '90s.

And its not even the 1st...

[arlo5724]

For a second there I thought maybe this was a late April fool's joke...

Re:And its not even the 1st...

[dirtyforker]

Don't be silly. Debian don't release their April Fool's jokes until October.

Re:And its not even the 1st...

[Anonymous Coward]

They did actually intend to release it on April 1st, but it got delayed ...

Re:And its not even the 1st...

[Anonymous Coward]

But when they do, you get some of the most stable April Fool's jokes possible.

Re:And its not even the 1st...

[koxkoxkox]

Parent should be modded informative and not funny, as it is true : see http://lists.debian.org/debian-devel-announce/2007 /03/msg00023.html

Our secret plan was to announce the release on April 1st
(that would have been fun, don't you think so :) ), but well - quality is
more important.

Multipath broken in debian etch!

[ljaguar]

etch ships with CONFIG_IP_ROUTE_MULTIPATH_CACHED (experimental) enabled in the kernel. This breaks the multipath route behavior in iproute. As the google search shows, it is wreaking havoc with anyone using multipath and dual-wan systems. Those who upgraded this morning to the new stable may be in for a ride. This is a known and documented issue but cannot be found in debian's bug tracking system. This issue is not unique to Debian but it should not have passed through the release engineering for the new stable release.

Re:Multipath broken in debian etch!

[Bitsy Boffin]

Surely anybody doing anything like that would be rolling thier own kernel anyway? The only time I've used the Debian supplied kernels is when installing, soon as that's done I always compile a fresh one.

Re:Multipath broken in debian etch!

[fo0bar]

etch ships with CONFIG_IP_ROUTE_MULTIPATH_CACHED (experimental) enabled in the kernel. This breaks the multipath route behavior in iproute. As the google search shows, it is wreaking havoc with anyone using multipath and dual-wan systems. Those who upgraded this morning to the new stable may be in for a ride. This is a known and documented issue but cannot be found in debian's bug tracking system. This issue is not unique to Debian but it should not have passed through the release engineering for the new stable release.

So, this was reported for a different kernel on a different distro? What happened when you filed the bug report with Debian's BTS?

Re:Multipath broken in debian etch!

[Anonymous Coward]

Hmm, why does someone post to a site named debian-administration.org, but does not make a Debian bug report?

Re:Multipath broken in debian etch!

[Anonymous Coward]

not everyone's got the time and rarely anyone has the need. don't be a gentoo user.

Re:Multipath broken in debian etch!

[ljaguar]

i didn't know about it until i updated and things broke.

as a debian stable user, there's a reasonable expectation that, after 21 months in development, they don't ship a kernel with experimental feature that is known to be broken?

I don't mean this is an experimental feature that breaks sometimes. This feature is just clearly documented to be broken. As in it doesn't work.

I only found out about the stuff that I posted because I updated this morning and all hell broke loose.

I know I should have tested it on a test machine before bringing it into production. (or maybe waited a bit) But this is a small machine in an informal setting. I don't have a test machine. But I do have 20+ users with slow internet. and it's really not asking for too much to expect a thing so blatant.

Re:Multipath broken in debian etch!

[cxreg]

not everyone's got the time and rarely anyone has the need. don't be a gentoo user.

That's pretty ignorant. Few if any pieces of software have the number of compile time options as the Linux kernel. Even if you module-ize everything you possibly can, there are still many choices you make that you are bound to, such as IO schedulers and pre-empting.

Any serious Linux user is capable of and knows the value of compiling their own kernel.

Re:Multipath broken in debian etch!

[cymen]

If you have no test system and the machine is providing service to users then do not upgrade to .0 releases. It's simple common sense. Maybe you had some overwhelming need to get this release that goes against the need to keep service reliable but you didn't mention it so I'll assume not. Let other people do the testing of that .0 release to find all the bugs and huge gotchas that are basically inevitable.

Re:Multipath broken in debian etch!

[Anonymous Coward]

If you think this should be fixed, please file an appropriate bug report at http://bugs.debian.org/

Re:Multipath broken in debian etch!

[dondelelcaro]

This is a known and documented issue but cannot be found in debian's bug tracking system. This issue is not unique to Debian but it should not have passed through the release engineering for the new stable release.

The reason why it slipped through the release engineering for the new stable release is quite simply because no one reported it as a bug.

If someone had reported it, it would have been dealt with and otherwise resolved. Indeed, it may still be resolved in a point release, but it definetly won't be unless you (or someone like you) who experiences the bug files a bug in the bug tracking system (using reportbug or your MUA). Since (as of a few days ago) no one has filed such a bug related in anyway to MULTIPATH_CACHED, it has not been fixed.

Considering the sheer number of people who (supposedly) use testing, none of whom apparently found the bug and/or bothered to report it, it was just not a popular feature to have been tested properly. Like it or not, a critical part of Debian's QA are the users who are using the testing and unstable distributions and reporting bugs. If they don't find it, no one will. (In case you haven't figured it out yet, there's nothing magical about being a Debian Developer in this regard; we're users too, and do the same type of testing.)

Re:Multipath broken in debian etch!

[gweihir]

Huh? Who uses distro-supplied kernels anyways, except for the initial installation?

Re:Multipath broken in debian etch!

[Macka]

I know I should have tested it on a test machine before bringing it into production. (or maybe waited a bit) But this is a small machine in an informal setting. I don't have a test machine. But I do have 20+ users with slow internet. and it's really not asking for too much to expect a thing so blatant.

Man, that's pretty reckless, and you know it. Did you even take a backup first? As for not having a test machine, with Xen and VMware are your disposal these days there's no real excuse for not installing it elsewhere, and at least taking a few days to give it the once over before going near a real server. The truth is that you rushed in without proper forethought and planning and you got burned.

Re:Multipath broken in debian etch!

[Anonymous Coward]

When you start with Linux, you use the stock kernel, because it is easily available and works. When you gain experience, you start to compile your own. When you become a professional sysadmin, you use the stock kernels, because they are easily available and work.

Re:Multipath broken in debian etch!

[ljaguar]

you say that as if debian .0 releases are just any old .0 releases.

debian testing release is one of the most popular distribution in its own right.

this isn't exactly some hacked up job released after big push to meet deadline. this went through months of release engineering and countless beta-testers.

debian stable release (the snapshot of etch as of today) do not get updates or bugfixes. etch 4.0 will not see any updates to gnome or kernel or gaim or anything. debian stable only gets security bugfixes. (if the bug is just a bug without security implications, it does not get fixed.)

don't you think this puts on an extra burden of not enabling (once again, known to be nonfunctional) experimental kernel option?

yes, testing before live production is good practice. yes, patience before upgrading is a virtue. but only because debian fucks up sometimes. if debian doesn't fuck up ever, patience is not a virtue. and i'm saying that debian fucked up.

Re:Multipath broken in debian etch!

[wouterke]

Because compiling your own kernel is a waste of time, and the benefits from optimizing it for your own processor are negligable anyway?

Re:Multipath broken in debian etch!

[Anonymous Coward]

thank you.

Re:Multipath broken in debian etch!

[logixoul]

Um, me? Why would I go out of my way to introduce points of failure in an integrated system with the promised benefit of gaining, like, 5% more speed? (not trolling btw, just curious)

Re:Multipath broken in debian etch!

[oddityfds]

> Any serious Linux user is capable of

Yeah. Except they always seem to end up disabling initrd for some unknown reason ("initrd is hard, man..." ... not), and then forget to reenable it when they switch back!

> and knows the value of compiling their own kernel.

Yup. 0, to me, except if I do some forms of kernel hacking.

The statment "Everyone serious compiles their own kernel anyway" is just not true.

Re:Multipath broken in debian etch!

[Anonymous Coward]

When you become a professional sysadmin, you use the stock kernels, because they are easily available and work.

Not to mention you don't have time to go compiling custom kernels on 50 different systems. Then try to explain when you file a bug report that "Well, no, the problem doesn't happen with the stock distribution kernel, just my custom one but I can't find anyone else having this problem with any other system than distribution X so it seems to be a bug here in something that we're tickling." Nope. Custom kernels are a bad idea... even OpenBSD maintainers will tell you to FOAD unless you're running their distributed kernel because they have no idea WTF you've done to your kernel.

Re:Multipath broken in debian etch!

[rbanffy]

The problem with rolling out my own kernel is that the more customized the machine gets, the more complicated it is to rebuild it.

I had used my own kernel fresh from kernel.org for ages, but then I realized it was so much more work than just running the stock kernel - that had all the problems and workarounds documented - in order to be on the bleeding edge (something hard to do with Debian stable, anyway). I just gave up on it. I thought that if there is a package manager, I should use it fully. "linux-image" is a package.

I see heavily customized kernel machines or hand-installed software have more maintenance problems, take longer to rebuild on disasters and, in general, cost more to keep running than fully packaged ones.

If running stock machines increases reliability and reduces cost, it's only my sense of adventure that kept me building my own kernels. It was nice to learn my way around it and is a handy knowledge if something really requires it, but, if the standard one does the job you, I advise you to stay with it.

That said, I still prefer to install the "non-infrastructure software" on a given machine (Zope, Plone, JDK, Tomcat, Rails are the usual suspects) by myself, outside package management. I don't want to be surprised by apt if something breaks the hard way.

Re:Multipath broken in debian etch!

[daveewart]

Any serious Linux user is capable of and knows the value of compiling their own kernel.

Which includes knowing when it is not necessary to do so. Unless you have extremely strange hardware, or very esoteric requirements for the system, the packaged kernels are absolutely fine. Building your own gains very little over the packaged kernels in these circumstances, either in performance or convenience; it will probably actually make life more complicated, as you will need to keep your kernel up-to-date manually, rather than just using the newer packaged kernel for your distro.

Re:Multipath broken in debian etch!

[smittyoneeach]

Now, why might this be a common behavior pattern?
You try out a new tool, you do the Dumbest Thing That Could Possibly Work, because you don't know any better.
You gather some experience, and you try out all of the gizmo features, to strut your stuff.
Once the 'new' wears off the gizmo features, you relax, and go back to the DTTCPW, because you're bored of the gizmos.
What's the difference?
When things go wrong, you know which of those gizmo features to trot out and fix the problem.
It's all about negotiating the learning curve, man. Rather like a plant that grows madly when planted, becomes overgrown, and requires a trimming to come back to a full, balanced maturity.

Re:Multipath broken in debian etch!

[koh]

Recent Linux adopters (especially Windows-converted ones) do not feel the need to tinker with the kernel. After all, the web says that if you mess up, you won't be able to boot, you should have an emergency livecd ready, etc. And it works NOW anyway. Madness.

Fortunately, with tools like genkernel et al., they don't need to. Who cares if they use the deadline scheduler instead of CFQ? Who cares if they load dozens of modules that end up returning "no such device"? As long as it runs, and it brings new adopters, tweak your own kernel and be happy with it :)

Moreover, what if genkernel eventually, say, becomes able to scan and profile your block device access, then choose the appropriate I/O scheduler? Won't you run it, just once, before reconfiguring your kernel just to check out what it says? What if it's right?

Easily configurable kernels. Let them have it. I remember back in the days when I spent all-nighters getting the freaking things to recognize a CD-ROM drive. This rite of passage is really getting old.

Re:Multipath broken in debian etch!

[mr_sas]

When you start with Linux you use whatever kernel your distro vendor gives to you.

Re:Multipath broken in debian etch!

[swillden]

Any serious Linux user is capable of and knows the value of compiling their own kernel.

Particularly on Debian, since it makes it so easy.

apt-get install linux-source-<version> kernel-package
cd /usr/src
tar jxf linux-source-<version>-tar.bz2
cd linux-source-<version>
make xconfig
make-kpkg --initrd kernel_image

The result is an installable .deb package. To make the configuration process quicker, copy your current kernel config from /boot so you can just tweak the items you want to change, rather than starting from scratch. Note that you only need to install kernel-package the first time you do this. It provides the make-kpkg command, and depends on all of the needed build tools so that they'll all get pulled in as well. Also, you can skip the "--initrd" option to make-kpkg if you're careful to make sure that all components needed to boot the system are compiled into the kernel image, not built as modules.

That said, I rarely build my own kernels. I used to do it frequently, because I needed to add some patch to support some hardware component or something, or because I thought it would be beneficial to strip the kernel down to exactly what I needed. These days I don't own a machine with less than 1GB RAM, and I rarely run into hardware that requires kernel patches -- usually the driver is in the kernel tree and when it's not modules-assistant will nearly always build me a module with a minimum of fuss. So now the only time I build a custom kernel is when I want to tweak some obscure option or I'm actually hacking on the kernel.

Re:Multipath broken in debian etch!

[Anonymous Coward]

Don't you think this puts on an extra burden of not enabling (once again, known to be nonfunctional) experimental kernel option?

Because this is Debian Linux, the answer to your question is, "Yes, you should have known about it and filed a release critical bug."

Re:Multipath broken in debian etch!

[cas2000]

> When you start with Linux, you use the stock kernel, because it is easily available and works.
> When you gain experience, you start to compile your own.

so far, so good. reasonably accurate.

> When you become a professional sysadmin, you use the stock kernels, because they are easily available and work.

no, that's when you've become a lazy slob. don't project your faults onto others.

real professional sysadmins compile a custom kernel that is perfectly suited to the particular server, with exactly the drivers it needs either compiled in or as loadable modules....plus a bunch of extra network card etc drivers compiled in as modules in case they're needed for an emergency replacement if a NIC dies (i.e. drivers for whatever's common and/or cheap and available from any computer shop in an emergency...doesn't matter if it sucks, as long as you can get the machine running quickly while you get the real card replaced).

Re:Multipath broken in debian etch!

[CRiMSON]

Cause we all know recompiling your kernel is a HUGE undertaking.

Re:Multipath broken in debian etch!

[Door-opening Fascist]

As a professional sysadmin, I've only built a custom kernel if there was actually some real gain to be had. Otherwise, it just makes installing updates harder. Anything that makes a box unique is one more thing that can break in a pre-packaged update. In modern hardware there's not much to be gained by paring down the kernel, and vendor kernels I've seen are heavily modularized anyways.

Re:Multipath broken in debian etch!

[Anonymous Coward]

Eh, I think you're being a tad silly. Some "real" pro sysadmins run one or two really big servers, and they probably do all that kind of special configuration and planning. Many (I'd say most) pro sysadmins have to deal with two or three... dozen. When you have that much going on, consistency of software is more important than the hand-tuning.

As an analogy, you'd be a really dumb automotive engineer if you tried to hand-tune every Toyota Corolla off the assembly line. On the other hand, though, you'd also be really dumb to NOT hand-tune a Formula One race car.

Re:Multipath broken in debian etch!

[Anonymous Coward]

The reason why it slipped through the release engineering for the new stable release is quite simply because no one reported it as a bug.

That is reasonable, but when they introduce old bugs that have been fixed*, one has to wonder if they are really up to the task of keeping a sane kernel. As much as I like to use Debian, I don't think it has the same quality as it used to have.

* Loading of kernel modules for disabled onboard sound devices, preventing other sound cards from working. Affects the Deb AMD64 on A8V mobos for instance.

Re:Multipath broken in debian etch!

[YoungHack]

When you start with Linux, you use the stock kernel, because it is easily available and works. When you gain experience, you start to compile your own. When you become a professional sysadmin, you use the stock kernels, because they are easily available and work.

That is so true. It drives me nuts when a system is "special" and I have to go back and compile a custom kernel for it. I've been trying to standardize back to stock kernels for quite a while now. Definitely less headache when possible. The more systems you run, the more convenient stock kernels are.

Re:Multipath broken in debian etch!

[gmack]

The problem with using distro kernels is that if your machine is new enough there will be drivers you need that aren't in the distro kernel or won't unnecessarily work properly.

I've had customers give me servers with not supported or improperly supported network devices and raid controllers.

My personal PC has a sound controller that's not supported by anything older than 2.6.19.

It used to be that when I'd do a Linux install I would install my own php, apache, ftpd, mysql etc but over time it's gotten better. Now I'm down to the kernel and my favorite window manager.

I have little doubt there will come a day when I don't need to do my own kernel installs but that day isn't here yet.

Re:Multipath broken in debian etch!

[GrenDel Fuego]

I think at the end of the day it all depends on what you need to support. If you're supporting a single high performance system, well then a hand optimized kernel makes sense.

If you're supporting a few hundred servers then any differences between the systems need to be kept to a minimum.

Re:Multipath broken in debian etch!

[fimbulvetr]

I think you're trolling, you can count the number of servers you admin on one hand, or you're inexperienced. You might say it's because I'm a lazy slob, I might say it's because I have several hundred machines. While groups of them are the same (6 here, 12 there, etc.), it'd be absurd to even consider what you're suggesting - not to mention the insanity a security update could bring.

Re:Multipath broken in debian etch!

[fimbulvetr]

WTF?? It's a .0 release. This means there have been MAJOR (Repeat: MAJOR) changes. Despite having been in RC Status for some time, bugs WILL still leak through, and the initial wave of upgrades will certainly be hit by a few. Check the mailing list for every single debian release. Shit happens.

If you think the debian release team owes you a favor, good luck.

p.s. debian stable can get fixes outside of security, but only for high priority bugs dealing with data loss and the like.

p.p.s. you speak of "experimental" in the kernel with a negative connotation. Normally, "experimental" in the kernel means "a helluva lot more stable than what comes out of redmond". Do you understand the process code has to go through to make it into a vanilla kernel? It's pretty much past late RC stage.

Re:Multipath broken in debian etch!

[Anonymous Coward]

When you become a professional sysadmin, you use the stock kernels, because they are easily available and work

There's no such simplistic rule. Professional sysadmin, managing 1500 machines. Using Debian with custom-compiled kernels, no initrd/initramfs, self made scripts to auto-deploy. It all depends on what you call "professional". To me an admin managing 30 machines in a SME is just as "professional" as another one managing 1500 machines. Some sysadmin compile their own kernels, others don't. But at first sight I'd be enclined to say that an admin rolling is own kernels on 1500 machines with custom-made scripts probably knows his job.

Without even mentionning that nowadays partitionning/virtualization is getting bigger and bigger by the day and that with quite some technologies you MUST compile your own kernel (good luck using, say, a stock Xen kernel that supports all the hardware you need... And, yup, Xen is used professionally since quite some time).

YMMV, but you're +5 insightful only reflects shortsightedness: just as it is dumb to say "anyone knowledgeable compiles its own kernels" it is stupid to say "anyone really knowledgeable uses stock kernel". Black / White. Way too simplistic nonsense.

Re:Multipath broken in debian etch!

[Mathness]

I was surprised to see that "bug" again. It is easyly dealt with, in /etc/modprobe.d/blacklist add

blacklist snd_via82xx
blacklist via82cxxx_audio

Re:Multipath broken in debian etch!

[lintux]

Actually IIRC you can change your I/O scheduler per-device on the fly via /sys or /proc. And for just the pre-emptive/non-pre-emptive difference, distros probably ship separate server/non-server kernels.

Re:Multipath broken in debian etch!

[misleb]

If nothing else, initrd has to go!

Re:Multipath broken in debian etch!

[rbanffy]

I had a similar problem a couple weeks ago.

I had one Dell Poweredge 1900 with a SATA RAID controller that was not supported by Debian stable. I simply decided it would be better to install CentOS instead, since it's good enough and the machine was supposed to host a bunch of virtual servers with OpenVZ. The VPSs are all Debian, but I saw it less of a problem to go Red Hat and Yum than it would be to roll our own kernels (and apply security fixes from time to time).

But I agree. With time, I came to rely more and more on the OS package management - even if I have to change OSs sometimes.

Re:Multipath broken in debian etch!

[misleb]

No, when you become a professional, you make a custom kernel package and distribute it to all your servers running Debian... preferably through your own custom package repository... because that way it is easily available and it works.

-matthew

Re:Multipath broken in debian etch!

[drinkypoo]

My personal PC has a sound controller that's not supported by anything older than 2.6.19.

Ubuntu Feisty: Linux sec2lpt7-linux 2.6.20-14-generic #2 SMP Mon Apr 2 20:37:49 UTC 2007 i686 GNU/Linux

Granted it's a beta release, but I've found that Ubuntu betas are more stable than some distributions' finals.

Re:Multipath broken in debian etch!

[strstrep]

Debian stable gets bugfixes for significant bugs in later -r1 -r2 releases. This is not limited to security bugfixes. Security bugfixes are the only ones that are pushed out using the security.debian.org repository, however.

Re:Multipath broken in debian etch!

[drinkypoo]

WTF?? It's a .0 release. This means there have been MAJOR (Repeat: MAJOR) changes. Despite having been in RC Status for some time, bugs WILL still leak through, and the initial wave of upgrades will certainly be hit by a few. Check the mailing list for every single debian release. Shit happens.

It's called debian stable. It should use stable, tested features. Enabling experimental features and not doing exhaustive testing puts this kernel release directly into the "amateur" camp, which is sad because Debian is a mainstay.

you speak of "experimental" in the kernel with a negative connotation. Normally, "experimental" in the kernel means "a helluva lot more stable than what comes out of redmond

It's labeled experimental for a reason. That means don't use it in production because it may change and if it is not currently broken, it probably will be later.

And frankly I am tired of seeing the argument of "better than windows". Well, whoop de fucking shit. Windows 2000 is by all reports a better operating system than Vista (in terms of doing what you want it to do) but I wouldn't use either to operate a nuclear power plant. Besides, the EULA forbits it. Explicitly.

Re:Multipath broken in debian etch!

[Cal Paterson]

The statment "Everyone serious compiles their own kernel anyway" is just not true.

Not only is it not true, it's not even what the GP said.

He said that any serious user is capable of compiling their own kernel. This is largely true. Go ask on #debian; most of them are actually capable of it, but don't actually do it, because the benefit is not enough.

On my aging laptop, smaller, static kernels are useful to me because otherwise boot times become too long. So there, I do build my own kernel - with debian testing no less.

Re:Multipath broken in debian etch!

[PitaBred]

It's not. But I have better things to do, like actually use my computer and not worry about having to recompile when a security update comes down the line.

Re:Multipath broken in debian etch!

[Copid]

Um, me? Why would I go out of my way to introduce points of failure in an integrated system with the promised benefit of gaining, like, 5% more speed? (not trolling btw, just curious)

I wouldn't even go that far. I just built a debian system on an amd64 machine and went through to customize the kernel. What I found was that I only changed a few minor options from their stock amd64 configuration. The only major difference is that the one that comes from Debian has every module under the sun ready to load, and I didn't feel like screwing around disabling them to save a few minutes of compile time. I spent quite a lot of time messing around for no appreciable gain.

I used to do a lot of kernel building and tuning. When I was in college, my machine always had the bare minimum kernel stripped down to just what I was using. It made a difference, but it was a pain. These days with the set of options available in the pre-packaged kernels, I rarely bother unless I need something weird (e.g. The 4KB kernel stack size is too small). When I go down the list of reasons to take my time to build a custom kernel, performance is just slightly ahead of "I like watching text scroll by" in order of importance.

Re:Multipath broken in debian etch!

[fimbulvetr]

It's called debian stable. It should use stable, tested features. Enabling experimental features and not doing exhaustive testing puts this kernel release directly into the "amateur" camp, which is sad because Debian is a mainstay.

Do you not understand? Exhaustive testing is done by YOU! and me, and the original poster who seems to have accomplished the epitome of bad administration. It's our job to try and break the betas, alphas and RCs. It's our fault if the final release doesn't work with our exotic setup. It's amazing how the concept of Linux escapes some people. Linux is us. Us is Linux. IOW: We have seen the enemy, and he is us.

It's labeled experimental for a reason. That means don't use it in production because it may change and if it is not currently broken, it probably will be later.

No, it means that the code looks good, everything seems reasonable, but we were unable to account for anything more than 99.9% of things. If you think you're outside of 2+ standard devations, please be cautious when trying this option. If your machine isn't anything funky, you'll be just fine.

And frankly I am tired of seeing the argument of "better than windows". Well, whoop de fucking shit. Windows 2000 is by all reports a better operating system than Vista (in terms of doing what you want it to do) but I wouldn't use either to operate a nuclear power plant. Besides, the EULA forbits it. Explicitly.

Guess I struck a chord. I'll leave Windows out of this, then.

Re:Multipath broken in debian etch!

[drinkypoo]

It's labeled experimental for a reason. That means don't use it in production because it may change and if it is not currently broken, it probably will be later.

No, it means that the code looks good, everything seems reasonable, but we were unable to account for anything more than 99.9% of things.

I hate to have to be the first person to tell you this, because it implies that you have been living under a rock up to now, but this is how all software works. In fact, I doubt that most software can be counted on to be that reliable.

But this is Debian stable. It's supposed to be stable! It's not called Debian Experimental. Activating unnecessary experimental features just plain doesn't make any sense.

Guess I struck a chord. I'll leave Windows out of this, then.

It's not just Windows, the point is that we don't need to compare to another operating system to make a judgment about whether something works right or not, or whether a reasonable decision was made - although it's true that Windows is just about the worst basis for comparison.

Re:Multipath broken in debian etch!

[Anonymous Coward]

i used debian's kernel-package to build a kernel as close to debian's stock kernel as possible. (same patch-level, same config except the one tiny option)

on my pentium II, it took 4+ hours. (because stock builds just about every module out there)

you must admit, it is a pain that could have been avoided by foresight.

Re:Multipath broken in debian etch!

[Anonymous Coward]

From what i have seen, the disabledness as listed in the bios can only trick the windows os itself. Windows doesn't seem to be able to 'see' the disabled hardware, but drivers/software running under windows can. Linux just seems to be able to find it itself. This might not be whats causing your particular problem, but it is just something i have noticed that might be helpful.

Re:Multipath broken in debian etch!

[Anonymous Coward]

20+ users and one server. This is the kind of place where the "debian true believer" works. As you can see debian does not live up to the hype but you believe it anyways. I was using a mission critical server running debian admined by a true believer. When he updated to the last stable release all those years back whenever it was, well, all kinds of shit broke. It was a huge mess. But he continued to believe. Why, i do not know because it was clear as day that debian was a fiasco. It was so outdated and behind on any innovation happening in open source and then the release finally comes and screws the whole site so bad...damn.

If you look at admins on huge "enterprise level" deployments they basically use redhat or maybe suse.

Once (if) you graduate to "the big leagues" of managing a whole corporate network putting faith in a project like debian is just not going to cut it.

Re:Multipath broken in debian etch!

[gweihir]

Because compiling your own kernel is a waste of time, and the benefits from optimizing it for your own processor are negligable anyway?

It is not about speed. It is about stability and features. One thing I do is compile my hardware in statically, nothing to go wrong on module loading. There are numerous other things. Also, it is a great way to keep up with what is currently supported by the kernel. And, lo and behold, if I run my own kernel, no distro-update can break my kernel!

Re:Multipath broken in debian etch!

[petermgreen]

yeah that is a good idea if you run on identical hardware and have a good reason to use a custom kernel.

but why worry about supporting a custom kernel when you don't have to? are marginal performance gains really worth the hassle of maintaining one or more custom kernels for the boxes you administer?

Re:Multipath broken in debian etch!

[misleb]

yeah that is a good idea if you run on identical hardware and have a good reason to use a custom kernel.

This isn't Windows. LInux is pretty forgiving about different hardware. For most machines, the only significant difference is the ethernet card. And you can have all those compiled as modules.

but why worry about supporting a custom kernel when you don't have to?

Perhaps if you don't have to, yoiu shouldn't. But often there are good reasons. Biggest reason (for me) to compile a customer kernel is to get rid of initrd and simplify your bootup procedure. Another reason is to get new features and hardware support. If you have one machine that needs some special hardware driver, it is easier to just build a single kernel package and distribute it to all machine than to keep track of which ones have a custom driver/kernel. Debian kernels, like the rest of the packages, have nasty habit of getting pretty outdated.

are marginal performance gains really worth the hassle of maintaining one or more custom kernels for the boxes you administer?

It isn't necessarily about performance.

-matthew

Re:Multipath broken in debian etch!

[adrianmonk]

I think at the end of the day it all depends on what you need to support. If you're supporting a single high performance system, well then a hand optimized kernel makes sense.

Only insofar as Linux can't get full performance with a stock kernel. Which brings up two questions:

1. Is there really a difference?
2. If so, is it a necessary difference?

I am not a Linux expert (although I've been using various flavors of Unix and Linux for 17 years), but I know there are plenty of versions of Unix that don't ever require kernel recompiles. Maybe someone who is an expert with Linux can explain whether a custom kernel really does provide performance improvements (aside from "I saved 10 kilobytes of RAM").

And if recompiling really does make a measurable improvement in performance, it would also be nice to know whether that's an inherent issue or whether there might be ways to make the stock kernel build perform just as well as virtually any custom build. That is, would it be possible to eliminate the difference if it were a major goal of the Linux development effort to do so?

Re:Multipath broken in debian etch!

[wouterke]

That does mean you get to recompile your kernel every time you buy a new mouse. Well, not that often, perhaps, but you get the point.

Re:Multipath broken in debian etch!

[PastaLover]

I am not a Linux expert (although I've been using various flavors of Unix and Linux for 17 years), but I know there are plenty of versions of Unix that don't ever require kernel recompiles. Maybe someone who is an expert with Linux can explain whether a custom kernel really does provide performance improvements (aside from "I saved 10 kilobytes of RAM").

And if recompiling really does make a measurable improvement in performance, it would also be nice to know whether that's an inherent issue or whether there might be ways to make the stock kernel build perform just as well as virtually any custom build. That is, would it be possible to eliminate the difference if it were a major goal of the Linux development effort to do so?

The only reason why I recompile my kernels these days is because I run them on desktop systems and CONFIG_PREEMPT is disabled in the default debian kernels (which makes sense for a server system, but not a desktop one). This sacrifices some throughput for lower latency, which makes the system far more usable on a desktop system. If you measure your performance in throughput of course, this actually reduces performance. Most other stuff in the kernel I know of is configurable (i.e. the schedulers) or equally niche (optimize kernel for size, interesting for embedded systems).

When looking around for the CONFIG_PREEMPT thing I found some old threads that indicated it used to configurable, but apparently it isn't at the moment, or not as far as I can tell. Ubuntu ships with it enabled by default, which makes sense for a desktop distro.

Re:Multipath broken in debian etch!

[PastaLover]

And for just the pre-emptive/non-pre-emptive difference, distros probably ship separate server/non-server kernels.

Yeah Debian doesn't. I brought it up on debian-devel a while ago but didn't get any responses. I guess people just don't feel like supporting both or something.

Re:Multipath broken in debian etch!

[Magada]

Afaik, you can and should assign a slot for each card you have - including the onboard one - in /etc/modules.d/alsa or whereever your distro keeps them:

#real soundcard
alias snd-card 0 snd-
alias sound-slot 0 snd-

#onboard
alias snd-card-1 snd-via82xx
alias sound-slot-1 snd-via82xx

Re:Multipath broken in debian etch!

[cas2000]

> I think you're trolling, you can count the number of servers you admin on one hand, or you're inexperienced.

wrong on all three counts. i've admined hundreds of servers for over 10 years.

> You might say it's because I'm a lazy slob, I might say it's because I have several hundred machines

so? that's not unusual.

apt-get install kernel-package

(i'll presume you already have ssh installed for scp and dont need to install it)

> While groups of them are the same (6 here, 12 there, etc.), it'd be absurd to even consider what you're suggesting

it's not difficult. you just need to manage your kernel .config files. copy them in and out of /usr/local/src/linux as required, and use "make oldconfig" to answer any new/changed questions in newer kernels, and keep copies of each config for each machine/kernel-version combo. e.g. cp .config ../CONFIGS/config.machine.version

> not to mention the insanity a security update could bring.

you mean you let apt upgrade your kernel automatically? that's not just lazy and slobbish, that's cretinously negligent.

the main reason to compile custom kernels for machines is not for size or speed, it's so that you, as sysadmin, know exactly what is compiled into that kernel.

Re:Multipath broken in debian etch!

[fimbulvetr]

you mean you let apt upgrade your kernel automatically? that's not just lazy and slobbish, that's cretinously negligent.

ORLY? Tell me, after I've tested the updates on my lab servers, and considering a update is only a backport of a fix, how could it possibly be negligent? Oh, I see, it's not really, you just didn't want to admit that when compiling your own kernel it's a very very bad idea to consider updating all of your machines manually when a new one comes out.

the main reason to compile custom kernels for machines is not for size or speed, it's so that you, as sysadmin, know exactly what is compiled into that kernel.
Oh yeah, I forgot that 'less /boot/config-$version' didn't work.

Listen, you can compile your kernels all you want, I'm not saying it's bad. I am, however, saying it's a waste of time and you have yet to refute that. The onus is on you to prove otherwise since you're preaching about how it's such a good idea.

Re:Multipath broken in debian etch!

[emilper]

ljaguar, you've been plagiarized by the famous Steven J. Vaughan-Nichols. You made it to eweek.com, too.

Re:Multipath broken in debian etch!

[NateTech]

So quit whining and put it IN the bug tracker. Sheesh.

This release begs the question...

[bogaboga]

The question is: -

Will I be able to have Debian perfectly handle [all] my basic multimedia requirements well by default? I would like to play Yahoo, CNN, ABC, BBC andd FOX video and audio by default. Let a slashdotter inform a soul.

Re:This release begs the question...

[The Anarchist Avenge]

You keep using that word. I do not think it means what you think it means.

Re:This release begs the question...

[Doctor Crumb]

Short answer: no. Long answer: not until those sites release their content in a format that can be legally distributed by debian. "Free Software" does not only refer to the price.

Re:This release begs the question...

[Anonymous Coward]

And how does that relate to petitio principii??

Re:This release begs the question...

[MrDomino]

By default, no. You'll have to install some extra packages from the non-free repository to play non-free media. However, all your multimedia requirements are just an apt-get install away; flash 9 (which fixes lots of long-standing Linux flash issues), mp3, win32 codecs, etc... I've been using it on my laptop for a while, and it's been pretty solid; I've got no complaints yet.

Re:This release begs the question...

[Geoffreyerffoeg]

"Means." You keep using that word. I do not think it means what you think it means.

In particular, the English language is defined by common use, not by some hypothetical Academie Anglaise, and certainly not by Slashdotters.

Re:This release begs the question...

[MadMidnightBomber]

<pedant>No, begging the question is assuming the answer. It justs asks the question.</pedant>

Anyway debian provides a wonderful, stable server distro with the best free software out there. If you want stuff like proprietary audio and video codecs, you can probably get or compile them, but it's not the primary goal of debian. You might be better off with something else.

Re:This release begs the question...

[CrossChris]

Will I be able to have Debian perfectly handle [all] my basic multimedia requirements well by default?

Don't be silly. Debian is predominantly American distro, and they're scared sh*tless of the DMCA. Most multimedia codecs contravene that Act, and also contravene the Debian "purity" doctrines!

If you want a distro with pre-installed, comprehensive multimedia capabilities, you'll have to look at Mint Linux or PCLinuxOS.

Re:This release begs the question...

[Kjella]

Flash 9 is just to apt-get from non-free. As for multimedia, I use debian-multimedia as the source, but it still doesn't seem to play embedded WMV (I just get a gray box), I've understood there's some plug-ins to fix it for Firefox but not for Opera...

Re:This release begs the question...

[Professor_UNIX]

Will I be able to have Debian perfectly handle [all] my basic multimedia requirements well by default? I would like to play Yahoo, CNN, ABC, BBC andd FOX video and audio by default.

No, but it's not really the fault of the Debian (or any GNU/Linux distribution) maintainers. Many of these sites are defective by design and only work properly with Windows... sometimes only with a certain version of a Windows web browser: Internet Explorer 6. As a MacOS X user it's a *little* less painful to get a lot of these sites to work in Firefox or Safari in order ot get streaming video to work, but by no means does everything run smooth. The situation is even worse with Linux in regards to how poorly these sites choose to support that platform.

The only thing I'm happy about is that most of these sites are migrating to using streaming video using a Flash-based player like YouTube does so they just use normal HTTP for the transfer mechanism and are simple to get working through a firewall. In the bad old days I had to worry about shit like RealVideo proxies, Quicktime, RTSP, PNA, Windows MMS, etc. While they're probably more efficient, they require your firewall to have a specialized application proxy and it's just an extra pain in the ass if they break the protocol in a new version. The sites that aren't using a Flash player are just streaming Quicktime/Windows Media over HTTP as well so it has the same effect. The main pain-in-the-ass site I experience is with CNN and FoxNews.

Re:This release begs the question...

[Qzukk]

In particular, the English language is defined by common use

Not only that, but "beg" means exactly what the original poster meant it to mean, it's only that someone else came along and said "if you use it like this, then you actually mean something that has nothing at all to do with asking for something".

Re:This release begs the question...

[fdfisher]

Will I be able to have Debian perfectly handle [all] my basic multimedia requirements well by default? I would like to play Yahoo, CNN, ABC, BBC andd FOX video and audio by default. Let a slashdotter inform a soul.

No, because many of those are proprietary formats, which Debian will never support out of the box. However, it is very easy to enable those formats by adding any number of alternative package repositories at apt-get.org.

Re:This release begs the question...

[rawtatoor]

Debian Multimedia

It isn't quite as involved as you think. I believe everything you could want are in the deb multimedia repo, including the W32 codecs and libdvdcss.

Its as easy as adding the line to your sources.list:
deb http://www.debian-multimedia.org/ sarge main
Of course that is for i386, check the bottom of the above link to see the available options

Re:This release begs the question...

[mdm-adph]

Dear god, I know what you mean -- CNN's video player causes my old Linksys Wireless-B router to go completely kaput everytime I try and view a video. It's a pretty well-documented problem, one that Linksys refuses to fix.

Re:This release begs the question...

[Anonymous Coward]

The OP may be begging, but the question was not begging. Please don't protest if people correct him. I know how language develops in general, but you shouldn't expect educated people to champion the legitimacy of inaccuracies and mistakes, even if they sometimes win out in the end.

Re:This release begs the question...

[PastaLover]

Will I be able to have Debian perfectly handle [all] my basic multimedia requirements well by default? I would like to play Yahoo, CNN, ABC, BBC andd FOX video and audio by default. Let a slashdotter inform a soul.

Yahoo probably won't work. They go out of their way to make it hard for you to watch video. Apple movies works fine with the extra codecs and stuff mentioned elsewhere though.

Re:This release begs the question...

[HeroreV]

What about the freedom to enable support for evil proprietary formats via evil binary-only drivers? Giving me the option isn't going to take away my freedom.

Re:This release begs the question...

[Knara]

Isn't that what the non-free repositories are for?

Re:This release begs the question...

[HeroreV]

Users have to learn about those repositories, enable them, find out what packages they need to get, and install them. Debian doesn't try to help in the slightest.

When I (double) click on a file to open it, if it's possible to determine what software is needed to open it and I don't have that installed, the operating system should ask me if I want to install the necessary software, even if it nags me about legality and freedom and whatnot.

That would be giving me an option. An operating system should try to help users do whatever they want to do. Since it's obvious that many users want to enable such stuff, the operating system should try to help them do it.

Re:This release begs the question...

[Knara]

I don't know if you've noticed, but Debian isn't a "beginner" Linux dist and doesn't try to be. It's a distribution aligned behind an ideal. Now, no one is saying that you have to use Debian. Feel free to use Ubuntu, which is just Debian made easier (partially by restricting your options and partially by adding in software that doesn't jive with the driving ideal of Debian). That's fine, go nuts.

I don't see what the problem is here, really. The reason we have a lot of linux dists is exactly because people have different levels of technical aptitude, different levels of patience, and different expectations of their operating systems. Debian isn't your thing, that's fine. I'm not sure why you feel the need to have *them* change their dist practices and ideology when you can just go use RedHat/SUSE/Gentoo/Ubuntu/etc until you find the one you like.

Re:This release begs the question...

[Doctor Crumb]

You have just described *exactly* what ubuntu feisty(due for release in a week or two) does. When you first try playing an mp3/whatever, it pops up a dialog box asking you if you want to install the necessary stuff. It doesn't even nag you about legality or freedom. :)

I've been using Kubuntu feisty for a few weeks now (and ubuntu for over a year), and it is an *excellent* distribution.

Re:This release begs the question...

[HeroreV]

That's excellent news. Kubuntu Edgy is the first Linux distribution that I decided I could actually switch to from Windows.

Re:This release begs the question...

[HeroreV]

Debian isn't a "beginner" Linux dist and doesn't try to be.

I wish that was true, but it's not. Recently, many people high up in the Debian community have expressed that they want Debian to change in order to win over the people who have instead chosen Ubuntu. I absolutely hate that. I wish Debian would stay Debian and not try to become Ubuntu.

Now, no one is saying that you have to use Debian.

But there are people in the Debian community who want to get more people using it. I'm pointing out that without completely changing everything Debian stands for, that just isn't going to happen. I for one don't think Debian should completely change itself just to win a popularity contest.

The reason we have a lot of linux dists is exactly because people have different levels of technical aptitude, different levels of patience, and different expectations of their operating systems.

I totally agree! That's why I hate that Debian is changing!

Re:This release begs the question...

[Knara]

Changing Debian to be easier to use isn't a bad thing. There's no reason that there should be no attention paid to ease of use, so long as the ability to configure something to my liking isn't removed. I don't see any indication that Debian is doing that. On a related subject, while I don't use Gentoo, I found it an unhappy bit of news to learn they'd removed their stage 1 installation option as a default documented path. Seemed pointless to me.

Re:This release begs the question...

[Anonymous Coward]

I got news for you choad, my outdated debian 3.1 already has more codecs and handles more media types than the XP machine I have access to at work. Like the multipath BS above, its lame F.U.D. FUD!

Re:whew!!

[jackstack]

Guess not. should have known better.

Re:whew!!

[Anonymous Coward]

you fail it.

Shoddy rushed release

[canadiangoose]

So this is what happens when you rush a Debian release out in less than 2 years, eh?

Seriously though, this is a rather surprising bug to slip through.

Too late?

[ezh]

Debian has turned into a political zoo of OSS dinosaurs, who are too big and too ancient. They spend lots of time arguing over political issues and raise barrier too high for hew developers.

During Debian Project Leader (DPL) election campaign candidates were almost in unison looking up to Ubuntu as an example on how to attract new users and developers. With Etch out and new DPL in Debian's goal can be summarized in one phrase: "Let's catch up with Ubuntu"

How Debian's brand new DPL wants to do this:

• rework website
• rework bugtracking system
• sex up the desktop, and
• encourage optional desktop releases every 6 months...

I wonder how they are going to do it... Especially the last bit :-)

Re:Too late?

[cymen]

You know I spent a couple of years bitching about how slow Debian is to upgrade. Now I say let them be slow. They serve some market and plenty of other distributions serve those that want more up to date systems. Why change Debian? Slow releases are a core feature.

Re:Too late?

[Anonymous Coward]

too late? it broadly had the same or newer revisions of software than the just released RHL5, a few older.

kernel same
apache same
gcc same
openoffice same
postgres same
icdeove same
iceweasel newer
php newer
kde newer
mysql newer
gnome older

if you want bleeding edges you know the alternatives

Re:Too late?

[gweihir]

You know I spent a couple of years bitching about how slow Debian is to upgrade. Now I say let them be slow. They serve some market and plenty of other distributions serve those that want more up to date systems. Why change Debian? Slow releases are a core feature.

Actually, ''testing'' is usually reasonably current. If not, you can roll your own package or lock the package and install your own stuff over it. A bit of a pain, but that way I had X11 support for my 7600GT well before Debian had it.

I will likely be going to the next ''testing'' in a month or so.

Re:Too late?

[Anonymous Coward]

gcc same Actually RHEL's GCC includes all sorts of funky extra patches, e.g. OpenMP support that won't be in FSF until 4.2, generally because the Red Hat guys wrote them. I take your point in general but RHEL's GCC wins.

Re:Too late?

[swillden]

Actually, ''testing'' is usually reasonably current. If not, you can roll your own package or lock the package and install your own stuff over it. A bit of a pain, but that way I had X11 support for my 7600GT well before Debian had it.

And ''unstable'' is even more current than testing, and not unstable in the common sense of the word. The biggest annoyance I have with unstable is that my periodic upgrades are bigger than with testing, but I have a fast network connection, so I don't care that much. I've been using unstable as my primary work/play platform for about four years now, and the only time it's given me trouble was during a bit of XFree86 upgrade weirdness that lasted about a day.

Even better, if you're using unstable, it's really easy to pull packages in from experimental, which pretty much always has the latest and greatest releases of everything, so you almost never have to roll your own package or install from source.

In my experience, I have far less trouble running unstable than I do testing. The downside to unstable is that there is no security team addressing security fixes, but that's rarely an issue for long, since unstable tends to pick up upstream versions very frequently.

Re:Too late?

[Anonymous Coward]

Debian has turned into a political zoo of OSS dinosaurs, who are too big and too ancient. They spend lots of time arguing over political issues and raise barrier too high for hew developers.

And we will thank them if Debian will never sell itself like that Novell/SuSE hooker did to Microsoft's money.
The Social Contract at the Debian site is a freedom commitment that should be taken seriously before complaining about the way they manage the project.

Re:Too late?

[gweihir]

Well, I have to say I had some smaller issues with ''unstable'', so on my production systems (a Linux cluster among them and several servers)I want ''testing''. Have run it with automatic updates every 3 days for several years now and had one single issue, but that was minor enough that I do not remember what it was. And once I downgraded ssh to the version from ''stable'' without any problem at all, because there was a vulnerability. All these machines, except two, are not running X11, admittedly. But since X.org, there is hope that the problem that Xfree has become will indeed be solved. They should have forked some years eralier IMO.

I think most people are not aware how high the standards for ''stable'' really are in Debian. It is not only stable operation, but also no changes to interfaces and software, except security or other critical fixes. ''Stable'' is what you put on a server that has to be absolutely dependabl in the sense that maintenance updated do not break anything, not even software not part of Debian. Most people want to run ''testing'' and some indeed ''unstable''.

Re:Too late?

[swillden]

Have run it with automatic updates every 3 days for several years now and had one single issue, but that was minor enough that I do not remember what it was.

There's a good explanation of the reliability of testing vs unstable. With testing, it's quite safe to run with automatic updates, with a little monitoring of operations so that you'll notice if something breaks due to a config file format change or something similar. With unstable it's quite safe to perform updates, but you do want to take a look at the package list first, just so than in the rare case (i.e. once every few years) that something actually breaks -- rather than just needing to be reconfigured -- you know which package to downgrade until the problem is resolved.

And once I downgraded ssh to the version from ''stable'' without any problem at all, because there was a vulnerability.

For others who may not know, this is no longer necessary, because there is now a security team watching over testing. Stable has always received backported security patches, and unstable is kept up to date with upstream code, so security patches hit unstable quickly. For most of Debian's history, however, testing only got security patches after they'd made their way through unstable. Even in the best case, that meant a delay of 10 days or so, but in the worst case it might be months if there is some outstanding issue preventing the package update from moving into testing. As of about two years ago (IIRC), it was recognized that lots of users were using testing as a production distribution, and that the lack of security patches was a problem. So, a security team was organized for testing. They port security patches into whatever version of the package is currently in testing, avoiding the delay as fixes migrate in from unstable.

I think most people are not aware how high the standards for ''stable'' really are in Debian. It is not only stable operation, but also no changes to interfaces and software, except security or other critical fixes.

Indeed, testing is more stable than most distros' releases, and unstable is only slightly worse than most other releases. Debian stable sets a very high standard.

Debian on the desktop

[freefm]

Man, they really hauled ass and have some killer desktop features that rival Ubuntu's tbr, like restricted drivers install. I might check this out over ubuntu, 'cause I know how stable a server it is. Good show!

Any chances of KDE 4?

[ranga_the_don]

Does it bundle KDE4 by chance?

Re:Any chances of KDE 4?

[mr_sas]

No, KDE4 isn't released yet and is still some time away from being stable as far as I know.

Re:Any chances of KDE 4?

[Zantetsuken]

as far as I know, KDE4 will be out around October... wikipedia

Why compete?

[rolfwind]

I think this new Debian release is good news for Ubuntu which relies on it, so their next release can be on the 4.0 foundation.... but why would Debian want to compete with Ubuntu? They both have different goals in mind. I love Ubuntu to death, but with the 6 month release cycle, it feels like it's always advancing, but also not as stable as something that I would want to use on a server.

Re:Why compete?

[ezh]

We lost countless users to Ubuntu. Admittedly, Ubuntu drew a lot of its users from other distributions and even from Windows. But there is no reason for Debian to be simply the distribution upon which Debian-based distributions are based, we can also get new users by being more appealing.

http://www.debian.org/vote/2007/platforms/sho

Re:Why compete?

[mr_sas]

You don't have to upgrade Ubuntu every 6 months just because they release that often, every release is supported for 18 months and Ubuntu 6.06 (Dapper) is supported for 5 years on the server.

Ubuntu don't base their releases on stable Debian, they base it on unstable (Sid)

Re:Why compete?

[Anonymous Coward]

Not to mention the fact that many Ubuntu packages are crash prone and unusable. Just trying using packages from universe/multiverse on an AMD64. I believe the rule with Ubuntu is: "If it compiles, include it, even if it segfaults on startup." It really shows, too...

Re:Why compete?

[Punch-Drunk Slob]

FWIW, I compared memory consumptions after logging in (no apps run except terminal) between the latest Debian and Ubuntu:

Debian 4.0rc0 [non-expert GUI install] = 118760k used
Ubuntu 7.04 beta [alternate install] = 221752k used

So, which version of Ubuntu is this?

[FMota91]

*looks around innocently*

Re:So, which version of Ubuntu is this?

[Anonymous Coward]

Farty Frog :-)

Re:So, which version of Ubuntu is this?

[alienmole]

It's Ubuntu's dad.

Re:So, which version of Ubuntu is this?

[Anonymous Coward]

This could be seen as a perfectly valid question, considering how Debian Sarge and Ubuntu Hoary achieved a good level of binary compatibility.
So, to recast this, will some/all Etch binaries run on Ubuntu Dapper (last long-term release), Edgy (current stable release) or Feisty (in beta, to be released Real Soon Now)? Or vice versa?
Debian's long release cycle has at least the advantage that packagers have a stable platform to aim for, which means that several closed-source packages (e.g. Gizmo, a VOIP app) offer debian packages.

Next testing is "Lenny"

[cyber_rigger]

Debian's next testing version will be code named "Lenny" (from the movie Toy Story).

http://times.debian.net/1034-Release-update:-Etch+ 1-=-Lenny,-Call-for-Testing,-Time-shift

Re:Next testing is "Lenny"

[MsGeek]

My question: when are they going to call a Debian release "Wheeze" after the penguin toy? Oh. Wait. I know.

Re:Next testing is "Lenny"

[marcello_dl]

So, in my usual way to celebrate a debian release let me say:

when will Lenny be out?

Re:Next testing is "Lenny"

[Alphager]

According to the release-announcement in less than two years, but they will first evaluate all the feedback they get for the etch-cycle before making real plans.

Re:Next testing is "Lenny"

[marcello_dl]

I expected a "when it's ready". You apostate! :)

Should I upgrade my new server?

[ZakuSage]

I just put it together and installed Sarge yesterday, and I'd rather keep things running stable on it after all that work. Does Etch have any showstopping bugs that would stop a 'apt-get dist-upgrade'? Will it fuck up my apache, proftpd, sshd, or smb servers? Anything I should really know before letting some 600 or so packages change?

Re:Should I upgrade my new server?

[fo0bar]

Does Etch have any showstopping bugs that would stop a 'apt-get dist-upgrade'? Will it fuck up my apache, proftpd, sshd, or smb servers? Anything I should really know before letting some 600 or so packages change?

Yes, read the release notes for the answers to those questions. (and much much more! act today!)

Re:Should I upgrade my new server?

[MrDomino]

There's currently a dodgy bug where udev assigns devices different names than the install system, sometimes causing the system to not boot. It's easily fixable by editing your fstab, but can recur; you might want to hold off on upgrading if you're using strange drivers for your disks.

Re:Should I upgrade my new server?

[**loki969**]

Just keep in mind what cymen mentioned in his/her post above:

If you have no test system and the machine is providing service to users then do not upgrade to .0 releases. It's simple common sense.

Missing package

[Bob54321]

Doesn't even include firefox...

Re:Missing package

[toufeeq]

it's called iceweasel in debian.

Re:Missing package

[hondamankev]

These guys are going to analtate themselves into oblivion. I know this is flamebait, but who takes a distro seriously with such jems such as;

1: "...the Debian Security Team may come to a point where supporting Mozilla products is no longer feasible and announce the end of security support for Mozilla products."

2: "register_globals ... is now finally deprecated on Debian systems"

lol?

It takes a skilled, yet very short bussed person to have any thing to do with such garbage.

Re:Missing package

[Daengbo]

Debian should stop supporting Firefox if the two parties can't agree on the licensing. Just make Epiphany the default Gnome browser. I don't see the problem.

Re:Missing package

[Jussi K. Kojootti]

1: "...the Debian Security Team may come to a point where supporting Mozilla products is no longer feasible and announce the end of security support for Mozilla products."

You do know that Mozilla does not support old releases (this includes security fixes)? Debian has two choices: backport security fixes themselves or stop support (for that version) entirely.

2: "register_globals ... is now finally deprecated on Debian systems"

What the hell is so funny in these quotes? I don't get it...

Re:Missing package

[JohnnyBigodes]

If register_globals refers to the PHP configuration directive, then yes, I'm pretty much glad that it's deprecated (and I hate Debian myself).

For years now it's been practially deprecated in PHP code and it's already disabled in many other default installations, it's only good (and regular procedure) that Debian followed suit.

Re:Missing package

[wouterke]

Just for clarity: Debian hasn't enabled register_globals in its default configuration since ages, either. The comment you refer to relates to security updates for PHP. Basically, it says "if you use register_globals anyway, you're on your own; we don't support that"

Re:Missing package

[LordLucless]

I'm assuming the "register_globals" referred to is an old default setting for PHP, long known to be a major security hole. Turning it (along with magic quotes) off is one of the first things I do when setting up PHP on a new system. It's a bit two-faced for them claiming that they may not support Mozilla due to security concerns, while simultaneously saying that they're only just changing a default behaviour nefarious for security flaws.

Re:Missing package

[Anonymous Coward]

Debian's had it turned off. The security team will no longer backport patches that fix holes opened by turning it back on.

Re:Missing package

[cortana]

It already is the default, and I believe it has been since before the issue of the use of Mozilla corp's trademarks was raised.

Re:Missing package

[cortana]

Perhaps you should actually read the release notes, which the original poster abridged for the purposes of trolling.

For many years, turning on the register_globals settings in PHP has been known to be insecure and dangerous, and this option has defaulted to off for some time now. This configuration is now finally deprecated on Debian systems as too dangerous. The same applies to flaws in safe_mode and open_basedir, which have also been unmaintained for some time.

Starting with this release, the Debian security team does not provide security support for a number of PHP configurations which are known to be insecure. Most importantly, issues resulting from register_globals being turned on will no longer be addressed.

If you run legacy applications that require register_globals, enable it for the respective paths only, e.g. through the Apache configuration file. More information is available in the README.Debian.security file in the PHP documentation directory (/usr/share/doc/php4, /usr/share/doc/php5).

It has been off since at least the release of sarge. They are merely stating that there will be no security updates released for security bugs in PHP applications that are only exposed when register_globals is set on (which, again, has not been the default configuration for years)!

Re:Missing package

[fimbulvetr]

The problem is the fact that a "ctrl-t" in Epiphany doesn't give you the focus on the address bar. I swear the devs set it up that way so they could see how many people would throw chairs. This is by far the most annoying UI issue I've _ever_ run across, and I used to use GAIM!

Why would someone open a new tab and NOT go somewhere with that new tab? It's this kind of stupid shit that will eventually drive me away from gnome.

Re:Missing package

[cortana]

Because opening a new tab takes you to you home page, which takes the focus. Apparantly most normal, nontechnical users expect this.

If you don't like it, you have four options:

  1. Press Ctrl+Enter after typing your address; this causes the address to be opened in a new tab
  2. Set your home page to about:blank; creating a new tab then has the focus go to the address entry
  3. Patch the source code
  4. Use Firefox!

Re:Missing package

[Daengbo]

1.5 Ctrl+t then Ctrl+l to give focus.

Re:Great! But . . .

[Anonymous Coward]

Mod Dumbass.

Might take some searching:

[Kadin2048]

Just to follow up, by "non free repository," you'll need something outside the normal Debian repo system -- probably Penguin Liberation Front, certainly nothing U.S.-based -- in order to get that software. (Although I think the Debian/Ubuntu PLF mirrors are down at the moment.)

In addition to Flash (patent issues) and the Win32 codecs (patents), you'll also need libdvdcss2 (DMCA) if you want to play DVDs, and you might as well get LAME if it's not in there by default (god knows -- probably patents).

Putting
deb http://www.debian-multimedia.org/ stable main
into your sources.list ought to work, but I'm not sure how actively that repo is maintained (it still lists sarge as the stable tree). The VideoLAN people likewise just have instructions for Sarge but hopefully that'll change soon.

Re:Might take some searching:

[Novus]

I am not a lawyer, but I have read the applicable law reasonably carefully, and I'm familiar with the cases mentioned here.

Redistributing the Flash player is less a patent problem than side effects of a restrictive licence. For example, openSUSE goes out of its way to install browsers compatible with its bundled Flash player; Novell apparently has a deal with Adobe to allow redistribution of acroread and flash-player. Debian seems to circumvent this problem by having the package installer download Flash straight from Adobe. Nice and legal either way (assuming Adobe isn't violating a patent somewhere or something like that, which I doubt).

libdvdcss2 is trickier. Using Finland as an example of an EU country (applicable law), the situation seems to be that you are allowed to circumvent CSS to watch a movie, but I'm not lawyer enough to tell whether CSS qualifies for legal protection (that depends on whether it's an effective copy protection mechanism, I think) and whether the law requiring the copyright holder/distributor to provide a circumvention device, if necessary, is applicable. You'd also be very hard pushed to argue substantial non-circumventing use, making redistribution quite risky. In conclusion, I think libdvdcss2 users in Finland are safe, but redistributors may have a harder time. Other EU countries should be similar, as most of this legislation originates with the EU.

The win32 binary codecs are, in part at least, straightforward copyright infringment (unlicensed derivative works), but haven't been subject to any legal action I've heard of. Some of the codecs developed from scratch (e.g. some MPEG variants) seem to need patent licences in some areas; this is the primary cause of problems with MP3 (openSUSE circumvents this by using Real's Helix engine for MP3 decoding, which is licensed).

In conclusion, the situation is a mess and if you want to be safe, stick to what the major corps tell you is OK. If it isn't, they take the heat.

Re:Might take some searching:

[Knuckles]

Although I think the Debian/Ubuntu PLF mirrors are down at the moment

This may help: http://medibuntu.sos-sts.com/

What's next?

[Deanodriver]

What's next, Duke Nukem Forever? Damn, I can't make the Vista jokes anymore... :(

new debian still outdated

[timmarhy]

i used debian on a few projects... projects where any kind of features, performance or even remotely up to date software is not required. the reason debian is falling apart is the politics and fucking attitude people get when entering the project. if you ask why a port is 3 years out of date, instead of getting a mature response like " no one there to maintain it" or " it breaks compatability with feature X we are working on it"... you get little smartarse comments about how your welcome to update it yourself. frankly after my experiences with debian, that project can fuck off and die, and i'll dance a happy little jig over it's grave.

Is it 1997 or 2007 ?

[Muki]

As I was recovering from a spring flu, I was bored enough and decided to upgrade from sarge to etch on my trusty old 600Mhz 256MB Compaq Deskpro. For the most part it went smooth and nice, but what amazes me is why the X stuff is still somewhat awkward. Hardware is certainly not bleeding edge. Maybe I'm just without a clue after a decade of professional multiplatform unix administration, but it sure beats me why X stuff still needs to be this clumsy - we're in year 2007, aren't we - ? Recently I installed two Dell 2900's at work and with Fedora FC6 it was surely as smooth as ever could be. Now someone jumps in and tells that 'Debian is not intended to be easy'. OK, but how is this intended to boost anyone's productivity to battle with stuff that was perhaps ok back in the early 90's ? Debian is such a stable (pun intended) and rock-solid platform to run servers on, I sure like it, but I'd like to see some minor refinements in getting wheels to roll. Used to run sarge at work, used to set up sarge systems for friends small businesses and home use, but have since then moved on to Fedora due to these unnecessary issues. Beat the living daylight out of me but I just don't feel like attacking the xorg.conf or XF....conf with vi anymore "cool" these days. Especially on very common hardware. Other than that, thanks for the debian folks for the release !

Re:Is it 1997 or 2007 ?

[wellingj]

I have generally stuck to Ubuntu on the laptop for ease of use,
but Debian has really gained some polish in this latest stable version so I'm running it on my Desktop.
So far I have no complaints. Etch did a lot better job configuring X than Sarge did when I installed it
on my circa 2002 IBM NetVista (odd name now...) with a 1.7 Celeron, which only has 256mb ram. Gnome
worked fine on startup, but I quickly installed Xfce (Fluxbox had some kind of problem but I didn't look
to hard into it) and now it's every bit as snappy as my computer at work (HP laptop, Win XP, 1G ram, Core Duo 1.8)

go figure.....

Re:Is it 1997 or 2007 ?

[Anonymous Coward]

Sorry, what awkwardness are you referring to? None of my sarge systems have required any adjustments to the X configuration when upgrading to etch, which is what you seem to suggest happened to you. And setting up X on a new etch system is certainly more refined than sarge was, thanks in part to the switch to Xorg 7.1. A specific bug report about the problems you encountered, with video hardware details, would surely do much more to help us get it right for the next time than posting a complaint in a slashdot comment.

Re:Is it 1997 or 2007 ?

[Muki]

I agree - you have a point there - dunno how I missed the obvious - should've taken a detailed log on the events and put some feedback as in a bug report back to debian.org. I guess I still had some fever...or maybe it was a spontaneous act on my behalf ? The Xorg is a very welcome feature indeed. Will you allow me to test this sarge -> etch on another machine and keep a log on what I do and what happens ? This way I could come up with a usable bug report, should the problem come up again. I'd like to see a fresh etch install and another case upgrading from existing sarge to etch. When it comes to bug reporting, apparently I didn't have a clue ;)

Re:Is it 1997 or 2007 ?

[Jussi K. Kojootti]

For the most part it went smooth and nice, but what amazes me is why the X stuff is still somewhat awkward. Hardware is certainly not bleeding edge

apt is pretty magical, but expecting a dist-upgrade to upgrade your hardware is a bit much.

Re:Is it 1997 or 2007 ?

[Anonymous Coward]

It won't teach you language comprehension either.

He means his hardware isn't bleeding edge.

Re:Is it 1997 or 2007 ?

[Qzukk]

Hm, part of the problem with X in linux is that X has surpassed pretty much all of the various distributions' pretty little configurator tools. You can now run Xorg -configure, follow the instructions, and have a perfectly working configuration that autodetected your card and your monitor's capabilities in most cases (and it'll tell you what to do if it failed). What's needed now is for the distributions to rewrite their pretty little configurator tools to use this rather than having the user wade through dialog after dialog of card models (mine isn't listed!) and refresh rates (horizontal-whatzit?) and color depths (huh?).

I was hoping for the Xorg version in experimental to make it into testing before the release, but such is life (that version's autoconfig uses /dev/input/mice as the default mouse instead of asking you to set the mouse up yourself. The new intel video driver also works great and isn't braindamaged like the i810 driver that used its own internal configuration and ignored settings in xorg.conf)

Re:Is it 1997 or 2007 ?

[krmt]

We know it's a pain, and it's a major goal for the next release. The Debian X Strike Force burned the entire release cycle moving first from XFree86 to Xorg, and then from the monolithic Xorg to modular Xorg. By the time it all that was finished, about a year and a half had passed and there was a few months to polish things up for the release. During this time, essentially an entirely new team was built up (only one person from the team that worked on XFree86 in Sarge is still an active member) and there was huge changes as the entire codebase was repackaged for 7.0 and we moved from a private SVN repo to git.debian.org, which was no small feat while we did our best to keep the updates coming at a good pace.

So expect to see some improvements to this stuff in the next year or so. A lot of work is happening at X.org to improve autoconfiguration, and Debian is moving to help develop it and deliver it to the users. Lenny is going to be really exciting from this point of view.

Re:Is it 1997 or 2007 ?

[cortana]

FYI, the release notes have some tips about how you can use the 'script' program to automatically capture a log of the entire upgrade process, which makes it much easier to create good bug reports. Sure beats writing down steps taken by hand, and making mistakes or ommitting stuff due to human nature. :)

Re:Is it 1997 or 2007 ?

[krmt]

The stuff in experimental is really not polished yet. It hasn't been released upstream for a reason, after all, and the Debian packaging isn't really adapted to it yet. More importantly for Debian, no other driver besides the new intel supports randr 1.2 right now, so we'd have to special case a lot of things for that driver, which isn't really worthwhile right now. The Lenny cycle will be largely devoted to adapting to the new stuff going on at X.org including randr 1.2 and input hotplugging, but what's in experimental right now is just the first glimpses of what's in store.

Re:Is it 1997 or 2007 ?

[drinkypoo]

Why doesn't the installer just capture a log, so you don't have to re-run the installer just to make a bug report? I'm not big on bug reports, because filing them is usually a huge annoyance. I have filed many issues against drupal modules, mostly because they are easy to file... And Ubuntu has a crash reporting tool, so all I have to do is check a couple boxes and I'm in, so I do make Ubuntu bug reports.

Re:Is it 1997 or 2007 ?

[cortana]

Well, debian-installer itself does create log files, and they are attached to any bug reports filed against the 'installation-reports' package.

But this is an entirely separate process from upgrading. As far as apt is concerned, going from sarge -> etch is no different than upgrading a single package. It would be interesting to have apt automatically log all user interaction for every invocation with typescript, however...

I agree that filing a bug report can be annoying, but Debian at least makes it as easy as running reportbug, or sending an email to submit@bugs.debian.org. It has the best bug reporting process that I have seen--far easier than _any_ system that makes you sign up for an account (bugzilla). Of course, things could be worse! I wanted to file a bug report against Apple's OS X Mail program today (it's 2007 and this piece of crap doesn't use the IMAP NAMESPACE command yet...). I had to sign up for an Apple ID, and then apply for a WDC membership (which required me to agree to a 5000 word EULA). Finally I logged into the bug tracker, only to be greeted by 500 error caused by a null pointer exception.

Re:Is it 1997 or 2007 ?

[suggsjc]

Haha, but I wonder how many people/corps you could sell with that line...
Upgrading hardware just got easier. Its as simple as issuing a few commands

apt-get update memory processor

Too bad we just missed April Fools. Maybe I can use that one for Larry in 2014.

Re:Is it 1997 or 2007 ?

[myrdos2]

You shouldn't normally need to edit xorg.conf manually. Just run 'dpkg-reconfigure xserver-xorg' to get an ugly ASCII gui that will edit it for you. It would be nice if this was a bit better documented, I often see people who feel xorg.conf needs to be edited by hand.

Re:Is it 1997 or 2007 ?

[Matt Perry]

...Debian X Strike Force...

That would be a great name for an open-source counterstrike clone. You could even pick if you want to play for Team Emacs or Team Vim.

dammit!

[Anonymous Coward]

I just finished downloading 3.1r6 (7 disks) on my 9600 baud modem yesterday. Please, Debian, stop releasing new versions so quickly.

Re:dammit!

[alienmole]

Try having the CDs mailed to you -- you'll get higher bandwidth that way. 'Course, the ping times suck.

Upgrade

[Craig Ringer]

The upgrade seems smooth enough, though it's rougher than woody -> sarge was for me. Then again, I'm running much more complex systems now.

- squid may break if you use it for transparent proxying. It wants the "transparent" option after the listern directive(s) now to enable transproxying, but never used to.

- the xlibs upgrade does not go well if it can't remove everything in certain directories. In particular, having the jedit package installed screws this up badly. I had to do some manual fixing to get this working.

- Make really, really sure you have enough room in /var/backups when you upgrade slapd, or it'll require some hand fixing and a db4.2_recover.

- You'll probably want to use the maintainer's CUPS config, then re-configure it to your specs. The CUPS config has changed a lot and is not really compatible.

- cyrus delivery socket permissions may need resetting if you use cyrus & postfix.

Overall, though, for a system as complex as my servers, the process was largely fuss free.

Re:Upgrade

[javifs]

It would help other Debian users if you either submitted a bug report to the upgrade-reports package describing your expirience and the problems you encountered, or, even better, a bug to the release-notes package to document these issues. Some of them might even be fixed for the next point release, and the bugs will be forwarded to the package maintainers so that etch's packages are fixed. Contributing these issues back to developers is really simple, just read http://www.debian.org/releases/stable/reportingbug s

Re:Upgrade

[dlgeek]

- cyrus delivery socket permissions may need resetting if you use cyrus & postfix.

Did you use dpkg-statoverride like it says in /usr/share/doc/cyrus-doc-2.2/README.postfix.gz? This will preserve the permissions.

Benjamin (Debian Cyrus Team)

The *only* serious distro

[alienmole]

I'll see your flamebait and raise you...

Who takes a distro seriously

Oh please, does anyone other than script kiddies take any distro *other* than Debian seriously?
Let's see:

• There's Gentoo for the script kiddie/ricer set
  
• RedHat for the clueless corporate types who're lost if they can't use a purchase order to obtain it
  
• Fedora for the lost souls who haven't yet figured out that it's never going to recover from RedHat's abandonment
  
• Suse is a German distro owned by Novell -- see RedHat
  
• Ubuntu is an ancient African word, meaning "I can't configure Debian" (as someone's sig once said)
  
• Lots of other small distros with funny names that won't be around in two years time
  

OK, Slackware is great for hobbyists, I'll give you that.

So anwyay, which are the distros we're supposed to be taking seriously? Besides Debian?

Re:The *only* serious distro

[Anonymous Coward]

You forgot Mandrake

Re:The *only* serious distro

[regexes]

lol.. Thank you for this post. :-)

Re:The *only* serious distro

[alienmole]

Mandrake... let me see... ... nope, no such distro. I see one called "Mandriva"... ;-)

Re:The *only* serious distro

[Zantetsuken]

Even then, IIRC, Mandriva is based on Debian, is it not?

Re:The *only* serious distro

[alienmole]

It would really bolster my argument if I could say yes, but Mandriva was based on Red Hat and KDE originally.

Re:The *only* serious distro

[Anonymous Coward]

Ubuntu is an ancient African word, meaning "I'm getting too old for this shit!"

Lost in translation.

New?

[VincenzoRomano]

From the announcement page:

K Desktop Environment 3.5.5a
GNOME desktop environment 2.14
OpenOffice.org 2.0.4a
GIMP 2.2.13
PostgreSQL 8.1.8

After 21 months of continuus development is seems they left something behind!

Instant Success!

[crhylove]

They could instantly surpass Ubuntu by pretty much adding all the stuff Ubuntu does (it's all FOSS anyway, right?), but making these small changes:

1. Give users an option to use commercial drivers right off. The new Ubuntu is doing this, but the implementation is still a little rough around the edges, and it's not at all clear that commercial drivers are frequently better than the FOSS ones, which is certainly true for GPU issues.

2. Default to Iceweasel and Icebird. Debian does this already, so they are a leg up. True FOSS is true FOSS, right? And for some dumb reason Ubuntu still defaults to Evolution.

3. Make it even easier to turn on compiz/beryl. Still pretty hard even in feisty, requires xorg.conf editing and such... Lame.

4. Make the default menu look more like windows. You know: "Start" menu, Quicklaunch, App running display (with preview), System Tray, Clock/Calender. Eliminate the top bar that gnome defaults to.

5. Have four potentially different wall papers for each desktop. The first distro to do this is ahead of the Linux Pack.

6. Include some really good foss games. You know, games with 3d sound and video, and online multiplayer. Urban Terror is free (as in beer). Use that one, till a better full FOSS alternative comes along. Hell ioquake3 with the original quake 3 demo files would be better than what most distros ship with.

7. Have Iceweasel, Icebird, Pidjin, Tomboy Notes, and Open Office Writer automatically in the quick launch.

8. Make it REALLY EASY to get EVERY CODEC.

9. Install Wine, and while you're at it, fix wine so that you can easily create a launcher on the desktop to any windows app, running under wine, that runs like intended right off the bat.

10. Have a gorgeous theme by default. For some reason the Ubuntu crowd is obsessed with shit brown. This is the part that is easiest to beat Ubuntu on.

Do this, and Debian will be THE distro for everyone, and easily supplant Ubuntu, Windows, and Mac OS X.

Do it not, and remain the odd arcane distro that only a few back room IT nerds use while half assed FOSS OSes (that duplicate each other's efforts, and rarely work that well out of the box) continually lag behind the corporate behemoths that have already got themselves pre installed on 90% of sold computers as it is (Windows/Mac).

I mean, or just stay private and personal, and to hell with saving the world, which seems like the current Linux mantra.

rhY

Re:Instant Success!

[cortana]

[Debian] could instantly surpass Ubuntu by pretty much adding all the stuff Ubuntu does (it's all FOSS anyway, right?),

It is not. Many of Ubuntu's changes involve installing non-free software by default. Debian will never do this. You may feel that this will consign the distribution to obscurity until the end of time; go right ahead, it won't change anything, because Debian is about freedom (and technical superiority) and not market share.

but making these small changes:

1. Give users an option to use commercial drivers right off. The new Ubuntu is doing this, but the implementation is still a little rough around the edges, and it's not at all clear that commercial drivers are frequently better than the FOSS ones, which is certainly true for GPU issues.

What is a commercial driver? There are plenty of commercial drivers that are already in Debian main. It is only non-free drivers that are relegated to the, um, non-free section; they will never be installed by default, because to do so would be to go against everything that the Debian project stands for.

2. Default to Iceweasel and Icebird. Debian does this already, so they are a leg up. True FOSS is true FOSS, right? And for some dumb reason Ubuntu still defaults to Evolution.

In fact the default apps are Epiphany/Evolution if you use GNOME and Konqueror/Kmail if you use KDE. As it should be--these apps are designed to work as a part of their respective desktop environments, rather than in spite of them, like Firefox/Thunderbird.

3. Make it even easier to turn on compiz/beryl. Still pretty hard even in feisty, requires xorg.conf editing and such... Lame.

As for the software, compiz is packaged for Debian, like any other piece of software. Beryl is not because of the upstream developers' rather... cavaliere attitude towards licensing an copyright. It's a sucky situation, but without a radical overhaul of the US legal system this is not going to change. More details at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3 88701.

As for editing xorg.conf... once composite is readt to be enabled by default, it will be enabled by default and every distribution will be able to use it by default. This will be up to the xorg developers themselves, since it is they who are in the best position to make this decision. Until then, Debian should not make invasive changes such as enabling optional and experimental features of core system software such as xorg.

4. Make the default menu look more like windows. You know: "Start" menu, Quicklaunch, App running display (with preview), System Tray, Clock/Calender. Eliminate the top bar that gnome defaults to.

Maybe they should just install XPDE by default? Or just give up and tell people to install Windows in the first place?

This annoys me a great deal actually. Every distro apart from Debian seems to think that it is necessary to change the default layout of their desktop environments so much that they become unrecognisable to inexperienced users. This makes it impossible to write distribution-neutral instructions on how to do anything in GNOME, KDE, etc. Grr!

6. Include some really good foss games. You know, games with 3d sound and video, and online multiplayer. Urban Terror is free (as in beer). Use that one, till a better full FOSS alternative comes along. Hell ioquake3 with the original quake 3 demo files would be better than what most distros ship with.

The games you mention are non-free. As I said above, if you want them installed by default then you are using the wrong distro. Try Ubuntu instead.

8. Make it REALLY EASY to get EVERY CODEC.

It is already very easy to obtain every codec that Debian is able to distribute. They are probably even ins

Re:Instant Success!

[petrus4]

It is not. Many of Ubuntu's changes involve installing non-free software by default. Debian will never do this. You may feel that this will consign the distribution to obscurity until the end of time; go right ahead, it won't change anything, because Debian is about freedom (and technical superiority) and not market share.

For those of us who find the Debian attitude annoying, it's actually a good thing that you're so uncompromising...we can hope that that, combined with the terrible release schedule will eventually render the distribution entirely extinct.

Maybe they should just install XPDE by default? Or just give up and tell people to install Windows in the first place?

...

The games you mention are non-free. As I said above, if you want them installed by default then you are using the wrong distro. Try Ubuntu instead.

Yep, great idea. Encourage people to move to Windows, Ubuntu, anything but Debian itself...Let's hasten the inevitable as much as we can...that way, we'll no longer have to listen to the smug superiority and brain dead insistence on holding to a failed philosophy. I'm looking forward to it.

Re:Instant Success!

[fimbulvetr]

I'm glad to see all of this constructive criticism you offer. Indeed, it's also a sight for sore eyes that you've masterfully created a distribution above and beyond the stability and predictability that debian provides. Not only that, but you've kept it free and you promise to keep it free. If only other groups could so finely establish their principles and stick by them.

Oh wait! You haven't done any of this. Instead, you just bitch about something you're jealous of. You hate the fact that an OS can promise "free" and always deliver. You can't stand that stable really does mean stable. Apt-get? It bothers the shit out of you that a package manager just works. People that contribute to debian? You can't imagine that people would contribute back to a community.

It's cool to hate.

Re:Instant Success!

[crhylove]

Well I appreciate your vehemence and passion, but I have to wonder: Don't you want Debian to succeed? I think as long as the core operating system is completely FOSS, and you lean towards FOSS when FOSS is available, you could still completely dominate the market NOW by adding a couple of things here and there that JUST WORK and are NICE:

Beryl
Games
Commercial Drivers
Wine
VOIP
Joost or a clone.

Now, I'm not completely delusional, and know that this is a potential trojan horse for the whole OS, but by just going ahead, and then systematically eliminating them as FOSS alternatives crop up (which they continually will), you could get the market dominance an OS needs to FORCE the hand of the corporations who are largely holding you back now with commercial drivers, etc.

It's silly to think you can win without getting your hands dirty. I say fight dirty now, and once you are installed on >50% of the new computers sold BECAUSE PEOPLE DEMAND YOUR SUPERIOR PRODUCT, you can work back towards the goals initially established.

I agree with you though, that maybe Debian isn't the place for this, and maybe a fork like Ubuntu is. Sadly though, Ubuntu is almost as pig-headed as Debian on many of these issues, and defaults to a shit brown that nobody in their right mind can even tolerate to consider. *sigh* Maybe ReactOS will keep progressing and beat Linux and every other OS to the punch by GIVING THE PEOPLE WHAT THEY WANT. Maybe not though, it's FAR too soon to tell.

I just wish somebody in the Linux world actually had the balls to step up to MS/Mac/Nvidia/Intel/Sony/Creative and say, "FUCK YOU. OUR OS IS BETTER THAN YOURS, NOW OPEN YOUR SHIT UP, OR LOSE TO A COMPETITOR WHO WILL!"

This window of opportunity of Vista totally sucking and Beryl totally rocking will only be open for so long, if now isn't the time for some Linux distro to step up and kick ass, I don't know when that time will be.

Re:Instant Success!

[petrus4]

If you're wondering why I hate, your own particular screed here actually offers some good examples. I'll take it point by point.

Indeed, it's also a sight for sore eyes that you've masterfully created a distribution above and beyond the stability and predictability that debian provides.

There hasn't been much that's stable or predictable about the release schedule lately, has there? Not only that, although yes, internal patching is performed abundantly, one of the other primary ways that Debian provides "stability" is simply to continue to use packages that are years old. It is also the sickening tone of superiority present in the above that is one of the main reasons why Debian's developers have always managed to antagonise me. That isn't jealousy over actual achievements; it's resentment for an attitude which I not only consider alienating and unnecessary, but which, due to my own experiences with the distribution, I also feel is largely unjustified.

Not only that, but you've kept it free and you promise to keep it free.

Bragging about something which only Debian people themselves care about hardly counts, does it? ;) It's also no secret that the only reason why the people running Ubuntu have made noise about not including binary drivers etc is purely in order to keep some of the Debian developers themselves happy. The only real effect it has is to make life temporarily more difficult for end users...but once they find the codecs/drivers, they simply then begin using them and cease caring about that debate entirely.

Newsflash:- Caring in any way whatsoever about the FSF's definition of freedom is due purely to a combination of a) mind control induced emotionalism, and b) neurological disability. It isn't based on anything remotely close to legitimate reason, and thus, feeling superior because you yourself happen to fall into this category is likewise delusional.

If only other groups could so finely establish their principles and stick by them.

Yeah, that kind of BS beaurecracy is really something other distros need, isn't it? As I said earlier, it did wonders for Etch's release schedule. Of course, never mind that other distributions *do* exist that have social contracts/mission statements etc, and that they've generally done those distros about as much good as they've done Debian itself...which is to say, roughly zilch. Having a catalogue of idealism does absolutely nothing to reduce internal conflict or produce code faster, and if anything, the Etch debacle has also proven how grossly inefficient a system which tries to be democratic is when compared to a dictatorial model...because nothing ever gets concretely decided, one way or the other. You might not like what I'm saying, here...but it actually happened.

You can't imagine that people would contribute back to a community.

This is yet another example of exactly the kind of moronic insularity of opinion that I'm objecting to here. Do you honestly believe that Debian is the only distro in existence where reciprocal collaboration occurs? But of course...Debian is the only non-profit distro that exists, right? Forget Slackware. Forget Gentoo. Forget any of the BSDs. As one other similar moron commenting on this article said, they're not "serious" like Debian.

You're so chronically deluded that I actually have no idea why I'm bothering to try and respond to you at all...it's not like I believe that any of what I'm saying is actually going to get through. Also, not that you're going to believe this anywayz, but my overall point was that I don't hate Debian because it's cool...I hate it because I feel I have valid reason.

Re:Instant Success!

[cortana]

Newsflash:- Caring in any way whatsoever about the FSF's definition of freedom is due purely to a combination of a) mind control induced emotionalism, and b) neurological disability. It isn't based on anything remotely close to legitimate reason, and thus, feeling superior because you yourself happen to fall into this category is likewise delusional.

Demonstrably false. If ATI's drivers were free software then it would be possible to debug them when they go wrong. As it is, I run them, they crash my laptop, I and I'm stuck up shit creek without a paddle!

No, it's because a catastrophically bad system

[Anonymous Coward]

The reason is not that it has not been reported as a bug _To Debian_. It has been reported multiple times to others, perhaps to LKML?

The problem is that Debian doesn't more or less automatically read these bug reports. The mentality is that "if it's not reported to debian, it's not a bug". This eases the burden of being a package maintainer, but it certainly doesn't help Debian or the users.
What is needed, is cooperation of bug-reporting cross-distro, at least for bugs that are not distro-specific. Do we really need dozens of bug-reports for the same bug?

And to clarify: This is not Debian-specific.

Re:No, it's because a catastrophically bad system

[rbanffy]

A package maintainer should not be _overly_ concerned in fixing bugs in the original software.

Those are and should be dealt with upstream. If the package maintainer is also one of the original software maintainers, then he/she should be more concerned with those bug reports.

That said, it pays to know about the bugs in the software you package. While the package maintainer is not necessarily a maintainer of the original tree, he/she should be aware of the bugs he/she packages so workarounds (or patches) can be incorporated during packaging.

Re:No, it's because a catastrophically bad system

[ljaguar]

in this case, all they had to do is not enable equal cost multipath caching.

read the linux kernel mailing list. read what others are saying about this option. it's been in the kernel for 4+ years without any maintenance. it's broken and everyone knows it. the guys are like, "yeah it's broken and it's fucking up multipath. we'll get rid of it in 2.6.23 for sure"

there's no reason why debian kernel builders should have made the conscious decision to _enable_ equal cost multipath caching. it gains you absolutely nothing, and it actually fucks up the multipath that works fine when you have it off like you should.

again, this is something that debian conspicuously enabled that broke an already working functionality. and it that regard, debian made a mistake.

Re:No, it's because a catastrophically bad system

[dondelelcaro]

The problem is that Debian doesn't more or less automatically read these bug reports. The mentality is that "if it's not reported to debian, it's not a bug". This eases the burden of being a package maintainer, but it certainly doesn't help Debian or the users.

No, it's the case that if it's not reported to Debian, it's not a bug that we're aware of and can otherwise deal with. Before being so eager to point fingers at other volunteers, point the finger at yourself, ask and answer: "Why didn't I report this bug?" "What can I do to improve the situation?"

Ideally the package maintainers track upstream bugs closely and can do this, but for large packages it's well beyond the ability of volunteers to do easily; even Linus misses reported bugs, and he tracks the kernel full time. The Developers who do this work for Debian don't only work on the kernel.

What is needed, is cooperation of bug-reporting cross-distro, at least for bugs that are not distro-specific. Do we really need dozens of bug-reports for the same bug?

At least in Debian, we need the bugs reported there as well, because we have to know what versions of Debian packages are affected. We have various methods of connecting the Debian bug report to the upstream bug reports, but first someone must notice that the bug affects upstream and also affects the Debian package. Since no one noticed it, nothing happened.

Debian - still alive?

[diwadm]

With the advent of Ubuntu, does anyone have any reason to use Debian?

Re:Debian - still alive?

[Clazzy]

Ubuntu users do. Ubuntu completely relies on the Debian upstream packages for each release. Ubuntu them patches everything and submits the patches back to Debian. You could argue that Ubuntu could do all this by itself but Debian is massive and is known for its high packaging standards which is a good thing. Ubuntu and Debian, at the end of it, are two different things with two different goals. Debian wants stability, Ubuntu wants the latest technology and packages. Ultimately, Debian should still be important for servers and Ubuntu for the desktop. Just don't dismiss Debian yet.

Re:Debian - still alive?

[h2k1]

and if there were no debian unstable? maybe ubuntu could see their release cycles getting longer, and who knows, maybe passing the 21 months of the latest debian etch. seriously, does anyone need a cutting edge new software every six months? does it improve so much the productivity of your computer work? or maybe is just a symptom of the excellent release times of the latest versions of concurrent softwares and their stability? obviously, the linux users that are uncomfortable with the debian policy and philosophy are the ones that consume tons of bandwidth downloading and installing several distributions a day, knowing nothing more than the installation routines in a graphical environment. But hey, if you need a reason to use debian after ubuntu, just use unstable. congrats and thanks to the debian team for this forth release in a linux world that goes on the two-digit-release and, sho, please... please do not update the debian site, i just like to see it on links, it is sexier in a high level of geekness!!!

Re:Debian - still alive?

[Anonymous Coward]

Well, Ubuntu only looks at a very limited set of packages. Everything else is "universe" and only looked on by people calling themself "Masters of the universe". Would you thrust such people?

Ubuntu tries hard to do better of 90% of the use-cases. If you are the rest you are screwed.
(You get packages missing the binaries so never ever possible to work in a *release*, non-working stuff, and much more work to configure).

And while with one program being in the 90% might be easy, but with many tasks to be done, there are hight chances that you are the rest of the 10% somewhere, or even the last 1% that gets hit very hard.

Face it, we are all a minority, putting the majority over the minority hurts us all.

Re:Debian - still alive?

[Anomylous Howard]

I'll bite the flame bait and ask -- with Debian stable, does anyone have any reason to use the LTS Ubuntu Server installation?

Seriously, I'm using Ubuntu on one of our servers, but really don't see any advantage over Debian.

Re:Debian - still alive?

[swillden]

Ultimately, Debian should still be important for servers and Ubuntu for the desktop.

IMO, Debian also makes a fine desktop platform, particularly if you run testing or unstable (which is generally more up-to-date than Ubuntu). I prefer Debian over Ubuntu for my desktops.

Re:Debian - still alive?

[Clazzy]

Sorry, I should've been more clear. Ubuntu is a better desktop OS for new users. Many of the new features they've included I believe aren't in Debian (i.e. autoinstalling codecs, that Add/Remove thing they have, upstart and usplash) or at least aren't installed by default. You are right, though. Debian works just fine for the desktop too. I'd be using it myself but I spent ages getting Ubuntu to how I want it and I don't want to go through the whole thing again for what'll be only a small change.

Re:Debian - still alive?

[Brunellus]

Ubuntu users do, every day. Ubuntu is a Debian daughter, and its own success depends on the success of the Debian project.

My outsider's perspective on the Debian/Ubuntu relationship is this: Debian is a very large, very ambitious project. Its main goal is an entirely Free operating system; all other goals seem to be subordinate to that main goal. Ubuntu is interested in a reasonably up-to-date operating system for end-users, and focuses its development on a set of core packages for that purpose. Every six months, Ubuntu takes Debian, cleans it up for a new Ubuntu release, and then returns.

As far as I know, all the licenses are adhered to, and code is flowing upstream steadily (if not necessarily in the ways that upstream devs would prefer).

Debian is a gas giant: massive and stable in its orbit. Ubuntu is a comet: eccentric, periodic, and brilliant.

Re:Debian - still alive?

[Anonymous Coward]

I've been using Debian on servers for years, but I'm seriously considering a switch to Ubuntu Server LTS when the next one is released. One reason is that Ubuntu seems to be "officially supported" by more software than Debian (vmware for example).

I'm not sure that Debian is any more stable or more reliable than Ubuntu Server LTS because I haven't heard any specific examples from people who propagate that meme.

On the other hand, the time between LTS releases might even be longer than Debian releases, so we'll see.

Re:Debian - still alive?

[synthespian]

- Does anyone have a reason to use Debian?

- Ubuntu users do.

[Then yadda yadda yadda about how Ubuntu "depends" on Debian.]


Ubuntu users have a reason to use Debian....A mindbending proposition...

Re:Debian - still alive?

[Anonymous Coward]

Personally, I see only disadvantages to using Ubuntu on the server. With universe and multiverse officially unsupported, you have no idea if a package will work, or just segfault on startup. This is an especially big problem if you're running on a non-i386 platform, like AMD64 or Sparc.

Re:Debian - still alive?

[Respect_my_Authority]

Ubuntu is a Debian daughter, and its own success depends on the success of the Debian project.

Yup, Ubuntu-daughter leads a largely independent life of her own but she still comes home every once in a while to grab the food (new packages) that Debian-mother has made. Without these regular food supplies from mother, Ubuntu would be in a serious danger of starving. And Ubuntu also sends a lot of her clothes (bug reports) home for Debian-mother to wash and iron.

Many of Ubuntu's strengths are inherited directly from Debian. It's quite amazing that there currently doesn't seem to be any worthwhile competition to Ubuntu on the desktop arena. A Debian-based system with some desktop polish seems to be a hot item today. Some other desktop-oriented distros have features that Ubuntu lacks, but Ubuntu's Debian-inheritance is a great advantage that those other distros lack.

Debian's release cycle fits the needs of Linux servers but Debian has traditionally lacked a clear and consistent desktop strategy. Sometimes I think that it might actually be a good thing for Ubuntu if Debian started competing with Ubuntu by improving the desktop strategy in Debian. A friendly competition and exchange of new features and ideas between Ubuntu and Debian could potentially benefit both distros.

For this to happen, Debian would need additional releases that are targeted to desktop users, and it would also need additional artwork/themes and special developer teams that concentrate on desktop issues. Also the Debian website needs an overhaul and an official Debian user forum would also be nice.

These changes would need a lot of work but I don't think it would be totally impossible if there is enough interest among the developers to push Debian in this direction. Actually, the new Debian Project Leader Sam Hocevar has already suggested some of these things in his candidate platform and the fact that Sam was elected suggests that also other developers support these ideas.

Q: can I run it on my machine?

[Anonymous Coward]

I've been to the site, looked at it, but still can't seem to determine if it can run on my machine.

I've got a "gigabit ethernet" Macintosh G4 (m/n M7893LL/A, dual-processor, 500 mhz, 1 gig of ram) set up by my sister - here's the system: http://support.apple.com/specs/powermac/Power_Mac_ G4_Gigabit_Ethernet.html

I've downloaded ubuntu and ran it from the disc, and it seemed to run fairly well, but I'd like to try another 'flavor' (yes, I know I'll have to install it on my second drive, and that it doesn't run from the disc).

Any help? Please? Thanks. (I don't want to ask _her_ 'cause she's OSX-rabid but, fortunately, not a slashdotter - so I can ask here) :)

Re:Q: can I run it on my machine?

[Gleng]

Yeah, it should run fine on that machine. I've run Debian on a 120MHz Powermac 7200 and a 1.33GHz G4 Mac mini, and it was sweet on both.

Any PowerPC based computer should run Debian fine.

Re:Q: can I run it on my machine?

[Anonymous Coward]

Any PowerPC based computer should run Debian fine.

Uh. If it's a NuBus-based Mac, you might not have everything supported.

(I do own a NuBus-based PPC that does run Debian. It needs a custom kernel.)

Re:Q: can I run it on my machine?

[Gleng]

Cool, fair enough. I didn't know that!

Also, PowerPC based Amigas such as the AmigaOne require some fiddling, but I'm not lucky enough (or unlucky enough, depending on your views of the Articia S) to own one, so I can't say first hand.

Speaking of Amigalike systems, the Efika runs Debian too, but also requires a custom kernel.

How many CD's for minimal?

[capica]

Previous releases needed only first CD to install a working machine/desktop. Does that still apply? I won't be having broadband at home, only at work, so only security updates will be fetched.

Re:How many CD's for minimal?

[teab v1.0]

As far as I'm aware from looking briefly at the Debian website, I think so.

This time, however, you have a choice of 3 "first" CDs - the default one that includes GNOME, one that includes KDE, and one that includes XFCE. This should, in theory, mean that you get only the desktop stuff that you need. They are listed on the main iso-cd download page, which for i386 is http://cdimage.debian.org/debian-cd/4.0_r0/i386/is o-cd/

However I will say this - I have not installed a Debian desktop from CD only for a couple of years, and am unlikely to do so in the near future. So I could be wrong...

Re:How many CD's for minimal?

[jetxee]

Please mod parent up. That's useful information. And might be important in many cases.

Re:How many CD's for minimal?

[cortana]

Note that if you are performing an offline installation and want to install the full Desktop task, that you will need CD2 (since not all Desktop packages fit onto the first CD). Full details are in the release notes.

Re:How many CD's for minimal?

[teab v1.0]

Cheers for that - I hadn't looked that far into the website obviously.

I thought Debian was dead

[Cro Magnon]

So, I guess Easter is a good time for a resurrection. :)

Interesting, Funny, Flamebait, Troll

[alienmole]

The parent got one of each. I think that's a Slashdot straight flush, or something. Now all it needs is Insightful...

Why use this over ubuntu?

[august sun]

Not trying to be incendiary, but I've never used debian itself, only derivatives.

I was wondering if any fans could give me any reasons why to run this over say any of the ubuntu clan?

Or is it simply the case that debian + polish = ubuntu?

Again, I'm asking actually hoping that someone will pull a Torvalds and say something like "it doesn't presume its users are idiots", which would actually tweak my interest.

Re:Why use this over ubuntu?

[halovaa]

I have two friends, both of whom have recently switched to Linux for everything except a few games that can't be handled with Cedega. I didn't push them into it, they just grew frustrated with Windows and knew that there were alternatives. One installed Debian (AMD64 + ia32 chroot even!) and I elected to install Kubuntu (Edgy 32-bit) on the other's as I figured it would be more noob-friendly. The guy who uses Debian said "It starts off broken and you fix it, but then it stays fixed, while Windows starts off fixed but then breaks itself." He also liked that it would warn him about doing something stupid, but would trust him enough to let him do it anyway. He's now perfectly happy with it, rapidly flipping a Beryl/Compiz cube around to IM people while playing WoW. He uses Unstable, he runs beta software, he fiddles with things. Don't get me wrong, the Ubuntu friend definitely preferred it over his struggles with Windows. He told me, when he found himself booting into Windows to play WoW that he would ask himself "Why can't Windows be Linux?" The problems come because Ubuntu is just less flexible than Debian. First, it supports a much more limited set of packages officially than Debian. This requires adding the universe and multiverse repositories, because he didn't want only the most useful packages, he wanted to try anything that sounds interesting. Cedega wasn't working well with WoW and the three of us thought it might be because of the 8xxx series drivers being installed instead of the 9xxx series. Now the Debian versions of these were only available in Experimental, but with some help from me, the Debian guy was able to install them easily enough, and nothing broke. In Ubuntu however, only Feisty had the 9xxx series. From experience, I've learned that you can't just upgrade one or two packages to a newer version in Ubuntu like you can in Debian. Things like libc6 change versions from release to release, and the whole system has to be upgraded. I figured that Feisty should be near enough stable that upgrading to it wholesale should go pretty well. We even used the update manager provided with Ubuntu. Incompatible packages ended up installed, as versions were moved into and out of Feisty (I think), and right now his system is usable, but will require some extensive fixing by me to get apt working again. The lesson? Ubuntu is great if you do what they expect you to as a normal desktop user. If you want to do something less common, it's not as flexible as Debian and can get in your way.

Re:Why use this over ubuntu?

[Anonymous Coward]

Your own response is one reason (in my opinion), although there are three other key things that I note:

      1. Ubuntu uses dash as /bin/sh which means that some external apps/scripts will not work because they presume bash.

      2. Much more importantly, Ubuntu's "multiverse" is not supported by Ubuntu: but that multiverse is all of Debian's 22,000 apps which are directly supported by Debian devs.

      3. With module-assistant the non-free nvidia and and radeon drivers are a "m-a a-i" away.

And with the Marillat repository you have every proprietary codec available within Debian anyway.

I use unstable as my desktop and if you wish to do the same, then you *must* install apt-listbugs.

Hope this is what you want.

Re:Why use this over ubuntu?

[brufar]

Debian - Gives the user control to choose what they want to use, more packages more options..
Ubuntu - Makes most of the initial choices for the user..

Debian - manual configuration of a lot of items..
Ubuntu - a bit better at auto-configuration of hardware.

Debian - Etch 20,400+ Packages in the official repository
Ubuntu - Fiesty I think it's around 6000 Packages but can't find a stat anywhere to confirm exact munber.

Debian 13 hardware Architectures i386, x86-64, PowerPC, 68k, SPARC, DEC Alpha, ARM, MIPS, HPPA, S390, IA-64, AMD64, Intel EM64T
Ubuntu 3 Hardware Architectures i386, AMD64, PowerPC,

I've used child distros in the past an always ran into problems. I would then switch to the parent distros to get away from the problems.. So I use Debian rather than one of it's numerous children to prevent a repeat of my previous experiences. http://www.debian.org/misc/children-distros

Re:Why use this over ubuntu?

[Anonymous Coward]

I'm a longtime Debian user. I've installed Ubuntu a couple times, and it's pretty nice. Its installer is especially nice, compared to Debian's. Most other things look basically like Debian ... but brown.

But for day-to-day work, I stick with Debian.

Ubuntu just doesn't have all the latest packages that Debian-unstable does. It's more up-to-date than Debian-stable, sure, but if you want a package from (say) last week, it's going to be in Debian-unstable, and not Ubuntu. IOW, if you prefer Ubuntu over Debian-stable for recent releases, you'll like Debian-unstable even more!

I know you can enable "universe" in Ubuntu and just grab Debian packages, but if you're going to do that for enough things, why not just run straight Debian? So that's what I do.

If you can survive the Debian installer (which I really wish I didn't have to apologize for) it's a great system.

Re:Why use this over ubuntu?

[synthespian]

"Child-distros"...This term seeks to disqualify other distros and aims to affirm Debian's superiority.

How ridiculous...PR newspeak for Debian.

Fact: a large contingent has simply dropped Debian because of their inability to get their act together, and their propensity for "bikeshed arguments."

Re:Why use this over ubuntu?

[thewolfro]

Hi, To imagine what kind of things i like from a distro, i will tell you my "linux story": I have used RedHat for 2 years than i discovered the ease of using debian apt; I have used Debian for 2 years and then i discovered Gentoo after i was tired of compiling and optimizing my system (1 year and a half), i decided to give Debian another chance; guess what... it was almost as fast as a Gentoo system with all the optimizations i've tried. After another 2 years on testing/unstable, i decided to try Ubuntu/Kubuntu (now i have both of them on my system) i was surprised about the performance of Ubuntu (maybe i am a little silly but i have to say it: it seem to be faster than Debian) besides all that you do not have to configure anything it simply works from the start (at least for me it does). Ubuntu relays on Debian unstable packets so the packets are very new. On debian testing things work great but the packets are a little old (you also have to make some settings here and there to make your system look like a real desktop) On debian unstable, the packets are newer but the things broke some times (i do not recommend unstable unless you have a strong hard) Debian stable is great only on servers (this is rock stable) I am looking at Ubuntu as if it is the desktop version of Debian (I have great respect for debian; they have a lot of packages under development ... but let's get serious we are talking about a desktop here... who needs all that?? i do not need 2 or more packets doing the same thing; i am rather happy with a packet that works from the beginning without me doing any configuration). So, in my opinion, for desktop systems, the battle is between Debian testing and Ubuntu. Because of the newer packages i choose Ubuntu. I you like a complete Desktop solution you should try Ubuntu/Kubuntu also. George

Re:Great! But . . .

[dramenbejs]

I laughed loudly.

That's sad, really.

[Tyln Sylverwind]

I've witnessed attempts by various individuals to fundamentally alter the goals of Debian. Most common is trying to make Debian a more "desktop-oriented" distribution. Good attempts turn out as separate distributions. Honestly, that's how it should stay.

See, Debian not only welcomes child distributions, it thrives on them.

http://www.debian.org/misc/children-distros

At some point in time, I would encourage consideration of Debian's slogan, "The Universal Operating System".

Debian has been and always will be an operating system that equally (as in equity) targets all applications; that's why child distributions are necessary, and why Debian Unstable is so damned important. Child distributions are required to pull the Debian project in a productive direction. Debian Unstable is required to tie the required functionality of child distributions together and, in turn, propagate the benefits to all parties involved.

It doesn't make sense to take a piece of software to any sort of bleeding-edge when it will be deployed world-wide on Debian servers and Debian routers. Furthermore, the fact that a child-distribution is already working to "sex up the desktop" is evidence that Debian need not take initiative in such a direction; it's already involved.

Re:That's sad, really.

[Wesley Felter]

It looks like soon enough everyone will be using Debian's children and no one will be using Debian. At that point there will be no need to even have stable Debian releases at all.

Re:That's sad, really.

[Tyln Sylverwind]

Except for use by those who either want to develop a distribution, build software, or manually configure their distribution beyond what's worthwhile in most other distributions?

Sounds like more of the same to me. Anywhere that I see Ubuntu cropping up, Debian wasn't there to begin with.

I have witnessed Ubuntu replace most of the SuSE installations I was aware of. That's a big win for Debian on the desktop market.

And I've yet to see anybody try to use Ubuntu as a server. Really, I don't get what they're going for with that "server" branch. I guess they want to make it just like using Ubuntu... only not? Kinda sounds like Debian making a desktop fork to me.

Maybe I'm just weird. See, I'm not on the consumer end. I tend to witness a lot of cooperation when browsing around for software. Some of the most productive users of Debian seem to be the developers of other distributions. So long as Debian remains a valuable asset to them, I don't think it's going to vanish anytime soon.

awesome

[makoffee]

I wouldn't normally get so excited about a distro release, but this is Debian after all. I think I was just a twinkle in my father's eye when 3.0 was released. The other reason I'm so excited is that Debian 4.0 is the first linux distribution that seemed to recognize all my new hardware. YAY!

Re:awesome

[portnoy]

3.0 was released in mid-2002. May I say, you're remarkably articulate for a five-year-old. :-)

Who actually thought...

[Polly_Morf]

... Debian Etch would be release before Duke Nukem Forever?

debian is extremely redundant

[themusicgod1]

Debian has users that will continue to use it for a long, long time. I was just talking with someone who still uses potato on their email server. Potato! I know I'll probably end up using debian or some derivative of it until either I die or all the modern day computers die. Debian is simply not going to go away because you don't like it, or becase it doesn't do multimedia as well as ubuntu[1], games as well as windows[2], doesn't optimize as well as gentoo, or whathaveyou; it serves a purpose, and the fact that it's still got life shows that this purpose is an important one, that many people are striving for.

Wanting to be able to legally[4] *use* a computer, and wanting to be free to make changes to it, and to share your work is not simply an 'annoying' attitude; it's a necessary result of years of working with computers[3], seeing how one's actions and the similar actions of their peers impact the rest of the world.

Second; not all the things you can do with a computer involve multimedia. There's a lot of serious research, and work that needs the help of computers; For these applications you do not need win32 codecs, or resource-hogging compiz; you just need a working operating system. Debian is ideal for this situation, because you only have as much graphical overhead as you want, and either have the tools you need, or the open platform to develop them on.

[1] ubuntu is a debian fork anyway. the whole point about debian is that you can fork it, like ubuntu has, and be successful; and then the next guy can come along, and do the exact same thing. It's the baseline; the absolute minnimum. If you're distro of choice isn't as good as debian it's either optimized highly in one direction, or it's not a serious distro.

[2] Windows is dying! netcraft confirms!

[3] And years of doing difficult tasks, which inevidably require the use of a computer.

[4] Barring the country you live in becomming a third world dictatorship(more plausible than debian dying off), of course.

prob with debain driveres for nvidia

[tejaswin1988]

do we expect this version to include the drivers for nvidia onboard ethernet card which persting prob with debain

Re:prob with debain driveres for nvidia

[cortana]

You can find out with the Unofficial Debian HCL. Currently it indexes modules included in Etch's kernel, which is based on Linux 2.6.18.

Re:prob with debain driveres for nvidia

[tejaswin1988]

its pretty interesting solution

Freedom

[Anonymous Coward]

Freedom.

Yes!

[Anonymous Coward]

Because module loading goes wrong so often on my machine...

Use a dictionary

[cortana]

http://www.google.com/search?q=define:child

The word is clearly used in reference to offspring/progeny!

Etch works...

[ioshhdflwuegfh]

One of the cool features of Debian is that one can download loads of packages from the net (3 dvd's in this case, and already the first dvd alone is sufficient to get a pretty decent system) and install them on box w/o internet connection (which happens to be exactly what I need). The only other distro that I know of with the same capability is Fedora Core (ok, CentOS too but with less "edge"), so it seems that Debian was just enough faster with the release of Etch than Fedora with FC7 (even if the later will be edgier it is still probably a month of CPU time for me).

In any case, AMD64 Etch ended up on my new comp (Core 2 with one of the fancier nvidias) last night, and the installation (using installgui option, dual boot) was trivial, particularly comparing with the previous installation of Debian I did about a year ago, and just as easy if not easier compared with other distros I tried (Xubuntu 6.05, Gentoo 2006.1, FC6 and one Mandriva power pack, all 64bit). Almost all of things just work without any editing of any files, only installing of packages from dvds (in particular, movies do play; I didn't configure any nvidia specific stuff yet; desktops are all there working fine). Now I'll have to tweak few things but overall it is already usable (things compiled and running full speed).

One thing I miss is ntfs-3g. Sure, it's not stable yet but it did work for me (on another comp with FC6) and it seems that what is packaged is just not enough to get my ntfs partitions and external drives writable, but then I might just not know how to do it with what's in the distro.