Slashdot Mirror
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."
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.
O frabjous day! Callooh! Callay!
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
>> Techflock-flock onto the best bits of technology
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.
This is your sig. There are thousands more, but this one is yours.
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.
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
-- Is "Sig" copyrighted by www.sig.com?
I've been running Debian Unstable [and] it's every bit as stable as the Fedora install it replaced
/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.
.db files.
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
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
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.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
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.)