> You can't expect SuSE to read your mind. If you have a > support contract > with SuSE, then when you have a problem, ask them to fix it. > Even if you > don't think you will need the fix for long because you don't > plan to use > the broken software for much longer, getting the report in > helps others > too. > > Helping each other is an importand part of OSS. > > If there are significant changes in Samba 2.2.8 over 2.2.3 (and I > suspect there are), then that implies that for many users, > upgrading is > more than just "rpm --upgrade ...." Users who don't want those new > features won't bless the vendor who inflicts them on the user-base. > > It's not practical for a vendor to fit its release cycles with OSS > developers. IBM, on its software, controls development and release > cycles, and in splitting MVS into separater products all those years > ago, made the task a little easier. > > The Samba folk have a release cycle. > The Linux Kernel people have several: 2.0 (I don't think it's quite > defunct yet), 2.2, 2.4 and 2.5 streams. > > Then there are gcc, KDE, GNOME and many others, all with their own > schedults, sometimes depending others, sometimes not. > > Vendors take a snapshot of the world around them, put a selection > together and go through their testing cyycle. Following one, two or > three betas they figure they have something that works. > Maybe, and they > release it. > > Any time they introduce a new version of a package "because it's got > this great new feature," they risk breaking hundreds of thuousands, > maybe millions, of peoples' computers all at once. > > Red Hat has stuffed things up a time or two, and you can safely bet > there were lots of unhappy users complaining about it, even if tehy > hadn't paid for it. > >
You're absolutely right. After I wrote the previous comment, I gave it some thought and decided to open a support issue for the Openldap password replication problem. I'm curious to see what their response is. My problems with Samba went deeper than just nifty new features though. There were things that just didn't work that I can't remember off the top of my head. If SuSE was doing such thorough testing, they MIGHT have noticed that Samba caused the original kernel 2.4.7 to crash before shipping the CD's. That didn't exactly inspire confidence. > > > > > > >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. > > > I've never explored the reasons for Red Hat's configuration > choices, but > it's a fair bet that if Windbind failed their testing, they would not > make it part of the default package. Enrol in their Bugzilla > system and > see what you can find. > For the Linux/390 environment, I'm not dealing with RedHat, I'm dealing with SuSE. Actually, I prefer Redhat for the Intel side, and my relationship with them has been more productive. They don't lock everything up behind registration codes and support agreements. I picked up a fix for user password changing for Openldap from them and refitted it to the SuSE supplied package. Very helpful. But I have to work with what they want here, and that's SuSE.
