"Redhat only provided patches for a version for about 2 years for a version of RHEL if I remember correctly."
Although now RHEL 5 and RHEL 6 have (at least) 10 year lifecycles. Slightly OT but somewhat relavent I think. On Thu, Mar 21, 2013 at 8:08 AM, Nico Kadel-Garcia <[email protected]> wrote: > On Thu, Mar 21, 2013 at 12:11 AM, Yasha Karant <[email protected]> wrote: > > This is perhaps a silly question, but I would appreciate a URL or some > other > > explanation. > > > > A faculty colleague and I were discussing the differences between a > > supported enterprise Linux and any of a number of "beta" or "enthusiast" > > linuxes (including TUV Fedora). A question arose for which I have no > > answer: why did SL -- that has professional paid personnel at Fermilab > and > > CERN -- select to use the present TUV instead of SuSE enterprise that is > RPM > > (but yast, not yum) based, and has to release full source (not > > binaries/directly useable) for the OS environment under the same > conditions > > as TUV of SL? SuSE is just as stable, but typically incorporates more > > current versions of applications and libraries than does the TUV chosen. > > Any insight would be appreciated. If SuSE had been chosen (SuSE > originally > > was from the EU and thus a more natural choice for CERN), what would we > be > > losing over SL? > > To the best of my knowledge, there is no SuSE Enterprise clone > equivalent to > > the SL or CentOS clones of TUV EL. > > > > Yasha Karant > > These tend to go on, so keep it very short. > > YaST is not my friend: it was very poor, and dangerous to use, when I > used it with SuSE 9.x and I've not heard of it getting better. Neither > is SuSE's practice of bundling the patch files for SRPM's into > tarballs, which have individual patches activated or not iin a yes/no > fashion in the .spec file. This makes editing and source controlling > htem very painful. And the licensing agreements between Novell (the > owners of SuSE) and Microsoft are very dangerous, and provide no > patent coverage for free or open source repackagers. > > I could go on, but that's plenty. > -- Thanks, Jamie Duncan @jamieeduncan
