See below. > -----Original Message----- > From: Post, Mark K [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 27, 2003 8:41 PM > To: [EMAIL PROTECTED] > Subject: [LINUX-390] FW: SLES 8 > > > Ken Hall said: > >The downside (I've found) of the SuSE philosophy on > maintenance of the SLES > >series is that they never (normally) release a new VERSION > of a product to > >fix a problem. They just retrofit patches to the version > supplied with the > >distro. > Hmm. Sounds almost like IBM's philosophy of shipping PTFs > and APARS for the > current release. Which would you say has more risk > associated with it? > Installing a patched version of the current release, or > installing a brand > new release? I would (usually) prefer to install the patched version, > myself. A lot of things can change between releases of a > package, including > inter-product dependencies, configuration file changes, startup script > requirements, and on, and on. I would rather be relatively > sure that the > only thing different between what I'm running now and what > I'm going to be > installing is that a bug was squashed. >
If it were possible to fix the problems entirely with patches, I wouldn't care. This is what IBM does. When they find a problem, they regress back to all previously supported releases and release different PTF's for each release. Those fixes are granular, connected via SMP, and theoretically equivalent to each other. But SuSE doesn't have the resources to deal with every product like this. Volatile products like Samba can get dozens of bugfixes between releases. So they fixate on the version released with the distro (whether it's good or bad) and then pick and choose the fixes they release. There has been exactly one upgrade to Samba since the CD, but 9 releases from the Samba team, with literally dozens of changes and fixes. What bothers me is that this is the ONLY support model they provide. As I've said before, when a new version of Samba comes out, an Intel RPM is typically available within hours or days. A 390 RPM is never (officially) made available. That's not the way support for 390 is structured. If the problem is bad enough, or enough users complain, they'll try to retrofit the fix. Otherwise, you're out of luck. > >This has been a major headache for products like Samba, > where the many bug > >fixes come fairly frequently in version/release upgrades. > The version of > >Samba that came with SLES7 was 2.2.0a, which turned out to > be just about > >unusable, so we had to "roll our own" versions of 2.2.5 and up. > I would be curious as to what you found unusable about Samba > 2.2.0a. I'm > still running that in production on some of my systems. From my > perspective, unless there are features in the newer versions > of a product > that you just cannot live without, you're better off > installing patched > versions of the current release. You can just about kill > yourself trying to > stay current with all the Open Source packages out there. > The "release > early and release often" development philosophy is good for > the community in > general. "Install early and install often" is probably not a > good idea for > a particular organization. > Well, 2 come to mind: 1) It stopped accepting connections at 50 users. 2) There was a problem with joining domains with smbpasswd. It couldn't find the DC. Both gone in later releases. > >Same thing with Openldap, and the latest version won't even > build properly > >on SLES7 because SuSE had to add patches to it that aren't > in the base > >versions yet. > This is one of the hazards you run into when you decide to > get away from > being a consumer of a package, and into the role of developer. It's > happened to me any number of times, and it's rarely been an > easy problem to > surmount. If it's important enough to me, I follow through. > If not, I > decide to try to wait for the next update from my distributor. > Except that with Open Source, it's often quicker to go pull the latest version from the developer and build yourself rather than wait for the support vendor to retrofit a patch. The Openldap problem is a Catch-22. There's a known bug in versions up to a certain point (please don't make me go look) where password changes don't replicate to slave servers. It was fixed several versions ago, but the SuSE-supplied version is about 4 releases older, and doesn't have the fix. The problem is that "officially" libtool (which is used to build shared libraries) and Openldap don't know about Linux/390, so SuSE patched them to properly recognize it. Unpatched versions don't build shared libraries because they don't recognize the architecture. So here I have to depend on for SuSE to fix the problem. (Disclaimer: I haven't actually gone to SuSE with this because we're in the middle of switching to Kerberos for password storage anyway, so the issue becomes moot soon. I'm just using this as an example.) > >There also seem to be product features disabled or "missing", such as > >Winbind in Samba, and quota support, sometimes because the > various required > >components aren't at the right level, or often for no > apparent reason at > >all. When this happens, there's almost no way to fix it and > stay within > >the "official" support scheme. > Things like this are usually options that can be selected at > compile-time. > You should have the source RPM for the package, so you should > be able to > tweak the spec file for it to turn those on, if you really > want them. You > may find out the hard way, though, that they were left turned > off for good > reasons. (Similar to the reasons that Red Hat didn't turn on > LVM in their > 7.2 platform.) Linux distributors are not interested in gratuitously > turning of functionality, since they'll usually get asked why > something > isn't available, when distribution xyz has it. (Again, take > Red Hat 7.2 and > LVM for example.) > Agreed, but I often find little logic in their choice of build-time options. Winbind left out of Samba, for example, and support for LDAP maps left out of autofs. No Kerberos server package at ALL. But that's because these are features *I* need, so I admit I'm biased. But then they include packages like cdrecord and ppp. Why? Does anyone care about these in a mainframe server OS? I suspect because they build cleanly without fiddling. > > Mark Post >
