From: Lamar Owen lowen@pari.edu
Referencing SL3 and CentOS 3 (as I haven't run SL4 as yet) there were some scientific applications and some Java stuff, eclipse for one,
You do understand the redistribution issues with Java, correct? It's a Sun problem (a typical thorn for Red Hat in general), not a Red Hat one.
part of cluster suite for another, included. Lessee, https://www.scientificlinux.org/distributions/30x/features/ is the reference. GFS, Eclipse, Cluster Suite, OpenAFS, ksh93, a set of 'tweak' RPMs (my favorite being the serial console tweak RPM).
Red Hat is pushing to get GFS in the stock kernel. They bought out Sistina for a reason, to keep it GPL. These things don't happen overnight. ;-> GFS was introduced as an add-on, and probably will until it is in the stock kernel -- Red Hat is trying to avoid heavily patching the kernel nowdays (for various reasons).
As far as OpenAFS, I assume you mean the server? Or you don't like Red Hat's included client in the kernel? As always, make a Bugzilla request if you want something.
For SL4, the doc is at https://www.scientificlinux.org/distributions/4x/features/ and includes fewer addons. OpenAFS is the biggest of these, I guess.
And I too have deployed OpenAFS. The server is 100% userspace, so it shouldn't be too difficult to get it included, at least in Fedora Core (possibly the next RHEL5).
Once the cluster suite and eclipse are available they probably will be rolled in.
Eclipse is now in Fedora Core 4. One thing to always remember that Eclipse's licensing is outside the control of Red Hat, and is IBM. It is also released under a non-GPL compatible license by IBM, and is similar in restriction to Sun/Mozilla licenses, so I'm sure Red Hat was hesitant to include it before.
The Fermi version of SL 3 had included a packaged JRE and was very attractive for that, but later releases have not had that and rather have pointers to download from sun.
It is illegal to redistribute the JRE for Linux without a license. Again, see Sun for details. ;->
Pine also is in the SL dists.
Pico/Pine also changed licenses awhile back and is considered "non-free." Nano replaced Pico, can't remember what replaced Pine.
Once again, I will remind people that an "enterprise/SLA" focused distro will rarely be focused on features. At the same time, it's clear that it requires many "enterprise" software packages built upon an "enterprise" distro -- which is not uncommon. Red Hat can't ship an "all-in-one" distro for enterprises -- and a SL solution is going to be on the other side of the spectrum from, say, a financial industry focused Linux.
So Red Hat would rather ship a common base, supported by SLAs, and then sell add-ons with SLAs for a more specific configuration.
If you want an industry-specific Linux, you're not going to find it from a generic distribution vendor. And you shouldn't wonder why they don't throw in things -- especially not things like Java which are _illegal_ to bundle freely.
-- Bryan
P.S. As always, maintain your own APT/YUM repository internally, and mix in any required RPMs. I virtually _never_ install from CD/DVD, almost always via NFS -- possibly with some post-install APT/YUM.
-- Bryan J. Smith mailto:b.j.smith@ieee.org
On Sat, 2005-05-28 at 19:38 -0400, Bryan J. Smith wrote:
From: Lamar Owen lowen@pari.edu
Referencing SL3 and CentOS 3 (as I haven't run SL4 as yet) there were some scientific applications and some Java stuff, eclipse for one,
You do understand the redistribution issues with Java, correct? It's a Sun problem (a typical thorn for Red Hat in general), not a Red Hat one.
Righto ... no JRE redistributes in CentOS ... that is not allowed :)
They also have mp3 stuff ... also not allowed :)
part of cluster suite for another, included. Lessee, https://www.scientificlinux.org/distributions/30x/features/ is the reference. GFS, Eclipse, Cluster Suite, OpenAFS, ksh93, a set of 'tweak' RPMs (my favorite being the serial console tweak RPM).
Red Hat is pushing to get GFS in the stock kernel. They bought out Sistina for a reason, to keep it GPL. These things don't happen overnight. ;-> GFS was introduced as an add-on, and probably will until it is in the stock kernel -- Red Hat is trying to avoid heavily patching the kernel nowdays (for various reasons).
For CentOS-3.x you can get GFS (and RH ClusterSuite) here:
http://bender.it.swin.edu.au/centos-3/
(there is no GFS/RHCS for RHEL-4 (or CentOS-4) yet)
As far as OpenAFS, I assume you mean the server? Or you don't like Red Hat's included client in the kernel? As always, make a Bugzilla request if you want something.
For SL4, the doc is at https://www.scientificlinux.org/distributions/4x/features/ and includes fewer addons. OpenAFS is the biggest of these, I guess.
And I too have deployed OpenAFS. The server is 100% userspace, so it shouldn't be too difficult to get it included, at least in Fedora Core (possibly the next RHEL5).
OpenAFS: I'll have to look at the license that it is released under ... that might be able to be in Extras ... someone want to maintain it :)
Once the cluster suite and eclipse are available they probably will be rolled in.
When RHGFS / Eclipse / RHCS are released for RHEL-4 they will be available for CentOS-4.
Pine also is in the SL dists.
Pico/Pine also changed licenses awhile back and is considered "non-free." Nano replaced Pico, can't remember what replaced Pine.
Correct ... Pine is non-free license, won't be built for CentOS-4 :)
On Saturday 28 May 2005 19:38, Bryan J. Smith b.j.smith@ieee.org wrote:
From: Lamar Owen lowen@pari.edu
Referencing SL3 and CentOS 3 (as I haven't run SL4 as yet) there were some scientific applications and some Java stuff, eclipse for one,
You do understand the redistribution issues with Java, correct? It's a Sun problem (a typical thorn for Red Hat in general), not a Red Hat one.
I was asked what the differences between CentOS and SL were. I simply enumerated some of the differences. The Fermi internal Linux had permission from Sun to redistribute JRE for a particular version, apparently, but the latest does not include a JRE.
As to Pine, the license does not preclude distribution; Red Hat just didn't like the way modifications couldn't be done, rendering it unsupportable. A 'SLplus' repo addition to CentOS (hosted by Fermi or whoever) would probably handle the things that are different (like pcp and the others), and that could handle things.
However, with the reaction this got I wonder if Connie and the rest would want to try working in that direction. The OpenAFS kernel portion could be a problem, but could be handled again by a 'SLPlus' repository.
Overreaction is not a good thing, and the upthread post was an overreaction; you're not telling me anything I don't know, Bryan. I was just enumerating the differences; nothing more. I do not use SL at this point; but just pointing out the duplication of effort that is going on.
On Sat, 2005-05-28 at 22:41 -0400, Lamar Owen wrote:
On Saturday 28 May 2005 19:38, Bryan J. Smith b.j.smith@ieee.org wrote:
From: Lamar Owen lowen@pari.edu
Referencing SL3 and CentOS 3 (as I haven't run SL4 as yet) there were some scientific applications and some Java stuff, eclipse for one,
You do understand the redistribution issues with Java, correct? It's a Sun problem (a typical thorn for Red Hat in general), not a Red Hat one.
I was asked what the differences between CentOS and SL were. I simply enumerated some of the differences. The Fermi internal Linux had permission from Sun to redistribute JRE for a particular version, apparently, but the latest does not include a JRE.
The answer to your immediate question is that CentOS is a community operating system and anyone who wants to can use it. We take contributions to CentOS from non-developers, and we add developers from the community. Those contributions, however, must be accepted into CentOS and be redistributable by us.
I don't think Pine and OpenAFS will be part of CentOS, neither can anything that plays mp3's nor can anything that distributes JAVA (unless it is an Open Source java, the Mozilla project is working on one ... so maybe later).
CentOS supports the Free Software Foundation's position on non-GPL products .. and if they recommend not releasing products with a certain license, we will try to do what they ask.
We are under the RH microscope too ... if we breath wrong, we are contacted. We can not do what SL is doing for their release notes, for example. Instead, we have to include the RH release notes in their unmodified form (or we can't use them at all).
As to Pine, the license does not preclude distribution; Red Hat just didn't like the way modifications couldn't be done, rendering it unsupportable. A 'SLplus' repo addition to CentOS (hosted by Fermi or whoever) would probably handle the things that are different (like pcp and the others), and that could handle things.
However, with the reaction this got I wonder if Connie and the rest would want to try working in that direction. The OpenAFS kernel portion could be a problem, but could be handled again by a 'SLPlus' repository.
If they SL wanted to use CentOS as their base and add other things (like pine, mp3's, java, etc.) and were not part of the CentOS Project, and those programs stayed on their servers, that would be fine.
I have corresponded with Connie Sieh in the past (not about this subject though), and I like the Scientific Linux project. If they had CentOS public mirrors on their site and created just the addons, which they maintained separate from CentOS, then something might be able to be worked out.
-
Bryan J. Smith <b.j.smith＠ieee.org> -
Johnny Hughes -
Lamar Owen