Forum OpenACS Q&A: OpenACS on Debian pros and cons...
I concider switching from 8.0 to Debian...
Now, if you're not sure which distro you like better, here are a few notes from my evaluation of RH9 over the past few days.
- More consistency of system file locations
- Single, very good packaging system (apt)
- Easier to find packages if they exist.
- System scripts make more "sense" to me.
- Keeping system up to date with patches is free.
- One distro for desktop and server.
- Fewer packages (though you can use alien to convert .rpm to .deb, you always run the risk of breaking something)
- Stable distribution of Debian lags way way behind.
- No official vendor hardware or software support
RedHat 9 Pros:
- More packages
- Packages are MD5 signed
- Nice graphical admin tools (you may not care)
- Good integration with Gnome and KDE desktops
- Multiple packaging systems (up2date, yum,apt) are confusing.
- RedHat has only just now got automatic dependency resolution with apt and yum.
- RedHat patches the heck out of their kernels. I'm assuming they do QA testing before they release such heavily patched kernels, but even so they get far less testing than a stock kernel.
- Future of "free" Red Hat is in question right now. "Free" Red Hat is now called "Fedora Core". Red Hat will *not* offer support for Fedora. See http://fedora.redhat.com/ for more information. Basically they are trying to create a Debian-like system where many people could contribute packages. Fedora will be the proving ground for new technologies to eventually go into ES/AS.
The *only* reason we would switch to RH is support. Vendors are getting tighter and tighter about support for Linux, and who can blame them? It's not enough for them anymore for you to just tell them "I'm running Linux, kernel 2.4.21".
Actually, I just thought of one more reason to use RH--if you purchase a server from a vendor that offers RH preinstalled. If that is the case, then you should stick with RH. We just went through a horrible time with a vendor trying to figure out what was wrong with one of our servers. Fortunately he never said "well I only certify my boxes with RH", but a large vendor (Dell? HP?) definitely would.
In another case I replaced a default RH install with Debian on another server at a remote colo, and then RH released a technical advisory for the RAID controller on the box. They offered to send a tech to flash the firmware on the card and update the SCSI driver to go with it. When the tech arrived he realized that if he tried to boot the box with the RedHat patch CD he very likely would render the machine unbootable because the machine didn't actually have RH on it. Fortunately we realized this in time.
Don't get me wrong, I LOVE Debian. I'd hate to leave it, but the Red Hat install base is reaching critical mass.
The Fedora thing really worries me. Lots of RH advocates are saying "don't worry, it is just opening up the development and Fedora packages should always work on AS/ES, and vice versa", but time will tell. Before Fedora I wasn't worried because you could always guarantee that the "Free" and the "Pay" versions of RH were pretty close. Now I think Fedora is going to zip way out in front of AS/ES.
I've rambled enough.
Fewer packages? I have currently 16651 available packages. I haven't counted Red Hat's packages, but last time I checked it had much less than that. Now if you include packages built by who-knows-who-and-how-that-can-screw-up-your-system...
"No official vendor hardware or software support". Not true. HP is one vendor I know that certifies its hardware on Debian. In fact, Debian is the Linux development platform at HP (http://lwn.net/2001/0517/a/hp-deb.php3). More vendors _in the U.S._ likely support Red Hat though.
About MD5 sums for packages, at least on sid packages have their MD5 sums.
For "nice graphical admin tools", pretty much all of the good admin tools of other distributions have been packaged for Debian, so if you want them, just install them. I packaged the PostgreSQL administrator graphical app that Red Hat wrote, for example, although it's not really an OS admin tool (http://packages.debian.org/unstable/misc/rhdb-admin.html)
Roberto and Jeff,
Thanks for that information. Let me clarify some things.
Roberto said: HP is one vendor I know that certifies its hardware on Debian. In fact, Debian is the Linux development platform at HP
This is really good information since I consider HP right up there with Dell in terms of quality of equipment.
As far as the packages question, I think what I meant was that if I need a binary of a particular piece of software that is not in the Debian repo the chances of finding a .rpm are a *lot* higher than finding a .deb.
Jeff said: I recently installed oracle 9i on debian and it went at least as smoothly as redhat and thus far have had no problems at all with it while testing. So even for oracle I think debian would be a reasonable choice.
Maybe, but Oracle's official stance on that is that they *will not honor a support contract* if you are not on a certified platform, and Debian is not certified. I would LOVE to get Debian certified, and I think that if Oracle were to wake up they would realize that Debian is probably the most stable of the Linux distros out there. I have no idea how to go about doing that, if anyone has any ideas about who to talk to, please speak up.
Becoming Oracle-certified costs, I suppose that is the issue here. OTOH RedHat 8 is not Oracle-certified either, only a RHES with a particular kernel version. (There's a bunch of other Linuxes certified for Oracle including Suse SLES, some Chinese distro etc. )
i'm also looking at other platforms. debian seems similar to freebsd in package management and reputation for stability... anybody have any experience with it and oacs?
OpenBSD is the easiest to secure, FreeBSD has more capabilities than OpenBSD in terms of ports and will support slightly more hardware - they are faster at supporting new stuff.
I have run OpenACS on Linux in the past and not been impressed.
However, I recently loaded Debian 3.0r1 on a new system, and put everything on an XFS partition (XFS is a journaled filesystem from SGI); and the performance increase can not be denied; most likely due to Linux caching everything it can up to the amount of RAM it has (OpenBSD has a fixed amount you can change at boot time for use in caching). It was easy to install as well.
I have not done any stringent performance tests, but running Postgres on XFS seems to speed up vacuums and other tasks.
My guess is that Oracle probably will still give you support whether your Linux distribution is "certified" or not, but yes, they maintain their out to use "you're not running Red Hat Advanced Server" as an out if they can't figure out your problem our don't want to deal with you. Seriously though, Oracle (126.96.36.199 anyway) mostly just works. If I remember correctly, our few support requests (TARs) to Oracle have been submitting the occasional (rare) mysterious Oracle trace file for them to tell us what the heck it means.
Oh and using Metalink - Metalink is actually very useful, for serious Oracle work you really need it to look through all the bug reports, etc. etc., even if you never open a TAR asking for help.
I just started using Red Hat (7.3) again more extensively, and it is ok too (although if not for yum and the rpm version of apt-get I would strongly consider ditching it yet again). But the currently playing out "consumer" vs. "enterprise" version splitting is indeed concerning. There was some excellent discussion about this Beowulf list in the last few months.
I may have some details wrong, but I think now if you do buy the "enterprise" Red Hat version, in order to get the support - which is the only reason to buy that version - you have to sign a license that says you will not ever install the expensive enterprise version on machines you haven't bought another license for, nor will you give to anyone else to do so, etc.
In practice, it is perfectly feasible to download all of Red Hat's source rpms for their enterprise version (which they make availabe for download as per the GPL; they do not make the binary packages available) and compile it yourself. But legally speaking, once you go down the path of buying the "Red Hat Advanced Server" license and signing that support contract, you lost that option.
Oh yeah, if it was up to me, I'd use Debian for everything, barring some much more compelling reasons than "Oracle Corp. says to use Red Hat". Like say, running Linux on an embedded microcontroller that's just too small for Debian, that sort of thing. :)
Of course, if you have multiple systems you would only do this once and then move the files over.
You would not lose data or configuration information, but would have to reboot.
Here's what Tom Lane had to say about the issue:
"Journaling metadata is good. Journaling file contents is redundant --- turn that off if you can. (Of course, if there is anything other than Postgres files on the same device, you may not want to turn off contents journalling..."
For ext3 that means mounting the /var/lib/postgres (or wherever your postgres data is stores) with the option "data=writeback".
I've only heard great things about SGI's XFS, especially its superb ACL features.
Postgres runs like a charm on all of my BSD machines, and I had very little trouble setting up OpenACS (aside from the known little patches to get a few models compile). This, unfortunately, may change with AOL Server 4 -- the stock distribution does not compile at all -- there seems to be just too much Linux-ism (no flames, please) in it (NB: fi your experience differs -- please let me know. I think I saw a few posts mentioning AS4 on OSX which is FreeBSD with Mach kernel).
FreeBSD does not have journaled FS, but it has a feature that maybe better in some circumstanese -- soft updates. I am not sure, however, how it affects Postgres -- never benchmarked it nor seen any benchmarks on it.