As I said to Dave Hull, I have some clients who are still running RH 7.x servers, and I'm at a loss for what to tell them about upgrading. They can't afford RedHat's Enterprize subscriptions. If they could, they'd probably go with Microsoft because there are more prople who are familiar with it. (They don't have to go looking for linux geeks.) When RedHat changed it's policies they promised that they would document the procedure for upgrading from 7.x and 9.x to Fedora, but I've never been able to find those documents. I have had too many bad experiences with SuSE's package updates (particularly KDE) to recommend the downloadable version for a server. I feel the purchased version is not current enough given the price, and I would not be comfortable recommending it given the quality of the downloadable version. Gentoo is nice, but either you let it get behind or you risk upgrades that will break things. The etc-update system does not adequately discriminate between files that are normally customized for the local installation and files that are not usually changed by end users, leading to a lot of work sorting out configurations every time you update. Gentoo also has wierd, non-standard configuration issues - like the DHCP client over-writing the NTP configuration by default. Mandrake is a good desktop distro, but I've never run it as a server, and there are issues with packages such as not participating in KDE's binary distributions, not making bug-fix updates available, update mirrors being chronicly unavailable, etc. I mean to try Debian, but am reluctant to rely on source code packages without a package manangement system. It's not clear to me that you can do a complete debian install and stay within the apt system. Can you? I'll be interested in the list's comments on this, and other suggestions.
On Thu, 18 Nov 2004 11:29:16 -0600 Jonathan Hutchins <hutchins@tarcanfel.org> wrote:
As I said to Dave Hull, I have some clients who are still running RH 7.x servers, and I'm at a loss for what to tell them about upgrading.
They can't afford RedHat's Enterprize subscriptions. If they could, they'd probably go with Microsoft because there are more prople who are familiar with it. (They don't have to go looking for linux geeks.)
When RedHat changed it's policies they promised that they would document the procedure for upgrading from 7.x and 9.x to Fedora, but I've never been able to find those documents.
Just update them to Fedora. I would suggest a reinstall vs an upgrade. There always seems to be an issue or two with upgrading and if these systems are setup sanely there isn't much of a time difference. --------------------------------- Frank Wiles <frank@wiles.org> http://www.wiles.org ---------------------------------
On Thursday 18 November 2004 11:29 am, Jonathan Hutchins wrote:
I have had too many bad experiences with SuSE's package updates (particularly KDE) to recommend the downloadable version for a server. I feel the purchased version is not current enough given the price, and I would not be comfortable recommending it given the quality of the downloadable version.
I'm just going to touch on this portion of your email. SuSE's packages are very well tested, and I've never had a problem with them. Even when getting the KDE updates. Now, I HAVE had some problems with KDE updates out of the supplemental tree. But if you look at their readme, those packages are provided out of kindness to the SuSE community. They aren't nearly as well tested; in fact, they are the packages that are being tested for the next SuSE release. If you've had update problems using these packages, well, you get what you paid for. If you use those packages, you should report any problems you find. You've effectively volunteered to be a beta tester when you use those packages. Regarding price, the Enterprise version (such as SLES 9) is quite expensive. I don't blame you for not recommending the downloadable version for a server usage. I certainly wouldn't use it. And if you feel the Enterprise versions are too far behind, why not just run the Professional version of the desktop product? 9.1 Pro is incredibly stable, and reasonably up to date for being over 6 months old. 9.2 is available now, and the price isn't all that bad either. You can get the 'upgrade' version for only $60. It comes with a printed Administration Guide, 5 CDs and 2 DVDs. 32 bit and 64 bit editions are in the same box, although to install the 64bit edition you must use the DVDs. If you pay for the 'full' version, the price jumps to I believe $90, and in edition to what you get above you also get a very nice printed Users Guide. Yes, you can buy the 'upgrade' version and do a full install. Lots of people like the printed manuals and I think the inclusion of those alone make the product worth $60-$90. Rich
Jonathan Hutchins wrote:
I mean to try Debian, but am reluctant to rely on source code packages without a package manangement system. It's not clear to me that you can do a complete debian install and stay within the apt system. Can you?
I think you criss-crossed Slackware with Debian. Debian has a full package management system with a full installer that will even auto probe hardware and partion for you. It also installs some binary kernels stuff for you and configures X. (This is the new installer I'm talking about.) The Debian package management system (apt) is the one to which all others are compared. Slackware has a small package management system that uses simple tar.gz files. I have never run Slackware; in our LUG, atleast Wade Wassenburg does. Debian has my vote for the best reliable to flexible ratio in a distribution -- but not the prettiest. The other-mentioned SuSE Enterprise Linux Server 9 has some wonderful GUI tools and it has 5 years of upgrade protection but its plagued by the standard released-based restrictions. We're trying to run terminal servers off of it and are faced with the prospect of building and maintaining RPM's in the long term ourselves. (Not fun.)
--- Jason Clinton <me@jasonclinton.com> wrote:
Jonathan Hutchins wrote:
I mean to try Debian, but am reluctant to rely on source code packages without a package manangement system. It's not clear to me that you can do a complete debian install and stay within the apt system. Can you?
I think you criss-crossed Slackware with Debian.
Debian has a full package management system with a full installer that will even auto probe hardware and partion for you. It also installs some binary kernels stuff for you and configures X. (This is the new installer I'm talking about.) The Debian package management system (apt) is the one to which all others are compared.
Slackware has a small package management system that uses simple tar.gz files. I have never run Slackware; in our LUG, atleast Wade Wassenburg does.
I've run Slackware up to 9.0. The packaging system isn't as simple as tar.gz (you can't just throw any old tar.gz at it and expect it to install properly), its a little more complicated than that, but still less complex than other installers including Debian. Slackware also has the feature of storing all its install records in plaintext files so you can grep them quickly and easily. Having said all that, while I've not been able to install Debian properly in the past (3.0_rc0), Debian's apt and to some extent even RPM would be a little better for the average user given that they're probably going to be needing GUI frontends to access the package database. I don't recall a GUI frontend to "installpkg" in Slackware. Also, I think you've criss-crossed Slackware with Gentoo. Slackware packages are all binary tar.gz packages, not source tar.gz files. You do all your own compiling in Slackware. ===== "There ought to be limits to freedom." -- George W. Bush, Austin Press Conference, May 21, 1999 __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com
On Friday 19 November 2004 08:22 pm, Leo Mauler wrote:
Debian's apt and to some extent even RPM would be a little better for the average user given that they're probably going to be needing GUI frontends to access the package database.
Given that the RPM Database is one of the heaviest loads on most of the RH systems I've run, I wouldn't want to use a GUI to manage it if there was any way to avoid it. I don't install GUI's on servers anyway. More and more utilitilities are senselessly compiled to require X, but I either avoid them or install the bare minimum and never run it.
Gentoo is nice, but either you let it get behind or you risk upgrades that will break things. The etc-update system does not adequately discriminate between files that are normally customized for the local installation and files that are not usually changed by end users, leading to a lot of work sorting out configurations every time you update. Gentoo also has wierd, non-standard configuration issues - like the DHCP client over-writing the NTP configuration by default.
I use Gentoo on all my servers (and several workstations) and once the Portage system (and its new /etc/portage configuration) is properly understood and put into place the management of the _cfg files is very logical and effecient. I agree that Gentoo does do some strange things (like the named package using /etc/bind and then having /etc/init.d/named (versus /etc/init.d/bind which seems more logical to me)) but I think its positives outway its issues. Positivies (in my opinion) like; forums.gentoo.org, very active support mailing list, very active IRC channel, the portage tree is updated daily, package management as a whole works very well, excellent collection of install and configure docs. I think it becomes the 'do what you know' scenario, my meaning is that if both you and your client are familiar with Redhat - stick with that and use Fedora. Regards, Steve
On Thursday 18 November 2004 01:53 pm, Steven Hildreth wrote:
I use Gentoo on all my servers (and several workstations) and once the Portage system (and its new /etc/portage configuration) is properly understood and put into place the management of the _cfg files is very logical and effecient.
I really have to disagree with you on this. I run three gentoo servers, and having to sort through the files that etc-update presents has caused me endless headaches. Many of the files etc-update handles are init scripts that would require a very advanced knowledge of the system to understand, let alone customize. These files should almost always be kept as distributed, and updated when the related packages are updated. Mixed in with these are essential configuration files that do _not_ change with package updates and which contain information essential to the local configuration, files which if replaced with the package updates will render the system useless. These files should only be updated if there is a _major_ change in the configuration method for a package. (/etc/fstab comes to mind as one that I've had trouble with.) I think this is one of the biggest disadvantages with gentoo, as it can be easy to miss one of the files that must be updated with a package change, or accidentally overwrite a file that should not be changed. In my experience, RPM based systems do a much better job of determining what files should be updated and what files should not.
As I stated, if you configure and use Portage properly you won't have these issues; http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3&chap=1 or; 'man 5 portage' The part in particular is to use portage CONFIG_PROTECT and CONFIG_PROTECT_MASK Again I understand it and my updates are very fluid, simple and painless. Just because you don't either 1) Like it or 2) Understand it doesn't mean its worthless. The level (and quality) of results returned by something is near linear to the level (and quality) to the input put into it. If used properly Portage is very powerful and works very well. Regards, Steven On Thu, 18 Nov 2004 14:14:55 -0600, Jonathan Hutchins <hutchins@tarcanfel.org> wrote:
On Thursday 18 November 2004 01:53 pm, Steven Hildreth wrote:
I use Gentoo on all my servers (and several workstations) and once the Portage system (and its new /etc/portage configuration) is properly understood and put into place the management of the _cfg files is very logical and effecient.
I really have to disagree with you on this. I run three gentoo servers, and having to sort through the files that etc-update presents has caused me endless headaches.
Many of the files etc-update handles are init scripts that would require a very advanced knowledge of the system to understand, let alone customize. These files should almost always be kept as distributed, and updated when the related packages are updated.
Mixed in with these are essential configuration files that do _not_ change with package updates and which contain information essential to the local configuration, files which if replaced with the package updates will render the system useless. These files should only be updated if there is a _major_ change in the configuration method for a package. (/etc/fstab comes to mind as one that I've had trouble with.)
I think this is one of the biggest disadvantages with gentoo, as it can be easy to miss one of the files that must be updated with a package change, or accidentally overwrite a file that should not be changed. In my experience, RPM based systems do a much better job of determining what files should be updated and what files should not. _______________________________________________ Kclug mailing list Kclug@kclug.org http://kclug.org/mailman/listinfo/kclug
participants (6)
-
Frank Wiles -
Jason Clinton -
Jonathan Hutchins -
Leo Mauler -
Rich Edelman -
Steven Hildreth