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!
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).
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.
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
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.
Six month release cycle, new packages, desktop orientation.
Peter
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?
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.
Save your wrists today - switch to Dvorak
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.
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.
/etc, local custom package distribution is a cinch, and the 'never-upgrade-only-update' mentality saves me a ton of work.
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
But faster? Probably not.
[1] Well, some parts of AIX, the rest is IBM's gift to admins from the deepest bowels of hell...
--
I Hit the Karma Cap, and All I Got Was This Lousy
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.)
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.
- Raynet --> .
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.
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 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.
" 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.
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.