Debian 3.0r4 Released

SeaFox writes "The Debian group has released an update to the 'Woody' distribution of the popular Linux/GNU OS. From the site: 'This is the fourth update of Debian GNU/Linux 3.0 (codename woody) which mainly adds security updates to the stable release, along with a few corrections to serious problems. Those who frequently update from security.debian.org won't have to update many packages and most updates from security.debian.org are included in this update.' But the question on everyone's mind is probably when the current Testing branch, featuring much more up-to-date packages, will be named the new stable release."

Comments

testing?!

[didde]

But the question on everyone's mind is probably when the current Testing branch, featuring much more up-to-date packages, will be named the new stable release.

Oh, come on! When will the submitter realize that stableis what most of us want to run on our servers and mission-critical hardware. I for one cannot afford doing an apt-get upgrade and breaking three, two or even _one_ package. Even worse would be putting a serious bug in the software on a production machine. With stable this chance is minimal, but of course not non-existant.

One possible solution would be to divide Debian into a "server version" and one for the workstations who actually _want_ (or need) to run stuff from testing. Although this would mean double the work for the package maintainers (et al) I'm sure it would make Debian even more attractive as a desktop alternative. Today, I don't know a single n00b or even semi-n00b using it for her home PC or similar - it's all Windows, Xandros or possibly SuSE. On the other hand basically all of my friends who proudly call them selves sysadmins are running Debian (stable) on their production boxes...

Unless of course they need to run RH to get IBM to support WebSphere =)

Re:testing?!

[IonPanel]

A Debian Server variant would indeed be good - with perhaps a pre-configured installer that sets up the most comonly used packages on a server.

Of course, another open-source group could provide this alongside the Debian Project ;)

Re:testing?!

[Roland Piquepaille]

A Debian Server variant would indeed be good -

Well, no need for that. The 3 main distros (stable, testing and unstable) simply represent the "level of paranoia"/package staleness choice one can make, i.e. stable is old stable packages, testing is reasonable up to date packages with a few problems, and unstable is cutting edge and you're on your own with problems.

What one may with is an additional level between stable (which is truly quite stale) and testing

with perhaps a pre-configured installer that sets up the most comonly used packages on a server.

That's what tasks are for. What you really want (and what everybody wants) is an easy intuitive point-and-click thingy that'll finally replace dselect.

Re:testing?!

[adeydas]

One possible solution would be to divide Debian into a "server version" and one for the workstations who actually _want_ (or need) to run stuff from testing. Although this would mean double the work for the package maintainers (et al) I'm sure it would make Debian even more attractive as a desktop alternative.

That would be the best way to go but wouldn't that also restrict features and perhaps some secrity loop-holes in the long run?!

Re:testing?!

[Anonymous Coward]

Well here's a semi-n00b who uses sarge/win98 (for gaming) dualboot on his home PC. Sure Debian was a bit hard to get running but now that I've gotten it up I must say it's the distro I've most enjoyed. Besides, I've learned a lot using it.
Even though sarge is "testing" It's been really stable and also my choice for desktop use.

Re:testing?!

[cipherz]

To be honest I've used testing (codename: sarge) on production machines without problems at all. The versions of software in stable is useless at some machines. I mean who can seriously use a mysql 3.x to anything other than fill up space ?
Though of course I am running a smaller risk, but usually I just upgraded a smaller box first to see if anything was broken - didn't encounter one broken thing yet... it's unstable (codename: sid) that gives me the most if any problems of course I have never, and will never use sid on a production machine I am not -that- suicidal :)

that was my two-cents and lets hope this new year brings a stable sarge =)

Re:testing?!

[didde]

Mr. Balmer, is that you?

Re:testing?!

[d^2b]

What you really want (and what everybody wants) is an easy intuitive point-and-click thingy that'll finally replace dselect.

Synaptic?

Re:testing?!

[novakreo]

One possible solution would be to divide Debian into a "server version" and one for the workstations who actually _want_ (or need) to run stuff from testing.

Or you could, you know, actually run stable on your servers and testing on workstations. Debian will let you mix and match, it's called pinning, and if you're not willing to run testing or unstable, Debian Backports provides modern packages compiled for stable.
The system you're describing already exists, you just need to know how to use it.

Re:testing?!

[didde]

If you really need MySQL 4 that bad then why don't you use backports.org which will allow you to run stable and yet keep some newer packages on your box?

Re:testing?!

[tacocat]

One possible solution would be to divide Debian into a "server version" and one for the workstations who actually _want_ (or need) to run stuff from testing. Although this would mean double the work for the package maintainers (et al) I'm sure it would make Debian even more attractive as a desktop alternative. Today, I don't know a single n00b or even semi-n00b using it for her home PC or similar - it's all Windows, Xandros or possibly SuSE. On the other hand basically all of my friends who proudly call them selves sysadmins are running Debian (stable) on their production boxes...

Please don't...

Debian already has four levels of version: stable, testing, unstable, and the new expiremental. Adding any more levels or options to the process will only slow down the release of stable. I really don't think you want to wait for the next release of Debian Dorever 3D do you?

If you want a server version then stick to stable. If there's a package that you need that's newer then selectively import that from testing while keeping the rest of your system stable.

It's a cute sounding suggestion, are you the one who is actually going to have to live with it, or are you trying to sound intelligent? You forget you are dealing with a voluneer group. If you add a shitload of beaurocratic complexity to the process you will have to start paying them to put up with your stupid ideas.

I've worked will someone for over a year on using Linux and they have settled on SuSE. They don't like it, but they just don't want to learn anything more about it. They have to settle for a lot of things that they can't do or can't do right.

Adding more distribution levels to Debian will only make things more difficult to manage. Don't fuck with it unless you want to fix it yourself.

When are you going to realize that there will always be two types of users on computers? Sheep and Geeks. Sheep like to download virus and spyware and adware and if they can't have butterflies for their mouse pointer they shit themselves. And they don't care about anything else. Let the sheep use Windows and be stupid and pathetic and annoying and let the rest of us use Linux and have a clue and not have to deal with the sheep unless we need some money. Sheep pay a lot of money for stupid stuff. Don't fix it for them, or we might all be out of work.

Re:testing?!

[tacocat]

Why must the solution always require a X-window GUI? You've now required a huge amount of resources be deployed just to update/select packages for a DNS/printer server.

Aptitude/apt-get rocks the socks off anything I've seen and I would really hate to try and run some GUI over my internet SSH connection across the country just to execute my periodic 'apt-get update && apt-get dist-upgrade'

Re:testing?!

[Anonymous Coward]

Oh, come on! When will the submitter realize that stableis what most of us want to run on our servers and mission-critical hardware. I for one cannot afford doing an apt-get upgrade and breaking three, two or even _one_ package. Even worse would be putting a serious bug in the software on a production machine. With stable this chance is minimal, but of course not non-existant.

Unfortunately, the "stable" release of Debian has given me lots of headaches, because it is obsolete. People want new features, and the sysadmin has no option but to get them working -- and then you need to use backported packages.
And I don't think stable is too stable anyway. For example, it ships version 1 of the Cyrus mail suite, which has been declared obsolete by upstream developers -- AND that means it doesn't get security updates from upstream.

Re:testing?!

[Anonymous Coward]

If you want a server version then stick to stable.

Stick with OpenBSD. It's more secure than Debian, and substantially more up to date package/version-wise.

Re:testing?!

[rpozz]

While I use Gentoo, SuSE has come up with quite a nice way of dealing with the problem you describe. YaST2 - while being a tad bloated, can either run in an X-Windows GUI, or work under ncurses using its own toolkit and thus keeping the layout just about the same.

Re:testing?!

[grumbel]

What Debian IMHO needs to do is to split their distribution into different parts and release those independendly for each other (base, x11, gnome, kde, etc.).

Its simply a completly hopeless undertaking to try to get all multiple thousands packages in Debian stable stable at the same point in time, it simply won't work. And while this undertaking is already almost impossible at the release time of a new Debian stable, it gets rather pointless once the Debian stable distro got a year or more old. At that point in time upstream often has already moved much further leaving Debian stable with a outdated, sometimes incompatible and bug filled version compared to the latest upstream.

Debian really must move much closer to upstream, when upstream releases a new stable version and it doesn't come with major incompatibilites or problems it should move into the stable branch of the distri and not have to wait three years till Debian decides its a good time to release a new distri.

The concept of having a non-changing[1] and security-patched list of packages is nice and good, but it simply can't work if there are no regular new releases and often multiple years between releases. These days Debian stable is really more a 'Debian obsolete' than anything.

[1] non-changing is really the meaning of 'stable' for Debian, not to be confused with software that is stable, have been burned one time to much by buggy software that was already fixed upstream but never made it into stable.

Re:testing?!

[Erwos]

You do realize that dselect and what you are proposing do with apt-get are not the same thing, right?

-Erwos

Re:testing?!

[Erik Hensema]

Oh, come on! When will the submitter realize that stableis what most of us want to run on our servers and mission-critical hardware.

Yes, but you don't want to install the current debian stable on new servers. It's just too old. Stable lacks the hardware support for modern servers (does Stable ship with a kernel which supports dual xeon machines with 2 GB ram? AMD Opteron? Modern chipsets? SCSI controllers?).

Debian Stable is good for old servers. Debian has no good offering for new servers. Nobody cares that debian can be installed in 48 MB of ram. 48 MB does not make a server. It makes an antique.

Debian should realise that if they want to make a serious server distribution, that people will want to run it on a server. A real one.

Re:testing?!

[marcello_dl]

Oh, come on! When will the submitter realize that stableis what most of us want to run on our servers and mission-critical hardware.

Maybe the submitter meant he can't wait for the testing release to become the new stable one because most of the included packages are mature enough (Sarge seems to be lagging because they wanted to include gnome 2.8) and because security updates are done asap on stable.

As for making a "server" distribution, I think it's not worth the effort, as answering the FAQ "which debian branch is better for my needs" should do. Personally i'm using debian unstable powerpc for my desktop and x86 stable with some backports for a server.

Re:testing?!

[__aainau5532]

First of all, I liked debian and run it for years, but. Yes but. Its become something like Qmail or djbdns. It became unmaintained, it became a nightmare. It has software what is over 30 months old and most software isn't even supported anymore by upstream. For example try to submit a PHP-bug or complain about Postfix or get support for Postgresql. It isn't there anymore. I don't mind running behind with my software when its still safe, but when upstreams say "UPGRADE before you complain!!!" its over for me. Currently I have machines with backports and lots of it, but I'm not going to wait for Sarge. I'm running tests with FreeBSD 5.2.1/5.3 for a while now and soon the first debian machines will be something of the past.

Re:testing?!

[imroy]

...with perhaps a pre-configured installer that sets up the most comonly used packages on a server.

Ooh, bad idea. Multiple vendors (amongst them Microsoft and RedHat) have already demonstrated that it's a bad idea for an OS installer to silently install services/daemons. When an exploit comes around, someone *will* write a worm and say bye bye to your credibility. Because there'll be an aweful lot of people who didn't even know that Apache/Sendmail/BIND/whatever was installed on their machines and didn't know to update. No siree, I like the current trend of disabling services/daemons on installation. Even better, Debian often sabotages config files to force the admin to spend at least a little time looking at a config file before firing up some daemon.

Re:testing?!

[A beautiful mind]

I've been running this debian sid(unstable) installation for 2.5 years now, since the time my old hdd gave it in. It is most of the time stable, and as some people were telling, the only difference between stable and unstable is that unstable isn't verified to be stable, most of the time you won't have problems with it. From the things i use on this desktop the only thing which was bugging me for a while was when they broke a library which made mplayer broken (it didn't play movies, just shown a grey frame afair). That issue took 2 weeks to be fixed...I found everything to be working correctly and stable, my desktop has around 60 days uptime since the last kernel upgrade. I use it quite much and well, although to keep it stable may require a bit higher knowledge of apt-get or dpkg or just know where to look (debian.org) it is very stable. I considered gentoo aswell after i have been made aware of it's existence, which was around 1.5 years ago and i think, personally, that the performance upgrade it gives isn't worth the compile time on my machine when upgrading ~200 packages.

Re:testing?!

[novakreo]

Sarge seems to be lagging because they wanted to include gnome 2.8

Gnome 2.8 is now in testing, according to the last release update. The main delay is the security update infrastructure for testing.

Security updates are done ASAP on unstable too, so it's also an option if you don't want to wait for security updates to migrate into testing.

Re:testing?!

[JAgostoni]

I actually (personally) call those: Debian Server = Testing Debian Workstation = Unstable I don't even feel the need to stick with the stable branch anymore. I just monitor the security mailing list and when I see some updates that affect me I upgrade that package. When a major package is updated (Apache, for instance) I wait a little bit and scan the Internet for success/failure anecdotes before I upgrade. As an example, I updatated my Apache/SSL a bit too soon and it broke my WebDAV Basic Auth. Good thing, as it turns out, as I just switched over to Digest authentication for an added layer of security.

Re:testing?!

[AKnightCowboy]

Oh, come on! When will the submitter realize that stableis what most of us want to run on our servers and mission-critical hardware.

Unless you need to run PHP4 in which case, the last time I checked last week, they were still arguing about whether it was even a necessary package, much less whether to update it in order to fix a major vulnerability. I've been using testing on my server for months now and it's rock solid. It's nice having fairly up to date packages vs. stuff that the author doesn't even have on their web site anymore!

Re:testing?!

[novakreo]

Backported pacakges are insecure. You should only use the binary version if you trust the person who compiled it.

True, but have a look at Ken Thompson's well-known presentation, Reflections on Trusting Trust. Can you trust your own compiler? Unless you can manage to manually write a trusted bootstrap environment to your hard disk, with which you only compile code that you've fully examined yourself, at some stage you'll need to trust that the toolchain you are using is safe, that the applications you are using are safe, and that at in any number of possible places where it could occur, no one has maliciously tampered with your sources or binaries.

I don't know anyone involved in Debian or any other Linux distro. How can I really be sure they aren't bad guys? Why should I trust them any more or less than the people behind Debian Backports?

In any case, you can always download Debian source packages from unstable, and attempt to compile them yourself on a machine running stable.

Re:testing?!

[d^2b]

I prefer aptitude as well, but the parent grandparent post did ask for a GUI.
For the occasional user, I do think synaptic is a bit easier to use. I don't see that having synaptic forces us not to use aptitude,
unless we get into one of those boring debates about splitting developer resources.

Re:testing?!

[bogie]

Wow, you made sense until that last paragraph. If that's really the way you view Windows users your unbelievably conceited and elitist. Oh and as someone who uses Windows but was using Linux probably years before you ever even heard of it I have to say that your theory on sheeps and geeks is full of shit.

Re:testing?!

[AmoebafromSweden]

-(does Stable ship with a kernel which supports dual xeon machines with 2 GB ram? AMD Opteron? Modern chipsets? SCSI controllers?).

Well at my work we run two Sun v60x servers. Our configuration are 2 Xeons and 2Gbyte ram.

They seem to be working fine with Debian stable.

(they are both firewalled and have no direct connection to the internet.)

Re:testing?!

[Kent Recal]

Give me a break here. For real linux-servers you'd better roll your own linux (remember, a real server takes a real admin...) or at the very least compile the critical runtime stuff (usually database, webserver, app server) and ofcourse the kernel from scratch.

If you seriously intend to put a stock distro kernel on it you have no deal setting up a "real" server.

Re:testing?!

[lederhosen]

"does Stable ship with a kernel which supports dual xeon machines with 2 GB ram? AMD Opteron? Modern chipsets? SCSI controllers?"

Yes

Re:testing?!

[spitefulcrow]

If you want to put a little more effort into installing a Linux distribution you should try Gentoo. You have to configure much of it yourself but it has bleeding-edge updates (things hit the Portage tree in testing branch almost as soon as the upstream software developers release an update and on most major architectures get moved to stable soon thereafter) and it's generally rock-solid. The only downside is the compilation time because it's a source-based distribution. Gentoo.org

Re:testing?!

[MasterOfMagic]

You realize that you can build MySQL 4.x from the source package on your stable machine, correct?

Re:testing?!

[jgrahn]

Yes, but you don't want to install the current debian stable on new servers. It's just too old. Stable lacks the hardware support for modern servers (does Stable ship with a kernel which supports dual xeon machines with 2 GB ram? AMD Opteron? Modern chipsets? SCSI controllers?).

Debian Woody ships with a 2.4 kernel and it's trivial (modulo initrd I guess) to upgrade to the latest 2.4 kernel. That should be enough for many, or most, modern Intel-based servers.

Re:testing?!

[ArtDent]

I run Debian Stable on a very modern server, with >2GB RAM, Fusion-MPT SCSI, gigabit ethernet and all that good stuff. It's just a matter of using a newer kernel than Woody's default.

I want the distribution to be stable, but I don't mind keeping the kernel up to date myself. With make-kpkg, it's a snap to build Debian packages out of kernel.org tarballs and, on this machine, it just takes a few moments.

(And yes, if this really was a mission critical server, and not just a department build machine, I'd build and test my kernels elsewhere before deploying them, but that's not the point.)

Re:testing?!

[Master Bait]

If you happen to buy a new computer, Debian 'stable' is too old to support the chipset, many devices and perhaps even the cpu (such as Opteron or Apple's 64-bit PPC). Otherwise, Debian stable is fine for new servers -- but only if you buy them used on Ebay!

They should reorganize their release names from stable, testing, unstable and experimental to Grandpa, Greybeard, Production and Current.

Re:testing?!

[Icco]

I think that you're blowing this alittle out of proportion i know a large amount of system admins who use Testing. I personally am a semi-noob and i run testing just fine.. its possible that i dont run any packages that break easily, but ive never had any packages break when i run apt-get upgrade.

Re:testing?!

[raynet]

But with make-kpkg you can easily compile and install your own custom kernel with any hardware support and patches you might need. And you can install the created .deb to as many servers you need to.

And I think Debian Stable comes with SMP enabled kernel, so it should work with dual xeons with up to 4GB of ram.

Re:testing?!

[EvilAlien]

"basically all of my friends who proudly call them selves sysadmins are running Debian (stable) on their production boxes"

Should that be interpreted as you suggesting you are a Debian missionary or something? I've observed that Debian seems to have a higher proportion of users who advocate it as the One True Linux compared to the other distributions. Only one of my many friends who are sysadmins uses Debian, and only for machines that have been around for awhile. The new stuff gets something like Gentoo, more cumbersome to manage, but quite capable of working in production. He used to be an advocate/missionary, but recently lost faith ;)

As far as desktop Debian flavors... Ubuntu seems to be a getting a lot of traction lately. I haven't spent any time checking it out yet (its on the list to research further, but not high on the list), but seems to be gaining popularity.

I was a fan of Storm and Progeny, back in the day, but both are effectively dead (Storm being stone-cold dead, and Progeny's near death experience stopped their progress IMO). Now, I wouldn't recommend Debian for desktop or server to any friends, colleagues, or casual acquaintances, sysadmin or not.

Re:testing?!

[Erik Hensema]

I'd fire you for doing that. Seriously. All the top distributions (including Debian) do extensive QA on the software they ship, especially the kernels. When compiling your own software, you dismiss this QA and take your own responsibility for the software quality, knowing that the quality is usally less. And don't even get me started on security fixes. Do you want to keep track of all custom compiled software on all your servers and make high qualily security fixes under high pressure?

Of course I can compile a kernel. I've been doing it for many years. I can do Linux From Scratch without the LFS book, no problem. But when it comes to servers, I want decent quality control on the software I run. Therefore I want to keep the software as close to the distribution I use as possible.

So yes, I am a real admin, and I do administer real servers. And as a professional I demand good quality and up-to-date (not bleeding edge!) software, software which Debian unfortunately cannot provide.

Re:testing?!

[Shadwell]

What's it like to be so afraid of the world that you never leave the house?

Re:testing?!

[Mr.Ned]

" First of all, I liked debian and run it for years, but. Yes but. Its become something like Qmail or djbdns. It became unmaintained, it became a nightmare. It has software what is over 30 months old and most software isn't even supported anymore by upstream."

Debian is most certainly not unmaintained in any sense of the word. Debian backports security fixes to the version in stable.

Re:testing?!

[Fenris Ulf]

He said aptitude, which is both a text-mode GUI replacement for dselect, and a drop-in command-line replacement for apt-get.

Re:testing?!

[Kent Recal]

When compiling your own software, you dismiss this QA and take your own responsibility for the software quality, knowing that the quality is usally less.

Ridiculous. How is software that was handpicked and compiled for the specific task by a qualified person worse than a generic distro package where often you don't even know what compiler version and flags were used and which exotic patches might have been applied?

If you prefer to not know what's running on your server, fine.
The fun ends when you sell that to your customers as a "professional" service.
Ever noticed how the major distros tend to move to new flashy glibc and gcc versions real quick? Wasn't it RedHat, the so-called "enterprise" linux vendor, that was bitten hard by shipping an, uh, "early" gcc-version not so long ago?

You're certainly not the right person to hire for any mission critical app.
(you know those where downtime really hurts and you can't just blame it on
"the vendor")

Last, your blanket statement about debian is so far off - not even worth discussing.

Re:testing?!

[asdfghjklqwertyuiop]

When compiling your own software, you dismiss this QA and take your own responsibility for the software quality, knowing that the quality is usally less.

It is probably a good idea if you need 2.6 and you need it to be stable, but 2.4 is now quite mature and does not undergo very drastic changes. It would be pretty reasonable to compile your own 2.4 and expect it to be pretty stable.

Re:testing?!

[isecore]

It's more secure than Debian

Nope.

This is a common misconception. True, BSD-systems can be made very secure. Also true is that Debian can be made very secure.

Security is a chain, i.e. nothing is stronger than the weakest link. If the person setting the system up is a complete bonehead then the system will have bonehead security. This is regardless of operating system (Winblows, Linux, BSD, AmigaOS, etc etc etc)

Re:testing?!

[justins]

Give me a break here. For real linux-servers you'd better roll your own linux (remember, a real server takes a real admin...) or at the very least compile the critical runtime stuff (usually database, webserver, app server) and ofcourse the kernel from scratch.

Since none of the commercial middleware and relational database vendors support anything except the commercial "enterprise" distributions, running stock kernels and stock everything else, you're pretty much blowing hot air here. Unless you think that the multi-cpu Oracle systems running on RHEL and SLES aren't "real" servers, which would be a pretty interesting position to take.

Re:testing?!

[forlornhope]

Even better, Debian often sabotages config files to force the admin to spend at least a little time looking at a config file before firing up some daemon.

Actually I would not call it sabotage as I usually see a good default config file that will work for most people. What I am seeing more and more are files in /etc/default that have a simple variable that needs to be defined and set to 1 otherwise the /etc/init.d/{service} script will refuse to start the service. This is very cool because it forces the admin to set the variable and maybe even read a bit before the service will ever be started. I am looking forward to all services getting switched over to this type of setup.

Re:testing?!

[tacocat]

No, I was being unbelievably sarcastic.

I'm scared to death that in the name of "Ease of Operation" people will settle for the likes of SuSE at the sacrifice of Debian and Gentoo.

I spend more than a year running only SuSE around here and found that it was very nice to use. Just as long as you didn't try to do anything that they didn't anticipate. They have a good concept in management of a workstation/server. But if your needs deviate from their path, it becomes increasingly difficult to execute. Many times it's easier to go back to source compilation.

So I spent two months with Fedora Core 1 and RedHat 9. Same thing only worse. They have some management tools that were horribly broken. Never should a script to manage firewall rules (iptables) effect the ntp time server. Under these version of RedHat, one would disable the other. A crime worthy of Microsoft in my opinion.

So I went back to Debian. It's not the cleanest install, but how many times to do you install a new Operating System? Especially when you can do an upgrade from one to the next. You can't do that with SuSE or Windows. I don't know about Mandrake or RedHat.

Debian allows me to do exactly what I want in a way that is compatable with the installation. The only time I've ever had to resort to source compilation is when they didn't have a package available.

Re:testing?!

[novakreo]

What's it like to be so afraid of the world that you never leave the house?

I have no idea. I'm not so paranoid that I don't ever use binaries from people I don't know; obviously without gcc, glibc, or the Linux kernel I wouldn't get very far. The grandparent AC said 'You should only use the binary version if you trust the person who compiled it.', and I'm simply trying to illustrate that unless you happen to personally trust the very large number of people involved in putting together your operating system of choice, you'll never really know for sure if it's compromised or not.

I am aware of what the other AC said, that Debian uses GPG signing, but again, it just makes a large group of people who trust each other, with no connection to me. There has been at least one incident in the past where unwanted code has made it into Debian, but this hasn't stopped me using it, since as I mentioned before, it's rather unfeasible to attempt to personally verify an entire distribution. I just install it, hope for the best, and move on with my life.

Re:testing?!

[bcrowell]

I'm running tests with FreeBSD 5.2.1/5.3 for a while now and soon the first debian machines will be something of the past.
Interesting. I used to have FreeBSD on both my server and my two desktops, but I recently switched the desktops to Debian. For me the real issue was that certain ports just were old, or were not really working and available. For me, the biggest ones that mattered were inkscape (an old version is all that's available), lilypond (I have several pages of notes on the problems involved in getting it to work on FreeBSD). There are also a lot of other ports that are marked broken on FreeBSD>=5 or broken on FreeBSD<5. On Debian, everything just works. But FreeBSD works great for me on a server. It's true that FreeBSD's ports system makes it easy to stay on the bleeding edge -- in fact, it makes it difficult not to stay on the bleeding edge. I really hated portupgrade, too; run portupgrade, wait several hours for everything to get recompiled, and then find out you have a totally broken system :-( The best thing about FreeBSD is the installer. The current version automagically installs x.org, and everything works, with no fiddling. That's a big win!

Re:testing?!

[imroy]

Yes, you're right. I guess I showed how long I've been using Debian. They used to do more subtle things to config files so that the daemon wouldn't start and you had to spend at least a little time looking in the main config file. Now they are putting a RUN_DAEMON="false" variable or something similar in the /etc/default/{service} config file that's read by the init script. Although a few still put an exit command early in the init script and require you to remove it or comment it out. This is a bad way to do this for two reasons: 1) The init script is not a config file and has no other settings the admin will look at and 2) dpkg wants to replace the edited init script each time you upgrade the package.

Re:testing?!

[Phleg]

This is insightful? What advantage does rolling your own give you at all? "Of course the kernel from scratch" is taunted, but is there any actual justification for this? Package management was invented for the explicit purpose of being better able to manage software upgrades, dependencies, and file locations. Can anyone give me one reason why this should be abandoned?

Re:testing?!

[__aainau5532]

The moment upstream say "No, upgrade because X, Y en Z" its unmaintained. Its that simple and I'm not complaining about security fixes. But even that isn't really that good anymore. PHP for example, there were problems discovered about 18 days ago and still no sign of there will be a DSA or not. Also the kernel has outstanding problems.

Re:testing?!

[__aainau5532]

First of all, no OS/distribution can fit all. And about the ports, yes that is a problem but no for me, because I first test it on a testmachine before putting it in production. Als your comment about x.org, I still needed to create configfile by hand, no real problem.

Re:testing?!

[Kent Recal]

I'll try to explain further, this is why it is essential:

1. You choose and know what will be running, including all libraries (starting
from glibc), patches, compiler and interpreter versions. No generic distro
package will be optimized for your purpose because no maintainer knows what
set of services is critical to you and what configuration options are
appropiate. You do not want to run public services with all kinds of
unnecessary modules and options compiled it (many of which could become
a security problem in the future).

2. When something breaks you know where to look because you set it up.
When the quarterly openssl hole is announced you get the patch and deploy
the new version without having to wait for a distro package to come out
and without having to audit the distro package (is it properly fixed, does
it break other stuff, does it depend on newest glibc that will upgrade half
your system to an unknown state?).

3. When working with pkg managers it can be hard to repeat an exact
installation of what you blessed to be your stable environment.
If you need to replicate a server you end up tar'ring it up anyways
because you can hardly rely on apt-get or rpm to still provide the exact
set of software that you once had (without updates getting in the way that
depend on other updates etc.)
So why not start from a well-defined base tarball in first place...

4. By diverting from the large population of default installations you evade
generic "mass"-exploits (worms).

5. Last but not least:
You do not want automatic updates on a server, period.
You setup and test the thing once, then it is a Running System.
There is no reason to "stay in sync" with anyone, as long as
your system ticks you would be a moron to change anything.
There are exactly two reasons to update a piece of software
on a live-system:
a) security problem (usually patch + recompile of the affected pkg)
b) you need an addtl service that depends on a newer version of something

Don't get me wrong, distros are fine for newbies, desktops, small/non-exposed servers and the like. For anything serious I wouldn't trust my business to someone who deploys distro updates (with depends) to a running prod. server.

Re:testing?!

[Kent Recal]

Since none of the commercial middleware and relational database vendors support anything except the commercial "enterprise" distributions, running stock kernels and stock everything else, you're pretty much blowing hot air here. Unless you think that the multi-cpu Oracle systems running on RHEL and SLES aren't "real" servers, which would be a pretty interesting position to take.

These are not servers within your responsibility. You buy them as blackboxes and expect oracle-support to keep them running for you. More an "appliance" than a server to me and why not, as long as oracle pays for downtime.

Re:testing?!

[tacocat]

I know. I used SuSE for over a year. It's a pig.

Re:testing?!

[Kent Recal]

Well, despite you're just a flaming AC I'll take the time and respond...

"1. You choose and know what will be running, including all libraries (starting from glibc), patches, compiler and interpreter versions"

That seems good, provided you are a real expert on all those fields. I bet you aren't, so you are doomed to make bad choices here.

Guess what, it's my job and I'm getting paid to be an expert on "all those fields" (which really is just advanced unix knowledge).

"2. When something breaks you know where to look because you set it up."

Probably a good reason. But then again, only *you* know that. If I were your boss this thing only is enough for me to fire you. I can and even want to have critical people because of his technical knowledge on the field and his work ability, but I don't want someone to be critical because of his knowledge of my company innerhoods, the one persons that works in a way that makes him unfireable is fired as soon as this is discovered so he doesn't have time to make things worse.

Ever heard about documentation?
If you don't trust your staff that's a different story and you probably
have bigger problems then.

"3. When working with pkg managers it can be hard to repeat an exact installation of what you blessed to be your stable environment."

That's bullshit. And it is such a bullshit that it can only mean that you have no idea about what a package manager is for, how does it works and which choices do you have. Then, all what you say about deploying you own LFS-like boxes is tainted from your unknowledgeability, and then not to be taken seriously. What package manages are FOR is (among other things) to achieve repeatability. I can (and do) deploy "clonic" boxes out from CVS (for config files) and package manager lists (either form rpm and/or dpkg) with total asurance of the results. You can't, OK, that's your problem, don't blame the tools you don't know about.


Dude, I've been working with kickstart (RedHat) and FAI (debian) for over a year. If you had that expirience you'd probably know that after a while you come to the point where you have to divert from the distro branch just because you don't want to update that friggin glibc just yet and everything else starts to depend on the updated package.
So you end up with a custom repository and start backporting packages where it matters. RedHat is already lost at that point (maybe they're better nowadays but back then RPM-hell made me abandon it).
Debian/stable is indeed quite stable but when your (considerably complex) FAI framework breaks down the nth time because some of the scripting magic is not as robust as it should be you begin to realize that rolling your own tarball is just so much less pita.

"you can hardly rely on apt-get or rpm to still provide the exact set of software that you once had (without updates getting in the way that depend on other updates etc.)"

Don't talk about what you ignore. I bet you *never* have properly used Debian under a production environment, otherwise you wouldn't say that. I *do* work with RH, and I *do* work with Debian, and I can tell you that having an upgrade that breaks your system is neither rpm's nor dpkg's fault, but their respective's distribution policy. I had Red Hat shoot me in the face some four o five times in the past due to a faulty upgrade (not that the package upgrade failed but because the new version broke something else), because Red Hat envisions their systems in a certain way. That's to me a big NO-NO, so I neither install nor counsel people to do so except when extrictly needed (and I try to do all on my hand to avoid those situations); now, Debian's policy is quite different and as a result, I didn't have a faulty upgrade on Stable boxes for almost six years (it is not that I had it six years ago, but that I have used Debian only from six years ago).

Well, the article we're

Re:testing?!

[justins]

You buy them as blackboxes and expect oracle-support to keep them running for you.

Ha. Not a professional DBA, are we?

Re:testing?!

[Billly Gates]

Well I only own a regular pc and I can tell you Xine and Mplayer crap on me all the time for any distro except debian and the 4.x versions of FreeBSD.

Now tell me if most of hte linux distro's are really that tested? SuSE particularly is very buggy.

If I were your boss I would fire you for installing free software that has not been testing for QA.

The redhat scare had to do with some patches for the stl library which many c++ unix programs needed to be ported to Linux.

In general Solaris and other unix admins do not like Linux that much for their servers. Reliablity is the number one reason.

Re:testing?!

[tacocat]

You don't have to do business with people who insist you use Windows. But that's your choice.

And I never said Windows users liked to fuck up they systems. But then sheep don't like being fed to the wolves either. Sometimes they don't know any better.

Sheep are very dim..

A serious issue with old packages

[Anonymous Coward]

I've always defended Debian Stable's stale package versions for the sake of stability, but recently a serious issue has arisen. The recent PHP security flaw has made this issue apparent. The version packaged for Woody is 4.1.x. The PHP developers no longer pay any attention to the 4.1 branch and their recent release for the newer 4.x release which fixed the security issues, also had other fixes included, making it difficult to backport them to the 4.1 branch. Last time I checked, no one on the Debian side had stepped up to fix the issue in 4.1.

Something really needs to happen here (and installing 3rd party backported packages is not a clean solution). Perhaps a policy that packages that are no longer supported upstream will be upgraded in stable.

Re:A serious issue with old packages

[WanderingGhost]

The recent PHP security flaw has made this issue apparent. The version packaged for Woody is 4.1.x. The PHP developers no longer pay any attention to the 4.1 branch and their recent release for the newer 4.x release which fixed the security issues, also had other fixes included, making it difficult to backport them to the 4.1 branch. Last time I checked, no one on the Debian side had stepped up to fix the issue in 4.1.

As someone pointed out in response to another post, the same problem happens with Cyrus (the version in Woody doesn't have security updates from upstream).

Re:A serious issue with old packages

[tacocat]

Could you have used Debians pinning to selectively upgrade PHP to the testing branch?

You've got a point about the slow fix to the flaw. But I don't believe the solution is going to be managed through adding additional levels complexity. But focusing on how to get the existing process to move more smoothly.

Re:A serious issue with old packages

[stevey]

The PHP issue was complex due to initially there being a lot of issues reported and ID's given which were later retracted.

All this was muddled by the PHPBB2 worm which the PHPBB people claimed for a long time was a flaw in PHP itself being exploited not a hole in their software.

Few people seemed to care to look into the situation carefully, had they done so they'd have released that woody wasn't vulnerable to several of the isses, eg these two.

Re:A serious issue with old packages

[mindas]

PHP is not the only one example, there are more. Lots of teams are simply releasing new software versions when critical bugs arise. For Debian/stable this is not the way things should work - they are always about to apply patches for old software instead of upgrading to the newer version. Being a developer, I prefer the latter way.

Not sure it matters which is stable

[ewanrg]

I personally run a Debian install from a Knoppix 3.6 HD Install at home on a couple boxes. It defaults to testing, and is quite happy to let me upgrade packages from "unstable" as well. I think there's something to be said for giving the user a few different branches of choice, and let them decide the level of risk they're comfortable with.

Some packages, such as MPlayer, I know are tested enough by the development team that I'll take the newest version as soon as it comes out. Others I'd prefer to know someone else has taken some pain with it :-)

Just my .02 worth

---

For more of my ramblings, look here

PHP Worm response?

[fatalexe]

Is this in response to that php bbs worm? Now if I could just figure out how to sync mysql with a backup, I might give ole deb another try.

Re:PHP Worm response?

[stevey]

To backup MySQL databases run the following command:

mysqldump --user=root --all-databases >foo.sql

All your table definitions and data will be exported as SQL which can be importated again easily.

Re:PHP Worm response?

[fatalexe]

Woo hoo I got a troll! Umn, what db should I use? I'm running a tiki-wiki. From my understanding with backups and chrooting it dosen't really matter if you get hacked.

Netcraft now confirms: Debian is obsolete

[Anonymous Coward]

Seriously, ever try installing Woody on a new machine with a new hardware RAID controller? You can't, you need a custom hacked install CD. I admin a bunch of servers and my boss likes Debian, however I'm sick of having to bend over backwards to just install Debian on our new rack boxes, much less try to use up-to-date packages. I'm going to try to sway him towards FreeBSD. Debian was a great thing back when compiling packages took hours and hours, but as fast as machines are these days waiting several years between stable releases is not viable. On top of that, with the time spent on debian-devel discussing (and flaming) trivial things like package ratings (someone posted an ITP for some R-rated thing), it's all just a waste of time.

Re:Not to troll but..

[basvdlei]

Ever looked at alternatives like aptitude?

Not so long ago there was a discussion on the development mailing-list about dselect. There are still many people using it on a daily bases and don't want it changed or removed. http://lists.debian.org/debian-devel/2004/11/msg00 629.html

Re:Not to troll but..

[Anonymous Coward]

Yes.
I've tried debian a number of times, as I would love to be able to access the huge array of binary packages available, but dselect always seems to tie itself into knots. It appears to randomly install and uninstall other packages when you try to install a new package, and eventually grind to a halt.
I have to use Gentoo now, and hate the compile times, and don't see any gain from the optimisation. At least though I have something that works and is predictable.

Re:Not to troll but..

[sunsrin]

Why dont you use Synaptic or Aptitude if you dont like dselect. Synaptic has nice usable gui and aptitude is much better than dselect if you like working on a terminal

Debian stale.

[Anonymous Coward]

With stable this chance is minimal, but of course not non-existant.

Debian stable is crap. The ISO images won't even install correctly here. The packages are ancient. The goal of a stable and reliable distribution is good but Debian stable is an embarrasing example of one. Out of date is not the same thing as stable. It's stale.

Re:Debian stale.

[Bloater]

That's exactly what the name "stable" refers to. "Unchanging", you put it on a server and expect to only need to update for security fixes.

That's why it is so long between stable releases... They have to make sure you can install and forget (except for the security fixes).

If you want a workstation use ubuntu, essentially a combination of testing/unstable. Or unstable.

That's what Ubuntu is for.

[pwhysall]

Six month release cycle, new packages, desktop orientation.

Re:That's what Ubuntu is for.

[ultrabot]

Not to mention the awful "media" replacement for mnt...

So it's /media/cdrom instead of /mnt/cdrom? What's the big deal?

no firewall

People should generally prefer the hardware firewall in their DSL modems/whatever, assuming that they have a box with NAT or actual firewall.

no firefox 1.0 last I looked

Yep, but installing the FF1.0 from the official package at mozilla.org works like a charm, and doesn't overwrite the old 0.9.3 or whatever it was.

and a host of other annoyances

Main annoyances are lack of supported KDE and an audio CD burning program (which Nautilus doesn't do). I'm expecting both to be corrected in Hoary.

but it is far from being on par with something like fedora/suse/mandrake when it comes to a desktop.

That's not my experience. I far prefer Ubuntu to any of those you mention, having tried all of them. I love the fact that I can apt-get most of the stuff that is available in debian Sid, yet my system doesn't break every other weekend. Fedora will probably rock too when they finally get their crap together regarding community participation etc.

Re:That's what Ubuntu is for.

[melodraama]

Not to mention the awful "media" replacement for mnt.

Duh! The "awful media replacement" is actually from Filesystem Hierarchy Standard and every distro should follow it.

Re:That's what Ubuntu is for.

[BenjyD]

No, if you nmap a default ubuntu install there are no open ports on any external interfaces. Postfix is running, but only listens on 127.0.0.1.

Re:That's what Ubuntu is for.

[arose]

Firefox 1.0 is also in Ubuntu Backports.

Discussion summary

[Knights who say 'INT]

A: "Debian is all old!"
B: "Yes, but it's stable and it rulez in professional environments where you can't crash"
C: "Um, but Red Hat has pro support, if you're a pro"
B: "You can buy support from vendors"
D: "Don't people realize stable means stable, and testing means testing and it's wonderful that there are so many options?"
E: "My Gentoo system rox!"
A,C,D: link to sites like funroll-loops.org
F: Hypes up debian-based Knoppix.
G: Hypes up debian-based Ubuntu.
A: "Debian testing is still old, I need new"
B: 'You could try gentoo, you unfaithful kid".
yadda yadda yadda.

Re:Discussion summary

[tacocat]

The each have their own place

RedHat (SuSE) A good distribution for someone who is looking for products which are supported by contractors and vendors. A widely popular distribution which targets the Enterprise computer industry with marketed points of Vendor support, Third party package availability, simplified GUI's with a design towards a single look and feel for all concerned. Gentoo Very actively developed based on some good ideas. It's newness prevents it from really approaching a serious consideration for many users and most Enterprise applications. Exceptions do exist, but are the minority. Very high potential for success once some concessions are made towards making the system more stable, easier to manage, and less likely to explode. Debian One of the oldest distributions and also surprisingly popular with software developers. Definitely one of the top five in the industry and holding strong. While it does not cater to the Enterprise crowd through market-speak, it could perform as such given the chance. Also there is a fundamental lacking in the One Size fits all approach that SuSE (and to some degree RedHat) have taken. This can lead to a confusion at the desktop when users switch between KDE, Gnome, and WindowMaker (top 3). It's also know for it's focus on being stable over current.

While there is a lot of pressure on Debian to move off the focus on stable and move towards being more current, this needs to be addressed not as a means of changing the process with greater options for the user community, but to address how the existing (and proven over years) process might be better improved upon. Much has been done through automation of the defined process steps already.

Re:Not to troll but..

[Anonymous Coward]

You shouldn't abondon a platform because of a one bad tool for which there are alternatives.

Debian Unstable

[SiChemist]

I've been running Debian Unstable on my home machine for a few months and I have to say that it's every bit as stable as the Fedora install it replaced on the same hardware. It's my main desktop at home and gets quite a workout.

The Debian "unstable" branch is as stable (at least for me) as any Linux distribution that I have used. Fast, too.

Re:Debian Unstable

[mikeage]

This is a common misconception about stable and unstable. Unstable does NOT mean that it's fragile, going to break, or unsafe for use. Instead, it means that it has not been verified as stable.

The guidelines for unstable/testing/stable as basically as follows:
All new packages are in unstable
After about 2 weeks, they are moved to testing, if there are no major bugs
At release time, they go into stable.

Thus, if you'd download the latest version from sourceforge, or any kind of "nightly build", you may as well use unstable. If you only use things that have been tested first, but like recent software -- use testing. If you need the best testing availabe (without, of course, paying for testing or doing it yourself!), go with stable

Re:Debian Unstable

[cortana]

It doesn't mean unstable as in crashing; it means unstable as in volitile, changing. Every night you can apt-get upgrade to a new host of potential problems. Stable is called such because the only changes that are ever made are backports of security fixes. Thus, stable is suitable for servers or large workstation deployments, etc, while testing/unstable are ok to use for random hacking on a desktop machine at home.

Re:Debian Unstable

[Hiro Antagonist]

Um, I don't see why one distribution would be any 'faster' than another, for the most part; they all run essentially the same code, and per-processor optimizations don't make any real-world difference (i.e., Gentoo). The only real difference might be in boot-up time, because Debian tends to be pretty minimalistic when it comes to the 'base' distribution required for installation, but this is quite tunable in RedHat, SuSE/Novell, Slackware, etc.

I use Debian more because it's designed, or has the appearance of being designed, by-and-for system administators. It's a System-V workalike, which is great for admins dealing with Solaris or AIX[1] in addition to Linux. Nothing compares to APT at all, and the DEB package format is highly superior to RPM -- no stupid per-file dependencies, and a text-backended DB in case you manage to corrupt it somehow. Config files have sane locations under /etc, local custom package distribution is a cinch, and the 'never-upgrade-only-update' mentality saves me a ton of work.

But faster? Probably not.

[1] Well, some parts of AIX, the rest is IBM's gift to admins from the deepest bowels of hell...

Re:Debian Unstable

[Spazmania]

I've been running Debian Unstable [and] it's every bit as stable as the Fedora install it replaced

I've been running Debian stable systems since '97 or so. I did some recent short-term work where I had to build and support some Red Hat Enterprise 3 systems and some Fedora Core 2 systems.

Talk about "fun" problems. I got all manner of grief from Red Hat's Linux kernel. I had a particularly fun one where every couple weeks the cached copy of one of the filenames would have a corrupted last character. So I compiled and installed a new kernel from the base linux source. I had also set the / partition to "rw,noatime" instead of "defaults" in /etc/fstab. Oops! mkinitrd (not used in Debian) turned this into a "mount -r -o rw,noatime /" in its script which crapped out fsck on boot. The server was 50 miles away and trying to talk someone through fixing it was even more fun: it seems I couldn't get it to continue to boot up after failing the fsck the way Debian will. No, exiting that shell generated a nice reboot and repeat.

And don't get me started about "up2date", Red Hat's version of apt-get. Damn thing gets stuck in infinite loops consuming 100% of the cpu until killed hours later. And no, the most recent updates havn't fixed it. Nor did following the instructions for regenerating the .db files.

My point is: I don't want to run anything as unstable as Fedora or Red Hat. That's why I chose Debian in the first place. So why would I want to run Debian Unstable?

I do want to see SOME forward motion though. Its long past time for those few package maintainers that are blocking testing's release to stable to either buckle down and get it done or be replaced.

Maybe it would help if they halted updates to those maintainers' packages in unstable and experimental until testing was releasable.

Re:Debian Unstable

[psavo]

If you only use things that have been tested first, but like recent software -- use testing.

No no no. testing doesn't get security updates whatsoever. If for whatever reason sec-update package is bugged, it will not propagate to testing. This will make the 2 week delay even longer, possibly putting sec update off for a very long time. It's stable or unstable, testing is just to have new stable in a few years.

Re:Debian Unstable

[justins]

It's a System-V workalike

Like any distro adhering to the LSB, or in reality just about any distro except Slackware or Gentoo.

Re:Debian Unstable

[davegaramond]

True, but since this misconception is so common, perhaps the "Unstable" label is not appropriate (i.e. who the hell gave the "unstable" name in the first place? we know it means fragile!)

So perhaps choose another name for this branch: incoming? bleedingedge? cuttingedge?

Re:Debian Unstable

[BenjyD]

"Every bit as stable as fedora", "Every bit as unsinkable as the titanic"

Fedora Core 3 was one of the buggiest distros I've used. If Debian Unstable is still like that (which it was when I used it a year or so ago), I wouldn't use it for anything beyond a test system.

On Fedora: gnome-volume-manager died all the time on unmounting memory cards, syncing to my Palm wouldn't work (kernel patch problem), xemacs wouldn't maximise, up2date would say "Updates available" in the notification area and then refuse to find any updates, NFS mounts wouldn't mount on boot unless I put the server address in /etc/hosts.

no, an up-to-date Stable

[mrmez]

Why do you think the question on everyone's mind is when Testing will move to Stable? It's because we want a stable version of Sarge, one which won't break packages.

Cripes, this is going to be one of those "how dense can a person be?" articles I mention to everyone I know so that they can laugh at your obliviousness to the blantantly obvious...

Ubuntu

[eonish]

One possible solution would be to divide Debian into a "server version" and one for the workstations who actually _want_ (or need) to run stuff from testing. Although this would mean double the work for the package maintainers (et al) I'm sure it would make Debian even more attractive as a desktop alternative.

Or just use Ubuntu warty... For the bleeding edge developer version, there is ubuntu hoary. Debian based distro aimed for desktop users with a huge and highly updated repository. Its gentoo's answer from deb binaries.

Re:Not to troll but..

[ultrabot]

RPM is a package that sucks balls too.

I hear that a lot, and occasionally someone who knows the differences between rpm and dpkg comes out and says what the differences are. I forget what they are, but I don't believe they are anything that a regular user might care about. rpm and dpkg are basically equivalent.

Has anyone noticed that the RPM distributions are starting to use the apt-get approach?

Of course, is there something in dpkg that makes it more suitable for apt/yum like functionality than rpm? Fedora supports both apt and yum frontends for rpm.

In fact I'm using both Debian and Ubuntu myself and kinda hope that they switched over to rpm. rpm is a standard as specified in LSB, and existence of two popular, basically equivalent tools w/ different interfaces (command line switches) and file formats seems like a waste of effort to me.

Re:Netcraft now confirms: Debian is obsolete

[AndyCater]

Move to Debian Testing (Sarge) which should be released as Stable soon. Includes Gnome 2.8 and will
include KDE 3.3 when it filters through. D-devel
has always been a bit like that anyway, FreeBSD will
possibly not give your boss what he wants or give you the breadth of readily installable packages.

Re:Not to troll but..

[tacocat]

Are you asking for Debian to switch to RPM because it's better or because more people compile software in RPM formats?

Do you realize just how hard it isn't to compile software in .deb formats as well? Might it make more sense to use the better of the two packages in the long run rather than going with the most popular?

Of course, you've already answered that question because you are using Linux in lieu of Windows.

Re:Netcraft now confirms: Debian is obsolete

[wasabii]

Testing has no security updates.

Re:Not to troll but..

[wasabii]

RPM's package database (last I checked) was a binary BDB database. Dpkg's is a series of text files. One per package.

Dpkg really never breaks unless you have widespread disk corruption.

RPM breaks all the time (for me at least). Database corruption means all your package info is lost.

Dpkg, if 1 files gets corrupt, you just install that one package again and the files are replaced.

I think RPM has file dependencies. I don't know how I feel about these. I tend to think they aren't that useful.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Not to troll but..

[ultrabot]

Are you asking for Debian to switch to RPM because it's better or because more people compile software in RPM formats?

No, I would like to see a simplification of the skillset needed to operate a Linux system. Especially if the other alternative is not "better", only "different".

Obviously we are talkin about Debian here, where politics are everything and egos are on the line, so I'm not exactly holding my breath...

Mod parent up

[ultrabot]

Also some thoughts:

.deb is package-oriented.

Wouldn't it be trivial to add package support to RPM, then? A package could easily say that instead of this file, the package requires this package, this version? The coding/design feat doesn't sound like rocket science.

Or are there still other technical reasons?

Re:Mod parent up

[Anonymous Coward]

Actually, RPM based distributions don't have to rely on manual downloads anymore. They can use YUM (for Fedora), apt-get (for Connectiva or Fedora), or URMPI (for Mandrake) to handled dependencies.

That being said, DEBs seem to be better constructed than RPMs. I really like the two stage configuration/installation of DEBs and the added flexibility they bring.

A stable Debian for the desktop?

[theantix]

Yeah, wouldn't it be nice if there was a stable version of Debian that was updated every six months or so? Something that had the wealth and quality of debian packages, but with a focus on a great stable desktop release? Yes, that sure would be nice if something existed like that. Alas, we can only idlely wish for that, as nothing similar exists in the linux world.

Testing, Sid, or...

[Anonymous Coward]

Quite a few people are commenting about using testing or Sid instead of stable, for a desktop. And other comments include using testing or backports if you don't like stable for a server.

The problem is that even though sid is fairly stable compared to other popular Linux distros (though things do break occasionally), others in this same story, and rightly so, have said they would never use sid for a server. The whole purpose of stable is for running a server these days. I'm sure there are some users out there that may use stable for purposes other than a server (Bonzai was good enough for me for low resource hardware, when I installed it, it was based on stable, don't know now). But most users who are installing stable on a new server, with new hardware, have rightly pointed out that many pieces of the new hardware either don't work, or if it is possible to get working, have to be heavily hacked.

If stable were newer, it may be considered more for company installs, as long as the Oracle or Websphere, or whatever other certification doesn't require Red Hat or Suse. And I'm sure that even in companies that run Red Hat or Suse for some applications that need it, may also run Debian Stable for some purposes where they can just set it and forget it!.

I've tried stable in a newer computer. And besides the difficulty with some hardware, I found X with XFce difficult to use. Even though it is a server install, I still find it easier and more productive to install and use KDE gui apps for administration. Sure, I use the server for development also. It isn't my main development box. But for tweaking some html here and there, dragging and dropping files here and there quickly, and for some other purposes, I simply prefer a gui to do it with. I would've used Firefox (wasn't out yet) or Mozilla with another app for file browsing, but I like konqueror for web and file browsing (and fish/ssh) and a few other utilities it is good at. And though KDE is really bloated and I'd like to free up some space (every time I try uninstalling something KDE related, it wants to uninstall most or all of KDE or important libraries, like trying to uninstall XMMS, or other KDE utilities or apps), but KDE or synaptic won't allow it. Synaptic is another reason for my running X. And that I also wanted to try out Quanta Plus.

The release I'm using on the server is testing. As some other posters have suggested using. But the problem with testing is that it doesn't get the attention of the security team. I believe this changed a month or two ago because testing is close to going stable. But I'm not aware of a security repository for testing. I'm sure I would have seen an announcement about it here on /., perhaps in one of the posts, or elsewhere (distrowatch maybe), or on one of the mailing lists. But I haven't seen anything.

If the testing distro did receive the attention of the security team, and there were security repositories, then that would make testing far more palatable for many users as a server distro. With careful updates/upgrades, it would be a good solid release for a server, with much more up to date applications.

My testing distro was once Mepis. But once installed, I uninstalled some unnecessary apps, fixed my sources list, and slowly but surely, the install is becoming 100% testing. It currently has KDE 3.2.3, instead of the KDE 3.3.x version. I haven't taken a look at KDE 3.3 yet, nor do I plan to install it, as that would entail switching to unstable for a few repositories, and pinning, two things I don't want to do. But KDE 3.2.3 is working good for me, and as I stated, it is on a server install, so the latest and greatest isn't necessary.

I had planned on waiting (when Bonzai didn't work out for me) for testing to become stable. Good thing I didn't, because I never would have got anything done. Since I got tired of waiting though, I installed testing, and now hope KDE 3.3

Re:Testing, Sid, or...

[Bodhammer]

Nice Post - why anonymous?

Re:Testing, Sid, or...

[justins]

And I'm sure that even in companies that run Red Hat or Suse for some applications that need it, may also run Debian Stable for some purposes where they can just set it and forget it!.

Why? They can do exactly the same thing with RH or SuSE's enterprise editions. That's one of their main selling points.

What do i need it for?

[northcat]

I can't think of a good reason await sarge's release other than having all the latest eye candy apps. Woody is working finely for me and it has all the features i would need. Of course there might be one or two program whose latest version I need, but I can upgrade them separately, and it doesnt warrant for a full system upgrade.

Re:Not to troll but..

[andywebsdale]

you can always use alien to change rpms to debs - I use it often & it usually works fine

Re:An explanation...

[slamb]

.deb is package-oriented. A .deb lists package dependencies that it requires: the name of the package and the version information. [...] An example: if package my-app depends on x-window-manager, my-app will only install if some package claims to be "x-window-manager". This could be an actual "x-window-manager" or a virtual package provided by, say "enlightenment" and/or "metacity".

RPM can do this, too. IIRC, recent Fedora systems have dependencies on smtp-daemon, which can be satisfied by either sendmail or postfix. And it provides system-config-mail which supplies a sendmail interface which dispatches to the one you have configured.

.rpm is file-oriented: a package lists its dependencies as files it requires.

.rpm can be file-oriented. It's the choice of the one making the package.

I'm not aware of anything .deb can do that .rpm can't, despite Debian fans raving about their superior package format. All of these things are more about the way the packages are made than the actual format.

Re:An explanation...

[More Trouble]

.rpm is file-oriented: a package lists its dependencies as files it requires. It's not necessarily important where the file came from - rpm supposes the file does what it is supposed to and is installed correctly.

This assumption is exactly where RPM runs into trouble. See An Analysis of RPM Validation Drift.

:w

Re:An explanation...

[AndyCater]

One thing you can do with a .deb because of the
internal format: you can unpack it with relatively standard unix tools. ar -x on a .deb will unpack it , mv the tar file to root then untar it there and all the files will magically drop into the appropriate places. Can't do that with rpm as far as I know. Saved my machine when I managed to hose it and had to put on individual packages until I could recover it.

Re:Not to troll but..

[tacocat]

The egos problem will take care of itself in time.

As soon as someone develops a package management system that's better than Debian, rather than just duplicating it, then Debian will be in a position to lose.

Gentoo has a lot of potential on their package management system, but I've been repeatedly burned by their lack of basic safeguards in configuration and updates. For example: who would ever upgrade their /etc/fstab table from their own system to the one provided as default (which is empty). This is one of those files that should never be permitted to upgrade even if the user begs for it.

I did manage to do that on more than on occasion. Why? Because they don't have any 'sane' defaults like Debian does. With Debian, if you have a file that's already there, they won't replace it unless you specifically tell it to. And it won't upgrade to a version that isn't compatible with your existing configuration without specifically telling you all about it.

And when someone tells me I'm a dope for doing these things incorrectly on Gentoo, they they probably need to consider themselves elitist and egomaniacal.

An update to APT

[jmkrtyuio]

I for one think that much more important would be an update to the APT system that did these things much smoother than gets done today:

- Selection and failover (possibly using multiples) of different mirrors, automatically. I would rather not have to manage the source.list and I am quite sure no newb wants to, even from synaptic.

Settings up bittorrent trackers or gnuttella networks for this might be worthwhile as well.

- Dependency resolution has started to see some cracks. Virtual packages that force you to choose one manually and so on so forth.

- More cryptography signing and verification for packages.

- An easier way to search for available packages based upon filename, title, description, man pages provided so on so forth.

- a mode whereby you can safely schedule apt-get upgrade to run from cron. Currently thats not completely safe to do without any human interaction. Call it apt-get computer-upgrade.

- single step update and upgrade (apt-get update upgrade)

APT while revolutionary in its time is starting to show its age relative to what we should be able to expect today.

Re:An update to APT

[csirac]

Selection and failover (possibly using multiples) of different mirrors, automatically. I would rather not have to manage the source.list and I am quite sure no newb wants to, even from synaptic.

All you do is add more than one source in sources.list. apt works through them in order until it hits a source without errors. Isn't that simple enough?

Settings up bittorrent trackers or gnuttella networks for this might be worthwhile as well.

A nice thought, but more open to tampering of the packages. I'm sure it wouldn't too hard to hack in (as far as challenges go), but statements like this are easily said by those not doing the code :-)

Besides, as a user and admin, I see absolutely nothing wrong with the current distribution system. As a mirror operator, it's probably a lot of data to keep in sync but I don't know.

Dependency resolution has started to see some cracks. Virtual packages that force you to choose one manually and so on so forth.

This is utterly deliberate, in fact it is a feature. Why should Debian choose for you? How would they decide? Have they got the right to decide? Not saying there's no room for improvement, but I'm interested in how you would propose to improve the current dependancy system.

More cryptography signing and verification for packages.

This I agree with. It would be nice to know that the whatever mirror I'm using hasn't been compromised and packages tampered; at the moment when you do apt-get update you get a list of md5sums for every package and if they don't match once downloaded, there's an error.

Of course, an attacker could modify the md5sum string in the package lists to match his tampered package - on the other hand, I guess with rsync the lifetime of the tampared file can only last until the next rsync, and some mirrors do this up to 6 times a day.

An easier way to search for available packages based upon filename, title, description, man pages provided so on so forth.

Use: apt-cache search for searching package names/descriptions, and apt-file to not only find what package owns a file on your HDD, but also list files contained within a package. Not sure what you mean about searching by man pages provided, do you mean by searching the contents of the man page? I'm pretty sure there's nothing in a package's man page that's not in the searchable description that would stop you from finding the package.

mode whereby you can safely schedule apt-get upgrade to run from cron. Currently thats not completely safe to do without any human interaction. Call it apt-get computer-upgrade.

It's called cron-apt, and I think this is a good time to show an example bash session:

csirac@singularity-0:~$ apt-cache search apt cron
cron-apt - Automatic update of packages using apt
debarchiver - Tool to handle debian package archives
mini-dinstall - daemon for updating Debian packages in a repository
csirac@singularity-0:~$ apt-cache show cron-apt
Package: cron-apt
Priority: optional
Section: admin
Installed-Size: 80
Maintainer: Ola Lundqvist <opal@debian.org>
Architecture: all
Version: 0.1.1
Depends: apt, bash (>= 2.03-6), mailx, debianutils (>= 1.7)
Recommends: liblockfile1
Filename: pool/main/c/cron-apt/cron-apt_0.1.1_all.deb
Size: 18558
MD5sum: dc06ddd83eb7828995f39ec189cef95a
Description: Automatic update of packages using apt
This package contains a tool that is run by a cron job
at regular intervals. By default it just updates the package list and
download new packages without installing. You can instruct it to run
anything that you can do with apt-get.
.
It also sends mail (configurable) to the system administrator on
errors.
.
Observe that this tool is a security risk, so you should not set it
to do more than necessary

WTF?

[fforw]

Even better, Debian often sabotages config files to force the admin to spend at least a little time looking at a config file before firing up some daemon.

stockholm syndrome?

Comment removed

[account_deleted]

Comment removed based on user account deletion

I found a bug that they wouldn't fix too.

[Mustang Matt]

I found that using sort() on array with only 1 value doesn't reindex it, but sort() on an array with multiple values does.

The debian PHP maintainers arguement was that some people might be relying on that bug. I can see his point but it's such a broken bug that I still feel it should be fixed. It makes doing a for loop through an array that has been sorted unreliable so that you have to use for each.

Ygggdrasil more up to date

[ZeekWatson]

Subject says it all, debian is the walking dead.

you should use foreach

[samjam]

You should always use foreach when looping over an array in php.

It makes me faint to think of you doing otherwise.

Sam

stable as a fossil

[samjam]

You make a good point.

Current is oftenmore important than stable where "stable" is stable beyond the practical life of the hardware and "stable" wont install on new machines.

Fossils are stable too, but not much good as meat.

As is pointed outm "stable" is just a label though, and although calling something less stable "stable" doesn't make it so, and you can selectively pick pages from "testing" and do your own security fixes.

I think security fixesfor testing, and easier pinning control in dselect would solve most of it.

(I know dselect has been superceded but I can never remember thename of the new program and I find it harder to use than dselect anyway [and that was hard enough])

Sam

Sam

Re:An explanation...

[samjam]

An RPM is a cpio archive, see :

man cpio

I say this, it is much easier to maintain RPM packages with their single .spec file than it is .deb packages with their whole debian directory.

I also prefer the RPM principle of "pristine sources" which try to make it impossible to build a package from manually hacked sources, you need to provide a seperate patch file.

dpkg and apt stuff let you hack the un-tar'd source and then happily build from it. If you cant seeANY haarm in this then you don;'t understand the value of being able to build from pristine sources and having packager patches kept seperate. I know I do, because of that I've easily been able to manage my own security updates. I know .deb best practice is to follow this, but the RPM tool tries to enforce it.

Sam

Sam

Any specific reason?

[Mustang Matt]

I have been converting to foreach, but is there any reason not to do it the other way?

The only reason I did it the other way is that's what I originally learned bringing it over from ASP years and years ago.

Re:Any specific reason?

[samjam]

If you for($i=0;$i$dummy) {
$object=&$array_of_objects[$key]; ...
}

Because we have been permitted to see the growth and maturing process of PHP we see lots of weirdisms some of which are not ironed out till PHP5. This also means that in PHP4 (and evebn more so in PHP3) there are a few clumsy idioms like the one I gave above that need to be used but which really ought to have a more compact representation.

Some others are (remember that PHP arrays are ordered):

1) get the first item out of an array as a reference. Of course the first item might not be $attay[0] and for me it often isn't:

reset($array);
$key=key($array);
$value=&$arra y[$key];

Actually we can do this ibn one line with

$value=&$array[array_shift(array_keys($array))];
but it is less clear

Extending use of an array from numeric-only keys to also string keys and NULL keys can often be the natural solution to extended functionality (for me at least) so it is convenient for myuse of arrays to contain as few assumptions as possible.

Sam

Roll your own kernels

[xixax]

We patch kernels so infrequently, I usally build them from source anyhow. For the most part, a kernel ir a kernel is a kernel, and I have never encountered any sitiuation where running my own kernel has messed up packages or dependancies.

I'm getting to a point where there are things in testing that I need, I'll grab those packages from backports.

Xix.

Re:Netcraft now confirms: Debian is obsolete

[/dev/trash]

But it works great on Ian's 486 he got in college.

Re:Not to troll but..

[bcrowell]

rpm is a standard as specified in LSB, and existence of two popular, basically equivalent tools w/ different interfaces (command line switches) and file formats seems like a waste of effort to me.
I agree with you that there are too many packaging systems out there. However, we'd be a lot better off if RPM would dry up and blow away, rather than Debian. RPM-based distros are a total PITA. You have to search all over the place for foo.rpm, and not just any foo.rpm but foo.rpm that's been packaged for your particular release of Red Hat. Then, oops, foo.rpm depends on bar.rpm. OK, more searching around to find out where you can get bar.rpm, and again, it has to be bar.rpm that's packaged for your particular release. And unlike Debian, you have no way of being sure that the rpm's you're getting aren't actually trojans -- Debian's system includes GPG-signing of the packages by the debian maintainers, and you don't have to guess where to get them, just apt-get.

The LSB basically is not fully implemented by any popular distro, and that's for two reasons:

1. In some ways it's a bad standard. It was designed around RPM because Red Hat was a big player, and that was a mistake.
2. It conflicts with how OSS programmers want to work. The LSB states that all binaries have to be statically linked (except for a very short list of highly standard, stable shared libraries). Well, nobody actually does that, and it's not hard to see why. Most OSS programmers don't want to hassle with static linking. We can go boo hoo about it, but these people are generally not getting paid to write OSS, so nobody can make them do something they think is inconvenient.

Re:An explanation...

[slamb]

But it's not that RPM *lets* you do package-centric management - rather the issue is that .deb *requires* it.

I disagree. The issue is that Debian requires you to do it a certain way. They could still do this if they used RPM. They have many other packaging rules that aren't enforced by the format, so I don't see any problem with one more.

They could additionally say "don't install non-Debian packages on a Debian system" and come up with a simple way to stop people from accidentally breaking this rule. (Perhaps requiring a dependency on a "debian" virtual package, with a "--non-debian" option to override.) Thus, they could share the toolset of the RPM world without compromising their project's goals.

Providing source installed would make like easier

[ras]

There are lots of conflicting posts here.

Some say Debian stable is too old to be useful. Near the end of stable's life I agree. It becomes difficult to buy hardware Debian will run on. Upstream authors stop answering your questions because you are running a 3 year old version they have forgotten about.

Some say the wouldn't run anything bar stable on their servers. I agree. After having installed Red Hat patches that broke my production servers, it is nice to use a distribution that knows what stable means: only bug fixes thanks.

Some say unstable is the answer to out of date software. Well it is, but I expect a distribution to just work. Unstable doesn't. Its fine if you just want to tinker, but if you want to earn your bread and butter on it - well it was too much pain for me.

Some say you can combine packages from unstable and stable. You can - but be prepared to have most of unstable dragged in as soon as you install something that requires a newer version of libc. This is not a tolerable solution for servers.

The ideal solution is a mix of stable and unstable. To make it work you have to re-compile the unstable software on stable - this avoids the library problems (such as libc). Mostly this just works - but sometimes it requires substantial effort by a programmer. Either you have to put this effort in yourself, or rely on a third party like www.backports.org, and www.apt-get.org, or bunk2, or ... well there are so many of them you can tell it is a real problem faced by a lot of people.

This is where allowing source installs comes in. If apt-get allowed you to install from source, things would be easier. In other words, apt-get install-from-source package... downloaded, compiled, and installed just as seemlessly as apt-get install package... does, including downloading and install dependencies and build dependencies. This would immediately overcome the libc problem.

Do that, and introduce a new policy. The policy says: In order to get out of experimental and into unstable, your package must be able to be compiled and installed via apt-get install-from-source package... on stable. This is not the draconian requirement is looks like. Recall apt-get install-from-source will download, compile and install any build dependencies as well. So if you used cdbs and someone installed your package on woody, cdbs would be downloaded, compiled, and installed for the build.

Do that and volia! - you have solved maybe 80% of the "stable is out of date" problems. Well maybe - I assume that most people are like me don't care that a couple of packages on their system (those from unstable) don't get regular security patches.

If you want to move to 95+%, then that is possible too. You have to allow multiple versions of libc (and other libraries) to be installed side by side. This is possible (I have have done it). Do that and I would be in distro heaven.

If read all the posts here the "stable is too old" - "use unstable" - "can't/won't use unstable on servers" is the most common thread. Isn't it worth spending some effort to fix that?

Debian to old?

[BrokenOne]

Why not just use the new Xandros 3.0? Right now am using Xandros 2.01 and so far its debian made easy and its still debian with the stuff that you "desktop/server" users want. os?