I like a stabel os, and both Slack and debian provide that. I may have been just as easily swayed by CentOS if i had have heard of it first. I am yet to try Cent/Redhat or even Suse enterprise Linux, so i can't make a comment on them, but i'm slightly turned off by the corporate influence, and as for now. Slackware and Debian are suiting me fine.

After using Debian I'm pretty angry I voted that it's more stable. Debian's okay (not my cup of tea) but the dependencies make it less stable in my opinion.

I agree, and sometimes you hit Debian-specific bugs.

I will admit, i have encountered bugs where i've installed software on Debian, and they haven't pulled in all the dependencies, but i don't regard that as a point against Debian in references to comparing it with slackware, since pkgtool doesn't pull in any packages.

My vote goes for Slackware.

While Debian 5 (Lenny) was a great version in terms of reliability, I find the current one to be an absolute regression. Debian 6 (Squeeze) was frozen before it should, and many "non critical" bugs were not fixed and eventually passed into Stable. Worse yet, many worrying bugs were marked as fixed because there were fixes available, but the fixes themselves are not currently included in Squeeze and the defective software remains in affecting the users.

The two first examples that come to my mind are a bug in PCmanFM that can lead to massive files destruction and a bug involving amule and wxwidgets that can cause memory exhaustion in a DoD style suicide. The PCmanFM one caused me a loss of some thousand of files, yet is marked as solved and has remained unpatched for more than 400 days.

Slackware has its own set of little bugs, but none of them is so disruptive, and I can live with them. The most annoying one I face is a segmentation fault that happens to XPDF when you pass many pages quickly under certain configurations. When you compare the current Stable releases of both distributions, you get newer apps and libraries in Slackware while having improved reliability.

Don't take me wrong, I used to really like Debian. I still think Debian security policies are among the best ones. However, Squeeze is not up to my demanded quality level nowadays, and I don't really care if Debian has the latest anti-DoD patches when amule stills DoD itself without assistance.

I voted for Debian as it's the underdog in this poll... but personally I regard Debian and Slackware as the two best distributions available.

As to outstanding bugs, I don't think there is any distro which releases 100% bug free. Debian admittedly have a lot more to deal with than Slackware, as they support many more architectures, desktop environments and have much larger repositories.

Does this looks outdated? http://slackware.com/changelog/

I have been using Debian for many many years before I switched to Slackware and I cannot vote either way, both seem tremendously stable to me. However, I have to say that Debian stable is definitively more outdated than Slackware and, if you go <stable>/Sid way you kinda lose a bit in terms of stability (however I don't recall having any problems caused by mixing stable and Sid.)

I was a longtime Debian user, that switched to Slackware. I would say that Slackware is both more up-to-date, and more stable. I just updated my Slackware 14 this morning, with Firefox 20, etc.

I used only Debian (and Ubuntu before it).
The original question is which is more stable. It probably depends a lot on your particular hardware and software configuration.
I installed Squeeze (Gnome) for my parents right when it came out. They havent used a computer before. But i had no stability issues whatsoever with that computer. Ever. It just works (i use only the stable repos on it).

On my home desktop i have Testing (mixed with unstable and even experimental, self-compiled packages here and there + self compiled kernels) and it runs 24/7, has a VM runing in the background permanently. Never had any non-self-inflicted stability issue with it despite the patchwork of packages from all repos (but i dont use third party repos, only for specific programs that dont exist in the official repos, the rest i recompile myself if i itch for a new version). Note that it has an AMD A8-5500 Trinity APU and i run the fglrx driver on it.

On my laptop i have largely the same setup (except its 32-bit and use only debian kernels on it). I carry it everywhere (i work on customer support/network administration) and i expect it to work perfectly stable when i open its lid (which it does).

Now, given the above, i can say that Debian IS stable (even when i mixed testing/unstable/experimental - i am agains mixing stable with anything except backports though). The dependency system is actually quite nicely designed and implemented + it has probably the largest repositories out there.

In my opinion, Debian and Debian based distros handle dependencies the worst way. Ignoring a dependency should be optional, but .deb based distros make this very hard. Even rpm distros handle this pretty well.

I couldn't disagree more. If you know what you are doing you can easily use the --{force,no-force}-depends or --ignore-depends= options of dpkg to install or remove packages without dependency errors. But the whole point of a dependency resolving package manager is to never leave the system in a broken state, otherwise dependency resolving would be pretty pointless. You actually never should have to do something like that if you aren't a developer (or have very special needs, in which case you either should learn how to create proper Debian packages or switch to a distro without dependency resolving).

No, with a Debian 'Gnome-session' installed try removing Nautilus without removing Gnome-session, it is very difficult. The 'ignore-depends' parameter does not work very well; at least for me.

In that case not the package management ssystem is at fault, but the package maintainers. The problem here is that they use meta-packages for ease of use. If you build up your Debian from the base install without using meta-packages this problem doesn't occur at all.
In short, this is a maintainer problem, not a problem that is caused by the package-manager.

Really? i'm skeptical, but will have to confirm this for my self. I will post my feedback on this in the following month approximately (Can't do it sooner due to being away for work.)