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.'"
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 [google.com] 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 [debian-adm...ration.org] and documented [launchpad.net] 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.
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 st
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.
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.
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.
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.
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.)
by Anonymous Coward
on Monday April 09 2007, @04:09AM (#18660883)
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.
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.
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.
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.
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-ima
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.
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.
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.
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.
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/ [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.
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 [adobe.com]. 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 [finlex.fi]), 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.
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.
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"
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.
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.
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.
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.
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
[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 [debian.org].
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 [debian.org].
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
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?
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 [debian.org] for the answers to those questions. (and much much more! act today!)
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"
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 !
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.
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.
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.
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.
Yay! (Score:5, Funny)
Re:Yay! (Score:5, Funny)
*ducks*
Disclaimer: I am not responsible for any loss of employment or productivity by clicking on any link in this post.
Parent
And its not even the 1st... (Score:5, Funny)
Re:And its not even the 1st... (Score:5, Funny)
Parent
Re:And its not even the 1st... (Score:5, Informative)
Parent
Re:And its not even the 1st... (Score:5, Informative)
(that would have been fun, don't you think so
more important.
Parent
Multipath broken in debian etch! (Score:5, Informative)
Shoddy rushed release (Score:5, Funny)
Seriously though, this is a rather surprising bug to slip through.
Parent
Re: (Score:3, Interesting)
Re:Multipath broken in debian etch! (Score:5, Interesting)
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.
Parent
Re:Multipath broken in debian etch! (Score:5, Insightful)
Parent
Re:Multipath broken in debian etch! (Score:4, Informative)
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.
Parent
Re:Multipath broken in debian etch! (Score:4, Insightful)
Parent
Re:Multipath broken in debian etch! (Score:5, Insightful)
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.)
Parent
Re:Multipath broken in debian etch! (Score:5, Insightful)
Parent
Re: (Score:3, Insightful)
Re:Multipath broken in debian etch! (Score:4, Insightful)
If you're supporting a few hundred servers then any differences between the systems need to be kept to a minimum.
Parent
Re: (Score:3, Insightful)
Yeah. Except they always seem to end up disabling initrd for some unknown reason ("initrd is hard, man..."
> 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: (Score:3, Interesting)
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-ima
Re:Multipath broken in debian etch! (Score:5, Insightful)
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.
Parent
This release begs the question... (Score:3, Interesting)
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... (Score:5, Informative)
Parent
Re: (Score:3, Informative)
Might take some searching: (Score:4, Informative)
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/ [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.
Parent
Re:Might take some searching: (Score:5, Informative)
Redistributing the Flash player is less a patent problem than side effects of a restrictive licence [adobe.com]. 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 [finlex.fi]), 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.
Parent
Re:This release begs the question... (Score:5, Informative)
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.
Parent
Re:This release begs the question... (Score:4, Funny)
In particular, the English language is defined by common use, not by some hypothetical Academie Anglaise, and certainly not by Slashdotters.
Parent
Too late? (Score:3, Informative)
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 [debian.org]:
- 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 bitWhy compete? (Score:4, Insightful)
Parent
Re:Too late? (Score:4, Insightful)
Parent
Re:Too late? (Score:5, Insightful)
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.
Parent
Re: (Score:3, Informative)
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
Instant Success! (Score:3, Insightful)
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
Re:Instant Success! (Score:4, Insightful)
[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 [debian.org].
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 [debian.org].
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
Parent
Next testing is "Lenny" (Score:5, Informative)
Debian's next testing version will be code named "Lenny" (from the movie Toy Story).
http://times.debian.net/1034-Release-update:-Etch
Re: (Score:3, Funny)
when will Lenny be out?
Should I upgrade my new server? (Score:3, Interesting)
Re:Should I upgrade my new server? (Score:4, Informative)
Yes, read the release notes [debian.org] for the answers to those questions. (and much much more! act today!)
Parent
Missing package (Score:5, Funny)
The *only* serious distro (Score:5, Funny)
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?
Parent
Re: (Score:3, Informative)
Is it 1997 or 2007 ? (Score:5, Interesting)
Re:Is it 1997 or 2007 ? (Score:5, Funny)
Parent
Re:Is it 1997 or 2007 ? (Score:5, Interesting)
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.
Parent
Upgrade (Score:4, Informative)
- 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
- 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:So, which version of Ubuntu is this? (Score:5, Insightful)
Parent
Re:dammit! (Score:4, Funny)
Parent
Re:Debian - still alive? (Score:5, Insightful)
Parent
Re: (Score:3, Informative)
Any PowerPC based computer should run Debian fine.
Re: (Score:3, Insightful)
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