On 23 Feb, L. Mark Stone wrote:
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.
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