SuSE vs. RH vs. BSD (Slightly OT)
Our local LUG is having a panel presentation (friendly debate) on SuSE vs. RH vs. BSD. I've been volunteered to be the SuSE presenter. I feel I've got good ammunition regarding SuSE's strong points and BSD's weak points, all based on personal experiences. But I really have next to no experience with RedHat. So, I'm looking for technical areas where I can contrast SuSE against RH. If anyone has migrated from RH to SuSE, it would be nice to know what drove that decision for example (movement in the opposite direction is also of interest!). If your response would help other SuSE users, please reply to the list. If your response is truly OT for this list, feel free to reply to my email address directly. Thanks! Mark -- _________________________________________________________ A Message From... L. Mark Stone Reliable Networks of Maine, LLC "We manage your network so you can manage your business." 477 Congress Street Portland, ME 04101 Tel: (207) 772-5678 Web: http://www.rnome.com
I don't know whether it's OT, but I'm also interesting in it. We move from RedHat to SuSe (and I'm not speaking about the entreprise version) when RedHat decided to give up with the redhat "for-the-public" version and launched the fedora project: fedora was to new and 6 months is too short for us as a release cycle. SuSe was the distribution with a free-of-charge version plus an entreprise version when support and certification were importants. Also we are novell client and will surely move the novell services on linux: we could have "one" unique distribution for everything using both professional and entreprise version. Those are not really "technical" considerations. The only technical thing is that I never had a "depedency" problem using yast (and for this reason never feel the need to use apt-get :-) for the last 4 years, i.e since I started putting suse on the servers. With RH, I remember various cross depencies problem and, starting from RH8, some crash from time to time of the rpm tool that required the deletion of some files and the rebuild of the database nothing else unfortunately Gaël "L. Mark Stone" <lmstone@rnome.com> wrote on 23/02/2005 15.50.53:
On 23 Feb, L. Mark Stone wrote:
3 things I would suggest mentioning, if you haven't already listed them.. are: 1. Suse's chkconfig system is a lot better. I like the ability to add requirements for starting/stopping services and it figuring out the order properly. RH's system of just putting the S and K numbers you want it to be doens't work well.. we had a problem at work for a long time where the defaults in the autofs4 init script stopped autofs after nfs.. which clearly didn't work. :) Of course, the downside to that for suse, is that if you don't have what it expects in there, it'll default to something really low, like S01. 2. Suse's package naming scheme on the amd64/x86_64/ia64e/em64t/etc platform is far, _far_ better. I've supported both SLES9 and RHEL3 on opteron hosts, and RH's system annoys me. Suse did the right thing by making 32bit compativble packages with names like glibc-32bit-<version> whereas RH only seperates them by the arch bit in the filename... i.e. SLES9: glibc-2.3.3-98.28.x86_64.rpm glibc-32bit-9-200407011233.x86_64.rpm (of course I'd love a matching version there instead of the date stuff.. but it works). RHEL3: glibc-2.3.2-95.27.i686.rpm glibc-2.3.2-95.27.x86_64.rpm It gets really fun when querying rpm... SLES9: rs-workstation SUSE-CORE-Version-9 {570}$ rpm -q glibc glibc-2.3.3-98.31 rs-workstation SUSE-CORE-Version-9 {571}$ rpm -q glibc-32bit glibc-32bit-9-200407291106 Pretty straightforward. RHEL3: preto066 RPMS {572}$ rpm -q glibc glibc-2.3.2-95.27 glibc-2.3.2-95.27 aroo? :) What if you upgrade one and not the other.. which is which? And I found that it's harder to include specific 32bit packages in a kickstart install. On sles, for autoyast, I just add the package.. like libelf-32bit (I created that myself btw.. it was very simple to do). On RHEL3 I have to install the 64bit.. because, AFAIK, the only way to get the 32bit package to install is to list the same package twice and it installs the 32bit one if it sees the same package again and a 32bit one exists. If anyone knows a better way, let me know. 3. I find it cleaner to add new packages into an update tree for SLES then RHEL. Not only is it easier (I just drop in a new rpm, and rebuild the descr file in that path) but I can keep my initial SLES9 tree intact, and add new rpms in a completely new path (though initially figuring out how to get a seperate update path working properly was kinda tough). For RHEL, you have to replace the rpm in the existing RPM tree, and recreate the genhdlist as well as the newer pkglist files too. If I leave the old rpm in place, it causes conflicts.. so the RHEL tree becomes changed over time and isn't the same as when I first installed the files on the NFS server. Of course, there could be a way to add rpms from a clean path for RHEL too... but I haven't seen how to do that. -- Mike Marion-Unix SysAdmin/Staff Engineer-http://www.qualcomm.com [Burns is a vampire, he's talking over an intercom] Burns: "Welcome, come in!... Ahhh fresh victims for my ever growing army of the undead." Smithers: "Sir you have to let go of the button." Burns: "Oh, Son of a B-" [Door bangs open] ==> Simpsons
participants (3)
-
g.lams＠itcilo.org -
L. Mark Stone -
mmarion＠qualcomm.com