Re: A silly question
2013/3/22 Yasha Karant ykar...@csusb.edu [...] I take it that I am correct in one regard: there is no CentOS equivalent using SuSE Enterprise as TUV? (CentOS as I understand the situation does not have paid professional developers, unlike SL or the Princeton distributions, but relies upon volunteers, many of whom are in fact computer programming professionals.) I have not found one. [...] As already mentioned, there are no source RPMs for SLES (main and updates) available without restrictions. So rebuilding is normaly not a big deal (in terms of infrastructure and tools that need to be used), but you need free access to the sources. If sometime in the future they provide free access to the sources, there will be a rebuild as well. Regards Thomas -- Linux ... enjoy the ride!
Re: A silly question
On Thu, Mar 21, 2013 at 12:11 AM, Yasha Karant ykar...@csusb.edu 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.
Re: A silly question
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 nka...@gmail.com wrote: On Thu, Mar 21, 2013 at 12:11 AM, Yasha Karant ykar...@csusb.edu 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
Re: A silly question
On 03/21/2013 12:11 AM, Yasha Karant wrote: ... 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? The answer to your question is very simple, and I'll answer it by asking you a question: where are the publicly available sources for current SLES/SLED and updates? Source is easily available through subscription channels (which meets the letter of the GPL; the GPL does not require public distribution, but it only requires distribution (or a written offer to distribute) to those to whom binaries are distributed) if you're a subscriber, but if you're not a SLES/SLED subscriber, where are the sources to the updates? The OpenSuSE source is easy, but OpenSuSE is to SLES or SLED as Fedora is to TUV EL, or at least close. To the best of my knowledge, there is no SuSE Enterprise clone equivalent to the SL or CentOS clones of TUV EL. There is a simple reason for that. And the answer is again 'where are the publicly available (not requiring a subscription) sources for SLES or SLED (and, most importantly, updates) found?' If source were publicly available, there would be rebuilds out there; the lack of rebuilds is pretty telling. Google for 'SLES rebuild' and see what you find. The fact of the matter is that our favorite upstream vendor goes beyond the requirements of the letter of the GPL and makes the source publicly available, not requiring a subscription to access. Now, it's been a while since I've looked for a public source distribution site for SLES/SLED sources, but I could not find it when I last looked, which was about a year ago when I was beginning work on figuring out which distribution to use for our three SGI Altix systems; I settled on rebuilding CentOS 5 from source on IA64, since I could not find publicly available update sources for SLES 11 (which is supported on IA64, for a substantial cost that I can't afford) anywhere. Sure, I can get SLES 'for free' for trial use, but that only gets you the 'service packs' and not the continuous updates (or the source for those updates) unless you pay for the subscription. SLC5.4 (SL CERN) was available on IA64 (that's the last version made available, too), and I used that as a bootstrap to rebuild CentOS 5 on IA64 from source, and I'm running CentOS 5.9 on IA64 now. And there is of course the SL-documented reason that someone else in-thread has already pointed out.
Re: A silly question
On Thu, Mar 21, 2013 at 01:51:33AM -0400, S.Tindall wrote: On Wed, 2013-03-20 at 21:11 -0700, Yasha Karant wrote: why did SL -- ... -- select to use the present TUV instead of SuSE enterprise ... You're right, it is a silly question. Or is Google broken again? https://www.scientificlinux.org/documentation/faq/general1 The link does not really answer the question, or only answers the FermiLab side of it. From the Brookhaven Lab (and TRIUMF) side, this selection happened very early on. We have settled on Red Hat Linux (without and well before the E and TUV nonsense) fairly quickly around the time the first dual and quad Pentium Pro machines came out. This must have been around 1998 time frame. These dual and quad Pentium Pro machines were clocked at around 200 MHz and cost a fraction of our massive Silicon Graphics UNIX (IRIX) machines, had about the same CPU performance for our physics applications, but with more RAM and with the 100Mbit ethernet. Stability was about the same as the SGI machines. So obviously, we switched from IRIX to Linux as quickly as we could port our software to run on Linux (porting from 64-bit IRIX to 32-bit Linux, how is that for progress?) Why Red Hat? There were other contenders at the time. We certainly had Debian proponents in house. I think the Red Hat graphical installer and the kickstart function were the main deal makers. Once selected, we stayed with Red Hat Linux and in a way we still are with it. Somewhere along the line came the split into Fedora, TUV E Linux, SL/SLC Linux, CentoOS, etc Some people are not aware of the history from before this split and think that that was the beginning of history. For us it was just one more bump on the road. P.S. From the CERN side, I know the story is different yet again. Maybe Alan Silverman will write it up in a book some day. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: A silly question
I thank several correspondents for the historical as well as engineering insights into why TUV EL is used over SuSE Enterprise. As for the suggestion that this sort of question belongs on an enthusiast list -- I have found very few enthusiasts who can provide the engineering basis for a decision. I take it that I am correct in one regard: there is no CentOS equivalent using SuSE Enterprise as TUV? (CentOS as I understand the situation does not have paid professional developers, unlike SL or the Princeton distributions, but relies upon volunteers, many of whom are in fact computer programming professionals.) I have not found one. Yasha Karant On 03/21/2013 10:23 AM, Konstantin Olchanski wrote: On Thu, Mar 21, 2013 at 01:51:33AM -0400, S.Tindall wrote: On Wed, 2013-03-20 at 21:11 -0700, Yasha Karant wrote: why did SL -- ... -- select to use the present TUV instead of SuSE enterprise ... You're right, it is a silly question. Or is Google broken again? https://www.scientificlinux.org/documentation/faq/general1 The link does not really answer the question, or only answers the FermiLab side of it. From the Brookhaven Lab (and TRIUMF) side, this selection happened very early on. We have settled on Red Hat Linux (without and well before the E and TUV nonsense) fairly quickly around the time the first dual and quad Pentium Pro machines came out. This must have been around 1998 time frame. These dual and quad Pentium Pro machines were clocked at around 200 MHz and cost a fraction of our massive Silicon Graphics UNIX (IRIX) machines, had about the same CPU performance for our physics applications, but with more RAM and with the 100Mbit ethernet. Stability was about the same as the SGI machines. So obviously, we switched from IRIX to Linux as quickly as we could port our software to run on Linux (porting from 64-bit IRIX to 32-bit Linux, how is that for progress?) Why Red Hat? There were other contenders at the time. We certainly had Debian proponents in house. I think the Red Hat graphical installer and the kickstart function were the main deal makers. Once selected, we stayed with Red Hat Linux and in a way we still are with it. Somewhere along the line came the split into Fedora, TUV E Linux, SL/SLC Linux, CentoOS, etc Some people are not aware of the history from before this split and think that that was the beginning of history. For us it was just one more bump on the road. P.S. From the CERN side, I know the story is different yet again. Maybe Alan Silverman will write it up in a book some day.
Re: A silly question
On Thu, Mar 21, 2013 at 4:22 PM, Yasha Karant ykar...@csusb.edu wrote: (CentOS as I understand the situation does not have paid professional developers, ... ) I don't mean to clutter the SL mailing list with the info about CentOS but thought it was worth correcting the above post. Here is a blog by a core CentOS developer: http://centosnow.blogspot.com/2012/06/centos-project-release-times.html Please see #2. Akemi
Re: A silly question
On Thu, Mar 21, 2013 at 04:29:59PM -0700, Akemi Yagi wrote: On Thu, Mar 21, 2013 at 4:22 PM, Yasha Karant ykar...@csusb.edu wrote: (CentOS as I understand the situation does not have paid professional developers, ... ) I don't mean to clutter the SL mailing list with the info about CentOS but thought it was worth correcting the above post. Here is a blog by a core CentOS developer: http://centosnow.blogspot.com/2012/06/centos-project-release-times.html Please see #2. In fact, CentOS sponsors are listed right on the CentOS home page. For completeness, SL/SLC sponsors are the US DOE (via FermiLab) and the CERN member states (via CERN) (most of the EU, Russia, etc. Not Canada, sadly). SLC at least will continue to exist long term because the CERN LHC experiments require massive compute farms to analyze the data, and these compute farms require an operating system and negotiations with Red Hat on bulk licensing RHEL were not successful, last I know. Standing behind all this in the shadows are the 800lbs gorillas IBM, Dell, HP co who design and build said farms that require an operating system to be useful. So much for the myth that Linux is some Finn's weekend hobby project. -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
A silly question
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
Re: A silly question
Well this is sort of a question I answer at work all the time so I can tell you and I know there are sites and even Linux journal articles that explain it.Essentially both labs had their own in-house compiled versions of RHEL already for slightly different reasons but CERNs was called LTS (long term support) Linux and their original goal was to keep doing security patches to older RHEL versions after Redhat declared EOL ( End Of Life) on earlier versions of RHEL because their were essentially appliances built for labs that were it was difficult to migrate the apps to newer versions of RHEL and at the time Redhat only provided patches for a version for about 2 years for a version of RHEL if I remember correctly. The problem is when you install something in a facility connected directly or by proximity with less that two firewalls in between to a secure US government facility it must have all security patches for any installed software within a few months of the creation of the fix for the security hole. Also every new version of any OS needs to be evaluated for security prior to being connected. So for CERN since so many US Government agencies already used RHEL, and the time its was so popular in the US, that any one in the US who knew linux had used Reheat at some point; it was really the only choice.As a matter of fact I can remember in the late 90s being so synotimous with linux in the US that I was having a problem with compiling a program due to a Redhat only bug caused by a patch they put into gcc so I ran into 4 different software stores asking if they had any linux distro other than redhat, the first three store I was told no the 4th store told me yea we have plenty and then walked me over to a wall filled floor to sealing of various different redhat (box set v5.x pre RHEL) box sets with various different support add-ons like the "secure webserver" version that included a script on an additional 3.5 floppy to set up a openssl CA for you, but the were all redhat.Fermilabs motivation to choose RHEL over SuSE I'm not sure of but I suspect since they are funded by multiple countries and the nature of their research they may have also run into the US Government security rules and its just easier in that case to go with the flow than deal with the long drawn out process of getting a different distro certified.-- Sent from my HP Pre3On Mar 21, 2013 12:11 AM, Yasha Karant ykar...@csusb.edu 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
