From killinganfor at netscape.net Mon Sep 1 03:40:25 2003 From: killinganfor at netscape.net (=?ISO-8859-9?Q?Burak_Ba=FE?=) Date: Mon, 01 Sep 2003 13:40:25 +0300 Subject: [cAos] Hello everyone Message-ID: <3F532219.3010609@netscape.net> I'm a C and C++ programmer and I'm a beginner in Linux. I want to join to this project, I can get a job in any section... Linux forever... From lance at uklinux.net Mon Sep 1 03:54:42 2003 From: lance at uklinux.net (Lance Davis) Date: Mon, 1 Sep 2003 11:54:42 +0100 (BST) Subject: [cAos] Hello everyone In-Reply-To: <3F532219.3010609@netscape.net> Message-ID: On Mon, 1 Sep 2003, [ISO-8859-9] Burak Ba? wrote: > I'm a C and C++ programmer and I'm a beginner in Linux. I want to join > to this project, I can get a job in any section... Hi - welcome aboard :) > > Linux forever... > Indeed .. Where are you located ?? Do you have any experience of rpm ??? Welcome aboard. We have a basic web application that allows us to maintain and /own/ packages in the distribution. Please fill out the web form at http://caosity.org/account_request.php and Greg will grant access. Once logged in you can adopt packages, and manipulate the SRPMS associated with a particular package. If there is a package that you wish to maintain just send a message to the list, including a dependency list of any packages or files that are not already included in the distribution. If you dont have experience with rpm then there are loads of other things you can do whilst gaining experience :) I'm sure Greg will advise but he is on a different timezone -8 IIRC. Regards Lance -- uklinux.net - The ISP of choice for the discerning Linux user. From tarik at gandur.tr.tc Mon Sep 1 04:17:21 2003 From: tarik at gandur.tr.tc (TARIK GANDUR) Date: Mon, 1 Sep 2003 14:17:21 +0300 Subject: [cAos] Hello everyone In-Reply-To: <3F532219.3010609@netscape.net> References: <3F532219.3010609@netscape.net> Message-ID: <200309011417.21242.tarik@gandur.tr.tc> Hi Burak, I'm glad to see you here. Welcome and happy coding :) Tar?k Gandur On Monday 01 September 2003 13:40, Burak Ba? wrote: > I'm a C and C++ programmer and I'm a beginner in Linux. I want to join > to this project, I can get a job in any section... > > Linux forever... > > _______________________________________________ > cAos mailing list > cAos at runlevelzero.net > http://www.caosity.org/mailman/listinfo/caos From greg at runlevelzero.net Mon Sep 1 14:42:19 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Mon, 1 Sep 2003 14:42:19 -0700 Subject: [cAos] Hello everyone In-Reply-To: <3F532219.3010609@netscape.net> References: <3F532219.3010609@netscape.net> Message-ID: <20030901214219.GD12043@titan.runlevelzero.net> Welcome! Lance's comments were all correct, and a great place to start. There are several other people here that either know Linux or code pretty well, but not necessarily RPM. I encourage people to post to this list with questions you may have regarding package management or cAos in general. Also, you should probably checkout: http://caosity.org/usr_help.php Thanks, and please forward questions to the list... Greg On Mon, Sep 01, 2003 at 01:40:25PM +0300, Burak Ba? told me: > I'm a C and C++ programmer and I'm a beginner in Linux. I want to join > to this project, I can get a job in any section... > > Linux forever... > > _______________________________________________ > cAos mailing list > cAos at runlevelzero.net > http://www.caosity.org/mailman/listinfo/caos -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From gmkurtzer at lbl.gov Mon Sep 1 14:52:08 2003 From: gmkurtzer at lbl.gov (Greg Kurtzer) Date: Mon, 1 Sep 2003 14:52:08 -0700 Subject: [cAos] Re: [Univ-linux] a very brief webpage In-Reply-To: <1062451812.21565.147.camel@opus> References: <1062451812.21565.147.camel@opus> Message-ID: <20030901215208.GA2526@tux.lbl.gov> I am not sure I agree with the first statement... An effort to augment the Red Hat Linux Project - rhl.redhat.com - with packages and utilities for university, educational and research use. My first and foremost responsibility is to maintain the installed systems that have been EOL'ed by RedHat. Many of these systems can not be upgraded for whatever reason, and thus will _need_ support. This is my major motivation for a project like this. I would probably open with a more general statement like: An effort to allow various institutions maintain packages for RedHat Linux that will both add functionality and needed security for EOL'ed products. Also just a thought... Why not just use the Fedora project for the RHL enhancement packages? Thanks for doing this!!! Greg On Mon, Sep 01, 2003 at 05:30:12PM -0400, seth vidal told me: > http://linux.duke.edu/projects/univ-linux/ > > Very simple - but I think it summarizes what we have talked about. > > let me know what more I should add. > -sv > > > _______________________________________________ > Univ-linux mailing list > Univ-linux at lists.dulug.duke.edu > https://lists.dulug.duke.edu/mailman/listinfo/univ-linux -- Greg M. Kurtzer, CSE: Linux cluster specialist Lawrence Berkeley National Laboratory Contact: O=510.495.2307, P=510.448.4540, M=510.928.9953 1 Cyclotron Road #90-1116, Berkeley, CA 94720 http://www.lbl.gov, http://scs.lbl.gov/, http://lug.lbl.gov/ Email: GMKurtzer_at_lbl.gov, Text: 5109289953_at_mobileatt.net From skvidal at phy.duke.edu Mon Sep 1 16:01:02 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 01 Sep 2003 19:01:02 -0400 Subject: [cAos] Re: [Univ-linux] a very brief webpage In-Reply-To: <20030901215208.GA2526@tux.lbl.gov> References: <1062451812.21565.147.camel@opus> <20030901215208.GA2526@tux.lbl.gov> Message-ID: <1062457261.28207.18.camel@binkley> > My first and foremost responsibility is to maintain the installed systems > that have been EOL'ed by RedHat. Many of these systems can not be upgraded for > whatever reason, and thus will _need_ support. This is my major motivation for > a project like this. I felt that 'augment' was inclusive of the additional duration for the security errata. And greater clarity was sorta the point of listing the goals. > Also just a thought... Why not just use the Fedora project for the RHL > enhancement packages? that has been discussed and would be a good idea. -sv ps: why'd you cross post? From killinganfor at netscape.net Tue Sep 2 01:24:26 2003 From: killinganfor at netscape.net (=?ISO-8859-9?Q?Burak_Ba=FE?=) Date: Tue, 02 Sep 2003 11:24:26 +0300 Subject: [cAos] Hello again... References: <20030901190002.10691.16011.Mailman@titan.runlevelzero.net> Message-ID: <3F5453BA.5020905@netscape.net> Hello everyone... I'm from Turkey. My timezone is GMT+2. I know to build RPMs. I can convert anything to RPM package as well... From lance at uklinux.net Tue Sep 2 03:43:06 2003 From: lance at uklinux.net (Lance Davis) Date: Tue, 2 Sep 2003 11:43:06 +0100 (BST) Subject: [cAos] Hello again... In-Reply-To: <3F5453BA.5020905@netscape.net> Message-ID: On Tue, 2 Sep 2003, [ISO-8859-9] Burak Ba? wrote: > Hello everyone... > > I'm from Turkey. My timezone is GMT+2. I know to build RPMs. I can > convert anything to RPM package as well... Great !! You need to register at http://caosity.org/account_request.php ?? You'll need to wait then to get approved by Greg. Then login to the temple http://caosity.org/temple.php and choose some packages to maintain at http://caosity.org/pkg_adopt.php . There are hundreds of packages there up for adoption. If there are packages that arent in the list that you want to maintain, or there are packages that you know inside out that have someone elses name on then you'll ned to email Greg - greg at runlevelzero.net . There is some documentation for the caos standard for SPEC files etc at http://caosity.org/docs_view.php, as well as information about maintaining your repository. Glad to have you aboard !! Regards Lance > _______________________________________________ > cAos mailing list > cAos at runlevelzero.net > http://www.caosity.org/mailman/listinfo/caos > -- uklinux.net - The ISP of choice for the discerning Linux user. From lance at uklinux.net Tue Sep 2 14:44:14 2003 From: lance at uklinux.net (Lance Davis) Date: Tue, 2 Sep 2003 22:44:14 +0100 (BST) Subject: [cAos] rpms Message-ID: How do you feel for example about the minicom SPEC, minicom is now a debian project at http://alioth.debian.org/projects/minicom/ The spec is (to my mind) horrible - its multilingual eg :- Summary: TTY mode communications package ala Telix Summary(de): TTY-Modus-Kommunikationspaket (?hnlich Telix) Summary(fi): Tietoliikenneohjelma, kuten Telix Summary(fr): Package de communication en mode terminal ? la Telix Summary(pl): Program komunikacyjny (podobny do Telix-a) Summary(tr): Telix benzeri, TTY kipi ileti?im paketi 1. Does caos allow this, ?? Should the extra languages be separate files somehow ?? I guess because finnish, polish and turkish are perhaps not the languages that I would have chosen to put in. I have seen this in a few other rpms - is it safe when we dont know the languages - ok the german looks ok, but what if it was Japanese or Chinese ??? Is it maintainable ??? 2. Should I contact %changelog * Mon Jun 23 2003 Daniel Tschan - updated to minicom 2.1 - rewrote spec file with the help of Martin Godisch to see if they want to maintain it in caos ??? This is a newer version than redhat ship BTW. Regards Lance -- uklinux.net - The ISP of choice for the discerning Linux user. From herrold at owlriver.com Tue Sep 2 14:59:58 2003 From: herrold at owlriver.com (R P Herrold) Date: Tue, 2 Sep 2003 17:59:58 -0400 (EDT) Subject: [cAos] Re: cAos] rpms In-Reply-To: Message-ID: On Tue, 2 Sep 2003, Lance Davis wrote: > > How do you feel for example about the minicom SPEC, minicom is now a > debian project at http://alioth.debian.org/projects/minicom/ > > The spec is (to my mind) horrible - its multilingual eg :- > > Summary: TTY mode communications package ala Telix > Summary(de): TTY-Modus-Kommunikationspaket (?hnlich Telix) > Summary(fi): Tietoliikenneohjelma, kuten Telix > Summary(fr): Package de communication en mode terminal ? la Telix > Summary(pl): Program komunikacyjny (podobny do Telix-a) > Summary(tr): Telix benzeri, TTY kipi ileti?im paketi > > 1. Does caos allow this, ?? Should the extra languages be separate files > somehow ?? I guess because finnish, polish and turkish are perhaps not the > languages that I would have chosen to put in. I certainly do not consider it something which should be stripped out unless it is preventing building. As with many things in the Open Source realm not related to security, we assume that they are accurate until advised to the contrary. [and at the time of a report, invite the reporter to submit a correcting diff.] Credit (point the blame at) the upstream source, note the version/release in the Changelog and move on. It may be prudent to make it express that the prime language of the project is English - but of course a couple approaches exist there as well for spelling in 'English' as well. ;) There is not really a clean 'include' file mechanism for .spec files that presently comes to mind. Clearly if moving to a checkout and build model, .spec file assembly with a preprocessor might be possible, but it seems to me, its cost far outweighs any obvious benefit. -- Russ Herrold From greg at runlevelzero.net Tue Sep 2 16:12:56 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Tue, 2 Sep 2003 16:12:56 -0700 Subject: [cAos] rpms In-Reply-To: References: Message-ID: <20030902231256.GB3730@titan.runlevelzero.net> On Tue, Sep 02, 2003 at 10:44:14PM +0100, Lance Davis told me: > 1. Does caos allow this, ?? Should the extra languages be separate files > somehow ?? I guess because finnish, polish and turkish are perhaps not the > languages that I would have chosen to put in. While, I don't see any need to remove them I will always argue that it is the package maintainers decision what gets kept and what gets dropped. In this circumstance I would recommend to only remove if it causes a problem. > I have seen this in a few other rpms - is it safe when we dont know the > languages - ok the german looks ok, but what if it was Japanese or > Chinese ??? Is it maintainable ??? That is an interesting point. What if it says something that is outright wrong in a language that the maintainer does not understand. I guess that I will once again leave the decision to the package maintainer and what they are comfortable with. > 2. Should I contact > > %changelog > * Mon Jun 23 2003 Daniel Tschan > - updated to minicom 2.1 > - rewrote spec file with the help of Martin Godisch > > to see if they want to maintain it in caos ??? Always a reasonable solution in my opinion! ;) > This is a newer version than redhat ship BTW. Excellent! Greg -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From herrold at owlriver.com Tue Sep 2 17:03:39 2003 From: herrold at owlriver.com (R P Herrold) Date: Tue, 2 Sep 2003 20:03:39 -0400 (EDT) Subject: [cAos] Re: cAos] rpms In-Reply-To: <20030902231256.GB3730@titan.runlevelzero.net> Message-ID: On Tue, 2 Sep 2003, Greg Kurtzer wrote: > > This is a newer version than redhat ship BTW. > > Excellent! oops -- forgot to comment on that. Newer != better, nor even imply it. As I recall minicom has really nasty SUID code in play here (/etc/minicom.users is really scary and essentially unauditable in potential combinations of holes), and shared lockfiles with uucp and mgetty, and so on. I would be tempted to hang back on this one, unless there is a clear benefit; an open hole needing fixing; or a complete understanding of the implications of the prior patches. -- Russ Herrold From lance at uklinux.net Tue Sep 2 18:47:48 2003 From: lance at uklinux.net (Lance Davis) Date: Wed, 3 Sep 2003 02:47:48 +0100 (BST) Subject: [cAos] Re: cAos] rpms In-Reply-To: Message-ID: On Tue, 2 Sep 2003, R P Herrold wrote: > On Tue, 2 Sep 2003, Greg Kurtzer wrote: > > > > This is a newer version than redhat ship BTW. > > > > Excellent! > > oops -- forgot to comment on that. Newer != better, nor even > imply it. As I recall minicom has really nasty SUID code in > play here (/etc/minicom.users is really scary and essentially > unauditable in potential combinations of holes), and shared > lockfiles with uucp and mgetty, and so on. I would be tempted > to hang back on this one, unless there is a clear benefit; an > open hole needing fixing; or a complete understanding of the > implications of the prior patches. Thanks for the warning .. Hmm - minicom doesnt install anything SUID ?? But I'll take a good look at it. Regards Lance -- uklinux.net - The ISP of choice for the discerning Linux user. From greg at runlevelzero.net Sat Sep 6 07:14:17 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Sat, 6 Sep 2003 07:14:17 -0700 Subject: [cAos] Version thoughts... Message-ID: <20030906141417.GA10238@titan.runlevelzero.net> This has been brought up before, but I want to bring it up again. I have been talking to several people on the phone and on IRC about cAos-1 and the core compatiability. -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From lance at uklinux.net Sat Sep 6 07:25:16 2003 From: lance at uklinux.net (Lance Davis) Date: Sat, 6 Sep 2003 15:25:16 +0100 (BST) Subject: [cAos] Version thoughts... In-Reply-To: <20030906141417.GA10238@titan.runlevelzero.net> Message-ID: On Sat, 6 Sep 2003, Greg Kurtzer wrote: > This has been brought up before, but I want to bring it up again. I have been > talking to several people on the phone and on IRC about cAos-1 and the core > compatiability. > and what is the consensus ??? Regards Lance -- uklinux.net - The ISP of choice for the discerning Linux user. From greg at runlevelzero.net Sat Sep 6 07:59:06 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Sat, 6 Sep 2003 07:59:06 -0700 Subject: [cAos] RHEL Support and compatiability. Message-ID: <20030906145906.GB10238@titan.runlevelzero.net> Background: http://caosity.org/pipermail/caos/2003-July/000095.html Based on many conversations that I have had now with users, other developers, and vendors I propose we do the following: cAos1: - RHEL2: glibc, gcc, (rpm), maybe other core packages - Kernel.org: Linux-2.4.x - Other packages are built from other sources or built by us cAos2 (when released): - RHEL3: glibc, gcc, (rpm), maybe other core packages - Kernel.org: Linux-2.6.x - Other packages are built from other sources or built by us The part that I wish to emphasize is using the RHEL packages... Cons: - Relying on RedHat for core packages Pros: - Ensures updates for core packages - Binary compatible with RH7.x (still IMHO the best RH version) - Allows us to focus our more of our efforts in the upper OS - We can still define and grow in our own direction - cAos1 should be compatible with RH73 :) - Defines when cAos2 will be released Before we discuss these topics or make decisions, I would like to first grow these lists (both pros/cons and package lists). If you have any other thoughts please add them to the list. We will then discuss our direction after we decide that the lists are accurate. Thanks, Greg -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From greg at runlevelzero.net Sat Sep 6 08:00:12 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Sat, 6 Sep 2003 08:00:12 -0700 Subject: [cAos] Version thoughts... In-Reply-To: <20030906141417.GA10238@titan.runlevelzero.net> References: <20030906141417.GA10238@titan.runlevelzero.net> Message-ID: <20030906150012.GC10238@titan.runlevelzero.net> LOL, that was weird... I actually thought I hit the delete key on this message! The rewrote version will be arriving in moments. Sorry! Greg On Sat, Sep 06, 2003 at 07:14:17AM -0700, Greg Kurtzer told me: > This has been brought up before, but I want to bring it up again. I have been > talking to several people on the phone and on IRC about cAos-1 and the core > compatiability. > -- > Greg M. Kurtzer > http://runlevelzero.net/ > http://caosity.org/ > http://warewulf-cluster.org/ > _______________________________________________ > cAos mailing list > cAos at runlevelzero.net > http://www.caosity.org/mailman/listinfo/caos -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From jim at rossberry.com Sat Sep 6 08:38:47 2003 From: jim at rossberry.com (Jim Wildman) Date: Sat, 6 Sep 2003 11:38:47 -0400 (EDT) Subject: [cAos] RHEL Support and compatiability. In-Reply-To: <20030906145906.GB10238@titan.runlevelzero.net> Message-ID: If you're not going to use the RHELx kernel, what's the point of using any of the rest of RHELx? I constantly get complaints from my end users about the Perl version, the Python version, etc. I see glibc, gcc and the kernel as a tightly intertwined group that should 'track' together. So Cons: Lose the back porting of 2.[456] patches into the 2.4.9 series Lose the compatibility/certification advantages of building on 1 kernel + patches Will potentially be using an 'old' compiler (the RHEL 2/RHL7 gcc/glibc) to build newer kernels On Sat, 6 Sep 2003, Greg Kurtzer wrote: > Background: > http://caosity.org/pipermail/caos/2003-July/000095.html > > Based on many conversations that I have had now with users, other developers, > and vendors I propose we do the following: > > cAos1: > - RHEL2: glibc, gcc, (rpm), maybe other core packages > - Kernel.org: Linux-2.4.x > - Other packages are built from other sources or built by us > > cAos2 (when released): > - RHEL3: glibc, gcc, (rpm), maybe other core packages > - Kernel.org: Linux-2.6.x > - Other packages are built from other sources or built by us > > The part that I wish to emphasize is using the RHEL packages... > > > Cons: > - Relying on RedHat for core packages > > Pros: > - Ensures updates for core packages > - Binary compatible with RH7.x (still IMHO the best RH version) > - Allows us to focus our more of our efforts in the upper OS > - We can still define and grow in our own direction > - cAos1 should be compatible with RH73 :) > - Defines when cAos2 will be released > > > Before we discuss these topics or make decisions, I would like to first grow > these lists (both pros/cons and package lists). If you have any other thoughts > please add them to the list. We will then discuss our direction after we > decide that the lists are accurate. > > Thanks, > Greg > ------------------------------------------------------------------------ Jim Wildman, CISSP, RHCE jim at rossberry.com http://www.rossberry.com From herrold at owlriver.com Sun Sep 7 14:37:54 2003 From: herrold at owlriver.com (R P Herrold) Date: Sun, 7 Sep 2003 17:37:54 -0400 (EDT) Subject: [cAos] Re: cAos] RHEL Support and compatiability. In-Reply-To: <20030906145906.GB10238@titan.runlevelzero.net> Message-ID: On Sat, 6 Sep 2003, Greg Kurtzer wrote: > cAos1: > - RHEL2: glibc, gcc, (rpm), maybe other core packages > - Kernel.org: Linux-2.4.x > - Other packages are built from other sources or built by us I am unclear on the reason want to use kernels directly from kernel.org. The dedicated team of professional kernel stabilizers which Red Hat has for its EL product (and staying with static -ac assigned dev entries) are almost certainly able to get to a more stable kernel than the random walk toward the 'latest and greatest' which kernel.org has. I do not know that I have seen a formal statement on non-security and performance enhancing errata by Red Hat on EL, but it seems to be on a quarterly cycle. Faster when the Broadcomm gig E driver stgabilization was happening. Perhaps a member of the list with a formal RHEL support proposal or contract can advise if specific representations are present. As to RPM version to follow, I really think RH QA has missed the ball here, and the rpm.org/fedora 4.1.1 is preferable to 4.0.4 (RHL 7.2/RHAS 2.1), or either of the RHL 8 or 9 RPM variants. > cAos2 (when released): > - RHEL3: glibc, gcc, (rpm), maybe other core packages > - Kernel.org: Linux-2.6.x > - Other packages are built from other sources or built by us > > The part that I wish to emphasize is using the RHEL packages... Again, the RPM variant for RHEL 3.0 is not formally stated, but will be for a NPTL kernel -- the rpm.org/fedora 4.2.1 variant may turn out to be a better choice. > Cons: > - Relying on RedHat for core packages This is a con in a non-GPL/OSS world -- but frankly, being free to choose for quality of integration and stability makes sense to me. (reprise of kernel discussion above) If the darn RH approach to desktop population will mature and finish stabilizing I would sure appreciate it. But I manually populate a non-RH desktop anyway (XCFE-3 rules) so I am willing to ignore the confusion. On the topic of shifting to guidestars for first cAos releases against compatibility toward the RHEL series, this makes sense presently due to timing -- but two years from now, their 'stability' is going to seem tired and stale. We will not recognize Gnome, KDE, or Open Office, and their requirements most probably will not be met within the initially shipping variands of RHAS 2.1 or RHEL 3.0 ;) -- Russ Herrold From greg at runlevelzero.net Sun Sep 7 22:30:01 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Sun, 7 Sep 2003 22:30:01 -0700 Subject: [cAos] Re: cAos] RHEL Support and compatiability. In-Reply-To: References: <20030906145906.GB10238@titan.runlevelzero.net> Message-ID: <20030908053001.GC13203@titan.runlevelzero.net> On Sun, Sep 07, 2003 at 05:37:54PM -0400, R P Herrold told me: > I am unclear on the reason want to use kernels directly from > kernel.org. The dedicated team of professional kernel > stabilizers which Red Hat has for its EL product (and staying > with static -ac assigned dev entries) are almost certainly > able to get to a more stable kernel than the random walk > toward the 'latest and greatest' which kernel.org has. The way that I see it is that while there kernel may be /sometimes/ seemingly more stable, they are forking the heck out of it and many of the times when you need to patch a kernel, it does not work with a Red Hat Kernel. note: I did call it a fork on purpose ;) Also, ironically I think I am one of the only people that I know running a standard RH kernel on our HPC clusters! ;) Please remember as well that the Red Hat Kernel should fit into cAos with no problems. Thus, while we may be distributing with a kernel.org kernel, people can use what they wish. Lastly, it is cleaner. I am presently maintaining the cAos kernel, and unless I know what each of the hundreds of Red Hat patches do, I won't even consider it because it is blind maintenance. Now, if someone else wants to maintain the kernel (or more specifically the Red Hat Kernel) I will welcome it. The two will even fit in the system because they are named different (ie. linux Vs. kernel which I did on purpose to facilitate dual installations). > As to RPM version to follow, I really think RH QA has missed > the ball here, and the rpm.org/fedora 4.1.1 is preferable to > 4.0.4 (RHL 7.2/RHAS 2.1), or either of the RHL 8 or 9 RPM > variants. Agreed (the the '()' was to demonstrate that I was still mulling over it). > > Cons: > > - Relying on RedHat for core packages > > This is a con in a non-GPL/OSS world -- but frankly, being > free to choose for quality of integration and stability makes > sense to me. (reprise of kernel discussion above) I don't have too much of a problem with the OSS ethics here, but my issue is with maintenance. glibc is actually pretty clean, but the kernel is really scary! ;) > On the topic of shifting to guidestars for first cAos releases > against compatibility toward the RHEL series, this makes sense > presently due to timing -- but two years from now, their > 'stability' is going to seem tired and stale. We will not > recognize Gnome, KDE, or Open Office, and their requirements > most probably will not be met within the initially shipping > variands of RHAS 2.1 or RHEL 3.0 ;) Agreed. Timing is everything. ;) I am hoping that the dependency conflicts will not be that profound but you are right to bring this up now. Maybe by that time we will have a larger following and volunteers to make some of this work ;) Otherwise, we will either have to run with the slightly older packages that work or (depending on how many users are still on this) EOL the OS (remember, we are hoping to maintain support for 3-5 years). Thoughts? -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From greg at runlevelzero.net Sun Sep 7 22:34:41 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Sun, 7 Sep 2003 22:34:41 -0700 Subject: [cAos] RHEL Support and compatiability. In-Reply-To: References: <20030906145906.GB10238@titan.runlevelzero.net> Message-ID: <20030908053441.GD13203@titan.runlevelzero.net> On Sat, Sep 06, 2003 at 11:38:47AM -0400, Jim Wildman told me: > If you're not going to use the RHELx kernel, what's the point of using > any of the rest of RHELx? I constantly get complaints from my end users > about the Perl version, the Python version, etc. Mostly complexity of the packages. python, perl, etc... is reasonable, but glibc is daunting ;). > I see glibc, gcc and the kernel as a tightly intertwined group that > should 'track' together. Hrmm... I have not had any complaints from people running standard kernel.org kernels on RedHat systems. My laptop and desktop are actually running the cAos kernel and have had no problems (actually the laptop runs better with now then with the Red Hat Kernel!). > So > Cons: > Lose the back porting of 2.[456] patches into the 2.4.9 series > Lose the compatibility/certification advantages of building on 1 kernel > + patches > Will potentially be using an 'old' compiler (the RHEL 2/RHL7 gcc/glibc) > to build newer kernels Yes, this is a big one. Maybe we would use a newer RHL gcc SRPM compiled against the older RHEL glibc. Am I scaring anyone yet, or does this sound reasonable? ;) Greg -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From pmatilai at welho.com Sun Sep 7 23:29:39 2003 From: pmatilai at welho.com (Panu Matilainen) Date: Mon, 8 Sep 2003 09:29:39 +0300 Subject: [cAos] Re: cAos] RHEL Support and compatiability. In-Reply-To: <20030908053001.GC13203@titan.runlevelzero.net> References: <20030906145906.GB10238@titan.runlevelzero.net> <20030908053001.GC13203@titan.runlevelzero.net> Message-ID: <1063002579.3f5c21d355b9b@webmail.welho.com> Quoting Greg Kurtzer : > On Sun, Sep 07, 2003 at 05:37:54PM -0400, R P Herrold told me: > > I am unclear on the reason want to use kernels directly from > > kernel.org. The dedicated team of professional kernel > > stabilizers which Red Hat has for its EL product (and staying > > with static -ac assigned dev entries) are almost certainly > > able to get to a more stable kernel than the random walk > > toward the 'latest and greatest' which kernel.org has. > > The way that I see it is that while there kernel may be /sometimes/ > seemingly > more stable, they are forking the heck out of it and many of the times when > you need to patch a kernel, it does not work with a Red Hat Kernel. > > note: I did call it a fork on purpose ;) > > Also, ironically I think I am one of the only people that I know running a > standard RH kernel on our HPC clusters! ;) > > Please remember as well that the Red Hat Kernel should fit into cAos with > no problems. Thus, while we may be distributing with a kernel.org kernel, > people can use what they wish. They certainly do patch the heck out of it but OTOH they include various advanced backports of things like NPTL and O(1) scheduler to mention a couple. Of those NPTL or lack of thereof when booting between RH kernel and stock kernel.org kernel I can imagine causing "interesting" effects. Or maybe not, I don't claim to understand the TLS/NPTL stuff and how it interacts with the rest of the system. But for example rpm-4.2 is know to trip up if you suddenly pull out NPTL/TLS capable kernel, glibc is another rather potential candidate. > > Lastly, it is cleaner. I am presently maintaining the cAos kernel, and > unless I know what each of the hundreds of Red Hat patches do, I won't even > consider it because it is blind maintenance. I maintained a "based on RH kernel but updated to newer kernel.org kernel" for a while back in RH7.0 days and merging the tens of patches was nothing short of scary, especially since I'm by no means a kernel hacker. Not to mention the opacity of "here's a new RH errata kernel, now what actually changed in it?" - the changes are hardly mentioned and they do "interesting" things there: all the RH7.1 - RH9 kernels share the same spec but the contents of the patches are wildly different on RH9. Go figure.. Nowadays I've taken the approach of maintaining the kernel (at work) by sticking to whatever RH releases and slapping a bunch of patches (crypto + some other misc fixes which are required by the environment) after RH's patches are applied. That works quite nicely as I basically don't need to know what the heck those RH patches do :), I just merge the couple of patches in when necessary. As a bonus I get what's mostly bug-compatible kernel with RH (though of course you can't go file bugs to RH bugzilla about such a thing) and don't have to maintain my own knowledge/bug database of known issues etc. > Now, if someone else wants to maintain the > kernel (or more specifically the Red Hat Kernel) I will welcome it. The two > will even fit in the system because they are named different (ie. linux Vs. > kernel which I did on purpose to facilitate dual installations). (despite the comments above, no I'm not volunteering, doing it once is enough for me :) > > > As to RPM version to follow, I really think RH QA has missed > > the ball here, and the rpm.org/fedora 4.1.1 is preferable to > > 4.0.4 (RHL 7.2/RHAS 2.1), or either of the RHL 8 or 9 RPM > > variants. > > Agreed (the the '()' was to demonstrate that I was still mulling over it). > > > > Cons: > > > - Relying on RedHat for core packages > > > > This is a con in a non-GPL/OSS world -- but frankly, being > > free to choose for quality of integration and stability makes > > sense to me. (reprise of kernel discussion above) > > I don't have too much of a problem with the OSS ethics here, but my issue > is > with maintenance. glibc is actually pretty clean, but the kernel is really > scary! ;) The kernel land /is/ scary, whether you take a kernel.org kernel or RH one. I've assured myself that RH employs by far the biggest crew of deep kernel gurus of any of the distributions and that they know what's good far, far better than I do. Has worked fine for me, but opinions are known to differ on the goodness/badness of RH kernel. Just my 2 cents... -- - Panu - From rick at linuxmafia.com Sun Sep 7 23:49:15 2003 From: rick at linuxmafia.com (Rick Moen) Date: Sun, 7 Sep 2003 23:49:15 -0700 Subject: [cAos] Re: cAos] RHEL Support and compatiability. In-Reply-To: <20030908053001.GC13203@titan.runlevelzero.net> References: <20030906145906.GB10238@titan.runlevelzero.net> <20030908053001.GC13203@titan.runlevelzero.net> Message-ID: <20030908064915.GF10351@linuxmafia.com> Quoting Greg Kurtzer (greg at runlevelzero.net): > note: I did call it a fork on purpose ;) > [...] > Lastly, it is cleaner. I am presently maintaining the cAos kernel, and unless > I know what each of the hundreds of Red Hat patches do, I won't even consider > it because it is blind maintenance. Just to second what you're saying, back when I was at $FIRM, customers would sometimes ask me exactly what patches differentiate the RH kernel from the standard one, and what was the purpose of each. I investigated that question for a good long time, intending to create some ongoing documentation outlining the answer. It turned out to be a subtle question: You unpack the SRPM and pore through it; you find quite a tremendous number of patches, but determining which are actually used on your CPU architecture becomes a protracted exercise in reading makefiles. I'm certainly not saying the RHEL kernel isn't worthy of respect. (It was among the first to incorporate the bigmem patch, for example, and had Alan Cox's VM throughout the early 2.4.x series when the kernel.org's VM was a travesty.) However, it is indeed something of a fork, at the minimum. Speaking of $FIRM, I'll also want to remind people of the existence of the Vermillion distribution: http://www.kainx.org/vermillion/ Vermillion (and its predecessor, Red Hat with VA Linux Enhancements) takes the other tack and _further_ modifies (fixes, we would have said) RH's kernels. It might be worth getting maintainer Michael Jennings on this mailing list or at least consult his advice. -- Cheers, First they came for the verbs, and I said nothing, for Rick Moen verbing weirds language. Then, they arrival for the nouns rick at linuxmafia.com and I speech nothing, for I no verbs. - Peter Ellis From herrold at owlriver.com Mon Sep 8 05:53:23 2003 From: herrold at owlriver.com (R P Herrold) Date: Mon, 8 Sep 2003 08:53:23 -0400 (EDT) Subject: [cAos] Re: cAos] RHEL Support and compatiability. In-Reply-To: <20030908053441.GD13203@titan.runlevelzero.net> Message-ID: On Sun, 7 Sep 2003, Greg Kurtzer wrote: > > Will potentially be using an 'old' compiler (the RHEL 2/RHL7 gcc/glibc) > > to build newer kernels > > Yes, this is a big one. Maybe we would use a newer RHL gcc SRPM compiled > against the older RHEL glibc. Am I scaring anyone yet, or does this sound > reasonable? ;) The RHL 7.2 compiler would he the heavily patched gcc 2.96 (in a good way, remembering Bero's reply). For compatability reasons, we are pretty well locked into the glibc as well. Latge parts of what we are used to compiling at the application layer will not be happy with it. Current variants of open office, later kde, XFree86 are all expecting compiler features not present there. -- Russ Herrold From lance at uklinux.net Mon Sep 8 06:42:28 2003 From: lance at uklinux.net (Lance Davis) Date: Mon, 8 Sep 2003 14:42:28 +0100 (BST) Subject: [cAos] Re: cAos] RHEL Support and compatiability. In-Reply-To: Message-ID: On Mon, 8 Sep 2003, R P Herrold wrote: > On Sun, 7 Sep 2003, Greg Kurtzer wrote: > > > > Will potentially be using an 'old' compiler (the RHEL 2/RHL7 gcc/glibc) > > > to build newer kernels > > > > Yes, this is a big one. Maybe we would use a newer RHL gcc SRPM compiled > > against the older RHEL glibc. Am I scaring anyone yet, or does this sound > > reasonable? ;) > > The RHL 7.2 compiler would he the heavily patched gcc 2.96 (in > a good way, remembering Bero's reply). ISTR a lot of people not liking RH releasing with gcc 2.96rh ... > Current variants of open office, later kde, XFree86 are all > expecting compiler features not present there. Does that mean that we would be forced to use old versions of those, possibly ones that shipped with RHEL2 , if they existed ... It looks like we may as well just fork RHEL2 directly into the caos framework and release it as caos1 (or maybe better as caos0 ) . We can still add packages and alternative later versions of things into the mix. The benefit is that it would undoubtedly get us a release much sooner , would test all the framework for future releases, would let us concentrate on building our own way of doing things such as installer, update mechanism etc - not forgetting that it would let universities etc install the equivalent of RHEL without having to pay the annual licensing fees and would probably continue to work on slightly older hardware that people want to use for servers and clusters ... Lance -- uklinux.net - The ISP of choice for the discerning Linux user. From rmcgaugh at atipa.com Mon Sep 8 19:32:26 2003 From: rmcgaugh at atipa.com (Rocky McGaugh) Date: Mon, 8 Sep 2003 21:32:26 -0500 (CDT) Subject: [cAos] Version thoughts from the Lurker Message-ID: Hello, I've been lurking around for the last couple weeks waiting to see exactly what direction cAos would take. Tonight I talked with Greg a bit and he encouraged me to post my opinions to the list. Two of the things I am most interested in are stability (of the distro) and third party support/compatibility. Most ISV's are, or will soon be, targeting their development to wards RHEL. I wish everything was OSS, but it is not. I would like to see cAos2 be 100% compatible with RHEL3. In my mind, this could lead to a structure such as: cAos2-core: made purely of RHEL3 srpms. cAos2-contrib: additional packages we feel are missing from rhel or updates of "core" that do not break or conflict with "core". cAos2-craxy: packages and groups of packages that do not worry about breaking rhel compatibility with "core". On servers, I personally would only use "core" and "contrib"; the "craxy" could lead to radical changes though. My thoughts are that if you only maintain the same toolchain and kernel, there will still be a lot of room for conflicts between supporting libraries/applications and commercial softwares. RHEL and UnitedLinux both provide specific bases for ISV's to expect. The further you deviate from these, the less value this project has in my opinion. Maintaining "core" should be fairly easy. I've done it with RHAS2.1 and my skills are not special. The "contrib" gives a lot of room for cAos2 to be tailored to fit many peoples needs, and "craxy" can be tailored to fit anyones needs. The "craxy" could provide 'bundles' of updated toolchain, Ximian, KDE12, Gnome4, or whatever else people might like to have with its own set of dependencies that are all working together off a common base. The "core" and "contrib" are just what fit my needs best. If cAos does not fit my need then I will continue looking or gang up with some like minded people..:) thanks for your time, -- Rocky McGaugh Atipa Technologies rocky at atipatechnologies.com rmcgaugh at atipa.com 1-785-841-9513 x3110 http://67.8450073/ perl -e 'print unpack(u, ".=W=W+F%T:7\!A+F-O;0H`");' From greg at runlevelzero.net Mon Sep 8 21:16:10 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Mon, 8 Sep 2003 21:16:10 -0700 Subject: [cAos] Version thoughts from the Lurker In-Reply-To: References: Message-ID: <20030909041610.GB4371@titan.runlevelzero.net> On Mon, Sep 08, 2003 at 09:32:26PM -0500, Rocky McGaugh told me: > Hello, Good to see ya! > I've been lurking around for the last couple weeks waiting to see > exactly what direction cAos would take. Tonight I talked with Greg a bit > and he encouraged me to post my opinions to the list. cAos is supposed to be a community project, and the more people from the community that we hear from the better decisions we can make for the community. Thanks for posting! > Two of the things I am most interested in are stability (of the distro) > and third party support/compatibility. Most ISV's are, or will soon be, > targeting their development to wards RHEL. I wish everything was OSS, but > it is not. Agreed. > I would like to see cAos2 be 100% compatible with RHEL3. 100% is a hard number to shoot for. Can't we just be like 80%? ;) > In my mind, this could lead to a structure such as: > > cAos2-core: made purely of RHEL3 srpms. Immediately what stands out is things that are in RHEL that are not redistributable. 100% is impossible because of this. > cAos2-contrib: additional packages we feel are missing from > rhel or updates of "core" that do not break or conflict > with "core". OK. > cAos2-craxy: packages and groups of packages that do not worry > about breaking rhel compatibility with "core". Hrmm... I don't think that I would even want to mess with things that would break the core! I see two alternatives. We are either our own distribution, _or_ we are RHEL compatible. If we are RHEL compat, then I don't even want to touch things that would break this. Way too messy (IMHO). > On servers, I personally would only use "core" and "contrib"; the "craxy" > could lead to radical changes though. > > My thoughts are that if you only maintain the same toolchain and kernel, > there will still be a lot of room for conflicts between supporting > libraries/applications and commercial softwares. > > RHEL and UnitedLinux both provide specific bases for ISV's to expect. The > further you deviate from these, the less value this project has in my > opinion. Hrmm... So I guess my question is what would be the base distribution, or what exactly is in cAos-core? Maybe a minimal RHEL install? Then the cAos contrib is Gnome, Mozilla, etc...? > Maintaining "core" should be fairly easy. I've done it with RHAS2.1 and my > skills are not special. The "contrib" gives a lot of room for cAos2 to be > tailored to fit many peoples needs, and "craxy" can be tailored to fit > anyones needs. Once again, I am good with the idea of contrib, but cAos crazy I am not sure about... Anyone else have thoughts here? > The "craxy" could provide 'bundles' of updated toolchain, Ximian, KDE12, > Gnome4, or whatever else people might like to have with its own set of > dependencies that are all working together off a common base. Why can that not be done in contrib? Your examples should not break things... > The "core" and "contrib" are just what fit my needs best. If cAos does > not fit my need then I will continue looking or gang up with some like > minded people..:) Well, as I said before. We are an attempt at a community solution. If the community states they need something different then what we are providing then we will migrate. Keep in mind that much of this sounds a bit like Fedora for RHEL... What would set us apart from them? Is it worth it? > thanks for your time, Anytime! ;) -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From greg at runlevelzero.net Mon Sep 8 23:29:32 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Mon, 8 Sep 2003 23:29:32 -0700 Subject: [cAos] Re: cAos] RHEL Support and compatiability. In-Reply-To: <20030908064915.GF10351@linuxmafia.com> References: <20030906145906.GB10238@titan.runlevelzero.net> <20030908053001.GC13203@titan.runlevelzero.net> <20030908064915.GF10351@linuxmafia.com> Message-ID: <20030909062932.GA5738@titan.runlevelzero.net> On Sun, Sep 07, 2003 at 11:49:15PM -0700, Rick Moen told me: > Just to second what you're saying, back when I was at $FIRM, customers > would sometimes ask me exactly what patches differentiate the RH kernel > from the standard one, and what was the purpose of each. I investigated > that question for a good long time, intending to create some ongoing > documentation outlining the answer. It turned out to be a subtle > question: You unpack the SRPM and pore through it; you find quite a > tremendous number of patches, but determining which are actually used on > your CPU architecture becomes a protracted exercise in reading > makefiles. > > I'm certainly not saying the RHEL kernel isn't worthy of respect. (It > was among the first to incorporate the bigmem patch, for example, and > had Alan Cox's VM throughout the early 2.4.x series when the > kernel.org's VM was a travesty.) However, it is indeed something of a > fork, at the minimum. I too don't have a problem with what they are doing to the kernel, but if you want to integrate other patches into it you may be in for a pretty large job! Also, I have had really good luck with the recent kernels from kernel.org. The seem to work very well for me, (better then the RH kernels in many circumstances). Maybe we can distribute two kernels. kernel-*.rpm, and linux*.rpm. kernel can be from RH, and linux from kernel.org. At this point I am just speaking thoughts. > Speaking of $FIRM, I'll also want to remind people of the existence of > the Vermillion distribution: http://www.kainx.org/vermillion/ > Vermillion (and its predecessor, Red Hat with VA Linux Enhancements) > takes the other tack and _further_ modifies (fixes, we would have said) > RH's kernels. It might be worth getting maintainer Michael Jennings on > this mailing list or at least consult his advice. I just sent him an email. Hopefully this project is interesting to him. :) Thanks! Greg -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From cyeoh at samba.org Tue Sep 9 00:17:53 2003 From: cyeoh at samba.org (Christopher Yeoh) Date: Tue, 9 Sep 2003 17:17:53 +1000 Subject: [cAos] Re: cAos] RHEL Support and compatiability. In-Reply-To: <1063002579.3f5c21d355b9b@webmail.welho.com> References: <20030906145906.GB10238@titan.runlevelzero.net> <20030908053001.GC13203@titan.runlevelzero.net> <1063002579.3f5c21d355b9b@webmail.welho.com> Message-ID: <16221.32417.981624.355479@gargle.gargle.HOWL> At 2003/9/8 09:29+0300 Panu Matilainen writes: > They certainly do patch the heck out of it but OTOH they include > various advanced backports of things like NPTL and O(1) scheduler to > mention a couple. Of those NPTL or lack of thereof when booting > between RH kernel and stock kernel.org kernel I can imagine causing > "interesting" effects. Or maybe not, I don't claim to understand the > TLS/NPTL stuff and how it interacts with the rest of the system. But > for example rpm-4.2 is know to trip up if you suddenly pull out > NPTL/TLS capable kernel, glibc is another rather potential > candidate. For LSB 2.0 compliance, it looks like an NPTL backport will probably be needed. But maybe its easy to extract just that patch from the Red Hat kernel. Chris -- cyeoh at samba.org From skvidal at phy.duke.edu Tue Sep 9 05:09:45 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 09 Sep 2003 08:09:45 -0400 Subject: [cAos] Re: cAos] RHEL Support and compatiability. In-Reply-To: <20030909062932.GA5738@titan.runlevelzero.net> References: <20030906145906.GB10238@titan.runlevelzero.net> <20030908053001.GC13203@titan.runlevelzero.net> <20030908064915.GF10351@linuxmafia.com> <20030909062932.GA5738@titan.runlevelzero.net> Message-ID: <1063109385.29681.75.camel@binkley> > Maybe we can distribute two kernels. kernel-*.rpm, and linux*.rpm. kernel can > be from RH, and linux from kernel.org. At this point I am just speaking > thoughts. If you're going to do this go ahead and add the above to a faq. b/c it will be a faq very soon. :) -sv From greg at runlevelzero.net Tue Sep 9 06:58:37 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Tue, 9 Sep 2003 06:58:37 -0700 Subject: [cAos] Re: cAos] RHEL Support and compatiability. In-Reply-To: <16221.32417.981624.355479@gargle.gargle.HOWL> References: <20030906145906.GB10238@titan.runlevelzero.net> <20030908053001.GC13203@titan.runlevelzero.net> <1063002579.3f5c21d355b9b@webmail.welho.com> <16221.32417.981624.355479@gargle.gargle.HOWL> Message-ID: <20030909135837.GA18030@titan.runlevelzero.net> On Tue, Sep 09, 2003 at 05:17:53PM +1000, Christopher Yeoh told me: > For LSB 2.0 compliance, it looks like an NPTL backport will probably > be needed. But maybe its easy to extract just that patch from the Red > Hat kernel. Oh man!!! :( Does RHEL2.1 ship with NPTL? Greg -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From pmatilai at welho.com Tue Sep 9 07:33:28 2003 From: pmatilai at welho.com (Panu Matilainen) Date: Tue, 9 Sep 2003 17:33:28 +0300 Subject: [cAos] Re: cAos] RHEL Support and compatiability. In-Reply-To: <20030909135837.GA18030@titan.runlevelzero.net> References: <20030906145906.GB10238@titan.runlevelzero.net> <20030908053001.GC13203@titan.runlevelzero.net> <1063002579.3f5c21d355b9b@webmail.welho.com> <16221.32417.981624.355479@gargle.gargle.HOWL> <20030909135837.GA18030@titan.runlevelzero.net> Message-ID: <1063118008.3f5de4b811ab1@webmail.welho.com> Quoting Greg Kurtzer : > On Tue, Sep 09, 2003 at 05:17:53PM +1000, Christopher Yeoh told me: > > For LSB 2.0 compliance, it looks like an NPTL backport will probably > > be needed. But maybe its easy to extract just that patch from the Red > > Hat kernel. > > Oh man!!! :( > > Does RHEL2.1 ship with NPTL? 2.1 doesn't have NPTL, AFAIK. NPTL is much, much newer stuff afterall, but will be in 3.0 enterprise line. -- - Panu - From greg at runlevelzero.net Tue Sep 9 07:47:17 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Tue, 9 Sep 2003 07:47:17 -0700 Subject: [cAos] Re: cAos] RHEL Support and compatiability. In-Reply-To: <1063118008.3f5de4b811ab1@webmail.welho.com> References: <20030906145906.GB10238@titan.runlevelzero.net> <20030908053001.GC13203@titan.runlevelzero.net> <1063002579.3f5c21d355b9b@webmail.welho.com> <16221.32417.981624.355479@gargle.gargle.HOWL> <20030909135837.GA18030@titan.runlevelzero.net> <1063118008.3f5de4b811ab1@webmail.welho.com> Message-ID: <20030909144717.GA18881@titan.runlevelzero.net> On Tue, Sep 09, 2003 at 05:33:28PM +0300, Panu Matilainen told me: > > Does RHEL2.1 ship with NPTL? > > 2.1 doesn't have NPTL, AFAIK. NPTL is much, much newer stuff afterall, but will > be in 3.0 enterprise line. Hrmm... I guess there is a decision to be made. Do we follow RHEL2 for cAos-1, or move in another direction? Based on all of our last posts, it seems that building a RHEL2 compat system is what is needed. Greg -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From pmatilai at welho.com Tue Sep 9 07:56:33 2003 From: pmatilai at welho.com (Panu Matilainen) Date: Tue, 9 Sep 2003 17:56:33 +0300 Subject: [cAos] Re: cAos] RHEL Support and compatiability. In-Reply-To: <20030909144717.GA18881@titan.runlevelzero.net> References: <20030906145906.GB10238@titan.runlevelzero.net> <20030908053001.GC13203@titan.runlevelzero.net> <1063002579.3f5c21d355b9b@webmail.welho.com> <16221.32417.981624.355479@gargle.gargle.HOWL> <20030909135837.GA18030@titan.runlevelzero.net> <1063118008.3f5de4b811ab1@webmail.welho.com> <20030909144717.GA18881@titan.runlevelzero.net> Message-ID: <1063119393.3f5dea211a2f0@webmail.welho.com> Quoting Greg Kurtzer : > On Tue, Sep 09, 2003 at 05:33:28PM +0300, Panu Matilainen told me: > > > Does RHEL2.1 ship with NPTL? > > > > 2.1 doesn't have NPTL, AFAIK. NPTL is much, much newer stuff afterall, but > will > > be in 3.0 enterprise line. > > Hrmm... I guess there is a decision to be made. Do we follow RHEL2 for > cAos-1, > or move in another direction? Based on all of our last posts, it seems that > building a RHEL2 compat system is what is needed. I guess it basically comes down to: Do you want to create an RH7.x ( + AS 2.1) compatible thing to kind of allow for longer EOL of 7.x, or do you want to look forward with this thing? -- - Panu - From greg at runlevelzero.net Tue Sep 9 07:57:00 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Tue, 9 Sep 2003 07:57:00 -0700 Subject: [cAos] RHEL and cAos Message-ID: <20030909145700.GB18881@titan.runlevelzero.net> One of the first obvious issues that I see with making the cAos base system RHEL is that it will limit us drastically as far as what we can add to. For example, you can't install Gnome2 on RedHat7.x (I am pretty sure) because of glib2 requirements and I am not sure you can upgrade glib2, etc... I think the solution is to make the RHEL base as small as possible, but then we risk breaking compatibility (ie. if Oracle needs the RHEL2 glib2). Obviously this will take testing... -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From cyeoh at samba.org Tue Sep 9 07:55:02 2003 From: cyeoh at samba.org (Christopher Yeoh) Date: Wed, 10 Sep 2003 00:55:02 +1000 Subject: [cAos] Re: cAos] RHEL Support and compatiability. In-Reply-To: <20030909144717.GA18881@titan.runlevelzero.net> References: <20030906145906.GB10238@titan.runlevelzero.net> <20030908053001.GC13203@titan.runlevelzero.net> <1063002579.3f5c21d355b9b@webmail.welho.com> <16221.32417.981624.355479@gargle.gargle.HOWL> <20030909135837.GA18030@titan.runlevelzero.net> <1063118008.3f5de4b811ab1@webmail.welho.com> <20030909144717.GA18881@titan.runlevelzero.net> Message-ID: <16221.59846.220330.64723@gargle.gargle.HOWL> At 2003/9/9 07:47-0700 Greg Kurtzer writes: > On Tue, Sep 09, 2003 at 05:33:28PM +0300, Panu Matilainen told me: > > > Does RHEL2.1 ship with NPTL? > > > > 2.1 doesn't have NPTL, AFAIK. NPTL is much, much newer stuff afterall, but will > > be in 3.0 enterprise line. > > Hrmm... I guess there is a decision to be made. Do we follow RHEL2 > for cAos-1, or move in another direction? Based on all of our last > posts, it seems that building a RHEL2 compat system is what is > needed. And for this you could follow LSB 1.3 conformance which doesn't officially test threads behaviour. Just something to think about for the longer term (and is rather important for ISV compatibility where POSIX threads behaviour is really needed). Chris -- cyeoh at samba.org From greg at runlevelzero.net Tue Sep 9 08:05:40 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Tue, 9 Sep 2003 08:05:40 -0700 Subject: [cAos] Re: cAos] RHEL Support and compatiability. In-Reply-To: <1063119393.3f5dea211a2f0@webmail.welho.com> References: <20030906145906.GB10238@titan.runlevelzero.net> <20030908053001.GC13203@titan.runlevelzero.net> <1063002579.3f5c21d355b9b@webmail.welho.com> <16221.32417.981624.355479@gargle.gargle.HOWL> <20030909135837.GA18030@titan.runlevelzero.net> <1063118008.3f5de4b811ab1@webmail.welho.com> <20030909144717.GA18881@titan.runlevelzero.net> <1063119393.3f5dea211a2f0@webmail.welho.com> Message-ID: <20030909150540.GC18881@titan.runlevelzero.net> On Tue, Sep 09, 2003 at 05:56:33PM +0300, Panu Matilainen told me: > I guess it basically comes down to: Do you want to create an RH7.x ( + AS 2.1) > compatible thing to kind of allow for longer EOL of 7.x, or do you want to look > forward with this thing? My thoughts are to have the RHEL2 compatibility to start with (because there are so many people that need this), and hopefully be able to move forward in the right direction as time moves on. I am thinking specifically cAos-1:RHEL2 being present, and cAos-2:RHEL3 being the near future. Maybe cAos-3,4,5... will be a different solution from Red Hat. It will all depend on how the initial cAos versions work out, and what the community needs then. I strongly consider this a community project, and my thoughts are greatly influenced by the community (and more so by the people contributing their time on this list). It seems clear where the community want's us to go, so as long as we can figure out how to get there in a manner that has a future then that is what we should do. -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From greg at runlevelzero.net Tue Sep 9 08:06:30 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Tue, 9 Sep 2003 08:06:30 -0700 Subject: [cAos] Re: cAos] RHEL Support and compatiability. In-Reply-To: <16221.59846.220330.64723@gargle.gargle.HOWL> References: <20030906145906.GB10238@titan.runlevelzero.net> <20030908053001.GC13203@titan.runlevelzero.net> <1063002579.3f5c21d355b9b@webmail.welho.com> <16221.32417.981624.355479@gargle.gargle.HOWL> <20030909135837.GA18030@titan.runlevelzero.net> <1063118008.3f5de4b811ab1@webmail.welho.com> <20030909144717.GA18881@titan.runlevelzero.net> <16221.59846.220330.64723@gargle.gargle.HOWL> Message-ID: <20030909150630.GD18881@titan.runlevelzero.net> On Wed, Sep 10, 2003 at 12:55:02AM +1000, Christopher Yeoh told me: > And for this you could follow LSB 1.3 conformance which doesn't > officially test threads behaviour. Just something to think about for > the longer term (and is rather important for ISV compatibility where > POSIX threads behaviour is really needed). Agreed. -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From gmkurtzer at lbl.gov Tue Sep 9 07:45:44 2003 From: gmkurtzer at lbl.gov (Greg Kurtzer) Date: Tue, 9 Sep 2003 07:45:44 -0700 Subject: [cAos] Re: Why not use an RH Enterprise system for the build? RHEL issues. In-Reply-To: <4.3.2.7.2.20030908103438.049eafb0@imap4.lbl.gov> References: <111BCA23190@maiser.uibk.ac.at> <4.3.2.7.2.20030908103438.049eafb0@imap4.lbl.gov> Message-ID: <20030909144544.GA23666@tux.lbl.gov> On Mon, Sep 08, 2003 at 03:02:46PM -0700, Jed Donnelley told me: > Redhat patches. Ideally this would be a shared effort (e.g. DOE?). There > is an effort to do a Linux distribution being led by some folks at LBL > (e.g. Greg Kurtzer, also cc'ed): > > http://caosity.org/ > > However, again that's more of its own distribution, not an effort to track > Redhat. It seems to me that your position with Fermi Linux is closer to My initial intention of cAos was to become a new distribution, but I have had various people in the community request a slightly different path. We are now _considering_ having the base cAos-1 system fully compatible with a RHEL2 base, and cAos-2 to be RHEL3 compatible. By compatible, I mean that we will be using the same source rpms as Red Hat distributes for the EL base recompiled on our supported architectures (presently i686 and x86_64). On top of this we will maintain community code. There are still _many_ details to be worked out as these ideas are still young. So in a nutshell, we may be releasing a rebuilt base of RHEL that is completely open in a packaged form (ie. ISO and network installers) and maintained. As I said, we are still considering this, and it will change a much of our initial goals and current build infrastructure (not to mention complicate many things like newer package dependencies). We are very open to thoughts and comments. Greg -- Greg M. Kurtzer, CSE: Linux cluster specialist Lawrence Berkeley National Laboratory Contact: O=510.495.2307, P=510.448.4540, M=510.928.9953 1 Cyclotron Road #90-1116, Berkeley, CA 94720 http://www.lbl.gov, http://scs.lbl.gov/, http://lug.lbl.gov/ Email: GMKurtzer_at_lbl.gov, Text: 5109289953_at_mobileatt.net From lance at uklinux.net Tue Sep 9 08:45:09 2003 From: lance at uklinux.net (Lance Davis) Date: Tue, 9 Sep 2003 16:45:09 +0100 (BST) Subject: [cAos] Version thoughts from the Lurker In-Reply-To: <20030909041610.GB4371@titan.runlevelzero.net> Message-ID: On Mon, 8 Sep 2003, Greg Kurtzer wrote: > Well, as I said before. We are an attempt at a community solution. If the > community states they need something different then what we are providing then > we will migrate. > > Keep in mind that much of this sounds a bit like Fedora for RHEL... What would > set us apart from them? Is it worth it? What sets us apart is the licensing, the fact that the open packages are not going to be tied up in a $$$ per seat license. Lance -- uklinux.net - The ISP of choice for the discerning Linux user. From herrold at owlriver.com Tue Sep 9 10:24:21 2003 From: herrold at owlriver.com (R P Herrold) Date: Tue, 9 Sep 2003 13:24:21 -0400 (EDT) Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030909144717.GA18881@titan.runlevelzero.net> Message-ID: On Tue, 9 Sep 2003, Greg Kurtzer wrote: > On Tue, Sep 09, 2003 at 05:33:28PM +0300, Panu Matilainen told me: > > > Does RHEL2.1 ship with NPTL? > > > > 2.1 doesn't have NPTL, AFAIK. NPTL is much, much newer > > stuff afterall, but will be in 3.0 enterprise line. > > Hrmm... I guess there is a decision to be made. Do we follow > RHEL2 for cAos-1, or move in another direction? Based on all > of our last posts, it seems that building a RHEL2 compat > system is what is needed. I see cAos as a community (collective) response to address the need for a longer lived support 'tail' for RPM based Red Hat derived GNU/Linux systems. RPM based in that Debian space, and Gentoo, and Slackware are not in scope. Red Hat derived in that the early problem space should address the market share leader (not much material commercial SuSE third-party US market seems to exist -- I see one-sies and two-sies only). [Note: I use the term 'market' to denote social-voluntary community support cadre interest as well as commercial-space paid support interest in this piece.] As to RHAS/RHEL vs. RHL base and ongoing support by cAos, part of issue with continuing support going forward on the RHL model, is that the product is consciously set to force end users into an annual upgrade if they wish to remain 'covered' with RH-signed package and up2date support. So I see two current segments -- the RHEL arm into the future (RHEL being the new longer lived branch), and extending the tail on RH 7.3 after 12/31 [although I expected more interest in extending the RH 6.2 tail, which did not develop]. If cAos (or Fedora) are relevant in the base package RHL space, it is solely as a 'safe' backporting updated package locus after RH EOL's a given release, with backporting occurring with a minimal tweak and recompile from an updated RH SRPM, or failing that, more extensive changes [which Red Hat has stated, and I have no reason to doubt, are a time sink with little intellectual reward, and like financial reqard. I (at Owl River) do it as I have to, but the more I have to backport, the more I consider telling the customer that the box is at EOL and needs a rebuild/replacement.] In order to be useful in RHEL space, yum and Jim Wildman's AS 2.1 proof of concept work with Seth on testing dailies are predicated on also having access to (and mirroring and yum-ifying) a binary feed RPM path, or on a willingness to perform and tweak the build updated SRPM process and rely upon non-'official' RPM updates; this 'gearing up process' seems to me pretty much the only reason for cAos in AS 2.1 space; in turn that implies sticking very close to RH SRPMs. [I would consider a 'fix' to the rpm version used, as mentioned on IRC, but that's about it.] The Red Hat license seems to preclude a mixed campus of licensed RHEL and non-licensed servers with rather serious contractual remedies outlined. The risk is too high for a commercial or other organization with a formal IS department concerned with its reputation, to cheat. So having a replica ( knockoff ! ) of RHAS 2.1 without the restricted elements is probably useful for cAos to offer (it provides both a test platform, and can provide a non-RH RHEL license offending way to build hosts with a long RH maintenance lifecycle) -- Paraphrasing, Red Hat has said, and says in its trademark guidelines that replacements for 'anaconda-images' and 'redhat-images' are sufficient to differientiate a distribution -- no legal advice offered; each person has to make their own determination from their own research and counsel. ---------------start disclaimer------------------- I_A_AL, but not your lawyer. I offer legal advice and formal opinion only within the confines of a previously established and explicit attorney-client relationship where privilege may be had; and NEVER on a public list server. ----------------end disclaimers ------------------ So I think an initial RHAS 2.1 knockoff has merit (how much 'market' demand exists is another question). But to be able to credibly crank out updates, you gotta have a base to build upgrades toward and to test on. As I was reading the cAos homepage to frame this piece, it carries these messages (material after the '--' are verbatim): -- stable Linux solution for organizations and individuals that do not need or want to purchase their Linux solution. -- an enterprise level community produced solution -- distribution targeting production environments -- an administrators Operating System ----------------------------------------------- The last two probably reflect the biases which I carry, and Greg and others here carry -- but there is an end user community accustomed to a *nix workstation. They want a tool, and are not particularly interested in maintaining it or changing it -- but changed file formats have to be read, and new capabilities in other operating system space have a way to become 'requirements' as well. So I see having: Current (and then Cautious as it updates, and fading into Closed when it is not longer being updated and a unpatchable security hole appears) for very close replicas; Contrib for room to graft on supported aftermarket parts which the future or other developers bring; and Crazy for the weekend and tryouts of the bleeding edge. Bump the major version of cAos as a installable variant appears, differing substantially as to (1) major kernel change -- memory model, threading, scheduler in the 2.4 kernel series so far (2) non-binary compatible glibc/compiler shift (3) perhaps package tool shifts -- jbj mentioned a plan for six point releases of rpm this next year -- I don't see how, but ... so looking at: http://caosity.org/docs_view.php?subject=Version%20Scheme we might have: cAos-0 RH 8 present build efforts cAos-1 RHAS 2.1 based cAos-2 RHEL-3.- based That's where my current thinking is. -- Russ Herrold From zoratu at datastacks.com Tue Sep 9 10:44:33 2003 From: zoratu at datastacks.com (Isaiah) Date: Tue, 9 Sep 2003 10:44:33 -0700 Subject: [cAos] Re: Why not use an RH Enterprise system for the build? RHEL issues. In-Reply-To: <20030909144544.GA23666@tux.lbl.gov>; from gmkurtzer@lbl.gov on Tue, Sep 09, 2003 at 07:45:44AM -0700 References: <111BCA23190@maiser.uibk.ac.at> <4.3.2.7.2.20030908103438.049eafb0@imap4.lbl.gov> <20030909144544.GA23666@tux.lbl.gov> Message-ID: <20030909104433.B17039@zoratu.com> On Tue, Sep 09, 2003 at 07:45:44AM -0700, Greg Kurtzer wrote: > My initial intention of cAos was to become a new distribution, but I have > had various people in the community request a slightly different path. The short-term goals of the project would be most influential on this subject. If the goal is immediate adoption, it makes more sense to create a harbor for Red Hat refugees. Invariably, cAosity will end up with multiple trees for {arch,idea,compliance} reasons. It is inevitable! So, what's the big deal how many branches there are if they all have the same root? Strive to make it as big as possible, but don't bend over backwards for everything. Let it be up to the package maintainers if they want to support a given platform that doesn't comply with some standard value of work per package. Then the overhead of all extra maintanence work is distributed across the project. A given build includes whatever happens to be ready. If someone misses the date, so what? It's only a goal; maybe they'll be ready for the next one. Yet another thing to consider along the lines of compliance is the ability to recreate any configuration of any version of cAosity at any time in the future. It's a sure way to win over ISO2001 potential "customers." It means a little more thinking about how the pieces fit together, but what else is new? :) -- - Isaiah From rick at linuxmafia.com Tue Sep 9 13:24:38 2003 From: rick at linuxmafia.com (Rick Moen) Date: Tue, 9 Sep 2003 13:24:38 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: References: <20030909144717.GA18881@titan.runlevelzero.net> Message-ID: <20030909202438.GV10351@linuxmafia.com> Quoting R P Herrold (herrold at owlriver.com): > The Red Hat license seems to preclude a mixed campus of licensed RHEL > and non-licensed servers with rather serious contractual remedies > outlined. Well, not the licence per se, but rather the support contract bundled with the licence if you get your RHEL by buying it from Red Hat, Inc. (which is necessary if you require RH technical support and access to signed packages _directly_ from RH, Inc. -- see ttp://www.redhat.com/licenses/). Nothing in the support agreement[1] (again, per se) appears to inhibit RHEL customers from handing out copies to outside parties, if they wish. Possible impediments may lie in copyright and trademark law. (IANAL, TINLA, nor am I trying to finagle legal advice. I'm sympathetic with attorneys' problems in discussing legal topics on public mailing lists, and try to deal with them in a spirit of respect and courtesy.) Copyright law: I'm a little fuzzy on whether any of the RHEL 2.1 packages' terms preclude redistribution[2]. From an earlier examination, I don't think they do, but could be wrong. RH, Inc.'s claim of compilation copyright over the ISOs as a whole asserts GPLv2 terms, for that part. If there are indeed non-redistributable packages, does someone have a list of them? Trademark law: Obviously, there are trademarks images, phrases, stylings, etc. within certain RHEL 2.1 packages (e.g., anaconda-images, redhat-images). My understanding is that non-profit redistribution, even with those trademarked items, by definition cannot infringe, but that for-profit redistribution might, if it might create confusion in the minds of likely RH, Inc. customers as to whether RH, Inc. produced or endorses its would-be competitor's product within the same market. (Additionally, under a post-1997 attempt by some large trademark holders such as Visa, Inc. to expand their claims, some marks are claimed to be so famous that anyone else's commercial use of the mark is claimed to inherently confuse their customers, and thus infringe.) I thought I'd mention that because Red Hat, Inc. persists in intimidating CD vendors and others from offering any product whose name includes any variation on "Red Hat". It's understandable that the firm attempts this, because the logic of trademark law requires that they be aggressive and unreasonable, to minimise the chance of their marks becoming generic. However, it's important to understand that I can sell my "Not Red Hat" distribution all day long and be in no danger whatsoever of anything other than getting toothless nastygrams from Red Hat Legal -- because it obviously could not create the specified type of customer confusion. To the contrary. And giving away items bearing Red Hat's trademarks inherently cannot infringe, either. So, anyhow: > The risk is too high for a commercial or other organization with a > formal IS department concerned with its reputation, to cheat. What you say is very true as stated (up top): Once an organisation deploys hosts under support contract, and for the duration of the self-renewing one-year terms thereof (until the customer cancels), the firm cannot safely also deploy RHEL hosts _not_ under support contract. However, I just thought I'd mention that such an organisation _could_ deploy all RHEL with _no_ support contracts, if it can obtain a copy. This would cut them off from official technical support and _direct_ access to signed updates via RHN, but I vaguely recall that they'd still be able to get those updates (even the signed ones) through other means. I'm in _no_ way saying that cAos won't be a very valuable addition to this mix of options on its own merits. I'm just making sure the other matter gets covered. (If I've missed something important, people's corrections will be most welcome. I'm trying to make sure I understand this matter fundamentally, because other people keep asking me.) [1] My remarks are based on the agreement applied to USA customers. RH, Inc. has, of late, introduced other service-agreement texts for elsewhere in the world, which I have not examined. [2] Please note that I'm not talking about open source vs. proprietary. E.g., the Pine MUA is under (barely) proprietary licence terms, which nonetheless permit redistribution. -- Cheers, Live Faust, die Jung. Rick Moen rick at linuxmafia.com From jim at rossberry.com Tue Sep 9 14:13:51 2003 From: jim at rossberry.com (Jim Wildman) Date: Tue, 9 Sep 2003 17:13:51 -0400 (EDT) Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030909202438.GV10351@linuxmafia.com> Message-ID: http://www.redhat.licenses/rhel_us_2-1.html?country=United+States& section 2.2 2.2 Customer's Computer System. Customer will be responsible for performing operations on Customer's computer system and Red Hat shall have no responsibility to perform operations on Customer's computer system. Customer acknowledges that Red Hat's ability to perform certain Support Services may be conditioned upon access to certain Customer information and access to Customer's computer system as reasonably requested by Red Hat. Such information may include, but is not limited to, the type of hardware Customer is using, a description of the problem for which Customer seeks Support Services, and additional software Customer is using that falls outside the Support Services scope of coverage. Customer understands and agrees that the completeness and accuracy of the information Customer provides to Red Hat may affect Red Hat's ability to provide Support Services. The Support Services purchased by Customer are intended for use only for the benefit of the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Customer and only for the Installed Systems with subscriptions. Customer ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ may not use one subscription for Support Services for more than one ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Installed System. Any unauthorized use of the Support Services will be ^^^^^^^^^^^^^^^^^ deemed to be a material breach of this Agreement. Already been through it with our purchasing people.... can't buy one and update many. So, someone, somewhere has to violate the EULA to get and redistribute the binary updates. On Tue, 9 Sep 2003, Rick Moen wrote: > > However, I just thought I'd mention that such an organisation _could_ > deploy all RHEL with _no_ support contracts, if it can obtain a copy. > This would cut them off from official technical support and _direct_ > access to signed updates via RHN, but I vaguely recall that they'd still > be able to get those updates (even the signed ones) through other means. > > I'm in _no_ way saying that cAos won't be a very valuable addition to > this mix of options on its own merits. I'm just making sure the other > matter gets covered. > > (If I've missed something important, people's corrections will be most > welcome. I'm trying to make sure I understand this matter > fundamentally, because other people keep asking me.) > > [1] My remarks are based on the agreement applied to USA customers. > RH, Inc. has, of late, introduced other service-agreement texts for > elsewhere in the world, which I have not examined. > > [2] Please note that I'm not talking about open source vs. proprietary. > E.g., the Pine MUA is under (barely) proprietary licence terms, which > nonetheless permit redistribution. > > ------------------------------------------------------------------------ Jim Wildman, CISSP, RHCE jim at rossberry.com http://www.rossberry.com From rocky at atipa.com Tue Sep 9 14:35:23 2003 From: rocky at atipa.com (Rocky McGaugh) Date: Tue, 9 Sep 2003 16:35:23 -0500 (CDT) Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: Message-ID: On Tue, 9 Sep 2003, Jim Wildman wrote: > > Already been through it with our purchasing people.... can't buy one > and update many. > > So, someone, somewhere has to violate the EULA to get and redistribute > the binary updates. > No, someone can get the SRPMS via anonyFTP and distribute however they wish. -- Rocky McGaugh Atipa Technologies rocky at atipatechnologies.com rmcgaugh at atipa.com 1-785-841-9513 x3110 http://67.8450073/ perl -e 'print unpack(u, ".=W=W+F%T:7\!A+F-O;0H`");' From lance at uklinux.net Tue Sep 9 14:54:57 2003 From: lance at uklinux.net (Lance Davis) Date: Tue, 9 Sep 2003 22:54:57 +0100 (BST) Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030909202438.GV10351@linuxmafia.com> Message-ID: On Tue, 9 Sep 2003, Rick Moen wrote: > Quoting R P Herrold (herrold at owlriver.com): > > > The Red Hat license seems to preclude a mixed campus of licensed RHEL > > and non-licensed servers with rather serious contractual remedies > > outlined. > > Well, not the licence per se, but rather the support contract bundled > with the licence if you get your RHEL by buying it from Red Hat, Inc. > (which is necessary if you require RH technical support and access to > signed packages _directly_ from RH, Inc. -- see > ttp://www.redhat.com/licenses/). Nothing in the support agreement[1] > (again, per se) appears to inhibit RHEL customers from handing out > copies to outside parties, if they wish. Possible impediments may lie > in copyright and trademark law. Errmm this http://www.redhat.com/licenses/rhel_us_2-1.html?country=United+States is actually a very wooly document , that appears to only cover the person/body that has paid the subscription license, and prevents them from installing on more than one system, allows redhat to audit theior systems and fine them 20% extra if they are more than 5% adrift in their payment for licenses etc etc. However it clearly states that :- Red Hat Enterprise Linux itself is a collective work under U.S. Copyright Law. Subject to the trademark use limitations set forth below, Red Hat grants Customer a license in this collective work pursuant to the GNU General Public License. > I thought I'd mention that because Red Hat, Inc. persists in > intimidating CD vendors and others from offering any product whose name > includes any variation on "Red Hat". It's understandable that the firm > attempts this, because the logic of trademark law requires that they be > aggressive and unreasonable, to minimise the chance of their marks > becoming generic. It is my understandiung that they could also allow those vendors to use their trademark and acknowledge it, without risk of losing it .,. > However, it's important to understand that I can sell > my "Not Red Hat" distribution all day long and be in no danger > whatsoever of anything other than getting toothless nastygrams from Red > Hat Legal Is that all you get ?? Do they not persist with their threats of legal action ?? What about removing their trademark images ??? -- because it obviously could not create the specified type of > customer confusion. Indeed :) Regards Lance -- uklinux.net - The ISP of choice for the discerning Linux user. From lance at uklinux.net Tue Sep 9 14:56:15 2003 From: lance at uklinux.net (Lance Davis) Date: Tue, 9 Sep 2003 22:56:15 +0100 (BST) Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: Message-ID: On Tue, 9 Sep 2003, Rocky McGaugh wrote: > > On Tue, 9 Sep 2003, Jim Wildman wrote: > > > > > Already been through it with our purchasing people.... can't buy one > > and update many. > > > > So, someone, somewhere has to violate the EULA to get and redistribute > > the binary updates. > > > > No, someone can get the SRPMS via anonyFTP and distribute however they > wish. Indeed they are published as https://rhn.redhat.com/errata/rh21as-errata.html without any hint that they are anything other than GPL ... Lance -- uklinux.net - The ISP of choice for the discerning Linux user. From zoratu at datastacks.com Tue Sep 9 15:12:04 2003 From: zoratu at datastacks.com (Isaiah) Date: Tue, 9 Sep 2003 15:12:04 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: ; from lance@uklinux.net on Tue, Sep 09, 2003 at 10:56:15PM +0100 References: Message-ID: <20030909151204.A18672@zoratu.com> The key term is services. If you got the built packages through RHN, and if you're using the services and support components of the contractual agreement you entered into, you cannot redistribute for hosts beyond what you've paid. If you download, strip of IP/TM/branding--the part Red Hat __really__ cares about--and rebuild/redistribute, you're in the clear. -- - Isaiah From jim at rossberry.com Tue Sep 9 15:28:27 2003 From: jim at rossberry.com (Jim Wildman) Date: Tue, 9 Sep 2003 18:28:27 -0400 (EDT) Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: Message-ID: Correct. I should have said "Red Hat generated and signed binaries" On Tue, 9 Sep 2003, Rocky McGaugh wrote: > > On Tue, 9 Sep 2003, Jim Wildman wrote: > > > > > Already been through it with our purchasing people.... can't buy one > > and update many. > > > > So, someone, somewhere has to violate the EULA to get and redistribute > > the binary updates. > > > > No, someone can get the SRPMS via anonyFTP and distribute however they > wish. > > ------------------------------------------------------------------------ Jim Wildman, CISSP, RHCE jim at rossberry.com http://www.rossberry.com From jim at rossberry.com Tue Sep 9 15:29:33 2003 From: jim at rossberry.com (Jim Wildman) Date: Tue, 9 Sep 2003 18:29:33 -0400 (EDT) Subject: [cAos] Re: Why not use an RH Enterprise system for the build? RHEL issues. (fwd) Message-ID: Sent this to the wrong list, though I think many of you saw it there, too. ------------------------------------------------------------------------ Jim Wildman, CISSP, RHCE jim at rossberry.com http://www.rossberry.com ---------- Forwarded message ---------- Date: Tue, 9 Sep 2003 13:37:21 -0400 (EDT) From: Jim Wildman To: rhel-rebuild list Subject: Re: Why not use an RH Enterprise system for the build? RHEL issues. I think this is the corrrect problem space. ie, those who want the technical advantages of Red Hat engineering, patching, etc, but who do not or can not or will not pay the $$$$. If we build cA0s around RHEL 2.1, then we've accomplished the goal of extending the support life of the 7.x series for another 3 years, sans the fees. cAos 2.x and RHEL3 == RH9 extended We need to keep the problem spaces separate. Those of us who want a supported 7.x series _probably_ don't care about the latest KDE _on that platform_. We are running servers that we want to essentially leave alone until we can justify replacing the hardware (1-3 years). We are probably not going to be running 'front line' commercial apps on these (Oracle, etc). Someone who is running their business on Linux with Oracle and cares about support (ie, Bank One, my employer) will REQUIRE that the software/support gets purchased. Believe me, I can get a package that costs $1000 per server installed/approved a lot faster than one that costs $0. Those who want the latest bleeding edge desktop apps also must want the churn that goes with it. (They're going to get it whether they want it or not). Fedora, Freshrpms, et al have this space covered. So I see this. 1) replace the installer (or automate the strip out of the RH copyright stuff) 2) mirror the src rpms for rhel, auto rebuild them on a controlled platform (Russ and Greg's work on the rebuilder, chroot environments, etc). This automatically means we are only dealing with OSS (or they couldn't release the src rpms). 3) QA the result to a published spec (ie, binary rpms have been built in the following environment and successfully installed on the following platforms, blah blah) and push out for others to grab. 4) do this for the 7.x/rhel2.1 == cAos 1.x set 5) do this for the 9/rhel3.x == cAos 2.x set Now you are exactly where RHEL customers are without the $$$ and without the corporate safety net of an 800 number to put in the level 1 help desk database. That is where I hear people on the rhl and rhel beta/devel lists wanting to be. On Tue, 9 Sep 2003, Greg Kurtzer wrote: > On Mon, Sep 08, 2003 at 03:02:46PM -0700, Jed Donnelley told me: > > Redhat patches. Ideally this would be a shared effort (e.g. DOE?). There > > is an effort to do a Linux distribution being led by some folks at LBL > > (e.g. Greg Kurtzer, also cc'ed): > > > > http://caosity.org/ > > > > However, again that's more of its own distribution, not an effort to track > > Redhat. It seems to me that your position with Fermi Linux is closer to > > My initial intention of cAos was to become a new distribution, but I have had > various people in the community request a slightly different path. > > We are now _considering_ having the base cAos-1 system fully compatible with a > RHEL2 base, and cAos-2 to be RHEL3 compatible. By compatible, I mean that we > will be using the same source rpms as Red Hat distributes for the EL base > recompiled on our supported architectures (presently i686 and x86_64). On top > of this we will maintain community code. There are still _many_ details to be > worked out as these ideas are still young. > > So in a nutshell, we may be releasing a rebuilt base of RHEL that is > completely open in a packaged form (ie. ISO and network installers) and > maintained. > > As I said, we are still considering this, and it will change a much of our > initial goals and current build infrastructure (not to mention complicate many > things like newer package dependencies). We are very open to thoughts and > comments. > > Greg > ------------------------------------------------------------------------ Jim Wildman, CISSP, RHCE jim at rossberry.com http://www.rossberry.com From rick at linuxmafia.com Tue Sep 9 19:44:24 2003 From: rick at linuxmafia.com (Rick Moen) Date: Tue, 9 Sep 2003 19:44:24 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: References: <20030909202438.GV10351@linuxmafia.com> Message-ID: <20030910024424.GY10351@linuxmafia.com> Quoting Jim Wildman (jim at rossberry.com): > http://www.redhat.licenses/rhel_us_2-1.html?country=United+States& > section 2.2 Please note that the limitation you underlined is on the _support services_, not the software. I tried to be extremely clear about that. > Already been through it with our purchasing people.... can't buy one > and update many. I already said that. A customer who is under the support contract is limited as to what deployments he may make within his firm. However (to reiterate), I have found nothing in the service contract that prohibits the customer redistributing the software, even during an unexpired, in-force service contract's duration. > So, someone, somewhere has to violate the EULA to get and redistribute > the binary updates. My point is that I can find no violation of any legal obligation in doing so[1]. (Doing it for profit would probably be trademark infringement as to the materials within the CDs that embody RH, Inc's registered marks. Please see my earlier post.) [1] To reiterate: The RHEL 2.1 CDs may include some software whose terms of usage preclude redistribution, but I have not yet identified any such. -- Cheers, "Linux means never having to delete your love mail." Rick Moen -- Don Marti rick at linuxmafia.com From rick at linuxmafia.com Tue Sep 9 19:47:25 2003 From: rick at linuxmafia.com (Rick Moen) Date: Tue, 9 Sep 2003 19:47:25 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: References: Message-ID: <20030910024725.GZ10351@linuxmafia.com> Quoting Lance Davis (lance at uklinux.net): > Indeed they are published as > > https://rhn.redhat.com/errata/rh21as-errata.html > > without any hint that they are anything other than GPL ... At the risk of indulging mild licensing pedantry, there is plenty in RHEL 2.1 that is not GPL: XFree86 is MIT/X-licensed, Mozilla is MPL, various BSD utils are BSD-licensed, Apache is Apache-licensed, Pine is under a proprietary but redistribution-allowed licence, etc. -- Cheers, "Please return all dogmas to their orthodox positions." Rick Moen -- Brad Johnson, in r.a.sf.w.r-j rick at linuxmafia.com From rick at linuxmafia.com Tue Sep 9 20:20:54 2003 From: rick at linuxmafia.com (Rick Moen) Date: Tue, 9 Sep 2003 20:20:54 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030909151204.A18672@zoratu.com> References: <20030909151204.A18672@zoratu.com> Message-ID: <20030910032054.GA10351@linuxmafia.com> Quoting Isaiah (zoratu at datastacks.com): > The key term is services. I agree, but let's please be careful what conclusions we draw from that.[1] > If you got the built packages through RHN, and if you're using the > services and support components of the contractual agreement you > entered into, you cannot redistribute for hosts beyond what you've > paid. The conclusion is, unfortunately, non-sequitur. If you have seen any legal obligations that inhibit redistribution (other than trademark concerns as to for-profit redistribution), please post details. Thanks! [1] In hopes of being a bit less terse and perhaps more helpful, here's my overall understanding: RH, Inc. happens to offer the RHEL software to the public only as part of a bundle that includes a one-year, self-renewing support contract. The contract binds the customer in certain ways during its term. After the first year, it can be terminated by the customer with a specified amount of advance notice, with pro-rata refund to the customer. The contract terms do _not_ purport to prohibit redistribution. Someone who receives a copy thus has received the software _unbundled_ from the support contract, and is subject only to the various codebases' licence restrictions under copyright law, plus the obligation to not infringe RH, Inc.'s copyright. Again, if there's some encumbrance I've missed, please point out its specifics to me. -- Cheers, kill -9 them all. Rick Moen Let init sort it out. rick at linuxmafia.com From lance at uklinux.net Tue Sep 9 20:22:05 2003 From: lance at uklinux.net (Lance Davis) Date: Wed, 10 Sep 2003 04:22:05 +0100 (BST) Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030910024725.GZ10351@linuxmafia.com> Message-ID: On Tue, 9 Sep 2003, Rick Moen wrote: > Quoting Lance Davis (lance at uklinux.net): > > > Indeed they are published as > > > > https://rhn.redhat.com/errata/rh21as-errata.html > > > > without any hint that they are anything other than GPL ... > > At the risk of indulging mild licensing pedantry, there is plenty in > RHEL 2.1 that is not GPL: XFree86 is MIT/X-licensed, Mozilla is MPL, > various BSD utils are BSD-licensed, Apache is Apache-licensed, Pine is > under a proprietary but redistribution-allowed licence, etc. With a little further pedantry - I was referring to the errata - rather than the packages themselves ... Regards Lance -- uklinux.net - The ISP of choice for the discerning Linux user. From rick at linuxmafia.com Tue Sep 9 20:24:57 2003 From: rick at linuxmafia.com (Rick Moen) Date: Tue, 9 Sep 2003 20:24:57 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030910024424.GY10351@linuxmafia.com> References: <20030909202438.GV10351@linuxmafia.com> <20030910024424.GY10351@linuxmafia.com> Message-ID: <20030910032457.GB10351@linuxmafia.com> Whoops, just to correct my own post: > > So, someone, somewhere has to violate the EULA to get and redistribute > > the binary updates. > > My point is that I can find no violation of any legal obligation in > doing so. My apologies! I failed to notice that you were talking about _binary updates_ despite your being very clear about that. I was still fixating on the legal encumbrances against RHEL itself. I have not examined any licence agreements applicable to RH's updating service, only the various obstacles to redistribution of RHEL. So, I appreciate your addressing the former. -- Cheers, Wall Street has all the emotional stability of a Rick Moen thirteen-year-old girl. -- Louis Rukeyser rick at linuxmafia.com From lance at uklinux.net Tue Sep 9 20:40:04 2003 From: lance at uklinux.net (Lance Davis) Date: Wed, 10 Sep 2003 04:40:04 +0100 (BST) Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030910032054.GA10351@linuxmafia.com> Message-ID: On Tue, 9 Sep 2003, Rick Moen wrote: > Quoting Isaiah (zoratu at datastacks.com): > > > The key term is services. > > I agree, but let's please be careful what conclusions we draw from > that.[1] > > > If you got the built packages through RHN, and if you're using the > > services and support components of the contractual agreement you > > entered into, you cannot redistribute for hosts beyond what you've > > paid. > > The conclusion is, unfortunately, non-sequitur. If you have seen any > legal obligations that inhibit redistribution (other than trademark > concerns as to for-profit redistribution), please post details. Thanks! > [1] In hopes of being a bit less terse and perhaps more helpful, here's > my overall understanding: RH, Inc. happens to offer the RHEL software > to the public only as part of a bundle that includes a one-year, > self-renewing support contract. The contract binds the customer in > certain ways during its term. After the first year, it can be > terminated by the customer with a specified amount of advance notice, > with pro-rata refund to the customer. The contract terms do _not_ > purport to prohibit redistribution. > > Someone who receives a copy thus has received the software _unbundled_ > from the support contract, and is subject only to the various codebases' > licence restrictions under copyright law, plus the obligation to not > infringe RH, Inc.'s copyright. I totally agree - the license for rhel is perfectly clear :- Red Hat Enterprise Linux itself is a collective work under U.S. Copyright Law. Subject to the trademark use limitations set forth below, Red Hat grants Customer a license in this collective work pursuant to the GNU General Public License. Per the agreement you cannot install on systems you havent paid for, but there is nothing that claims to limit your rights under the GPL to redistribute the software that you have received. Were there to be it would not be in accordance with the GPL under which it has been released. Lance -- uklinux.net - The ISP of choice for the discerning Linux user. From rick at linuxmafia.com Tue Sep 9 20:47:47 2003 From: rick at linuxmafia.com (Rick Moen) Date: Tue, 9 Sep 2003 20:47:47 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: References: <20030909202438.GV10351@linuxmafia.com> Message-ID: <20030910034747.GC10351@linuxmafia.com> Quoting Lance Davis (lance at uklinux.net): > Errmm this > http://www.redhat.com/licenses/rhel_us_2-1.html?country=United+States > is actually a very wooly document ,.... I agree. I spent a fair amount of time reading it carefully, before I was able (I think) to take its measure. > ...that appears to only cover the person/body that has paid the > subscription license, and prevents them from installing on more than > one system.... More than one system within (in effect) _his own_ business entity. The stated restriction (in clause 4) related to the defined term "Installed System". In clause 1A, we find: The term "Installed Systems" means the number of Systems on which Customer installs the Software. The term "System" means the hardware on which the Software is installed, which may be, without limitation, a server, a work station, a blade or an engine, as applicable. The clause 4 audit provisions grant RH, Inc. permission to "audit Customer's facilities and records from time to time in order to verify Customer's compliance" to make sure the customer has not "underreported the number of Installed Systems or amount of Services". ("Services" means "the Support Services and RHEN".) Please note that nowhere in there does the agreement purport to limit the customer's ability to _redistribute_ the software in question, only over where he may _install_ it. (The latter limitation is probably, by implication, applicable just within the firm.) They have to do a balancing act on that matter, tying the obligation to "Installed Systems" and "Services", because attempting to encumber the software itself would get them in very hot water with upstream copyright owners, many of whom use licences (e.g., GPLv2) that would bar RH, Inc. from _any_ distribution if they imposed such limitations. > However it clearly states that :- > > Red Hat Enterprise Linux itself is a collective work under U.S. Copyright > Law. Subject to the trademark use limitations set forth below, Red Hat > grants Customer a license in this collective work pursuant to the GNU > General Public License. That's the compilation copyright I referred to earlier. A compilation copyright is title to the creative work in arranging third-party works into a composite whole. E.g., an editor of a short-story anthology would enjoy copyright over the way he put together the volume, and nobody else would have the right to reissue the same collection of stories done exactly the same way, even with the story authors' permission. When I operated a dial-up BBS, my policies bulletin asserted compilation copyright over the design and arrangement of the BBS as a whole. This claim would (if held to be sufficiently creative and substantive to create a valid copyright interest) prevent other sysops from lawfully cloning my BBS as a whole. Please note that a compilation copyright has no necessary connection to the copyrights and licence terms of the constituent works. (Exception: Arguably, GPLv2 is the _only_ licence RH, Inc. could successfully assert over its compilation, because anything else would create licence conflict with the licences of GPL-covered works within the distribution.) > It is my understandiung that they could also allow those vendors to use > their trademark and acknowledge it, without risk of losing it .,. Yes. This would be a rational thing to do. Unfortunately, most firms with trademarks at risk of becoming generic succumb to the temptation of draconian enforcement efforts. I really can't blame them for doing so. > Is that all you get ?? Do they not persist with their threats of legal > action ?? In the "anyone can technically sue anyone over anything" sense, yes. But any legal action in that case would be easily dismissed, perhaps with sanctions for frivilous litigation. > What about removing their trademark images ??? To be sure. Back at $FIRM, where we maintained a RH-derived distribution that we supplied with our Linux servers and workstations (the one now known as Vermillion), we did a great deal of that, every time we worked on an RH, Inc. release to come up with our own. -- Cheers, "I don't like country music, but I don't mean to denigrate Rick Moen those who do. And, for the people who like country music, rick at linuxmafia.com denigrate means 'put down'." -- Bob Newhart From rick at linuxmafia.com Tue Sep 9 20:57:04 2003 From: rick at linuxmafia.com (Rick Moen) Date: Tue, 9 Sep 2003 20:57:04 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: References: <20030910032054.GA10351@linuxmafia.com> Message-ID: <20030910035704.GD10351@linuxmafia.com> Quoting Lance Davis (lance at uklinux.net): > I totally agree - the license for rhel is perfectly clear :- > Red Hat Enterprise Linux itself is a collective work under U.S. > Copyright Law. Subject to the trademark use limitations set forth below, > Red Hat grants Customer a license in this collective work pursuant to the > GNU General Public License. Please note that the above licence applies only to RH, Inc.'s copyright interest in the _compilation_, not to the constituent packages. This is the same compilation-copyright notice that regular RH releases have carried ever since around 4.x (if I remember correctly). Just to be very clear about this, when I noticed it at the time (many years ago), I interpreted it as a very cool, benign, and community-spirited gesture on the company's part. I still think so. They were essentially saying "To the extent we have an ownership interest in the way this distribution is put together, we're copylefting it for the public's benefit." > Per the agreement you cannot install on systems you havent paid for, but > there is nothing that claims to limit your rights under the GPL to > redistribute the software that you have received. Yes. Further, my reading of the limitation on installations is that it seems to apply only to systems within the customer's business entity -- but that point could be argued. -- Cheers, "Transported to a surreal landscape, a young girl kills the first Rick Moen woman she meets, and then teams up with three complete strangers rick at linuxmafia.com to kill again." -- Rick Polito's That TV Guy column, describing the movie _The Wizard of Oz_ From rick at linuxmafia.com Tue Sep 9 21:02:48 2003 From: rick at linuxmafia.com (Rick Moen) Date: Tue, 9 Sep 2003 21:02:48 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030910032054.GA10351@linuxmafia.com> References: <20030909151204.A18672@zoratu.com> <20030910032054.GA10351@linuxmafia.com> Message-ID: <20030910040248.GE10351@linuxmafia.com> Once again, I'm obliged to correct my post and apologise. > I agree, but let's please be careful what conclusions we draw from > that.[1] > > > If you got the built packages through RHN, and if you're using the > > services and support components of the contractual agreement you > > entered into, you cannot redistribute for hosts beyond what you've > > paid. > > The conclusion is, unfortunately, non-sequitur. If you have seen any > legal obligations that inhibit redistribution (other than trademark > concerns as to for-profit redistribution), please post details. Thanks! When you say "built packages from RHN", that is of course subject to whatever contract customers enter into for those services. My apologies for (again) confusing that with matters concerning RHEL, which is a different subject -- and is what I was still thinking about. -- Cheers, The shortest distance between two puns is a straightline. Rick Moen rick at linuxmafia.com From zoratu at datastacks.com Tue Sep 9 21:22:23 2003 From: zoratu at datastacks.com (Isaiah) Date: Tue, 9 Sep 2003 21:22:23 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030910032054.GA10351@linuxmafia.com>; from rick@linuxmafia.com on Tue, Sep 09, 2003 at 08:20:54PM -0700 References: <20030909151204.A18672@zoratu.com> <20030910032054.GA10351@linuxmafia.com> Message-ID: <20030909212223.A20191@zoratu.com> On Tue, Sep 09, 2003 at 08:20:54PM -0700, Rick Moen wrote: > The conclusion is, unfortunately, non-sequitur. If you have seen any > legal obligations that inhibit redistribution (other than trademark > concerns as to for-profit redistribution), please post details. Thanks! I've included them below. They are certainly NOT non-sequitur. > [1] In hopes of being a bit less terse and perhaps more helpful, here's > my overall understanding: RH, Inc. happens to offer the RHEL software to > the public only as part of a bundle that includes a one-year, > self-renewing support contract. The contract binds the customer in > certain ways during its term. After the first year, it can be terminated > by the customer with a specified amount of advance notice, with pro-rata > refund to the customer. The contract terms do _not_ purport to prohibit > redistribution. s,RH,Red Hat,g You must've read a different license agreement than I read. For your convenience, it's included with the product. --> This Subscription Agreement (the "Agreement") is between Red Hat, Inc. ("Red Hat") and any purchaser or user ("Customer") of Red Hat Enterprise Linux AS (or Red Hat Linux Advanced Server), Red Hat Enterprise Linux ES or Red Hat Enterprise Linux WS (collectively, "Red Hat Enterprise Linux" or "the Software"). PLEASE READ THIS AGREEMENT CAREFULLY BEFORE PURCHASING OR USING RED HAT ENTERPRISE LINUX. BY USING OR PURCHASING RED HAT ENTERPRISE LINUX, CUSTOMER SIGNIFIES ITS ASSENT TO THIS AGREEMENT. IF YOU ARE ACTING ON BEHALF OF AN ENTITY, THEN YOU REPRESENT THAT YOU HAVE THE AUTHORITY TO ENTER INTO THIS AGREEMENT ON BEHALF OF THAT ENTITY. IF CUSTOMER DOES NOT ACCEPT THE TERMS OF THIS AGREEMENT, THEN IT MUST NOT USE OR PURCHASE RED HAT ENTERPRISE LINUX. This Subscription Agreement (the "Agreement") is between Red Hat, Inc. ("Red Hat") and any purchaser or user ("Customer") of Red Hat Enterprise Linux AS (or Red Hat Linux Advanced Server), Red Hat Enterprise Linux ES or Red Hat Enterprise Linux WS (collectively, "Red Hat Enterprise Linux" or "the Software"). PLEASE READ THIS AGREEMENT CAREFULLY BEFORE PURCHASING OR USING RED HAT ENTERPRISE LINUX. BY USING OR PURCHASING RED HAT ENTERPRISE LINUX, CUSTOMER SIGNIFIES ITS ASSENT TO THIS AGREEMENT. IF YOU ARE ACTING ON BEHALF OF AN ENTITY, THEN YOU REPRESENT THAT YOU HAVE THE AUTHORITY TO ENTER INTO THIS AGREEMENT ON BEHALF OF THAT ENTITY. IF CUSTOMER DOES NOT ACCEPT THE TERMS OF THIS AGREEMENT, THEN IT MUST NOT USE OR PURCHASE RED HAT ENTERPRISE LINUX. <-- Those three paragraphs, at the beginning of the license agreement, make it quite clear you cannot _use_ or _purchase_ (heh) RHEL in good faith without agreeing to Red Hat's terms and conditions. Now let's move onto what quantifies RHEL, defined in the next paragraph. --> Red Hat Enterprise Linux are Linux-based operating systems provided under Red Hat's trademarks subject to the applicable end user license agreement. The term "Services" as used in this Agreement means, collectively, the Support Services and RHEN, each as defined herein. The term "Installed Systems" means the number of Systems on which Customer installs the Software. The term "System" means the hardware on which the Software is installed, which may be, without limitation, a server, a work station, a blade or an engine, as applicable. The initial number of Installed Systems is the number of copies of the Software that Customer purchases. <-- The ISOs are provided ONLY through RHEN. News flash: that means you can't distribute the ones Red Hat built for RHEL beyond the machines with legitimate entitlements for RHEL. For your clarification, here are the definitions you agreed to in the license: --> "Platform" means the combination of the CPU and other hardware a computer system uses, its exact operating system including the version number, the compiler required, the type of libraries (e.g. libc, glibc), and the type of crypto library available (e.g. libcrypt, pam). Changes to any of these components which break binary compatibility, or prohibit functioning (including recompiling) of software, unless modified by Red Hat, constitute a different platform and may disqualify it from receiving Support Services. Should a platform be discontinued during the term of this Agreement, Red Hat will have the option to continue supporting Customer on that platform or to issue Customer a pro-rata refund. Red Hat Enterprise Network ("RHEN") is an internet solution for managing one or more systems running Red Hat Enterprise Linux that allows Customers to register one or more Installed Systems, receive errata notification, update Installed Systems with the errata, search errata and download ISO images. RHEN also includes the following functionality: package profile comparison, systems search, systems grouping, ability for multiple systems administrators to manage Installed Systems and update systems by sets. <-- And now, let's move onto the part Lance doesn't understand--the product license is non-transferrable. ;) --> This Agreement, and all Services provided by Red Hat pursuant to this Agreement, may not be transferred, assigned or distributed without the prior written consent of Red Hat. Any attempted transfer, assignment or distribution without Red Hat's prior written consent shall terminate this Agreement, and Red Hat shall have no further obligation hereunder. <-- It's quite clear: get Red Hat to agree to your transfer and you're set to use what they've provided as part of a program you agreed to in the first place. The license DOES say the component EULAs are not limited by the product license agreement. Red Hat conforms to your GPL-shaped wire-frame shield by providing individual software components of RHEL in SRPM form, freely available and distributable under the component EULA terms. I'm Quite Sure(tm) this is how Red Hat's legal counsel will present the issue (Mark's _extensive_ background is IP). It is very simple and very clear, I don't know why some of you are being so stubborn, especially when the obvious workaround is to simply rebuild the SRPMs and ENTIRELY AVOID this topic. It's almost like you're looking for a fight for the sake of fighting. If that's the case, see ya & lotsa luck. -- - Isaiah From greg at runlevelzero.net Tue Sep 9 22:18:43 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Tue, 9 Sep 2003 22:18:43 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030909212223.A20191@zoratu.com> References: <20030909151204.A18672@zoratu.com> <20030910032054.GA10351@linuxmafia.com> <20030909212223.A20191@zoratu.com> Message-ID: <20030910051843.GB31256@titan.runlevelzero.net> On Tue, Sep 09, 2003 at 09:22:23PM -0700, Isaiah told me: > I'm Quite Sure(tm) this is how Red Hat's legal counsel will present the > issue (Mark's _extensive_ background is IP). It is very simple and very > clear, I don't know why some of you are being so stubborn, especially when > the obvious workaround is to simply rebuild the SRPMs and ENTIRELY AVOID > this topic. It's almost like you're looking for a fight for the sake of > fighting. If that's the case, see ya & lotsa luck. I don't think that anyone is looking for a fight as opposed to a friendly (rather heated) discussion of opinions. Obviously I can't speak for everyone on this, but that is my interpretation. I agree with you that since this is something that can be avoided, then we should. Also I am really not supportive of requiring RHEL to build the first iteration of cAos, so RH7x should be the build host (IMHO). Greg -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From rick at linuxmafia.com Tue Sep 9 22:27:32 2003 From: rick at linuxmafia.com (Rick Moen) Date: Tue, 9 Sep 2003 22:27:32 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030909212223.A20191@zoratu.com> References: <20030909151204.A18672@zoratu.com> <20030910032054.GA10351@linuxmafia.com> <20030909212223.A20191@zoratu.com> Message-ID: <20030910052732.GG10351@linuxmafia.com> Quoting Isaiah (zoratu at datastacks.com): > For your convenience, it's included with the product. [Service agreement text, snippet:] > IF CUSTOMER DOES NOT ACCEPT THE TERMS OF THIS AGREEMENT, THEN IT MUST > NOT USE OR PURCHASE RED HAT ENTERPRISE LINUX. > Those three paragraphs, at the beginning of the license agreement, make > it quite clear you cannot _use_ or _purchase_ (heh) RHEL in good faith > without agreeing to Red Hat's terms and conditions. Actually, no, it does not say that. It claims that this support-service subscription is an integral part of the bundle of software + service agreement being offered for sale, and that the purchasing customer must consent to it in order for that customer to deploy the particular instance of RHEL software thus bundled. That doesn't address redistribution of the software at all. (We'll get to the "non-transferrable" bit below.) > The ISOs are provided ONLY through RHEN. This once again begs the question: What if anything impairs lawful customers from redistributing? The "three paragraphs" you quoted do not do so. > News flash: that means you can't distribute the ones Red Hat built > for RHEL beyond the machines with legitimate entitlements for RHEL. That doesn't follow from anything you've thus far posted. > For your clarification, here are the definitions you agreed to in the > license: Thank you, but I've seen those. > And now, let's move onto the part Lance doesn't understand--the > product license is non-transferrable. ;) > --> > This Agreement, and all Services provided by Red Hat pursuant to this > Agreement, may not be transferred, assigned or distributed without the > prior written consent of Red Hat. Any attempted transfer, assignment or > distribution without Red Hat's prior written consent shall terminate this > Agreement, and Red Hat shall have no further obligation hereunder. > <-- That covers the _services_, not the software. > I'm Quite Sure(tm) this is how Red Hat's legal counsel will present the > issue (Mark's _extensive_ background is IP). Well, I'm not especially interested in how RH's hired legal flack would argue. That's not particularly relevant to the issue under discussion. > It's almost like you're looking for a fight for the sake of fighting. I'm not trying to fight with anyone. I'm just in the habit of studying and understanding legal issues and software licensing. I'm not arguing that anyone should do or not do anything, but rather trying to make sure I understand the rights and duties that actually pertain between various parties. -- Cheers, Remember: The day after tomorrow is the third day Rick Moen of the rest of your life. rick at linuxmafia.com From pmatilai at welho.com Tue Sep 9 23:12:18 2003 From: pmatilai at welho.com (Panu Matilainen) Date: Wed, 10 Sep 2003 09:12:18 +0300 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: References: Message-ID: <1063174338.3f5ec0c26086d@webmail.welho.com> Quoting Rocky McGaugh : > > On Tue, 9 Sep 2003, Jim Wildman wrote: > > > > > Already been through it with our purchasing people.... can't buy one > > and update many. > > > > So, someone, somewhere has to violate the EULA to get and redistribute > > the binary updates. > > > > No, someone can get the SRPMS via anonyFTP and distribute however they > wish. ..as long as you keep in line with RH trademark guidelines: you can grab those SRPMS and rebuild the lot but you can't call it anything RH* anymore, and you need to replace the contents of redhat-logos and IIRC anaconda-images with your own. -- - Panu - From rick at linuxmafia.com Tue Sep 9 23:37:11 2003 From: rick at linuxmafia.com (Rick Moen) Date: Tue, 9 Sep 2003 23:37:11 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <1063174338.3f5ec0c26086d@webmail.welho.com> References: <1063174338.3f5ec0c26086d@webmail.welho.com> Message-ID: <20030910063711.GH10351@linuxmafia.com> Quoting Panu Matilainen (pmatilai at welho.com): > ..as long as you keep in line with RH trademark guidelines: you can > grab those SRPMS and rebuild the lot but you can't call it anything > RH* anymore, and you need to replace the contents of redhat-logos and > IIRC anaconda-images with your own. It should be noted that this exceeds considerably the requirements of trademark law. The company's requests reflect the usual maximalist tendencies endemic in trademark protection, and should not be confused with the law. (That's not to say that complying with RH's "guidelines" might not be an excellent idea, on the theory of avoiding conflict.) -- Cheers, find / -user your -name base -print | xargs chown us:us Rick Moen rick at linuxmafia.com From jn at it.swin.edu.au Tue Sep 9 23:47:05 2003 From: jn at it.swin.edu.au (John Newbigin) Date: Wed, 10 Sep 2003 16:47:05 +1000 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <1063174338.3f5ec0c26086d@webmail.welho.com> References: <1063174338.3f5ec0c26086d@webmail.welho.com> Message-ID: <3F5EC8E9.2010805@it.swin.edu.au> Panu Matilainen wrote: > > > ..as long as you keep in line with RH trademark guidelines: you can > grab those SRPMS and rebuild the lot but you can't call it anything > RH* anymore, and you My 2c on this issue. AFAIK, you can't call it "Red Hat" but you can call it "RH". All that should be necessary to be able to distribute it is replace the images which RedHat have identified as requiring removal and call it RHEL. John. -- Information Technology Innovation Group School of Information Technology Swinburne University of Technology Melbourne, Australia http://www.it.swin.edu.au/staff/jnewbigin From rick at linuxmafia.com Tue Sep 9 23:55:18 2003 From: rick at linuxmafia.com (Rick Moen) Date: Tue, 9 Sep 2003 23:55:18 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030909212223.A20191@zoratu.com> References: <20030909151204.A18672@zoratu.com> <20030910032054.GA10351@linuxmafia.com> <20030909212223.A20191@zoratu.com> <20030910052732.GG10351@linuxmafia.com> Message-ID: <20030910065518.GA16548@linuxmafia.com> Just something I hadn't really noticed the first time: Quoting Isaiah (zoratu at datastacks.com): > The license DOES say the component EULAs are not limited by the > product license agreement. Red Hat conforms to your GPL-shaped > wire-frame shield by providing individual software components of RHEL > in SRPM form, freely available and distributable under the component > EULA terms. I think there's perhaps a bit of confusion about the ramifications of GPLv2 upstream licensing in this context. Yes, RH's release of SRPMs does indeed fully discharge their obligations under GPLv2 clause 3b. However, that's not the GPL provision that constrains Red Hat, Inc. from prohibiting redistribution.[1] It's actually clause 7 that blocks them from doing that: 7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. Clauses 1 and 2 (among others) require that any redistribution include all the upstream rights, including the right to redistribute source, binaries, or any other derivative works. Therefore, either Red Hat, Inc. must pass along those rights or may not distribute the covered works at all. [1] Technically, of course, this would constrain them only as to GPL-covered code from upstream, not as to other-licensed code in RHEL or codebases whose copyrights they own. -- Cheers, Rick Moen Age, baro, fac ut gaudeam. rick at linuxmafia.com From zoratu at datastacks.com Wed Sep 10 00:11:04 2003 From: zoratu at datastacks.com (Isaiah) Date: Wed, 10 Sep 2003 00:11:04 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030910052732.GG10351@linuxmafia.com>; from rick@linuxmafia.com on Tue, Sep 09, 2003 at 10:27:32PM -0700 References: <20030909151204.A18672@zoratu.com> <20030910032054.GA10351@linuxmafia.com> <20030909212223.A20191@zoratu.com> <20030910052732.GG10351@linuxmafia.com> Message-ID: <20030910001104.A20923@zoratu.com> On Tue, Sep 09, 2003 at 10:27:32PM -0700, Rick Moen wrote: > Quoting Isaiah (zoratu at datastacks.com): > > Those three paragraphs, at the beginning of the license agreement, make > > it quite clear you cannot _use_ or _purchase_ (heh) RHEL in good faith > > without agreeing to Red Hat's terms and conditions. > > Actually, no, it does not say that. It says it in plain English, Rick. "BY USING OR PURCHASING RED HAT ENTERPRISE LINUX, CUSTOMER SIGNIFIES ITS ASSENT TO THIS AGREEMENT." It's not even complex language, or any different from most EULA for that matter. > > The ISOs are provided ONLY through RHEN. > > This once again begs the question: What if anything impairs lawful > customers from redistributing? The "three paragraphs" you quoted do not > do so. [snip] > That covers the _services_, not the software. The services _are_ the software for RHEL. Errata and ISOs are only distributed through RHEN, already identified collectively as a service. ISV products only available on RHEL are only distributed through RHEN. Other third-party channel software on RHEL is only distributed through RHEN. > Well, I'm not especially interested in how RH's hired legal flack would > argue. That's not particularly relevant to the issue under discussion. Mark is the senior counsel, not the hired flack. The hired flack send the letters at least one person on this list has already received. Also, if I were putting myself anywhere even remotely near that blastzone I'd want to make damn sure I knew what the proponents of a suit were going to do--ESPECIALLY if I fancied myself interested in legal issues and software licensing. While we're in fancy-land, my mother always told me there are three people you never lie to, and there were two groups you always took seriously. You never lie to your doctor, your lawyer, or yourself, and you always take seriously the IRS and the parts of government enforcing passed legislation. -- - Isaiah From rick at linuxmafia.com Wed Sep 10 00:12:13 2003 From: rick at linuxmafia.com (Rick Moen) Date: Wed, 10 Sep 2003 00:12:13 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <3F5EC8E9.2010805@it.swin.edu.au> References: <1063174338.3f5ec0c26086d@webmail.welho.com> <3F5EC8E9.2010805@it.swin.edu.au> Message-ID: <20030910071212.GI10351@linuxmafia.com> Quoting John Newbigin (jn at it.swin.edu.au): > My 2c on this issue. AFAIK, you can't call it "Red Hat" but you can > call it "RH". (You can definitely call it "Red Hat" if you don't _sell_ it: Trademark infringement by definition must involve commerce. The above is not a recommendation, just a clarification of the applicable law.) > All that should be necessary to be able to distribute it is replace > the images which RedHat have identified as requiring removal and call > it RHEL. A prominent notice that this distribution is neither issued nor endorsed by Red Hat, Inc. would also help a great deal. That would disarm any notion of trademark infringement right at the heart of the matter. My understanding of trademark law (IANATL) suggests that such a notice would be both necessary _and_ sufficient, but certainly doing both is an effective belt-and-suspenders tactic. -- Cheers, Founding member of the Hyphenation Society, a grassroots-based, Rick Moen not-for-profit, locally-owned-and-operated, cooperatively-managed, rick at linuxmafia.com modern-American-English-usage-improvement association. From pmatilai at welho.com Wed Sep 10 00:14:44 2003 From: pmatilai at welho.com (Panu Matilainen) Date: Wed, 10 Sep 2003 10:14:44 +0300 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030910063711.GH10351@linuxmafia.com> References: <1063174338.3f5ec0c26086d@webmail.welho.com> <20030910063711.GH10351@linuxmafia.com> Message-ID: <1063178084.3f5ecf6416352@webmail.welho.com> Quoting Rick Moen : > Quoting Panu Matilainen (pmatilai at welho.com): > > > ..as long as you keep in line with RH trademark guidelines: you can > > grab those SRPMS and rebuild the lot but you can't call it anything > > RH* anymore, and you need to replace the contents of redhat-logos and > > IIRC anaconda-images with your own. > > It should be noted that this exceeds considerably the requirements of > trademark law. The company's requests reflect the usual maximalist > tendencies endemic in trademark protection, and should not be confused > with the law. > > (That's not to say that complying with RH's "guidelines" might not be an > excellent idea, on the theory of avoiding conflict.) Oh but you need to notice that redhat-logos aren't GPL or anything like it. They're published under a separate license which permits certain kinds of uses and redistribution .. but hey, this is getting wildly off-topic for cAos, it's not like I expect cAos having Red Hat logos all around it :) -- - Panu - From zoratu at datastacks.com Wed Sep 10 00:16:46 2003 From: zoratu at datastacks.com (Isaiah) Date: Wed, 10 Sep 2003 00:16:46 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030910065518.GA16548@linuxmafia.com>; from rick@linuxmafia.com on Tue, Sep 09, 2003 at 11:55:18PM -0700 References: <20030909151204.A18672@zoratu.com> <20030910032054.GA10351@linuxmafia.com> <20030909212223.A20191@zoratu.com> <20030910052732.GG10351@linuxmafia.com> <20030909212223.A20191@zoratu.com> <20030910065518.GA16548@linuxmafia.com> Message-ID: <20030910001646.A21030@zoratu.com> On Tue, Sep 09, 2003 at 11:55:18PM -0700, Rick Moen wrote: > Clauses 1 and 2 (among others) require that any redistribution include > all the upstream rights, including the right to redistribute source, > binaries, or any other derivative works. Therefore, either Red Hat, Inc. > must pass along those rights or may not distribute the covered works at > all. AFAIK, there is no immediate time requirement for passing on the changes. Cygnus Solutions, for example, had and still has custom-toolchain work that eventually must go upstream, but is waiting on the 'go signal' from the customer, and/or the functional timeout of the contracted work. -- - Isaiah From rick at linuxmafia.com Wed Sep 10 00:27:10 2003 From: rick at linuxmafia.com (Rick Moen) Date: Wed, 10 Sep 2003 00:27:10 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030910001104.A20923@zoratu.com> References: <20030909151204.A18672@zoratu.com> <20030910032054.GA10351@linuxmafia.com> <20030909212223.A20191@zoratu.com> <20030910052732.GG10351@linuxmafia.com> <20030910001104.A20923@zoratu.com> Message-ID: <20030910072710.GJ10351@linuxmafia.com> Quoting Isaiah (zoratu at datastacks.com): > It says it in plain English, Rick. Quite so. Let's read it, then: > "BY USING OR PURCHASING RED HAT ENTERPRISE LINUX, CUSTOMER SIGNIFIES > ITS ASSENT TO THIS AGREEMENT." That (1) requires that the _customer_ assent to the support agreement accompanying the software, and (2) nowhere prohibits redistribution. > The services _are_ the software for RHEL. This is not correct. I refer you, among other things, to http://www.redhat.com/software/whichlinux.html: Red Hat Enterprise Linux is sold through a one-year subscription and it does have a licensing agreement. But before you mention the "p"-word ("proprietary"), understand that the code is open and protected by the GPL license. It's not proprietary. We're licensing the services, not the software. > Errata and ISOs are only distributed through RHEN.... Yes, but that begs the question of redistribution. Which is what we were discussing. > Mark is the senior counsel, not the hired flack. A distinction without a difference. > You never lie to your doctor, your lawyer, or yourself.... Exactly. Mark is not _my_ lawyer. He's some other guys' hired gun. Thereby hangs my point about the gentleman. -- Cheers, find / -user your -name base -print | xargs chown us:us Rick Moen rick at linuxmafia.com From rick at linuxmafia.com Wed Sep 10 00:29:33 2003 From: rick at linuxmafia.com (Rick Moen) Date: Wed, 10 Sep 2003 00:29:33 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030910001646.A21030@zoratu.com> References: <20030909151204.A18672@zoratu.com> <20030910032054.GA10351@linuxmafia.com> <20030909212223.A20191@zoratu.com> <20030910052732.GG10351@linuxmafia.com> <20030909212223.A20191@zoratu.com> <20030910065518.GA16548@linuxmafia.com> <20030910001646.A21030@zoratu.com> Message-ID: <20030910072933.GK10351@linuxmafia.com> Quoting Isaiah (zoratu at datastacks.com): > AFAIK, there is no immediate time requirement for passing on the > changes. I wasn't speaking of "changes". You appear to have misunderstood what I said. I was saying that clause 7 requires that Red Hat, Inc. pass on to recipients the rights conveyed from upstream, including the right to redistribute any derivative works of the (GPLv2-covered) source code. Binaries are such derivative works. -- Cheers, "We're sorry; you have reached an imaginary number. Rick Moen Please rotate your 'phone ninety degrees and try again." rick at linuxmafia.com From rick at linuxmafia.com Wed Sep 10 00:32:50 2003 From: rick at linuxmafia.com (Rick Moen) Date: Wed, 10 Sep 2003 00:32:50 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <1063178084.3f5ecf6416352@webmail.welho.com> References: <1063174338.3f5ec0c26086d@webmail.welho.com> <20030910063711.GH10351@linuxmafia.com> <1063178084.3f5ecf6416352@webmail.welho.com> Message-ID: <20030910073250.GL10351@linuxmafia.com> Quoting Panu Matilainen (pmatilai at welho.com): > Oh but you need to notice that redhat-logos aren't GPL or anything > like it. They're published under a separate license which permits > certain kinds of uses and redistribution..... That is a very interesting point. Yes, I was thinking only of trademark issues, since that was being raised, here -- and are the only significant restrictions on those works I'd heard of until now. Do you know of a a handy place to see that licence? Much obliged. -- Cheers, The shortest distance between two puns is a straightline. Rick Moen rick at linuxmafia.com From pmatilai at welho.com Wed Sep 10 00:51:05 2003 From: pmatilai at welho.com (Panu Matilainen) Date: Wed, 10 Sep 2003 10:51:05 +0300 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030910073250.GL10351@linuxmafia.com> References: <1063174338.3f5ec0c26086d@webmail.welho.com> <20030910063711.GH10351@linuxmafia.com> <1063178084.3f5ecf6416352@webmail.welho.com> <20030910073250.GL10351@linuxmafia.com> Message-ID: <1063180265.3f5ed7e9319a2@webmail.welho.com> Quoting Rick Moen : > Quoting Panu Matilainen (pmatilai at welho.com): > > > Oh but you need to notice that redhat-logos aren't GPL or anything > > like it. They're published under a separate license which permits > > certain kinds of uses and redistribution..... > > That is a very interesting point. Yes, I was thinking only of trademark > issues, since that was being raised, here -- and are the only > significant restrictions on those works I'd heard of until now. Do you > know of a a handy place to see that licence? > > Much obliged. It's included in the redhat-logos package naturally, see /usr/share/doc/redhat-logos*/COPYING. -- - Panu - From zoratu at datastacks.com Wed Sep 10 00:57:32 2003 From: zoratu at datastacks.com (Isaiah) Date: Wed, 10 Sep 2003 00:57:32 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030910072710.GJ10351@linuxmafia.com>; from rick@linuxmafia.com on Wed, Sep 10, 2003 at 12:27:10AM -0700 References: <20030909151204.A18672@zoratu.com> <20030910032054.GA10351@linuxmafia.com> <20030909212223.A20191@zoratu.com> <20030910052732.GG10351@linuxmafia.com> <20030910001104.A20923@zoratu.com> <20030910072710.GJ10351@linuxmafia.com> Message-ID: <20030910005732.A21073@zoratu.com> On Wed, Sep 10, 2003 at 12:27:10AM -0700, Rick Moen wrote: > Quite so. Let's read it, then: > > > "BY USING OR PURCHASING RED HAT ENTERPRISE LINUX, CUSTOMER SIGNIFIES > > ITS ASSENT TO THIS AGREEMENT." > > That (1) requires that the _customer_ assent to the support agreement > accompanying the software, and (2) nowhere prohibits redistribution. --> "This Subscription Agreement (the "Agreement") is between Red Hat, Inc. ("Red Hat") and any purchaser or user ("Customer") of Red Hat Enterprise ^^^^^^^ Linux AS (or Red Hat Linux Advanced Server), Red Hat Enterprise Linux ES or Red Hat Enterprise Linux WS (collectively, "Red Hat Enterprise Linux" or "the Software")." <-- Customer is defined as any purchaser OR _user_. > > The services _are_ the software for RHEL. > > This is not correct. I refer you, among other things, to > http://www.redhat.com/software/whichlinux.html: > > Red Hat Enterprise Linux is sold through a one-year subscription and > it does have a licensing agreement. But before you mention the > "p"-word ("proprietary"), understand that the code is open and > protected by the GPL license. It's not proprietary. We're licensing > the services, not the software. I'm going to have to think about how to reply to this part. I've been working for 19 hours, and it's not coming to me. > > You never lie to your doctor, your lawyer, or yourself.... > > Exactly. Mark is not _my_ lawyer. He's some other guys' hired gun. > Thereby hangs my point about the gentleman. I think you purposely ignored "or yourself" and "the parts of government enforcing passed legislation." Oh well, I really hope you're right, but I'm not going to let such optimism delude me into not being paranoid about a very real possibility. -- - Isaiah From zoratu at datastacks.com Wed Sep 10 01:09:30 2003 From: zoratu at datastacks.com (Isaiah) Date: Wed, 10 Sep 2003 01:09:30 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030910072933.GK10351@linuxmafia.com>; from rick@linuxmafia.com on Wed, Sep 10, 2003 at 12:29:33AM -0700 References: <20030909151204.A18672@zoratu.com> <20030910032054.GA10351@linuxmafia.com> <20030909212223.A20191@zoratu.com> <20030910052732.GG10351@linuxmafia.com> <20030909212223.A20191@zoratu.com> <20030910065518.GA16548@linuxmafia.com> <20030910001646.A21030@zoratu.com> <20030910072933.GK10351@linuxmafia.com> Message-ID: <20030910010930.B21073@zoratu.com> On Wed, Sep 10, 2003 at 12:29:33AM -0700, Rick Moen wrote: > I was saying that clause 7 requires that Red Hat, Inc. pass on to > recipients the rights conveyed from upstream, including the right to > redistribute any derivative works of the (GPLv2-covered) source code. > Binaries are such derivative works. That's certainly your interpretation. Mine (and my lawyer's) is the source must be made available to whomever is legitimately distributed the derived work, to which Red Hat certainly conforms. -- - Isaiah From rick at linuxmafia.com Wed Sep 10 01:13:22 2003 From: rick at linuxmafia.com (Rick Moen) Date: Wed, 10 Sep 2003 01:13:22 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <1063180265.3f5ed7e9319a2@webmail.welho.com> References: <1063174338.3f5ec0c26086d@webmail.welho.com> <20030910063711.GH10351@linuxmafia.com> <1063178084.3f5ecf6416352@webmail.welho.com> <20030910073250.GL10351@linuxmafia.com> <1063180265.3f5ed7e9319a2@webmail.welho.com> Message-ID: <20030910081322.GM10351@linuxmafia.com> Quoting Panu Matilainen (pmatilai at welho.com): > It's included in the redhat-logos package naturally, see > /usr/share/doc/redhat-logos*/COPYING. One wget and a "cpio -iduv" later, we have the following from version 1.1.15: The redhat-logos package and the anaconda-images package (the "Packages") contain image files which incorporate the RED HAT trademark, Red Hat "Shadow Man" logo and the RPM logo (the "Marks"). RED HAT, the Red Hat "Shadow Man" logo, RPM, and the RPM logo are trademarks or registered trademarks of Red Hat, Inc. in the United States and other countries. Red Hat, Inc. grants you the right to use the Packages during the normal operation of other software programs that call upon the Packages. Red Hat, Inc. grants to you the right and license to copy and redistribute the unaltered Packages, but only in conjunction with copying or redistributing additional software packages that call upon the Packages during the normal course of operation and only in non-commercial distributions permitted under Red Hat's trademark guidelines found at www.redhat.com/about/trademark_guidelines.html or under a separate written license agreement from Red Hat. Red Hat, Inc. grants to you the right and license to copy and redistribute the Packages in commercial distributions without additional license or permission, but only in conjunction with copying or redistributing additional software packages that call upon the Packages during the normal course of operation and only when all of the Marks have been removed or replaced within the Packages. All such rights are granted to you without fee, provided that: 1. The above copyright notice and this license are included with each copy you make, and they remain intact and are not altered, deleted, or modified in any way; 2. You do not modify the appearance of any or all of the Logos in any manner; and 3. You do not use any or all of the Logos as, or as part of, a trademark, trade name, or trade identifier; or in any other fashion except as set forth in this license. NO WARRANTY. THIS PACKAGE IS PROVIDED "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL RED HAT, INC. BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS PACKAGE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. So, it seems that they have indeed given their trademark wishlist (PDF linked from http://www.redhat.com/about/trademark_guidelines.html) teeth via copyright law (absent removal of those images) -- and grant that copyright licence only to non-commercial distributions. Commercial distributions would have to replace the copyright-covered works. (Note that that does _not_ prevent commercial products from using the word "Red Hat" or any of the firm's other marks. The copyright encumbrance applies only to the particular works created by RH, Inc. that are included in that SRPM.) Sounds as if cAos would definitely want to skirt the issue by providing substitutes for those two packages, anyway. (I'd also strongly suggest the "not issued or endorsed" disclaimer I mentioned earlier.) -- Cheers, find / -user your -name base -print | xargs chown us:us Rick Moen rick at linuxmafia.com From rick at linuxmafia.com Wed Sep 10 01:14:48 2003 From: rick at linuxmafia.com (Rick Moen) Date: Wed, 10 Sep 2003 01:14:48 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030910010930.B21073@zoratu.com> References: <20030909151204.A18672@zoratu.com> <20030910032054.GA10351@linuxmafia.com> <20030909212223.A20191@zoratu.com> <20030910052732.GG10351@linuxmafia.com> <20030909212223.A20191@zoratu.com> <20030910065518.GA16548@linuxmafia.com> <20030910001646.A21030@zoratu.com> <20030910072933.GK10351@linuxmafia.com> <20030910010930.B21073@zoratu.com> Message-ID: <20030910081448.GN10351@linuxmafia.com> Quoting Isaiah (zoratu at datastacks.com): > That's certainly your interpretation. Mine (and my lawyer's) is the > source must be made available to whomever is legitimately distributed the > derived work, to which Red Hat certainly conforms. That would be an eminently reasonable interpretation of clause 3b. But -- to repeat -- I was speaking of clause 7. -- Cheers, "Cthulhu loves me, this I know; because the High Priests tell me so! Rick Moen He won't eat me, no, not yet. He's my Elder God, dank and wet!" rick at linuxmafia.com From rick at linuxmafia.com Wed Sep 10 01:24:21 2003 From: rick at linuxmafia.com (Rick Moen) Date: Wed, 10 Sep 2003 01:24:21 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030910005732.A21073@zoratu.com> References: <20030909151204.A18672@zoratu.com> <20030910032054.GA10351@linuxmafia.com> <20030909212223.A20191@zoratu.com> <20030910052732.GG10351@linuxmafia.com> <20030910001104.A20923@zoratu.com> <20030910072710.GJ10351@linuxmafia.com> <20030910005732.A21073@zoratu.com> Message-ID: <20030910082421.GO10351@linuxmafia.com> Quoting Isaiah (zoratu at datastacks.com): > Customer is defined as any purchaser OR _user_. Problem: Recipients of redistributed copies would not be parties to that technical support agreement. No privity of contract, offer/acceptance, etc. Thus my point. > I think you purposely ignored "or yourself" Hey, Isaiah: I've not been rude or make nasty personal remarks in any part of this discussion. Please take a bit greater care. > ...and "the parts of government enforcing passed legislation." Although I've never professed to be an expert in law, I've been doing my best to discuss specifics in light of what I believe is fairly careful study. If I have erred in my understanding of legislation, I certainly welcome your pointing out where this has happened. More to the immediate point, perhaps you wouldn't mind reminding me of what legislation we were discussing. I can't recall any. (But hey, you're saying it's the end of a long day for you, so I'll drop it.) -- Cheers, Rick Moen Age, baro, fac ut gaudeam. rick at linuxmafia.com From lance at uklinux.net Wed Sep 10 05:29:54 2003 From: lance at uklinux.net (Lance Davis) Date: Wed, 10 Sep 2003 13:29:54 +0100 (BST) Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030910081322.GM10351@linuxmafia.com> Message-ID: On Wed, 10 Sep 2003, Rick Moen wrote: > Quoting Panu Matilainen (pmatilai at welho.com): > > > It's included in the redhat-logos package naturally, see > > /usr/share/doc/redhat-logos*/COPYING. > > So, it seems that they have indeed given their trademark wishlist > (PDF linked from http://www.redhat.com/about/trademark_guidelines.html) > teeth via copyright law (absent removal of those images) -- and grant > that copyright licence only to non-commercial distributions. Commercial > distributions would have to replace the copyright-covered works. No the non-commercial distributions are not allowed with rhel - Ref :- http://www.redhat.com/about/corporate/trademark/guidelines/page9.html It says - in bold - This permission is not applicable to Red Hat? Enterprise Linux? or any Red Hat subscription product. It then goes on to say immediately afterwards :- Of course, you are always permitted to redistribute the code without utilizing Red Hat's trademark so long as you otherwise comply with the GNU General Public License and Red Hat's Trademark Guidelines. Which must include Rhel, as the previous sentence specifically excludes it , and confirms the right of redistribution. > Sounds as if cAos would definitely want to skirt the issue by providing > substitutes for those two packages, anyway. (I'd also strongly suggest > the "not issued or endorsed" disclaimer I mentioned earlier.) agreed. BTW - The discussion we had with RH's lawyers concerned whether it was acceptable to say :- If you're looking for xxx xxx Linux, whilst we still sell it, we no longer call it by its original name, due to trademark restrictions imposed by Red Hat Inc. xxx xxx 9 GPL is identical to the product published under the GPL by Red Hat Inc. The disks can be purchased individually, but we recommend that you buy the 6 CD-ROM set for ?10 - this includes 3 x binary installation disks, 2 x source code disks and documentation on disk. This software comes with NO support. which must have popped up in a Google search. the crazy thing is that due to redhgats requirements you have to remove the adverts for services from rh that pop up in anadonda when you install the software !! So lets discuss whether it will be ok to say that caos1 is compatible with Redhat Enterprise Linux .... Lance -- uklinux.net - The ISP of choice for the discerning Linux user. From lance at uklinux.net Wed Sep 10 06:01:43 2003 From: lance at uklinux.net (Lance Davis) Date: Wed, 10 Sep 2003 14:01:43 +0100 (BST) Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: Message-ID: On Tue, 9 Sep 2003, R P Herrold wrote: > so looking at: > http://caosity.org/docs_view.php?subject=Version%20Scheme > we might have: > cAos-0 RH 8 present build efforts > cAos-1 RHAS 2.1 based > cAos-2 RHEL-3.- based > > That's where my current thinking is. I agree , but would order them slightly differently :- cAos-0 RHAS 2.1 based past - stable version - ideal for servers / clusters maybe with groups of extra packages from caos-1 that upgrade and enhance the base kernel 2.4.9 glibc 2.2.4 gcc 2.96 (and gcc3) cAos-1 RH 8 present build efforts present - working version - workstations - LSB 1.3 kernel 2.4-20 (2.6 option ??? ) glibc 2.3.2 gcc 3.2 cAos-2 RHEL-3.- based future - replacement for caos 0 LSB 2 kernel 2.4.21 glibc 2.3.2 gcc 3.2.3 I guess caos-3 needs to be the equivalent of severn ;) Lance -- uklinux.net - The ISP of choice for the discerning Linux user. From greg at runlevelzero.net Wed Sep 10 07:13:35 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Wed, 10 Sep 2003 07:13:35 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: References: Message-ID: <20030910141335.GB8723@titan.runlevelzero.net> On Wed, Sep 10, 2003 at 02:01:43PM +0100, Lance Davis told me: > I agree , but would order them slightly differently :- > > > cAos-0 RHAS 2.1 based past - stable version - ideal for servers / clusters > maybe with groups of extra packages from caos-1 that upgrade and enhance the base > kernel 2.4.9 > glibc 2.2.4 > gcc 2.96 (and gcc3) > > cAos-1 RH 8 present build efforts present - working version - > workstations - > LSB 1.3 > kernel 2.4-20 (2.6 option ??? ) > glibc 2.3.2 > gcc 3.2 > > cAos-2 RHEL-3.- based future - replacement for caos 0 > LSB 2 > kernel 2.4.21 > glibc 2.3.2 > gcc 3.2.3 > > I guess caos-3 needs to be the equivalent of severn ;) I think in the nature of the recent discussions we can migrate the RHL build efforts to the RHEL base. This means that: cAos N LSB 1.3 RHEL2.1 base (gcc, glibc, etc...) kernel 2.4.22 (as of today) cAos N+1 LSB 2 RHEL3 base (gcc, glibc, etc...) kernel 2.6.x note: Since I am maintaining the "linux" package (kernel), I am going to use the kernel.org kernel. This actually leaves the package "kernel" which can be installed simultaneously with my "linux" package and can be 100% based on the RedHat kernel. My feeling is that I _really_ don't want to maintain that package and if someone else volunteers to do it, it can be there. I appreciate that many people will want to use the RedHat kernel, so that option is there. BTW: I am mostly inclined to make N = 1. Does this look reasonable? -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From rocky at atipa.com Wed Sep 10 07:37:08 2003 From: rocky at atipa.com (Rocky McGaugh) Date: Wed, 10 Sep 2003 09:37:08 -0500 (CDT) Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030910141335.GB8723@titan.runlevelzero.net> Message-ID: On Wed, 10 Sep 2003, Greg Kurtzer wrote: > I think in the nature of the recent discussions we can migrate the RHL build > efforts to the RHEL base. > > This means that: > > cAos N > LSB 1.3 > RHEL2.1 base (gcc, glibc, etc...) > kernel 2.4.22 (as of today) > > cAos N+1 > LSB 2 > RHEL3 base (gcc, glibc, etc...) > kernel 2.6.x > > note: Since I am maintaining the "linux" package (kernel), I am going to use > the kernel.org kernel. This actually leaves the package "kernel" which can be > installed simultaneously with my "linux" package and can be 100% based on the > RedHat kernel. My feeling is that I _really_ don't want to maintain that > package and if someone else volunteers to do it, it can be there. I appreciate > that many people will want to use the RedHat kernel, so that option is there. > > BTW: I am mostly inclined to make N = 1. > > Does this look reasonable? I guess I'm missing something somewhere. If you ship with a kernel.org kernel, then you are no longer "compatible" with RHEL. The whole point of RHEL is that you (and more importantly ISV's) are guaranteed a known package list to expect. -- Rocky McGaugh From lance at uklinux.net Wed Sep 10 07:39:26 2003 From: lance at uklinux.net (Lance Davis) Date: Wed, 10 Sep 2003 15:39:26 +0100 (BST) Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030910141335.GB8723@titan.runlevelzero.net> Message-ID: On Wed, 10 Sep 2003, Greg Kurtzer wrote: > I think in the nature of the recent discussions we can migrate the RHL build > efforts to the RHEL base. > > This means that: > > cAos N > LSB 1.3 > RHEL2.1 base (gcc, glibc, etc...) > kernel 2.4.22 (as of today) > > cAos N+1 > LSB 2 > RHEL3 base (gcc, glibc, etc...) > kernel 2.6.x > > note: Since I am maintaining the "linux" package (kernel), I am going to use > the kernel.org kernel. This actually leaves the package "kernel" which can be > installed simultaneously with my "linux" package and can be 100% based on the > RedHat kernel. My feeling is that I _really_ don't want to maintain that > package and if someone else volunteers to do it, it can be there. I appreciate > that many people will want to use the RedHat kernel, so that option is there. > > BTW: I am mostly inclined to make N = 1. > Does this look reasonable? yes - but afaics rhel2.1 is still using kernel 2.4.9, so that ought to be offered - from rhel. Lance -- uklinux.net - The ISP of choice for the discerning Linux user. From greg at runlevelzero.net Wed Sep 10 07:56:45 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Wed, 10 Sep 2003 07:56:45 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: References: <20030910141335.GB8723@titan.runlevelzero.net> Message-ID: <20030910145645.GA9180@titan.runlevelzero.net> On Wed, Sep 10, 2003 at 09:37:08AM -0500, Rocky McGaugh told me: > > note: Since I am maintaining the "linux" package (kernel), I am going to use > > the kernel.org kernel. This actually leaves the package "kernel" which can be > > installed simultaneously with my "linux" package and can be 100% based on the > > RedHat kernel. My feeling is that I _really_ don't want to maintain that > > package and if someone else volunteers to do it, it can be there. I appreciate > > that many people will want to use the RedHat kernel, so that option is there. > > I guess I'm missing something somewhere. If you ship with a kernel.org > kernel, then you are no longer "compatible" with RHEL. The whole point > of RHEL is that you (and more importantly ISV's) are guaranteed a > known package list to expect. You are right... I guess I am showing my personal biases of cAos (naturally). For example I don't need something that is 100% RHEL compatible (per se). I am mostly interested in following with RHEL because they are going to be supporting the the packages for an extended time frame. Even if I were to purchase RHEL, on many of the systems I work with I would use the kernel.org kernel anyway... Now I know that people will want to use the RHEL kernel, and this is why I mentioned that the slot is available for someone else to maintain if/when a volunteer is identified. I just simply don't want to do it because to do it right would mean you have to investigate their patches and understand what is going on. If someone else wants to take on glibc, I will do the RH kernel. ;) -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From rocky at atipa.com Wed Sep 10 08:43:02 2003 From: rocky at atipa.com (Rocky McGaugh) Date: Wed, 10 Sep 2003 10:43:02 -0500 (CDT) Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030910145645.GA9180@titan.runlevelzero.net> Message-ID: On Wed, 10 Sep 2003, Greg Kurtzer wrote: > You are right... > > I guess I am showing my personal biases of cAos (naturally). For example I > don't need something that is 100% RHEL compatible (per se). I am mostly > interested in following with RHEL because they are going to be supporting the > the packages for an extended time frame. Even if I were to purchase RHEL, on > many of the systems I work with I would use the kernel.org kernel anyway... > > Now I know that people will want to use the RHEL kernel, and this is why I > mentioned that the slot is available for someone else to maintain if/when a > volunteer is identified. I just simply don't want to do it because to do it > right would mean you have to investigate their patches and understand what is > going on. If someone else wants to take on glibc, I will do the RH kernel. ;) I see and understand your needs also. I think they can both be met by the same project. Suppose we base a cAos-1 off the 2.1 SRPMS, and call it something like "cAos1-base". This would effectively be maintained by RH until May, 2007. It would be a terribly boring tree, with mainly only security and critical bug fixes supplied. This would maintain maximum RHEL compatibility. It would have the same benefits and limitations as RHEL 2.1. It would be basically maintained by RH and should require little effort on our part...... The focus of this might be to "cleanly" separate it from RHEL. This might involve the logos and removal of the RHN services and probably java. Something like "cAos1-enhanced" could be built off the "cAos-base" and could have major changes like you envision. (To me, a kernel.org kernel is a major change.) Then suppose we also create both of the above based on the 3.0 SRPMs. The "enhanced" could be folded into trees that could stand on their own merits while still being built on common bases. Maybe they are better off as separate projects, but I dont think so. -- Rocky McGaugh From greg at runlevelzero.net Wed Sep 10 09:55:52 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Wed, 10 Sep 2003 09:55:52 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: References: <20030910145645.GA9180@titan.runlevelzero.net> Message-ID: <20030910165552.GB10047@titan.runlevelzero.net> On Wed, Sep 10, 2003 at 10:43:02AM -0500, Rocky McGaugh told me: > I see and understand your needs also. I think they can both be met by the > same project. > > Suppose we base a cAos-1 off the 2.1 SRPMS, and call it something like > "cAos1-base". This would effectively be maintained by RH until May, 2007. > It would be a terribly boring tree, with mainly only security and > critical bug fixes supplied. This would maintain maximum RHEL > compatibility. It would have the same benefits and limitations as RHEL > 2.1. It would be basically maintained by RH and should require little > effort on our part...... The focus of this might be to "cleanly" separate > it from RHEL. This might involve the logos and removal of the RHN services > and probably java. > > Something like "cAos1-enhanced" could be built off the "cAos-base" and > could have major changes like you envision. (To me, a kernel.org kernel > is a major change.) Hrmm, sounds interesting. I would defiantly be interested to help host this, but personally I am totally not interested in leading a total rebuild distribution. If there is someone else that wishes to lead that effort I would agree that this would be a nice solution. I am curious, why would someone _need_ a complete clone of RHEL? If they are installing something like Oracle, I would imagine that they would be most interested in purchasing support and the _real thing_... If the base is compatible (as it would be with the RH kernel), then what's the difference? Lets go back to the problem we are trying to solve... > Then suppose we also create both of the above based on the 3.0 SRPMs. > > The "enhanced" could be folded into trees that could stand on their own > merits while still being built on common bases. > > > Maybe they are better off as separate projects, but I don't think so. I like the idea of separating the cAosX-base as the RHEL component, as long as it is just a minimal base... But on the other hand, we should do what the community needs which is not necessarily what _I_ want. ;) Greg -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From zoratu at datastacks.com Wed Sep 10 10:29:01 2003 From: zoratu at datastacks.com (Isaiah) Date: Wed, 10 Sep 2003 10:29:01 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030910082421.GO10351@linuxmafia.com>; from rick@linuxmafia.com on Wed, Sep 10, 2003 at 01:24:21AM -0700 References: <20030909151204.A18672@zoratu.com> <20030910032054.GA10351@linuxmafia.com> <20030909212223.A20191@zoratu.com> <20030910052732.GG10351@linuxmafia.com> <20030910001104.A20923@zoratu.com> <20030910072710.GJ10351@linuxmafia.com> <20030910005732.A21073@zoratu.com> <20030910082421.GO10351@linuxmafia.com> Message-ID: <20030910102901.B23561@zoratu.com> On Wed, Sep 10, 2003 at 01:24:21AM -0700, Rick Moen wrote: > Problem: Recipients of redistributed copies would not be parties to that > technical support agreement. No privity of contract, offer/acceptance, > etc. Thus my point. If you buy a stolen car, it's still stolen. -- - Isaiah From lance at uklinux.net Wed Sep 10 10:39:18 2003 From: lance at uklinux.net (Lance Davis) Date: Wed, 10 Sep 2003 18:39:18 +0100 (BST) Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030910102901.B23561@zoratu.com> Message-ID: On Wed, 10 Sep 2003, Isaiah wrote: > On Wed, Sep 10, 2003 at 01:24:21AM -0700, Rick Moen wrote: > > Problem: Recipients of redistributed copies would not be parties to that > > technical support agreement. No privity of contract, offer/acceptance, > > etc. Thus my point. > > If you buy a stolen car, it's still stolen. Whether a BMW or a Toyota ..... -- uklinux.net - The ISP of choice for the discerning Linux user. From rick at linuxmafia.com Wed Sep 10 10:41:24 2003 From: rick at linuxmafia.com (Rick Moen) Date: Wed, 10 Sep 2003 10:41:24 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030910102901.B23561@zoratu.com> References: <20030909151204.A18672@zoratu.com> <20030910032054.GA10351@linuxmafia.com> <20030909212223.A20191@zoratu.com> <20030910052732.GG10351@linuxmafia.com> <20030910001104.A20923@zoratu.com> <20030910072710.GJ10351@linuxmafia.com> <20030910005732.A21073@zoratu.com> <20030910082421.GO10351@linuxmafia.com> <20030910102901.B23561@zoratu.com> Message-ID: <20030910174124.GT10351@linuxmafia.com> Quoting Isaiah (zoratu at datastacks.com): > If you buy a stolen car, it's still stolen. You're still stuck on the same problem: This once again begs the question of whether there's any restriction on redistribution. There's been no showing of same. Moreover, it changes the subject: Your assertion was that the recipient of such a redistribution is somehow a party to a service contract by virtue of being a "user". That is a non-sequitur: By the very nature of contracts, you are always bound only to contracts of which you're a party. (Required elements, in summary: offer, acceptance, consideration, capacity, lawful purpose, genuineness of assent, form.) Clearly, a person who receives a copy of RHEL without entering into a support contract is not a party to that contract. -- Cheers, find / -user your -name base -print | xargs chown us:us Rick Moen rick at linuxmafia.com From zoratu at datastacks.com Wed Sep 10 11:01:25 2003 From: zoratu at datastacks.com (Isaiah) Date: Wed, 10 Sep 2003 11:01:25 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030910174124.GT10351@linuxmafia.com>; from rick@linuxmafia.com on Wed, Sep 10, 2003 at 10:41:24AM -0700 References: <20030909151204.A18672@zoratu.com> <20030910032054.GA10351@linuxmafia.com> <20030909212223.A20191@zoratu.com> <20030910052732.GG10351@linuxmafia.com> <20030910001104.A20923@zoratu.com> <20030910072710.GJ10351@linuxmafia.com> <20030910005732.A21073@zoratu.com> <20030910082421.GO10351@linuxmafia.com> <20030910102901.B23561@zoratu.com> <20030910174124.GT10351@linuxmafia.com> Message-ID: <20030910110125.A23683@zoratu.com> On Wed, Sep 10, 2003 at 10:41:24AM -0700, Rick Moen wrote: > Moreover, it changes the subject: Your assertion was that the recipient > of such a redistribution is somehow a party to a service contract by > virtue of being a "user". That is a non-sequitur: By the very nature of > contracts, you are always bound only to contracts of which you're a > party. (Required elements, in summary: offer, acceptance, consideration, > capacity, lawful purpose, genuineness of assent, form.) Clearly, a > person who receives a copy of RHEL without entering into a support > contract is not a party to that contract. If I apply your argument to GPL'd software, Red Hat would be the licensee of all the software components and I'm free to violate the GPL as I wish. -- - Isaiah From rick at linuxmafia.com Wed Sep 10 11:13:08 2003 From: rick at linuxmafia.com (Rick Moen) Date: Wed, 10 Sep 2003 11:13:08 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030910110125.A23683@zoratu.com> References: <20030910032054.GA10351@linuxmafia.com> <20030909212223.A20191@zoratu.com> <20030910052732.GG10351@linuxmafia.com> <20030910001104.A20923@zoratu.com> <20030910072710.GJ10351@linuxmafia.com> <20030910005732.A21073@zoratu.com> <20030910082421.GO10351@linuxmafia.com> <20030910102901.B23561@zoratu.com> <20030910174124.GT10351@linuxmafia.com> <20030910110125.A23683@zoratu.com> Message-ID: <20030910181307.GV10351@linuxmafia.com> Quoting Isaiah (zoratu at datastacks.com): > If I apply your argument to GPL'd software, Red Hat would be the > licensee of all the software components and I'm free to violate the GPL as > I wish. I'm sorry, that doesn't follow. For one thing, GPLv2 is not a contract. It's a copyright licence, working through the mechanism of copyright law, not contract law. See GPLv2 clause 0: The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: (Some may argue that in particular cases of distribution, a contract is formed between two parties, but that's a separate matter.) -- Cheers, The shortest distance between two puns is a straightline. Rick Moen rick at linuxmafia.com From zoratu at datastacks.com Wed Sep 10 11:22:35 2003 From: zoratu at datastacks.com (Isaiah) Date: Wed, 10 Sep 2003 11:22:35 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030910181307.GV10351@linuxmafia.com>; from rick@linuxmafia.com on Wed, Sep 10, 2003 at 11:13:08AM -0700 References: <20030909212223.A20191@zoratu.com> <20030910052732.GG10351@linuxmafia.com> <20030910001104.A20923@zoratu.com> <20030910072710.GJ10351@linuxmafia.com> <20030910005732.A21073@zoratu.com> <20030910082421.GO10351@linuxmafia.com> <20030910102901.B23561@zoratu.com> <20030910174124.GT10351@linuxmafia.com> <20030910110125.A23683@zoratu.com> <20030910181307.GV10351@linuxmafia.com> Message-ID: <20030910112235.A23825@zoratu.com> On Wed, Sep 10, 2003 at 11:13:08AM -0700, Rick Moen wrote: > I'm sorry, that doesn't follow. For one thing, GPLv2 is not a contract. > It's a copyright licence, working through the mechanism of copyright law, > not contract law. See GPLv2 clause 0: > > The "Program", below, refers to any such program or work, > and a "work based on the Program" means either the Program > or any derivative work under copyright law: > > (Some may argue that in particular cases of distribution, a contract is > formed between two parties, but that's a separate matter.) Software does not fall out of the sky. You either wrote, or it was distributed to you. If it was distributed, it was either because you sought it, or it was forced upon you by some governing body. -- - Isaiah From herrold at owlriver.com Wed Sep 10 11:49:16 2003 From: herrold at owlriver.com (R P Herrold) Date: Wed, 10 Sep 2003 14:49:16 -0400 (EDT) Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030910110125.A23683@zoratu.com> Message-ID: On Wed, 10 Sep 2003, Isaiah wrote: > On Wed, Sep 10, 2003 at 10:41:24AM -0700, Rick Moen wrote: and so on. Each of us has seen this to and fro, here and on other lists, of non-lawyers discussing an issue which ultimately people who are potentially liable will ( or it would seem, at least, should) address with formal legal counsel, and for which formal advice may be obtained. I will not and for the reasons mentioned, really cannot substantively participate; a couple of other list and IRC folk have provided datapoints with their perspective as well. May I please ask, as a matter of procedure, that you two take it off the list, and come to a agreed statement of what the two of you believe, and _then_ jointly advise the list of the URL of your summary document (preserving the subject line and threading indicia). I am certain that persons interested in participating in that process can contact either of you and be included in the cc: fest. I know that Rick does this summary statement technique, with many of his recurrent topics (and I respect the effort it represents). But really, this back and forth here is overshadowing and drowning out technical matters. -- Russ Herrold From rick at linuxmafia.com Wed Sep 10 11:53:47 2003 From: rick at linuxmafia.com (Rick Moen) Date: Wed, 10 Sep 2003 11:53:47 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030910112235.A23825@zoratu.com> References: <20030910052732.GG10351@linuxmafia.com> <20030910001104.A20923@zoratu.com> <20030910072710.GJ10351@linuxmafia.com> <20030910005732.A21073@zoratu.com> <20030910082421.GO10351@linuxmafia.com> <20030910102901.B23561@zoratu.com> <20030910174124.GT10351@linuxmafia.com> <20030910110125.A23683@zoratu.com> <20030910181307.GV10351@linuxmafia.com> <20030910112235.A23825@zoratu.com> Message-ID: <20030910185347.GW10351@linuxmafia.com> Quoting Isaiah (zoratu at datastacks.com): > Software does not fall out of the sky. You either wrote, or it was > distributed to you. If it was distributed, it was either because you > sought it, or it was forced upon you by some governing body. No offence intended, but I'm not clear on what your point is. You're being more than a bit vague. If you are asserting that recipients of third-party redistributed RHEL software are parties to a technical-support service contract, please indicate where occurred the offer & acceptance, supported by consideration, etc. (Suggestion: You cannot, because it doesn't happen.) What I see is a codebase (mostly from upstream, non-RH origins and received by them under open-source licences including copyleft ones) distributed initially bundled with a support contract, without agreeing to which the customer is simply not offered a copy (by RH) at all. Nothing I've been able to find in the codebase's own terms of usage nor the service contract's provisions impairs the customer from redistributing further copies at will. (As noted, the software collection may incorporate some packages whose licence terms restrict redistribution, but I haven't been able to find them.) It it my clear understanding -- and I've explained why -- that this freedom to redistribute (at least some of the packages' binaries, those being derivative works of the SRPMs) is predictable from, if nothing else, GPLv2 clause 7. Your assertion that further recipients would be bound by the support agreement terms cannot be true, because that would conflict with clause 7 in the GPL-covered packages' licences from upstream, and would mean that RH would be prohibited from distributing that software at all. If you see some error in the above, please do explain. Hey, I'm not an attorney, but I _did_ argue application of GPLv2 clause 3b (the main source-access provision) with RMS on behalf of $FIRM, and won. ;-> (I'll be glad to tell that story if anyone's interested, provided we omit company names.) -- Cheers, Always remember: Clones are people two! Rick Moen rick at linuxmafia.com From lance at uklinux.net Wed Sep 10 11:59:49 2003 From: lance at uklinux.net (Lance Davis) Date: Wed, 10 Sep 2003 19:59:49 +0100 (BST) Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030910185347.GW10351@linuxmafia.com> Message-ID: On Wed, 10 Sep 2003, Rick Moen wrote: > (I'll be glad to tell that story if anyone's interested, provided we > omit company names.) Awww - I want the names ... ;) -- uklinux.net - The ISP of choice for the discerning Linux user. From rick at linuxmafia.com Wed Sep 10 12:40:00 2003 From: rick at linuxmafia.com (Rick Moen) Date: Wed, 10 Sep 2003 12:40:00 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: References: <20030910110125.A23683@zoratu.com> Message-ID: <20030910194000.GX10351@linuxmafia.com> Quoting R P Herrold (herrold at owlriver.com): > May I please ask, as a matter of procedure, that you two take > it off the list.... I think it's important to have a reasonable grasp of copyright and trademark law, if you're going to do an RH-derivative distribution. In fact, I _know_ that, from having been part of a team that produced one -- for profit, even -- and had to grapple with exactly those issues. Accordingly, I'd suggest that if one can't settle the most basic applicable relevant issues of copyright and trademark law, one can't really do an RH-derivative at all. And it's really not that difficult! But I'll be glad to reassure you that I have (categorically) no intention of endlessly debating with Isaiah or anyone else. Unless yet more creative objections come up, which doesn't seem likely, I don't think there's going to be much more on the topic. I _am_ disappointed, though. Elsewhere (e.g., OSI's license-discuss), it's been a great deal easier to discuss such matters, without the need to review basics like GPLv2 being a copyright licence, not a contract. > I know that Rick does this summary statement technique, with many of > his recurrent topics (and I respect the effort it represents). A FAQ may indeed emerge at some point. ;-> (And thank you.) -- Cheers, Wall Street has all the emotional stability of a Rick Moen thirteen-year-old girl. -- Louis Rukeyser rick at linuxmafia.com From zoratu at datastacks.com Wed Sep 10 13:17:08 2003 From: zoratu at datastacks.com (Isaiah) Date: Wed, 10 Sep 2003 13:17:08 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030910194000.GX10351@linuxmafia.com>; from rick@linuxmafia.com on Wed, Sep 10, 2003 at 12:40:00PM -0700 References: <20030910110125.A23683@zoratu.com> <20030910194000.GX10351@linuxmafia.com> Message-ID: <20030910131708.A24201@zoratu.com> On Wed, Sep 10, 2003 at 12:40:00PM -0700, Rick Moen wrote: > I think it's important to have a reasonable grasp of copyright and > trademark law, if you're going to do an RH-derivative distribution. In > fact, I _know_ that, from having been part of a team that produced one -- > for profit, even -- and had to grapple with exactly those issues. No, no, no, no. The POINT is to AVOID the issue. To make SURE you're in the clear. > Accordingly, I'd suggest that if one can't settle the most basic > applicable relevant issues of copyright and trademark law, one can't > really do an RH-derivative at all. And it's really not that difficult! For the Red Hat Linux product, you are absolutely correct. -- - Isaiah From rick at linuxmafia.com Wed Sep 10 13:36:52 2003 From: rick at linuxmafia.com (Rick Moen) Date: Wed, 10 Sep 2003 13:36:52 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: References: <20030910081322.GM10351@linuxmafia.com> Message-ID: <20030910203652.GY10351@linuxmafia.com> Quoting Lance Davis (lance at uklinux.net): > No the non-commercial distributions are not allowed with rhel - > > Ref :- > > http://www.redhat.com/about/corporate/trademark/guidelines/page9.html > > It says - in bold - > > > This permission is not applicable to Red Hat? Enterprise Linux? or > any Red Hat subscription product. > But this is smoke and mirrors from RH Legal: The "permission" in question applies to RH's _trademarks_, not the copyrighted images in the redhat-logos and anaconda-images packages. But trademark law simply doesn't give the owner any say whatsoever over non-commercial uses. The "Red Hat Trademark Guidelines" are actually a pretty well written and fair-minded tutorial on trademark legal issues, except where they address company specifics, which is where the razzle-dazzle comes out. E.g., on http://www.redhat.com/about/corporate/trademark/guidelines/page4.html: It occasionally comes to our attention that some companies or individuals are producing CD-ROM and other products that contain the software which Red Hat distributes as Red Hat?? Linux??. Although they are entitled to do this under the GPL and other applicable licenses, they do not have the right to use the name or brand their products "Red Hat," or to use the Red Hat trademarks in any way on their products or in related advertising, except under certain limited circumstances (See the sections entitled "Fair Use of Trademarks" and "Publishing And Marketing Red Hat?? Linux?? That Has Been Modified"). Doing so would cause confusion among the customers who purchase those products, because they may believe they are purchasing a product produced or sponsored by Red Hat, Inc. but, in reality, it is a product of another company altogether. I refer to that as razzle-dazzle rather than something outright erroneous because they've merely swept a mountain of counter-examples under their term "certain limited circumstances". An attentive reader would take the suggestion to consult the "Fair Use of Trademarks" page, and find out the following: A key element in evaluating whether the use of someone else's trademark is acceptable is whether the use is likely to cause confusion in the marketplace as to the source or sponsorship of a product. That is, indeed, the essence of trademark law. The trademark owner cannot successfully enjoin _any_ use of its trademarks, commercial or not, where customers clearly understand that the trademark owner did _not_ issue or endorse that competing product. In the case of the particular images in redhat-logos and anaconda-images packages, _copyright_ law gives RH traction to control usage -- but that would not apply to (hypothetically) third-party-created images that likewise embody those marks. > > Sounds as if cAos would definitely want to skirt the issue by providing > > substitutes for those two packages, anyway. (I'd also strongly suggest > > the "not issued or endorsed" disclaimer I mentioned earlier.) > > agreed. Good! Then this tortuous discussion has been worthwhile, in my view. > BTW - The discussion we had with RH's lawyers concerned whether it was > acceptable to say :- [snip example of weird circumlocution to avoid the term "Red Hat Linux".] The thing to bear in mind is that, because any company with a valuable trademark must (with reason) live in abject fear of that trademark becoming generic, _of course_ they will always make over-broad demands on people using their marks, far in excess of what the law entitles them to. That's the only way they can defer the day when they lose ownership entirely. > So lets discuss whether it will be ok to say that caos1 is compatible with > Redhat Enterprise Linux .... As always in these matters, there are two (related) questions: 1. Is what you want to do lawful? 2. Is what you want to do sufficiently unlikely to avoid conflict? The easy way to avoid conflict is to roll over and do what the other part wants. As to whether it's lawful (in my non-lawyerly opinion), please consult what I refer to as "the essence of trademark law", above. Unfortunately, the definitive answer in a particular case can only come from a judge in a lawsuit that goes all the way to judgement, because the ruling must be based on the totality of circumstances. Absent that, it's a game of bluff and blunder -- mostly, the trademark owner bluffing, and you blundering. ;-> -- Cheers, Errors have been made. Others will be blamed. Rick Moen rick at linuxmafia.com From zoratu at datastacks.com Wed Sep 10 13:46:05 2003 From: zoratu at datastacks.com (Isaiah) Date: Wed, 10 Sep 2003 13:46:05 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030910185347.GW10351@linuxmafia.com>; from rick@linuxmafia.com on Wed, Sep 10, 2003 at 11:53:47AM -0700 References: <20030910001104.A20923@zoratu.com> <20030910072710.GJ10351@linuxmafia.com> <20030910005732.A21073@zoratu.com> <20030910082421.GO10351@linuxmafia.com> <20030910102901.B23561@zoratu.com> <20030910174124.GT10351@linuxmafia.com> <20030910110125.A23683@zoratu.com> <20030910181307.GV10351@linuxmafia.com> <20030910112235.A23825@zoratu.com> <20030910185347.GW10351@linuxmafia.com> Message-ID: <20030910134605.A24337@zoratu.com> On Wed, Sep 10, 2003 at 11:53:47AM -0700, Rick Moen wrote: > If you are asserting that recipients of third-party redistributed RHEL > software are parties to a technical-support service contract, please > indicate where occurred the offer & acceptance, supported by > consideration, etc. (Suggestion: You cannot, because it doesn't > happen.) You continue to use dimunitive labels for the RHEL product. It is more than just being able to call a phone monkey for technical support. RHEL |-- GSS | |-- SLA 0 | |-- SLA 1 | `-- SLA n |-- OS | `-- Physical CD `-- RHEN |-- 3rd Party Channels |-- Errata `-- ISOs These are components delivered by Red Hat for a fee to entitled persons whom have accepted the subscription agreement to not distribute their entitlement to use Red Hat service beyond what is eligible. > Hey, I'm not an attorney, but I _did_ argue application of GPLv2 clause > 3b (the main source-access provision) with RMS on behalf of $FIRM, and > won. ;-> He yelled at my friend once for wearing a free O'Reilly tshirt, because they "sell books." While we're comparing penis sizes, I got 168 on my LSATs. And, while four years at Red Hat may have brainwashed me a bit--I am on the road to recovery, since my resignation last month--I've spent the better part of my life listening to attorneys talk about how the law and documents are interpreted by the people who make decisions. In most cases, the issue is whether you can mediate a disagreement or convince the right person when the shit hits the fan, not which semantics you weave into your words to out-smart a necessary evil of the free software community whom seems to not bathe because water costs money. -- - Isaiah From rick at linuxmafia.com Wed Sep 10 13:54:01 2003 From: rick at linuxmafia.com (Rick Moen) Date: Wed, 10 Sep 2003 13:54:01 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030910131708.A24201@zoratu.com> References: <20030910110125.A23683@zoratu.com> <20030910194000.GX10351@linuxmafia.com> <20030910131708.A24201@zoratu.com> Message-ID: <20030910205401.GZ10351@linuxmafia.com> Quoting Isaiah (zoratu at datastacks.com): > No, no, no, no. The POINT is to AVOID the issue. To make SURE you're > in the clear. The strategy of always giving the other party exactly what he wants does indeed have the advantage of avoiding disputes, and I'm definitely not knocking it in this case. All I'm saying is that you're better off understanding the law, or you can get into trouble even while trying to be friendly and compliant -- if not with today's stack of demands, then with tomorrow's, or (say) with a double-bind between conflicting claims. Confusion on relevant legal matters is A Bad Thing, I would say. -- Cheers, Founding member of the Hyphenation Society, a grassroots-based, Rick Moen not-for-profit, locally-owned-and-operated, cooperatively-managed, rick at linuxmafia.com modern-American-English-usage-improvement association. From rick at linuxmafia.com Wed Sep 10 13:59:18 2003 From: rick at linuxmafia.com (Rick Moen) Date: Wed, 10 Sep 2003 13:59:18 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030910134605.A24337@zoratu.com> References: <20030910072710.GJ10351@linuxmafia.com> <20030910005732.A21073@zoratu.com> <20030910082421.GO10351@linuxmafia.com> <20030910102901.B23561@zoratu.com> <20030910174124.GT10351@linuxmafia.com> <20030910110125.A23683@zoratu.com> <20030910181307.GV10351@linuxmafia.com> <20030910112235.A23825@zoratu.com> <20030910185347.GW10351@linuxmafia.com> <20030910134605.A24337@zoratu.com> Message-ID: <20030910205918.GA10351@linuxmafia.com> Quoting Isaiah (zoratu at datastacks.com): > These are components delivered by Red Hat for a fee to entitled > persons whom have accepted the subscription agreement to not > distribute their entitlement to use Red Hat service beyond what is > eligible. Once again, that entitlement is explicitly for _support_. That is not the question: The question is whether there's any impediment to redistributing the software, not the support entitlement. > While we're comparing penis sizes.... Now, you're just trying to engage in interpersonal squabbling. How sad. (I guess it would be arch to say "pissing match".) -- Cheers, "It ain't so much the things we don't know that get us Rick Moen in trouble. It's the things we know that ain't so." rick at linuxmafia.com -- Artemus Ward (1834-67), U.S. journalist From jim at rossberry.com Wed Sep 10 14:09:36 2003 From: jim at rossberry.com (Jim Wildman) Date: Wed, 10 Sep 2003 17:09:36 -0400 (EDT) Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030910205918.GA10351@linuxmafia.com> Message-ID: To get updated binaries you agree that they will only be installed machines you have registered. Registering machines costs money. Hence the suggestions to base cAos on rhel/rhas. Rebuild from src and provide the binaries without the subscription. On Wed, 10 Sep 2003, Rick Moen wrote: > Quoting Isaiah (zoratu at datastacks.com): > > > These are components delivered by Red Hat for a fee to entitled > > persons whom have accepted the subscription agreement to not > > distribute their entitlement to use Red Hat service beyond what is > > eligible. > > Once again, that entitlement is explicitly for _support_. That is not > the question: The question is whether there's any impediment to > redistributing the software, not the support entitlement. > > > While we're comparing penis sizes.... > > Now, you're just trying to engage in interpersonal squabbling. How sad. > (I guess it would be arch to say "pissing match".) > > ------------------------------------------------------------------------ Jim Wildman, CISSP, RHCE jim at rossberry.com http://www.rossberry.com From rick at linuxmafia.com Wed Sep 10 14:20:42 2003 From: rick at linuxmafia.com (Rick Moen) Date: Wed, 10 Sep 2003 14:20:42 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: References: <20030910205918.GA10351@linuxmafia.com> Message-ID: <20030910212042.GC10351@linuxmafia.com> Quoting Jim Wildman (jim at rossberry.com): > To get updated binaries you agree that they will only be installed machines > you have registered. Registering machines costs money. > > Hence the suggestions to base cAos on rhel/rhas. Yes, this is the whole idea behind (and genesis of) cAos, nay? There were a series of discussions at LBNL and elsewhere on that very point that lead to this project's founding. > Rebuild from src and provide the binaries without the subscription. You could do that, and that is almost certainly the path cAos is taking -- presumably stripping redhat-logos and anaconda-images. To revisit one of my original questions (which got blown away by all the noise that followed), are there any other RHEL packages known to have redistribution problems in their licences? -- Cheers, "Why is the alphabet in that order? Is it because of that song?" Rick Moen -- Steven Wright rick at linuxmafia.com From zoratu at datastacks.com Wed Sep 10 14:21:58 2003 From: zoratu at datastacks.com (Isaiah) Date: Wed, 10 Sep 2003 14:21:58 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030910205918.GA10351@linuxmafia.com>; from rick@linuxmafia.com on Wed, Sep 10, 2003 at 01:59:18PM -0700 References: <20030910005732.A21073@zoratu.com> <20030910082421.GO10351@linuxmafia.com> <20030910102901.B23561@zoratu.com> <20030910174124.GT10351@linuxmafia.com> <20030910110125.A23683@zoratu.com> <20030910181307.GV10351@linuxmafia.com> <20030910112235.A23825@zoratu.com> <20030910185347.GW10351@linuxmafia.com> <20030910134605.A24337@zoratu.com> <20030910205918.GA10351@linuxmafia.com> Message-ID: <20030910142158.A24545@zoratu.com> On Wed, Sep 10, 2003 at 01:59:18PM -0700, Rick Moen wrote: > Once again, that entitlement is explicitly for _support_. That is not > the question: The question is whether there's any impediment to > redistributing the software, not the support entitlement. *sigh* "The term "Services" as used in this Agreement means, collectively, the Support Services and RHEN, each as defined herein." A component to RHEN, the ISO distributed by Red Hat is only available for distribution and use on entitled systems. > Now, you're just trying to engage in interpersonal squabbling. How sad. > (I guess it would be arch to say "pissing match".) No, I just despise unnecessarily complex language, erroneous instances of "that," improper punctuation, and the assumption--this time on your part--anybody knows what anybody else is _trying_ to do. -- - Isaiah From rick at linuxmafia.com Wed Sep 10 14:35:01 2003 From: rick at linuxmafia.com (Rick Moen) Date: Wed, 10 Sep 2003 14:35:01 -0700 Subject: [cAos] cAos] RHEL Support and compatiability. In-Reply-To: <20030910142158.A24545@zoratu.com> References: <20030910082421.GO10351@linuxmafia.com> <20030910102901.B23561@zoratu.com> <20030910174124.GT10351@linuxmafia.com> <20030910110125.A23683@zoratu.com> <20030910181307.GV10351@linuxmafia.com> <20030910112235.A23825@zoratu.com> <20030910185347.GW10351@linuxmafia.com> <20030910134605.A24337@zoratu.com> <20030910205918.GA10351@linuxmafia.com> <20030910142158.A24545@zoratu.com> Message-ID: <20030910213500.GD10351@linuxmafia.com> Quoting Isaiah (zoratu at datastacks.com): > "The term "Services" as used in this Agreement means, collectively, the > Support Services and RHEN, each as defined herein." > > A component to RHEN, the ISO distributed by Red Hat is only available > for distribution and use on entitled systems. Nope. To quote the service agreement's definitions section: Red Hat Enterprise Network ("RHEN") is an internet solution for managing one or more systems running Red Hat Enterprise Linux that allows Customers to register one or more Installed Systems, receive errata notification, update Installed Systems with the errata, search errata and download ISO images. RHEN also includes the following functionality: package profile comparison, systems search, systems grouping, ability for multiple systems administrators to manage Installed Systems and update systems by sets. As previously mentioned, then, the described entitlement is to _support_ (by which I meant including the updating service). Frankly, everything RH writes about the subject is perfectly clear on that point, including the quotation I posted earlier from http://www.redhat.com/software/whichlinux.html : ...the code is open and protected by the GPL license. It's not proprietary. We're licensing the services, not the software. If you _were_ correct, then RH, Inc.'s licence to use and distribute upstream GPLv2-licensed codebases would cease, per clause 7. Which suffices to explain why they don't try, your conviction to the contrary notwithstanding. (Further attempt at interpersonal squabbling duly ignored.) -- Cheers, Rick Moen Age, baro, fac ut gaudeam. rick at linuxmafia.com From gmkurtzer at lbl.gov Thu Sep 11 12:34:03 2003 From: gmkurtzer at lbl.gov (Greg Kurtzer) Date: Thu, 11 Sep 2003 12:34:03 -0700 Subject: [cAos] Re: Why not use a RH Enterprise system to build a comparible 'enterprise' system from Redhat sources? In-Reply-To: <16FDDFA43B3@maiser.uibk.ac.at> References: <16FDDFA43B3@maiser.uibk.ac.at> Message-ID: <20030911193403.GC30740@tux.lbl.gov> On Thu, Sep 11, 2003 at 06:59:33PM +0200, Simon J Mudd told me: > > I think the most closest will be a taroon with all rhn updates up to > > the release date. > > One thing to be careful with is to be able to regenerate a particular > version of the "new" distribution. If you follow the "build using all > updates" then you can not build an original "base" cAos-2/3 version once > you've made changes, unless you clearly define the build environment > (OS/installed RPMs/...) and replicate it exactly. This is a good point. > The differences may be minor, but you can't guarantee that the > resulting cAos-2/3 will be the same as that built by someone else, and > bugtracking behaviour differences between the RHES and the cAos > equivalent will be more tricky. > > When you want to update the distribution, based on updated source RPMs > then you need to ensure that the newly built binary RPMS are also > referenced against a potentially new different build > environment(OS/installed RPMs/...) > > These differences may not be significant but it certainly would be > nice to have that information available. Thanks for brining this up. The problem that I see is building packages that require a specific version of another package that is not in the standard build environment. For example, we update Gnome and it requires a newer version of glib2. If we update glib2, then we are changing the build environment. So what determines what the build environment is? Is it reasonable to just have that documented, or must it be defined as a snapshot release (ie. gnome-core built on cAos-1.12.32)? > It is possible to perform this type of task on other oses like the > *BSDs as they build exclusively from source. However before starting > they have to build the *build* tools from the target source chain, > before building the remaining applications. This way they can ensure > that the end results are thus consistent. This is harder to achieve > in a Linux/RPM environment, especially if the hosting/build OS is > different from the target OS. Agreed. > I'll have to subscribe to the cAos list now I think... See you there! Greg -- Greg M. Kurtzer, CSE: Linux cluster specialist Lawrence Berkeley National Laboratory Contact: O=510.495.2307, P=510.448.4540, M=510.928.9953 1 Cyclotron Road #90-1116, Berkeley, CA 94720 http://www.lbl.gov, http://scs.lbl.gov/, http://lug.lbl.gov/ Email: GMKurtzer_at_lbl.gov, Text: 5109289953_at_mobileatt.net From wsoyinka at lbl.gov Thu Sep 11 15:17:40 2003 From: wsoyinka at lbl.gov (Wale Soyinka) Date: Thu, 11 Sep 2003 15:17:40 -0700 Subject: [cAos] New member In-Reply-To: <1062355365.1607.46.camel@kermit> References: <1062355365.1607.46.camel@kermit> Message-ID: <3F60F484.4070901@lbl.gov> Good to have you on board Ralf. Ralf Spenneberg wrote: >Hi, > >I am here by invitation through Greg Kurtzer. Thanks Greg. > >I just wanted to say, I am on board and will be happy to support the >cAos-project through my RPMs. > >Cheers, > >Ralf > > From websurfer at navegants.com Sun Sep 14 07:12:26 2003 From: websurfer at navegants.com (Josep M.) Date: Sun, 14 Sep 2003 16:12:26 +0200 Subject: [cAos] Presentation and question:) Message-ID: <6.0.0.22.2.20030914160941.0253c848@pop1> Hi! I?m new in this list, I subscribed when reading about rhel-rebuild mail-list, I would like know if You have started any compilation and the optimization parameters that are used. I?m trying of compile myself RHAS3.0 too. Josep From greg at runlevelzero.net Thu Sep 18 23:58:10 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Thu, 18 Sep 2003 23:58:10 -0700 Subject: [cAos] The rules of cAos. Message-ID: <20030919065810.GA11903@titan.runlevelzero.net> While there has not been much talk on the list as of late, we have been discussing on private mail, and IRC the immediate direction of cAos and what is needed from community based operating systems in general. I have spent some time talking with with many of you (off list) about operating system needs, and I think that we have come to a solution that will satisfy most everyone here. Basically I see two major pools of interest: One is a community RedHat like solution, and the other is a community based distribution that builds from community sources. cAos I think is capable of providing a solution to both pools of thought immediately (well within several months) by offering two solutions. I see the community based cAos (as has been discussed), and a cAos Enterprise Linux (cAosel). cAosel is looking to be a packaged form of the RHEL-Rebuild project. This can probably be maintained by a small to medium sized handful of developers and will pull directly from RHEL. We will remove all components of non-freely distributable code, and if needed replace it with a free counterpart. This will literally be a freely distributable drop in replacement for RHEL that will mirror their support errata (as long as RH does not change the source availability of their errata). The second (original) solution is a community distribution that is built using community sources. The goal here is to provide a Debian like social pool, while maintaining a RPM based operating system that is geared toward LSB compatibility, ease of use for the administrator, scientific computing as well as a general desktop/server platform. cAos will then be built by community sources, and some of the packages for the base system will be used from cAosel. We will attempt to keep this base small enough to not play a critical role in supportability, but large enough to maintain compatibility. There will be two development groups for each of these projects, but both projects may work closely. cAosel will be both a solution for RH refugees and people that want the RHEL compatibility, but don't want the support, and do not wish to pay as well as offer a migration path to the community developed cAos. cAos will be the much needed solution for a community based stable RPM based solution that will be built and managed by the community proper. Right now we need people to offer development resources to cAosel. There have been several people join this list from the RHEL-Rebuild list, and I am hoping that they will have interest here. If there is already a project in progress targeted to make a distributable RHEL clone, then we should make contact (I am unaware of any such project now). The first order of business is cAosel-1 (which will be built from RHEL2.1) and then cAos-1 will use that as a build host (until it is self hosting) as well as borrow some of the core packages. cAosel will be a fully functioning RHEL2.1 clone, which cAos will be a minimal distribution until package maintainers sign up. cAosel-2 will be built from RHEL3 and thus cAos-2. After that, cAos may split away from cAosel, and cAosel may also split from RHEL. The immediate goal of using RHEL as the base is to offer a migration path from the current commercially supported standard to a community solution. If anything needs to be described in more depth, or if there are concerns with this model, please forward to the list. Thanks. Greg -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From greg at runlevelzero.net Fri Sep 19 00:07:17 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Fri, 19 Sep 2003 00:07:17 -0700 Subject: [cAos] Presentation and question:) In-Reply-To: <6.0.0.22.2.20030914160941.0253c848@pop1> References: <6.0.0.22.2.20030914160941.0253c848@pop1> Message-ID: <20030919070717.GB11903@titan.runlevelzero.net> Sorry for the late response. I am going through old email that I have not yet responded to... On Sun, Sep 14, 2003 at 04:12:26PM +0200, Josep M. told me: > I?m new in this list, I subscribed when reading about rhel-rebuild mail-list, I would > like know if You have started any compilation and the optimization parameters > that are used. I?m trying of compile myself RHAS3.0 too. You mean like compile optimizations, or specific system optimizations (ie. /proc mods, hdparam, etc...)? As far as the compilation optimizations, these would all be defined by the package itself (usually in the make files) or are you thinking target architectures? Greg -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From jim at rossberry.com Sun Sep 21 14:35:23 2003 From: jim at rossberry.com (Jim Wildman) Date: Sun, 21 Sep 2003 17:35:23 -0400 (EDT) Subject: [cAos] The rules of cAos. In-Reply-To: <20030919065810.GA11903@titan.runlevelzero.net> Message-ID: This sounds like a very good organization/division of labor and intent. If you want a vote/input +1. On Thu, 18 Sep 2003, Greg Kurtzer wrote: > While there has not been much talk on the list as of late, we have been > discussing on private mail, and IRC the immediate direction of cAos and > what is needed from community based operating systems in general. I have > spent some time talking with with many of you (off list) about operating > system needs, and I think that we have come to a solution that will > satisfy most everyone here. > > Basically I see two major pools of interest: One is a community RedHat like > solution, and the other is a community based distribution that builds from > community sources. > > cAos I think is capable of providing a solution to both pools of thought > immediately (well within several months) by offering two solutions. I see the > community based cAos (as has been discussed), and a cAos Enterprise Linux > (cAosel). > > cAosel is looking to be a packaged form of the RHEL-Rebuild project. This can > probably be maintained by a small to medium sized handful of developers and > will pull directly from RHEL. We will remove all components of non-freely > distributable code, and if needed replace it with a free counterpart. This > will literally be a freely distributable drop in replacement for RHEL that > will mirror their support errata (as long as RH does not change the source > availability of their errata). > > The second (original) solution is a community distribution that is built > using community sources. The goal here is to provide a Debian like social > pool, while maintaining a RPM based operating system that is geared toward > LSB compatibility, ease of use for the administrator, scientific computing > as well as a general desktop/server platform. > > cAos will then be built by community sources, and some of the packages for the > base system will be used from cAosel. We will attempt to keep this base small > enough to not play a critical role in supportability, but large enough to > maintain compatibility. > > There will be two development groups for each of these projects, but both > projects may work closely. cAosel will be both a solution for RH refugees > and people that want the RHEL compatibility, but don't want the support, and > do not wish to pay as well as offer a migration path to the community > developed cAos. cAos will be the much needed solution for a community based > stable RPM based solution that will be built and managed by the community > proper. > > Right now we need people to offer development resources to cAosel. There have > been several people join this list from the RHEL-Rebuild list, and I am hoping > that they will have interest here. If there is already a project in progress > targeted to make a distributable RHEL clone, then we should make contact (I > am unaware of any such project now). > > The first order of business is cAosel-1 (which will be built from RHEL2.1) and > then cAos-1 will use that as a build host (until it is self hosting) as well > as borrow some of the core packages. cAosel will be a fully functioning > RHEL2.1 clone, which cAos will be a minimal distribution until package > maintainers sign up. cAosel-2 will be built from RHEL3 and thus cAos-2. After > that, cAos may split away from cAosel, and cAosel may also split from RHEL. > The immediate goal of using RHEL as the base is to offer a migration path > from the current commercially supported standard to a community solution. > > If anything needs to be described in more depth, or if there are concerns with > this model, please forward to the list. > > Thanks. > Greg > ------------------------------------------------------------------------ Jim Wildman, CISSP, RHCE jim at rossberry.com http://www.rossberry.com From jn at it.swin.edu.au Sun Sep 21 17:02:12 2003 From: jn at it.swin.edu.au (John Newbigin) Date: Mon, 22 Sep 2003 10:02:12 +1000 Subject: [cAos] The rules of cAos. In-Reply-To: References: Message-ID: <3F6E3C04.1030308@it.swin.edu.au> Jim Wildman wrote: > This sounds like a very good organization/division of labor and intent. > > If you want a vote/input +1. Before I vote, I have some questions... with cAosel, will it be supported until the RHEL end of life? What about support beond this date? What about bugs that RedHat won't fix, will these be fixed in cAosel? Perhaps this version also needs two streams, RedHat compatable and RedHat enhanced (for example, all our new PCs have network cards (Broadcom), video and audio chipsets (Intel) which are not supported under RHEL). Does this project have any financial support or backing? If the developers get board, are all the users going to be left high and dry? I am keen to see a distribution like cAosel come to light and I am prepared to help in any way that I can but before I jump on the bandwagon I need to make sure that it is going to meet our needs, otherwise we will maintain our own internal RHEL version. John. > > > On Thu, 18 Sep 2003, Greg Kurtzer wrote: > > >>While there has not been much talk on the list as of late, we have been >>discussing on private mail, and IRC the immediate direction of cAos and >>what is needed from community based operating systems in general. I have >>spent some time talking with with many of you (off list) about operating >>system needs, and I think that we have come to a solution that will >>satisfy most everyone here. >> >>Basically I see two major pools of interest: One is a community RedHat like >>solution, and the other is a community based distribution that builds from >>community sources. >> >>cAos I think is capable of providing a solution to both pools of thought >>immediately (well within several months) by offering two solutions. I see the >>community based cAos (as has been discussed), and a cAos Enterprise Linux >>(cAosel). >> >>cAosel is looking to be a packaged form of the RHEL-Rebuild project. This can >>probably be maintained by a small to medium sized handful of developers and >>will pull directly from RHEL. We will remove all components of non-freely >>distributable code, and if needed replace it with a free counterpart. This >>will literally be a freely distributable drop in replacement for RHEL that >>will mirror their support errata (as long as RH does not change the source >>availability of their errata). >> >>The second (original) solution is a community distribution that is built >>using community sources. The goal here is to provide a Debian like social >>pool, while maintaining a RPM based operating system that is geared toward >>LSB compatibility, ease of use for the administrator, scientific computing >>as well as a general desktop/server platform. >> >>cAos will then be built by community sources, and some of the packages for the >>base system will be used from cAosel. We will attempt to keep this base small >>enough to not play a critical role in supportability, but large enough to >>maintain compatibility. >> >>There will be two development groups for each of these projects, but both >>projects may work closely. cAosel will be both a solution for RH refugees >>and people that want the RHEL compatibility, but don't want the support, and >>do not wish to pay as well as offer a migration path to the community >>developed cAos. cAos will be the much needed solution for a community based >>stable RPM based solution that will be built and managed by the community >>proper. >> >>Right now we need people to offer development resources to cAosel. There have >>been several people join this list from the RHEL-Rebuild list, and I am hoping >>that they will have interest here. If there is already a project in progress >>targeted to make a distributable RHEL clone, then we should make contact (I >>am unaware of any such project now). >> >>The first order of business is cAosel-1 (which will be built from RHEL2.1) and >>then cAos-1 will use that as a build host (until it is self hosting) as well >>as borrow some of the core packages. cAosel will be a fully functioning >>RHEL2.1 clone, which cAos will be a minimal distribution until package >>maintainers sign up. cAosel-2 will be built from RHEL3 and thus cAos-2. After >>that, cAos may split away from cAosel, and cAosel may also split from RHEL. >>The immediate goal of using RHEL as the base is to offer a migration path >>from the current commercially supported standard to a community solution. >> >>If anything needs to be described in more depth, or if there are concerns with >>this model, please forward to the list. >> >>Thanks. >>Greg >> > > > ------------------------------------------------------------------------ > Jim Wildman, CISSP, RHCE jim at rossberry.com > http://www.rossberry.com > > _______________________________________________ > cAos mailing list > cAos at runlevelzero.net > http://www.caosity.org/mailman/listinfo/caos > > > -- Information Technology Innovation Group School of Information Technology Swinburne University of Technology Melbourne, Australia http://www.it.swin.edu.au/staff/jnewbigin From jim at rossberry.com Sun Sep 21 17:39:56 2003 From: jim at rossberry.com (Jim Wildman) Date: Sun, 21 Sep 2003 20:39:56 -0400 (EDT) Subject: [cAos] The rules of cAos. In-Reply-To: <3F6E3C04.1030308@it.swin.edu.au> Message-ID: Broadcom is supported in the current packages. On Mon, 22 Sep 2003, John Newbigin wrote: > What about bugs that RedHat won't fix, will these be fixed in cAosel? > Perhaps this version also needs two streams, RedHat compatable and > RedHat enhanced (for example, all our new PCs have network cards > (Broadcom), video and audio chipsets (Intel) which are not supported > under RHEL). > > Does this project have any financial support or backing? If the > developers get board, are all the users going to be left high and dry? > ------------------------------------------------------------------------ Jim Wildman, CISSP, RHCE jim at rossberry.com http://www.rossberry.com From herrold at owlriver.com Sun Sep 21 21:09:57 2003 From: herrold at owlriver.com (R P Herrold) Date: Mon, 22 Sep 2003 00:09:57 -0400 (EDT) Subject: [cAos] Re: cAos] The rules of cAos. In-Reply-To: <3F6E3C04.1030308@it.swin.edu.au> References: <3F6E3C04.1030308@it.swin.edu.au> Message-ID: On Mon, 22 Sep 2003, John Newbigin wrote: > Does this project have any financial support or backing? If the > developers get board, are all the users going to be left high and dry? The second question is misses the point of where Linux update support is -- Users who expect a free lunch on update support forever on every release out there are _already_ 'high and dry'. The real question is what is the cost/benefit balance between upgrade (recently made less palatible by RH in the RHL line) to a later freely and currently supported version of a distribution, vs. obtaining continuing updates to a generally EoL'd or cost-constrained 'official' variant. Even with GPL code availability, TANSTAAFL forever. Savvy users have previously had the luxury of a long free (free beer) commercial update _and_ upgrade support tail for some time. That's changed. But Owl River's been selling both kinds of support for years, even though it could be had for free at the expense of learning how. The Build vs Buy for our customers makes it easier to Buy professional admin, than to Build in-house 'savvy' Even a year ago, or five years ago, end users had make a choice to stay and pay for support to an upstream EoL'd version [I was working on a RHL 4.2 box earlier last week like that], or move on to a version in current no acquisition-cost version with automated support. But the automated free support path means having to solve the named changes; the dhcp changes; the apache changes. ... and that has been beyond the skillset of even savvy users unless they hold the other skills to make external update rebuilds basically just a convenience. Either a 'guru' or help desk has been "giving" support away, or it is being sold to that end user, or more commonly updates are just not be done [two weeks ago, I was working on a 'cracked box' not maintained since the site sysadmin I trained moved away two years ago] or doing cold install 'upgrades' with lost time in service being suffered. The choice and need for decisions on support is simply more appearent now, with the fast release cycle and short support tail announced by Red Hat on its RHL, and long cycle but non-free support options on its RHEL product lines, Those who are willing to pay for support will be supported for as long as they remain interested and their pocketbooks hold out. In RH[XX] or cAos or otherwise. See one e.g. at: http://www.owlriver.com/wings/ Looking back over time, we see that developers _will_ get bored, and lose interest in maintenance almost as quickly as new releases of packages become available -- There is no _developer_ interest in maintaining RHL 7.2 or RH AS 2.1. Heck, there is barely RH interest in most bugs over six months old -- Run a few RH Bugzilla queries, and the triaging is clear. The two releases last mentioned are interesting to cAos mainly insofar as they are a stepping stone 'proof of concept' on clean-room bootstrapping, autobuilding and packaging. [caveat: Early adopter commercial RH AS 2.1 users and all EoL'd RHL vaiant users will remain interested in updating embedded installations through the design life of the servers running and needing that given release featureset - but a cost/benefit analysis of Buying 'signed and recourse' maintenance may drive a version upgrade]. RHL 8 is interesting as the last kernel before the NPTL model really caused (short term) stabilization issues. RHL 9 will be as dead as Caesar for the non-hobby user once the RHEL 3.x series starts and non-RH signed (free, as in beer) builds appear (cAos-1). On the other hand, the cAos spectrum of supported release models is crafted so that maintainers and distributors of a distribution will remain interested longer in providing updates so long as end users (possibly an internal audience (non-direct cost recovery - permitting free rider 'savvy' updaters if the internal maintainer wishes to publish to cAos), possibly third-party (paid support model - generally blocking free riders)). So long as the end users are sufficiently interested to continue to support the maintainers, support will continue. When the users lose interest, maintenance will die off. TANSTAAFL. -- Russ Herrold ------------------------------------------------ TANSTAAFL -- From Heinlein, Rbt.; There Ain't No Such Thing As A Free Lunch From greg at runlevelzero.net Sun Sep 21 22:57:33 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Sun, 21 Sep 2003 22:57:33 -0700 Subject: [cAos] The rules of cAos. In-Reply-To: <3F6E3C04.1030308@it.swin.edu.au> References: <3F6E3C04.1030308@it.swin.edu.au> Message-ID: <20030922055733.GD23083@titan.runlevelzero.net> On Mon, Sep 22, 2003 at 10:02:12AM +1000, John Newbigin told me: > Before I vote, I have some questions... Good. :) > with cAosel, will it be supported until the RHEL end of life? What > about support beond this date? It all has to do with the community needs. While I can not speak for developers, I can say if enough people want it the community will produce (as long as there is an infrastructure to support it). > What about bugs that RedHat won't fix, will these be fixed in cAosel? > Perhaps this version also needs two streams, RedHat compatable and > RedHat enhanced (for example, all our new PCs have network cards > (Broadcom), video and audio chipsets (Intel) which are not supported > under RHEL). Remember that my position is that cAos is the _real_ project, and caosel provides a clean transition from RH to cAos, immediate long term support, saves many people, and provides a clean place to utilize some base packages for cAos as well as build the initial cAos releases. Thus to answer your question, caosel is (as I see it) a straight mirror of RH. If people in the community divide to maintain a specific caosel version after it has been EOL'ed, then they can do it. Once again, caosel is not a need for me, and I am probably not the best person for this job. I know that Rocky has showed interest here, and I would like to see several people join him to maintain caosel as a straight RH mirror (with the exceptions of the non-redistributable packages of course). cAos will be the place where these things get fixed. It will utilize the small core of caosel (planned at least for versions 1&2), and the rest will be community maintained packages (Debian style) on top of that base. > Does this project have any financial support or backing? If the > developers get board, are all the users going to be left high and dry? Well, I too have thought about this and being a developer myself I understand the issue directly. For caosel, I think that it will be driven by necessity. cAos will however have a different version methodology, and it can support the latest and greatest for package maintainers. This way, the motivation is the option to maintain the newest and most interesting packages, and letting the backend database keep track of the oldest known stable and letting people update against that repository (cautious Vs. current repositories). There are past list posts that describe this in better detail. > I am keen to see a distribution like cAosel come to light and I am > prepared to help in any way that I can but before I jump on the > bandwagon I need to make sure that it is going to meet our needs, > otherwise we will maintain our own internal RHEL version. Well, if you are already planning on maintaining a rhel-rebuilt version, I ask you to at least work with us so we can make something that is redistributable, and you (and others) can share the workload and benefit! This is caosel. Just to recap, cAos will use only the caosel base, and versions 1&2 should be basically compatible with RHEL2 and 3 (caosel-1 and caosel-2 respectively). Greg -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From herrold at owlriver.com Thu Sep 25 01:07:28 2003 From: herrold at owlriver.com (R P Herrold) Date: Thu, 25 Sep 2003 04:07:28 -0400 (EDT) Subject: [cAos] updated ORCbuildit, 0.03 Message-ID: I have updated the ORCbuildit script to address some of the issues raised on the IRC channel this evening. A fresh copy (ver 0.03) of this GPL'd script is at: ftp://ftp.owlriver.com/pub/local/ORC/buildfarm/ which uses a build chroot image and pumps out packages and various build logging information. External statistic generation hooks are also present for generating reports of webpage display front ends into the build pass data. The chroot image is presently being produced manually for the test shot on caosel-1 ; phase in of automatic installation of additional build requirement and hinting information will be added to the script after chroot image production is automated. -- Russ Herrold From greg at runlevelzero.net Thu Sep 25 08:18:10 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Thu, 25 Sep 2003 08:18:10 -0700 Subject: [cAos] updated ORCbuildit, 0.03 In-Reply-To: References: Message-ID: <20030925151810.GJ12424@titan.runlevelzero.net> Great!!! I am starting a new build now!! On Thu, Sep 25, 2003 at 04:07:28AM -0400, R P Herrold told me: > I have updated the ORCbuildit script to address some of the > issues raised on the IRC channel this evening. > > A fresh copy (ver 0.03) of this GPL'd script is at: > ftp://ftp.owlriver.com/pub/local/ORC/buildfarm/ > which uses a build chroot image and pumps out packages and > various build logging information. > > External statistic generation hooks are also present for > generating reports of webpage display front ends into the > build pass data. > > The chroot image is presently being produced manually for the > test shot on caosel-1 ; phase in of automatic installation of > additional build requirement and hinting information will be > added to the script after chroot image production is > automated. > > -- Russ Herrold > _______________________________________________ > cAos mailing list > cAos at runlevelzero.net > http://www.caosity.org/mailman/listinfo/caos -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From herrold at owlriver.com Sat Sep 27 20:15:04 2003 From: herrold at owlriver.com (R P Herrold) Date: Sat, 27 Sep 2003 23:15:04 -0400 (EDT) Subject: [cAos] ORCyum-chroot 0.01 released Message-ID: I announce initial release of a working, hands off, rpm dependency consistent, general chroot builder at: ftp.owlriver.com in /pub/local/ORC/buildfarm/ as ORCyum-chroot under GPL v. 2 license. It may be used to set up master chroots, for subsequent use for SRPM building, or more generally, as a copy of an install image, as a feeder for the buildiso script. The latter is important for it permits us to no longer carry an archive of hand-conputed consistent RPMS with the script. It is arch and release neutral, and will work in any environment where yum works. I have used it to produce consistent and working images with both a Rawhide, and a RHAS 2.1 archive so far. Reports and feedback (and patches) welcomed. -- Russ Herrold From jed at nersc.gov Mon Sep 29 17:09:47 2003 From: jed at nersc.gov (Jed Donnelley) Date: Mon, 29 Sep 2003 17:09:47 -0700 Subject: [cAos] cAos] RHEL Support and compatiability - why Message-ID: <4.3.2.7.2.20030929162342.0364f580@imap4.lbl.gov> On Wed, 10 Sep 2003 09:55:52 -0700 Greg Kurtzer wrote: >I am curious, why would someone _need_ a complete clone of RHEL? If they are >installing something like Oracle, I would imagine that they would be most >interested in purchasing support and the _real thing_... If the base is >compatible (as it would be with the RH kernel), then what's the difference? I seem to be in just the situation you describe Greg. I run some Oracle systems. For them I need the "real thing" RH Enterprise. Not because I need any support from Redhat. I've never gotten any support from Redhat and never expect to. I need the "real thing" because my DBAs need to get support from Oracle. They can't get such support unless they are running on a supported system. This is part of a deal between Redhat and Oracle. So far so good or bad depending on your perspective - Oracle was supported on Redhat 7.1 without such an agreement. However, we run many other systems for other general services, help desk, Web servers, mail systems, CVS services, instant messaging, LDAP, custom services, etc., etc. These systems don't need to be the "real thing", but from my perspective it would be helpful if they were as compatible as possible with the "real thing" systems and perhaps equally important that they be compatible with earlier Redhat systems. There is an angle that I think may be becoming lost in this discussion. The Redhat distribution has become the sweet spot Linux distributions because Redhat has made it available for free and supported it well (read years and years of patches). Now that situation is changing. Redhat will no longer support their "consumer" version well (only 1 year of patches - unsuitable for any production use in my opinion) and they are charging for their "enterprise" version. An important question is, where will the next "sweet spot" be for Linux distributions intended for production use? What is going to happen to all those people who have been following along with Redhat and now for reasons of administrative or dollar costs no longer find it effective to follow their Enterprise line? For many of my needs other than Oracle, I am most interested in following whatever that "sweet spot" turns out to be. When people want me to run a server to support software that they have developed, I most often find that their software was developed for Redhat. What will that software be developed for in the future? By making cAos a free distribution with good support (e.g. as long as Redhat Enterprise support) and having it compatible with Redhat as a start I think it reasonable that the cAos distribution could become that Linux "sweet spot" distribution. Anybody developing on Redhat Enterprise or on cAos could be confident their software would run on cAos or Redhat Enterprise and continue to run on cAos (the appropriate version) as it is patched, updated, and extended into the future. How this fits with Redhat's needs and the future commercial activity on Linux I have no idea. All I know is that in the short to medium term it is something that would be very helpful to me. What other choices do I have? --Jed http://www.nersc.gov/~jed/ From greg at runlevelzero.net Mon Sep 29 21:57:03 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Mon, 29 Sep 2003 21:57:03 -0700 Subject: [cAos] cAos] RHEL Support and compatiability - why In-Reply-To: <4.3.2.7.2.20030929162342.0364f580@imap4.lbl.gov> References: <4.3.2.7.2.20030929162342.0364f580@imap4.lbl.gov> Message-ID: <20030930045703.GB21853@titan.runlevelzero.net> On Mon, Sep 29, 2003 at 05:09:47PM -0700, Jed Donnelley told me: > I seem to be in just the situation you describe Greg. I run some Oracle > systems. For them I need the "real thing" RH Enterprise. Not because I > need any support from Redhat. I've never gotten any support from Redhat > and never expect to. I need the "real thing" because my DBAs need to get > support from Oracle. They can't get such support unless they are running > on a supported system. This is part of a deal between Redhat and Oracle. Got it. > So far so good or bad depending on your perspective - Oracle was supported > on Redhat 7.1 without such an agreement. > > However, we run many other systems for other general services, help desk, > Web servers, mail systems, CVS services, instant messaging, LDAP, custom > services, etc., etc. These systems don't need to be the "real thing", but > from my perspective it would be helpful if they were as compatible as > possible with the "real thing" systems and perhaps equally important that > they be compatible with earlier Redhat systems. So it looks like the cAos project will have two components (described at: http://caosity.org/pipermail/caos/2003-September/000385.html). Basically it states that there will be two breeds of cAos. The caos-el which is a freely distributable version of RHEL, and cAos is then the community solution which (for versions 1&2) borrows some of the core from caos-el. So the level of RHEL compatibility will be determined by which cAos version you choose. > There is an angle that I think may be becoming lost in this > discussion. The Redhat distribution has become the sweet spot Linux > distributions because Redhat has made it available for free and supported > it well (read years and years of patches). Now that situation is > changing. Redhat will no longer support their "consumer" version well > (only 1 year of patches - unsuitable for any production use in my opinion) > and they are charging for their "enterprise" version. An important > question is, where will the next "sweet spot" be for Linux distributions > intended for production use? What is going to happen to all those people > who have been following along with Redhat and now for reasons of > administrative or dollar costs no longer find it effective to follow their > Enterprise line? > > For many of my needs other than Oracle, I am most interested in following > whatever that "sweet spot" turns out to be. When people want me to run a > server to support software that they have developed, I most often find that > their software was developed for Redhat. What will that software be > developed for in the future? > > By making cAos a free distribution with good support (e.g. as long as > Redhat Enterprise support) and having it compatible with Redhat as a start > I think it reasonable that the cAos distribution could become that Linux > "sweet spot" distribution. Anybody developing on Redhat Enterprise or on > cAos could be confident their software would run on cAos or Redhat > Enterprise and continue to run on cAos (the appropriate version) as it is > patched, updated, and extended into the future. So my question is why is Debian not the "sweet spot" for you? Debian is free and supported for a reasonable amount of time. What about Gentoo? I am asking because I want to make sure that cAos meets your needs where other free distributions don't. I have my own ideas about this, but I want to hear from others. > How this fits with Redhat's needs and the future commercial activity on > Linux I have no idea. All I know is that in the short to medium term it is > something that would be very helpful to me. What other choices do I have? Agreed. So what shall we install today? -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From sjmudd at pobox.com Tue Sep 30 10:40:02 2003 From: sjmudd at pobox.com (Simon J Mudd) Date: 30 Sep 2003 19:40:02 +0200 Subject: [cAos] cAos] RHEL Support and compatiability - why In-Reply-To: <20030930045703.GB21853@titan.runlevelzero.net> References: <4.3.2.7.2.20030929162342.0364f580@imap4.lbl.gov> <20030930045703.GB21853@titan.runlevelzero.net> Message-ID: <86smmeyy31.fsf@unicorn.wl0.org> greg at runlevelzero.net (Greg Kurtzer) writes: [snip] > So it looks like the cAos project will have two components (described at: > http://caosity.org/pipermail/caos/2003-September/000385.html). Basically it > states that there will be two breeds of cAos. The caos-el which is a freely > distributable version of RHEL, and cAos is then the community solution which > (for versions 1&2) borrows some of the core from caos-el. > > So the level of RHEL compatibility will be determined by which cAos version > you choose. The only problem I see with having 2 versions is that over time they may well diverge (different target audience too). While there are people who need support for the latest hardware I certainly have stopped kernel chasing some time ago. _I_ want updates, backward compatibility and to not be forced to upgrade every X months. RH?s upgrade path as left "binary incompatiblity" between minor versions of the distributions (different incompatiblle db3 libraries on RH 7.x), and also haven?t provided backward compatibile librareis for thoese who need them. This I see is what RHEL is trying to provide, and for _me_ a low cost (or CAos equivalent) is very appealing. [snip] > So my question is why is Debian not the "sweet spot" for you? Debian is free > and supported for a reasonable amount of time. What about Gentoo? In my case I've been using RH since 3.0.3, so perhaps laziness is the reason. I know my way around a RH machine, but am far less comfortable with Debian. The package selector (dselect) is not wonderful, but perhaps I am ignorant of a better alternative. (I do use apt-get on RH and am happy with it) I've also tried GenToo and while emerge * seems to resolve all problems, I haven't found a way to get the same functionality as certain rpm commands (is there a howto?). I currently also use FreeBSD and it's "stability" is very good. The package management is certainly not perfect but I am happy with it. In that respect FreeBSD is similar in many ways to GenToo. > I am asking because I want to make sure that cAos meets your needs where other > free distributions don't. I have my own ideas about this, but I want to hear > from others. Hope my answers give you a feel for one lurker?s view on the subject. Simon From rocky at atipa.com Tue Sep 30 11:32:20 2003 From: rocky at atipa.com (Rocky McGaugh) Date: Tue, 30 Sep 2003 13:32:20 -0500 (CDT) Subject: [cAos] cAos] RHEL Support and compatiability - why In-Reply-To: <86smmeyy31.fsf@unicorn.wl0.org> Message-ID: On 30 Sep 2003, Simon J Mudd wrote: > greg at runlevelzero.net (Greg Kurtzer) writes: > > [snip] > > > So it looks like the cAos project will have two components (described at: > > http://caosity.org/pipermail/caos/2003-September/000385.html). Basically it > > states that there will be two breeds of cAos. The caos-el which is a freely > > distributable version of RHEL, and cAos is then the community solution which > > (for versions 1&2) borrows some of the core from caos-el. > > > > So the level of RHEL compatibility will be determined by which cAos version > > you choose. > > The only problem I see with having 2 versions is that over time they > may well diverge (different target audience too). While there are > people who need support for the latest hardware I certainly have > stopped kernel chasing some time ago. > > _I_ want updates, backward compatibility and to not be forced to > upgrade every X months. RH?s upgrade path as left "binary > incompatiblity" between minor versions of the distributions (different > incompatiblle db3 libraries on RH 7.x), and also haven?t provided > backward compatibile librareis for thoese who need them. This I see > is what RHEL is trying to provide, and for _me_ a low cost (or CAos > equivalent) is very appealing. > > [snip] It is expected that over the next 5 years the mainstream cAos and the enterprise compatible versions will take very different paths. To the cAos project, the EL compatible tree is just an initial base. The cAos project will provide a convenient location to distribute the static EL compatible tree and its updates to those who need it. Some members of the cAos project do not care about EL compatible tree, other than its use as a base. To others, like me, having a freely distributable EL clone is the main benefit. This is my understanding of the current plans. There was some discussion of moving the EL clone to another project, but there is a good argument to support the pooling of resources and visibility. -- Rocky McGaugh Atipa Technologies rocky at atipatechnologies.com rmcgaugh at atipa.com 1-785-841-9513 x3110 http://67.8450073/ perl -e 'print unpack(u, ".=W=W+F%T:7\!A+F-O;0H`");' From websurfer at navegants.com Tue Sep 30 11:37:10 2003 From: websurfer at navegants.com (Josep M.) Date: Tue, 30 Sep 2003 20:37:10 +0200 Subject: [cAos] New Packages for RHEL Message-ID: <6.0.0.22.2.20030930203403.025aa728@pop1> Hello. I would like ask if there is in mind create and maintain too a long set of packages that are not inclosed in RHEL by default,but that are very useful:) as example,mc,last version of gpg and many others.I mean similar as do Fedora now,but for the RHEL. Josep From rocky at atipa.com Tue Sep 30 11:53:19 2003 From: rocky at atipa.com (Rocky McGaugh) Date: Tue, 30 Sep 2003 13:53:19 -0500 (CDT) Subject: [cAos] New Packages for RHEL In-Reply-To: <6.0.0.22.2.20030930203403.025aa728@pop1> Message-ID: On Tue, 30 Sep 2003, Josep M. wrote: > Hello. > > I would like ask if there is in mind create and maintain too a long set of packages that are not > inclosed in RHEL by default,but that are very useful:) as example,mc,last version of gpg and > many others.I mean similar as do Fedora now,but for the RHEL. > > Josep > I see a need for it. Although some of the packages in the cAos mainstream would fit this description, I dont think it would be an enduring solution. A caosel-contrib or such. -- Rocky McGaugh Atipa Technologies rocky at atipatechnologies.com rmcgaugh at atipa.com 1-785-841-9513 x3110 http://67.8450073/ perl -e 'print unpack(u, ".=W=W+F%T:7\!A+F-O;0H`");' From rocky at atipa.com Tue Sep 30 12:14:03 2003 From: rocky at atipa.com (Rocky McGaugh) Date: Tue, 30 Sep 2003 14:14:03 -0500 (CDT) Subject: [cAos] The rules of cAos. In-Reply-To: <3F6E3C04.1030308@it.swin.edu.au> Message-ID: On Mon, 22 Sep 2003, John Newbigin wrote: > with cAosel, will it be supported until the RHEL end of life? What > about support beond this date? > > What about bugs that RedHat won't fix, will these be fixed in cAosel? > Perhaps this version also needs two streams, RedHat compatable and > RedHat enhanced (for example, all our new PCs have network cards > (Broadcom), video and audio chipsets (Intel) which are not supported > under RHEL). > > Does this project have any financial support or backing? If the > developers get board, are all the users going to be left high and dry? > > I am keen to see a distribution like cAosel come to light and I am > prepared to help in any way that I can but before I jump on the > bandwagon I need to make sure that it is going to meet our needs, > otherwise we will maintain our own internal RHEL version. > > John. (im talking about RHEL3 and cAosel-2, rhel2.1 and caosel-1 timelines would have to adjusted) Will it be "supported"? Depends on your definition of "support". RedHat will be supporting updates for 5 years. cAosel will have a minimum level of support based on RH's level of support for RHEL. Beyond that, additions such as enhanced driver support would certainly be possible, but it would require a separate repository. There would need to be as few changes as possible to maintain the desired level of compatibility. The goal of this EL tree is to pool the resources of all the people, like you and I, that would need to maintain our own trees anyway. Instead of maintaining whole trees, we can hopefully just need to maintain our specific requirements beyond the stock RHEL. -- Rocky McGaugh Atipa Technologies rocky at atipatechnologies.com rmcgaugh at atipa.com 1-785-841-9513 x3110 http://67.8450073/ perl -e 'print unpack(u, ".=W=W+F%T:7\!A+F-O;0H`");' > > > > > > On Thu, 18 Sep 2003, Greg Kurtzer wrote: > > > > > >>While there has not been much talk on the list as of late, we have been > >>discussing on private mail, and IRC the immediate direction of cAos and > >>what is needed from community based operating systems in general. I have > >>spent some time talking with with many of you (off list) about operating > >>system needs, and I think that we have come to a solution that will > >>satisfy most everyone here. > >> > >>Basically I see two major pools of interest: One is a community RedHat like > >>solution, and the other is a community based distribution that builds from > >>community sources. > >> > >>cAos I think is capable of providing a solution to both pools of thought > >>immediately (well within several months) by offering two solutions. I see the > >>community based cAos (as has been discussed), and a cAos Enterprise Linux > >>(cAosel). > >> > >>cAosel is looking to be a packaged form of the RHEL-Rebuild project. This can > >>probably be maintained by a small to medium sized handful of developers and > >>will pull directly from RHEL. We will remove all components of non-freely > >>distributable code, and if needed replace it with a free counterpart. This > >>will literally be a freely distributable drop in replacement for RHEL that > >>will mirror their support errata (as long as RH does not change the source > >>availability of their errata). > >> > >>The second (original) solution is a community distribution that is built > >>using community sources. The goal here is to provide a Debian like social > >>pool, while maintaining a RPM based operating system that is geared toward > >>LSB compatibility, ease of use for the administrator, scientific computing > >>as well as a general desktop/server platform. > >> > >>cAos will then be built by community sources, and some of the packages for the > >>base system will be used from cAosel. We will attempt to keep this base small > >>enough to not play a critical role in supportability, but large enough to > >>maintain compatibility. > >> > >>There will be two development groups for each of these projects, but both > >>projects may work closely. cAosel will be both a solution for RH refugees > >>and people that want the RHEL compatibility, but don't want the support, and > >>do not wish to pay as well as offer a migration path to the community > >>developed cAos. cAos will be the much needed solution for a community based > >>stable RPM based solution that will be built and managed by the community > >>proper. > >> > >>Right now we need people to offer development resources to cAosel. There have > >>been several people join this list from the RHEL-Rebuild list, and I am hoping > >>that they will have interest here. If there is already a project in progress > >>targeted to make a distributable RHEL clone, then we should make contact (I > >>am unaware of any such project now). > >> > >>The first order of business is cAosel-1 (which will be built from RHEL2.1) and > >>then cAos-1 will use that as a build host (until it is self hosting) as well > >>as borrow some of the core packages. cAosel will be a fully functioning > >>RHEL2.1 clone, which cAos will be a minimal distribution until package > >>maintainers sign up. cAosel-2 will be built from RHEL3 and thus cAos-2. After > >>that, cAos may split away from cAosel, and cAosel may also split from RHEL. > >>The immediate goal of using RHEL as the base is to offer a migration path > >>from the current commercially supported standard to a community solution. > >> > >>If anything needs to be described in more depth, or if there are concerns with > >>this model, please forward to the list. > >> > >>Thanks. > >>Greg > >> > > > > > > ------------------------------------------------------------------------ > > Jim Wildman, CISSP, RHCE jim at rossberry.com > > http://www.rossberry.com > > > > _______________________________________________ > > cAos mailing list > > cAos at runlevelzero.net > > http://www.caosity.org/mailman/listinfo/caos > > > > > > > > > From greg at runlevelzero.net Tue Sep 30 12:31:24 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Tue, 30 Sep 2003 12:31:24 -0700 Subject: [cAos] The rules of cAos. In-Reply-To: References: <3F6E3C04.1030308@it.swin.edu.au> Message-ID: <20030930193124.GA658@titan.runlevelzero.net> On Tue, Sep 30, 2003 at 02:14:03PM -0500, Rocky McGaugh told me: > Will it be "supported"? Depends on your definition of "support". RedHat > will be supporting updates for 5 years. cAosel will have a minimum level > of support based on RH's level of support for RHEL. Beyond that, additions > such as enhanced driver support would certainly be possible, but it would > require a separate repository. There would need to be as few changes as > possible to maintain the desired level of compatibility. This is a very good point. Something that I really want to make sure that we are careful about is that we will not be offering support except for public mailing lists and bug/security fixes where applicable. I want to be careful of our wording here strictly for political reasons. There are commercially supported Linux distributions, and if you want or need that type of support, invest in them. We are not trying to take any business away from them, rather offer a free community solution that they do not. Personally, I think that the community needs both solutions. I agree with Rocky about the separate repositories for additional packages or modifications. Personally, I would think that this repository would actually be pretty small, and would hope that the major changes, updates, and modifications would go into cAos itself. > The goal of this EL tree is to pool the resources of all the people, like > you and I, that would need to maintain our own trees anyway. Instead of > maintaining whole trees, we can hopefully just need to maintain our > specific requirements beyond the stock RHEL. Again, agreed. Greg -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From lance at uklinux.net Tue Sep 30 12:56:48 2003 From: lance at uklinux.net (Lance Davis) Date: Tue, 30 Sep 2003 20:56:48 +0100 (BST) Subject: [cAos] The rules of cAos. In-Reply-To: <20030930193124.GA658@titan.runlevelzero.net> Message-ID: On Tue, 30 Sep 2003, Greg Kurtzer wrote: > This is a very good point. > > Something that I really want to make sure that we are careful about is that we > will not be offering support except for public mailing lists and bug/security > fixes where applicable. I want to be careful of our wording here strictly for > political reasons. There are commercially supported Linux distributions, and > if you want or need that type of support, invest in them. We are not trying to > take any business away from them, rather offer a free community solution that > they do not. Personally, I think that the community needs both solutions. But there will be people who want to provide commercial support for Caos - and rightly so. They would be able to offer site support at reasonable prices .... We need to decide how we will interact with them ... maybe we would just have an area of the website that has links to people who would be prepared to do work on caos projects .... Lance -- uklinux.net - The ISP of choice for the discerning Linux user. From greg at runlevelzero.net Tue Sep 30 13:08:07 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Tue, 30 Sep 2003 13:08:07 -0700 Subject: [cAos] The rules of cAos. In-Reply-To: References: <20030930193124.GA658@titan.runlevelzero.net> Message-ID: <20030930200807.GA2090@titan.runlevelzero.net> On Tue, Sep 30, 2003 at 08:56:48PM +0100, Lance Davis told me: > But there will be people who want to provide commercial support for Caos - > and rightly so. Yep. > They would be able to offer site support at reasonable prices .... > > We need to decide how we will interact with them ... maybe we would just > have an area of the website that has links to people who would be prepared > to do work on caos projects .... Agreed. Actually, I have been tossing around this idea for quite some time. I would like to see a matchmaking service for cAos developers and contributors to find consulting positions. There can also be a portion for support organizations or companies as well as individual consultants. This should be really easy to do, and I think would offer much benefit. Thoughts? Greg -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From rocky at atipa.com Tue Sep 30 13:53:49 2003 From: rocky at atipa.com (Rocky McGaugh) Date: Tue, 30 Sep 2003 15:53:49 -0500 (CDT) Subject: [cAos] The rules of cAos. In-Reply-To: <20030930193124.GA658@titan.runlevelzero.net> Message-ID: On Tue, 30 Sep 2003, Greg Kurtzer wrote: > I agree with Rocky about the separate repositories for additional packages or > modifications. Personally, I would think that this repository would actually > be pretty small, and would hope that the major changes, updates, and > modifications would go into cAos itself. In the beginning, I think it would be small. I'd think most would be the same packages between caos-2 and caosel-2. I do think though, that the users of caos-2 will want more over the course of 5 years than the compat requirements will allow in caosel-2. -- Rocky McGaugh Atipa Technologies rocky at atipatechnologies.com rmcgaugh at atipa.com 1-785-841-9513 x3110 http://67.8450073/ perl -e 'print unpack(u, ".=W=W+F%T:7\!A+F-O;0H`");' From websurfer at navegants.com Tue Sep 30 14:34:58 2003 From: websurfer at navegants.com (Josep M.) Date: Tue, 30 Sep 2003 23:34:58 +0200 Subject: [cAos] New Packages for RHEL In-Reply-To: References: <6.0.0.22.2.20030930203403.025aa728@pop1> Message-ID: <6.0.0.22.2.20030930232940.03326520@pop3.navegants.com> Hell@ Yes,I mean as "the Fedora for the free RHEL",because I think that Fedora never will release packages for RHEL,only for the free Linux distribution.I think that adapt packages to RHEL or derivatives of these will be a good point.RHEL miss some packages,for example mailman is not inclosed and many others that can be interesting have "ready to install".Build a distribution can be so easy and compile the updates too,but adapt some packages will require more work. Is just my opinion. Josep Begin of Quote Rocky McGaugh : >On Tue, 30 Sep 2003, Josep M. wrote: >> Hello. >> >> I would like ask if there is in mind create and maintain too a long set of packages that are not >> inclosed in RHEL by default,but that are very useful:) as example,mc,last version of gpg and >> many others.I mean similar as do Fedora now,but for the RHEL. >> >> Josep >> > >I see a need for it. Although some of the packages in the cAos mainstream >would fit this description, I dont think it would be an enduring solution. > >A caosel-contrib or such. > >-- From skvidal at phy.duke.edu Tue Sep 30 14:45:11 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 30 Sep 2003 17:45:11 -0400 Subject: [cAos] New Packages for RHEL In-Reply-To: <6.0.0.22.2.20030930232940.03326520@pop3.navegants.com> References: <6.0.0.22.2.20030930203403.025aa728@pop1> <6.0.0.22.2.20030930232940.03326520@pop3.navegants.com> Message-ID: <1064958310.25805.43.camel@opus> On Tue, 2003-09-30 at 17:34, Josep M. wrote: > Hell@ > > Yes,I mean as "the Fedora for the free RHEL",because I think that > Fedora never will release packages > for RHEL,only for the free Linux distribution.I think that adapt > packages to RHEL or derivatives > of these will be a good point.RHEL miss some packages,for example > mailman is not inclosed > and many others that can be interesting have "ready to install".Build > a distribution can be so easy > and compile the updates too,but adapt some packages will require more > work. > Which is, imo, why work should be pushed into helping fedora core be stable and maintain fedora legacy packages. Then you're working with more people and contributing back to a whole set of packages some of which will find their way into RHEL. -sv From lance at uklinux.net Tue Sep 30 14:56:00 2003 From: lance at uklinux.net (Lance Davis) Date: Tue, 30 Sep 2003 22:56:00 +0100 (BST) Subject: [cAos] New Packages for RHEL In-Reply-To: <1064958310.25805.43.camel@opus> Message-ID: On 30 Sep 2003, seth vidal wrote: > On Tue, 2003-09-30 at 17:34, Josep M. wrote: > > Hell@ > > > > Yes,I mean as "the Fedora for the free RHEL",because I think that > > Fedora never will release packages > > for RHEL,only for the free Linux distribution.I think that adapt > > packages to RHEL or derivatives > > of these will be a good point.RHEL miss some packages,for example > > mailman is not inclosed > > and many others that can be interesting have "ready to install".Build > > a distribution can be so easy > > and compile the updates too,but adapt some packages will require more > > work. > > > > Which is, imo, why work should be pushed into helping fedora core be > stable and maintain fedora legacy packages. > > Then you're working with more people and contributing back to a whole > set of packages some of which will find their way into RHEL. So that all of the work we do would be owned by Redhat ?? No thanks. Lance -- uklinux.net - The ISP of choice for the discerning Linux user. From websurfer at navegants.com Tue Sep 30 14:52:47 2003 From: websurfer at navegants.com (Josep M.) Date: Tue, 30 Sep 2003 23:52:47 +0200 Subject: [cAos] New Packages for RHEL In-Reply-To: <1064958310.25805.43.camel@opus> References: <6.0.0.22.2.20030930203403.025aa728@pop1> <6.0.0.22.2.20030930232940.03326520@pop3.navegants.com> <1064958310.25805.43.camel@opus> Message-ID: <6.0.0.22.2.20030930234716.02594fa8@pop3.navegants.com> Hello. Maybe You are right in this point,the only problem that I see is the long life of RHEL,that fedora will release packages for more updated linux when RHEL will have one year old or more. Josep Begin of Quote seth vidal : >On Tue, 2003-09-30 at 17:34, Josep M. wrote: >> Hell@ >> >> Yes,I mean as "the Fedora for the free RHEL",because I think that >> Fedora never will release packages >> for RHEL,only for the free Linux distribution.I think that adapt >> packages to RHEL or derivatives >> of these will be a good point.RHEL miss some packages,for example >> mailman is not inclosed >> and many others that can be interesting have "ready to install".Build >> a distribution can be so easy >> and compile the updates too,but adapt some packages will require more >> work. >> > >Which is, imo, why work should be pushed into helping fedora core be >stable and maintain fedora legacy packages. > >Then you're working with more people and contributing back to a whole >set of packages some of which will find their way into RHEL. > >-sv From skvidal at phy.duke.edu Tue Sep 30 15:00:31 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 30 Sep 2003 18:00:31 -0400 Subject: [cAos] New Packages for RHEL In-Reply-To: References: Message-ID: <1064959231.25812.53.camel@opus> > So that all of the work we do would be owned by Redhat ?? > > No thanks. > Where did you see that? If you package or work on a program the copyrights over the work you did are yours. Not red hat's. At what point did you determine that happens? -sv From rocky at atipa.com Tue Sep 30 15:01:25 2003 From: rocky at atipa.com (Rocky McGaugh) Date: Tue, 30 Sep 2003 17:01:25 -0500 (CDT) Subject: [cAos] New Packages for RHEL In-Reply-To: <1064958310.25805.43.camel@opus> Message-ID: On 30 Sep 2003, seth vidal wrote: > Which is, imo, why work should be pushed into helping fedora core be > stable and maintain fedora legacy packages. > > Then you're working with more people and contributing back to a whole > set of packages some of which will find their way into RHEL. > > -sv Except that with a 4-6month release cycle, Fedora Core will never be stable. I am not critizing Fedora Core, except that it does not fit my needs. I need an inexpensive distro with a long lifespan that ISV's will support. If all software was OSS, then Fedora Core would probably work for me, but I need a core that Intel and PGI compilers are going to work on. -- Rocky McGaugh Atipa Technologies rocky at atipatechnologies.com rmcgaugh at atipa.com 1-785-841-9513 x3110 http://67.8450073/ perl -e 'print unpack(u, ".=W=W+F%T:7\!A+F-O;0H`");' From websurfer at navegants.com Tue Sep 30 14:57:41 2003 From: websurfer at navegants.com (Josep M.) Date: Tue, 30 Sep 2003 23:57:41 +0200 Subject: [cAos] New Packages for RHEL In-Reply-To: References: <1064958310.25805.43.camel@opus> Message-ID: <6.0.0.22.2.20030930235508.025705e8@pop3.navegants.com> Hello. As long is as GPL I don?t see this a problem,we will take ALL SRPMS for buid a distribution from Redhat,if they see anything in return,why not? If is free (GPL) all people can take benefit,maybe will be a good point don?t do duplicate works. Josep Begin of Quote Lance Davis : >On 30 Sep 2003, seth vidal wrote: > >> On Tue, 2003-09-30 at 17:34, Josep M. wrote: >> > Hell@ >> > >> > Yes,I mean as "the Fedora for the free RHEL",because I think that >> > Fedora never will release packages >> > for RHEL,only for the free Linux distribution.I think that adapt >> > packages to RHEL or derivatives >> > of these will be a good point.RHEL miss some packages,for example >> > mailman is not inclosed >> > and many others that can be interesting have "ready to install".Build >> > a distribution can be so easy >> > and compile the updates too,but adapt some packages will require more >> > work. >> > >> >> Which is, imo, why work should be pushed into helping fedora core be >> stable and maintain fedora legacy packages. >> >> Then you're working with more people and contributing back to a whole >> set of packages some of which will find their way into RHEL. > >So that all of the work we do would be owned by Redhat ?? > >No thanks. > >Lance From skvidal at phy.duke.edu Tue Sep 30 15:02:53 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 30 Sep 2003 18:02:53 -0400 Subject: [cAos] New Packages for RHEL In-Reply-To: <6.0.0.22.2.20030930234716.02594fa8@pop3.navegants.com> References: <6.0.0.22.2.20030930203403.025aa728@pop1> <6.0.0.22.2.20030930232940.03326520@pop3.navegants.com> <1064958310.25805.43.camel@opus> <6.0.0.22.2.20030930234716.02594fa8@pop3.navegants.com> Message-ID: <1064959373.25812.57.camel@opus> On Tue, 2003-09-30 at 17:52, Josep M. wrote: > Hello. > > Maybe You are right in this point,the only problem that I see is the > long life of RHEL,that fedora will release > packages for more updated linux when RHEL will have one year old or > more. Hi, Keeping a long life of fedora will be up to the user's willing to contribute time back to maintain security errata on older releases. Same as what caos will have to do (as far as rebuilding packages and patching anything that doesn't quite fit). -sv From skvidal at phy.duke.edu Tue Sep 30 15:04:55 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 30 Sep 2003 18:04:55 -0400 Subject: [cAos] New Packages for RHEL In-Reply-To: References: Message-ID: <1064959495.25805.60.camel@opus> > > Except that with a 4-6month release cycle, Fedora Core will never be > stable. I disagree. - RHL had a 6 month release cycle. > I need an inexpensive distro with a long lifespan that ISV's will support. > > If all software was OSS, then Fedora Core would probably work for me, but > I need a core that Intel and PGI compilers are going to work on. It's not obvious to me that the intel and pgi compilers (especially newer ones) will always work on a 3 or 4 yr old rhel. Not to mention that there will be some build inconsistencies b/t red hat's RHEL and the RHEL-rebuilt. -sv From lance at uklinux.net Tue Sep 30 15:08:49 2003 From: lance at uklinux.net (Lance Davis) Date: Tue, 30 Sep 2003 23:08:49 +0100 (BST) Subject: [cAos] New Packages for RHEL In-Reply-To: <1064959231.25812.53.camel@opus> Message-ID: On 30 Sep 2003, seth vidal wrote: > > > So that all of the work we do would be owned by Redhat ?? > > > > No thanks. > > > > Where did you see that? If you package or work on a program the > copyrights over the work you did are yours. Not red hat's. At what point > did you determine that happens? From websurfer at navegants.com Tue Sep 30 18:07:21 2003 From: websurfer at navegants.com (Josep M.) Date: Wed, 01 Oct 2003 00:07:21 -0100 Subject: [cAos] New Packages for RHEL In-Reply-To: <1064959495.25805.60.camel@opus> References: <1064959495.25805.60.camel@opus> Message-ID: <6.0.0.22.2.20031001000459.025a8e00@pop3.navegants.com> Hello. Interesting pont the inconsistences between "original RHEL" and "derivatives", I plan compile my own using the beta,and after install this rebuilt,and with this rebuilt will compile the definitive rebuilt,I think this will be the more closest to the autentical RHEL that I can find myself. (after i will build i686 packages too) Josep Begin of Quote seth vidal : >> >> Except that with a 4-6month release cycle, Fedora Core will never be >> stable. > >I disagree. - RHL had a 6 month release cycle. > > >> I need an inexpensive distro with a long lifespan that ISV's will support. >> >> If all software was OSS, then Fedora Core would probably work for me, but >> I need a core that Intel and PGI compilers are going to work on. > >It's not obvious to me that the intel and pgi compilers (especially >newer ones) will always work on a 3 or 4 yr old rhel. Not to mention >that there will be some build inconsistencies b/t red hat's RHEL and the >RHEL-rebuilt. > >-sv > > > > >_______________________________________________ >cAos mailing list >cAos at runlevelzero.net >http://www.caosity.org/mailman/listinfo/caos From skvidal at phy.duke.edu Tue Sep 30 15:21:54 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 30 Sep 2003 18:21:54 -0400 Subject: [cAos] New Packages for RHEL In-Reply-To: References: Message-ID: <1064960514.25805.73.camel@opus> > > > > Where did you see that? If you package or work on a program the > > copyrights over the work you did are yours. Not red hat's. At what point > > did you determine that happens? > > >From the fedora trademark guidelines - why should we produce something > that we wont even be able to legally use the name of ??? So if you say 'based off of' or 'compatible with' RHEL do you think red hat's trademark people won't be upset? Also - the whole point would be to contribute to the project, not to fork it and run. -sv From rick at linuxmafia.com Tue Sep 30 15:42:23 2003 From: rick at linuxmafia.com (Rick Moen) Date: Tue, 30 Sep 2003 15:42:23 -0700 Subject: [cAos] cAos] RHEL Support and compatiability - why In-Reply-To: <86smmeyy31.fsf@unicorn.wl0.org> References: <4.3.2.7.2.20030929162342.0364f580@imap4.lbl.gov> <20030930045703.GB21853@titan.runlevelzero.net> <86smmeyy31.fsf@unicorn.wl0.org> Message-ID: <20030930224222.GX20106@linuxmafia.com> Quoting Simon J Mudd (sjmudd at pobox.com): > I know my way around a RH machine, but am far less comfortable with > Debian. The package selector (dselect) is not wonderful, but perhaps > I am ignorant of a better alternative. ncurses-based: aptitude gtk+-based: synaptic There are lots of others -- all of which work equally well with the RPM version of the apt tool suite (apt-get, apt-cdrom, etc). > I currently also use FreeBSD and it's "stability" is very good. The > package management is certainly not perfect but I am happy with it. > In that respect FreeBSD is similar in many ways to GenToo. Or vice-versa. ;-> -- Cheers, "The only good goth is a shoggoth...." Rick Moen -- Alistair J.R. Young, in r.a.sf.w.r-j rick at linuxmafia.com From greg at runlevelzero.net Tue Sep 30 15:47:08 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Tue, 30 Sep 2003 15:47:08 -0700 Subject: [cAos] New Packages for RHEL In-Reply-To: <1064960514.25805.73.camel@opus> References: <1064960514.25805.73.camel@opus> Message-ID: <20030930224708.GB3370@titan.runlevelzero.net> On Tue, Sep 30, 2003 at 06:21:54PM -0400, seth vidal told me: > So if you say 'based off of' or 'compatible with' RHEL do you think red > hat's trademark people won't be upset? Actually, if it is up to me I would remove all mention of RedHat from the distribution and caosity.org. I was talking with someone today even about caosel, and the redhat-config-* packages, /etc/redhat-release, redhat-logos, etc... I am of the opinion that anything named with the RedHat trademark should be either not included in the distro or forked with a different name. I think that sym links are reasonable like csh->tcsh and /etc/redhat-release->/etc/caosel-release. But in the end this is up to the caosel maintainers, not I. The cAos project (not EL) should not have any reference to RedHat in the finished product (except for rpm change logs, docs, etc...). Seth is right. I don't think that RedHat would like us using their trademark for a similar software project. And RedHat has many times more lawyers then we do! ;) Greg -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From csieh at fnal.gov Tue Sep 30 16:02:44 2003 From: csieh at fnal.gov (csieh) Date: Tue, 30 Sep 2003 18:02:44 -0500 (CDT) Subject: [cAos] New Packages for RHEL In-Reply-To: <20030930224708.GB3370@titan.runlevelzero.net> Message-ID: I agree, I think RedHat will tolerate people taking the SRPMS and making a new distribution out of it as long as RedHat is not named. Clearly there is some legal right that exists to use the SRPMS as you wish but the name RedHat is another story. Connie Sieh Fermi National Accelerator Laboratory On Tue, 30 Sep 2003, Greg Kurtzer wrote: > On Tue, Sep 30, 2003 at 06:21:54PM -0400, seth vidal told me: > > So if you say 'based off of' or 'compatible with' RHEL do you think red > > hat's trademark people won't be upset? > > Actually, if it is up to me I would remove all mention of RedHat from the > distribution and caosity.org. > > I was talking with someone today even about caosel, and the redhat-config-* > packages, /etc/redhat-release, redhat-logos, etc... I am of the opinion that > anything named with the RedHat trademark should be either not included in the > distro or forked with a different name. I think that sym links are reasonable > like csh->tcsh and /etc/redhat-release->/etc/caosel-release. But in the end > this is up to the caosel maintainers, not I. > > The cAos project (not EL) should not have any reference to RedHat in the > finished product (except for rpm change logs, docs, etc...). > > Seth is right. I don't think that RedHat would like us using their trademark > for a similar software project. And RedHat has many times more lawyers then > we do! ;) > > Greg > From rocky at atipa.com Tue Sep 30 16:36:34 2003 From: rocky at atipa.com (Rocky McGaugh) Date: Tue, 30 Sep 2003 18:36:34 -0500 (CDT) Subject: [cAos] New Packages for RHEL In-Reply-To: Message-ID: On Tue, 30 Sep 2003, csieh wrote: > I agree, I think RedHat will tolerate people taking the SRPMS and > making a new distribution out of it as long as RedHat is not named. > Clearly there is some legal right that exists to use the SRPMS as you wish > but the name RedHat is another story. > > Connie Sieh > Fermi National Accelerator Laboratory Exactly. I do not expect cAosel to displace a single RHEL customer. Some will need RHEL to get support from certain ISV's (Oracle, IBM). These people should buy RHEL or SLES. Some people will need dedicated hand-holding through their whole production linux deployment or 24/7/365 support. These people should buy RHEL or SLES. Then there are people like me that want the technical merits of RHEL or SLES but dont need the support. We should clone RHEL or SLES. We are the people that never would have bought RHEL anyway (not at >$100/node). Anyway, my point is that I'm not trying to hurt RH's revenues. I dont think we'll impact their bottom line in the least. I see no reason for them to worry about us at all. I do not understand their reasoning though, leaving such a huge gap in their services. I know there are a lot of other people like me that are willing to pay a reasonable distribution cost and $100 a year to access updates but do not want to pay $$$ for support I dont need. Heck, even give us incident support at $100 (or $200) per hour. -- Rocky McGaugh Atipa Technologies rocky at atipatechnologies.com rmcgaugh at atipa.com 1-785-841-9513 x3110 http://67.8450073/ perl -e 'print unpack(u, ".=W=W+F%T:7\!A+F-O;0H`");' From mej at kainx.org Tue Sep 30 16:46:50 2003 From: mej at kainx.org (Michael Jennings) Date: Tue, 30 Sep 2003 19:46:50 -0400 Subject: [cAos] cAos] RHEL Support and compatiability - why In-Reply-To: <20030930224708.GB3370@titan.runlevelzero.net> <1064959495.25805.60.camel@opus> <86smmeyy31.fsf@unicorn.wl0.org> <4.3.2.7.2.20030929162342.0364f580@imap4.lbl.gov> References: <1064960514.25805.73.camel@opus> <20030930224708.GB3370@titan.runlevelzero.net> <1064959495.25805.60.camel@opus> <3F6E3C04.1030308@it.swin.edu.au> <4.3.2.7.2.20030929162342.0364f580@imap4.lbl.gov> <20030930045703.GB21853@titan.runlevelzero.net> <86smmeyy31.fsf@unicorn.wl0.org> <4.3.2.7.2.20030929162342.0364f580@imap4.lbl.gov> Message-ID: <20030930234650.GB28527@kainx.org> I fear I may be jumping into the middle of a melee here. However, after watching the discussion on the list for the past couple of days, and remembering having the exact same discussions at VA, I felt like maybe my hindsight might have some benefit for cAos. So I'll try to convey my thoughts and experience as best I can; please feel free to take them or leave them as you see fit. :-) On Monday, 29 September 2003, at 17:09:47 (-0700), Jed Donnelley wrote: > I seem to be in just the situation you describe Greg. I run some > Oracle systems. For them I need the "real thing" RH Enterprise. > Not because I need any support from Redhat. I've never gotten any > support from Redhat and never expect to. I need the "real thing" > because my DBAs need to get support from Oracle. They can't get > such support unless they are running on a supported system. This is > part of a deal between Redhat and Oracle. If the reasoning behind using RHEL as your base is to get support from Oracle through their RedHat support, don't bother. You might be able to sucker them by telling them you have an RHEL system, but depending on their agreement with RH, it might not even matter, and the risk is far too great for any company who can afford to use Oracle to take. > So far so good or bad depending on your perspective - Oracle was > supported on Redhat 7.1 without such an agreement. VA made possible Oracle's support for RH 7.x. Unless things have changed in the past couple of years, Oracle has no love for RedHat. If a new enterprise Linux leader emerged, they might be willing to support it. However, the big hurdle is the Oracle testing suite. It ain't cheap. :-) > However, we run many other systems for other general services, help > desk, Web servers, mail systems, CVS services, instant messaging, > LDAP, custom services, etc., etc. These systems don't need to be > the "real thing", but from my perspective it would be helpful if > they were as compatible as possible with the "real thing" systems > and perhaps equally important that they be compatible with earlier > Redhat systems. From mej at kainx.org Tue Sep 30 16:56:22 2003 From: mej at kainx.org (Michael Jennings) Date: Tue, 30 Sep 2003 19:56:22 -0400 Subject: [cAos] New Packages for RHEL In-Reply-To: References: Message-ID: <20030930235622.GC28527@kainx.org> On Tuesday, 30 September 2003, at 18:36:34 (-0500), Rocky McGaugh wrote: > Exactly. I do not expect cAosel to displace a single RHEL customer. Maybe, maybe not. It really depends on *why* they're using RHEL. For many customers, Vermillion is probably viable for their needs. For others (like Oracle people), Vermillion's different kernel would be an issue (not to mention any RH/Oracle contracts). > Some will need RHEL to get support from certain ISV's (Oracle, > IBM). These people should buy RHEL or SLES. Agreed. > Some people will need dedicated hand-holding through their whole > production linux deployment or 24/7/365 support. These people should > buy RHEL or SLES. I disagree here. My company and lots of others do quite a bit of business supporting their distribution of choice for their customers. We as a company generally use Vermillion because, although there is no official relationship between Vermillion and the company, we do have very close personal relationships with its maintainer.... *grin* If people need hand-holding, on-call support, remote administration, etc., they should first find the company with whom they wish to do their Linux business. Then go with whatever they recommend. > Anyway, my point is that I'm not trying to hurt RH's revenues. I > dont think we'll impact their bottom line in the least. I see no > reason for them to worry about us at all. Agreed. People who are buying RHEL are doing so for a reason, and people who aren't are refusing to do so for a reason. These aren't likely to change dramatically based on the presence of a free alternative. (If they were, do you really think RH would be providing their stuff under the GPL? Of course not. Case in point: VA Research^WLinux Systems^W^WSoftware.) HTH, Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) ----------------------------------------------------------------------- "What good is having someone who can walk on water if you don't follow in His footsteps?" -- Unknown From websurfer at navegants.com Tue Sep 30 17:09:21 2003 From: websurfer at navegants.com (Josep M.) Date: Wed, 01 Oct 2003 02:09:21 +0200 Subject: [cAos] New Packages for RHEL In-Reply-To: <20030930224708.GB3370@titan.runlevelzero.net> References: <1064960514.25805.73.camel@opus> <20030930224708.GB3370@titan.runlevelzero.net> Message-ID: <6.0.0.22.2.20031001020244.02584b80@pop3.navegants.com> Hello. There is anoter solution: 1 - Use the taroon beta,or severn beta and a script for "build yourself" the distribution.This mean that every person who want must build herself the distribution.but only one standard script for all people. 2 - If You build yourself the distribution just for your use don?t need remove anything,isnt ? 3 - The packages produced in caos can be "added" to the distribution,there is not need of change all full packages...why do duplicate work? Josep Begin of Quote Greg Kurtzer : >On Tue, Sep 30, 2003 at 06:21:54PM -0400, seth vidal told me: >> So if you say 'based off of' or 'compatible with' RHEL do you think red >> hat's trademark people won't be upset? > >Actually, if it is up to me I would remove all mention of RedHat from the >distribution and caosity.org. > >I was talking with someone today even about caosel, and the redhat-config-* >packages, /etc/redhat-release, redhat-logos, etc... I am of the opinion that >anything named with the RedHat trademark should be either not included in the >distro or forked with a different name. I think that sym links are reasonable >like csh->tcsh and /etc/redhat-release->/etc/caosel-release. But in the end >this is up to the caosel maintainers, not I. > >The cAos project (not EL) should not have any reference to RedHat in the >finished product (except for rpm change logs, docs, etc...). > >Seth is right. I don't think that RedHat would like us using their trademark >for a similar software project. And RedHat has many times more lawyers then >we do! ;) > >Greg >-- >Greg M. Kurtzer >http://runlevelzero.net/ >http://caosity.org/ >http://warewulf-cluster.org/ >_______________________________________________ >cAos mailing list >cAos at runlevelzero.net >http://www.caosity.org/mailman/listinfo/caos From rocky at atipa.com Tue Sep 30 17:26:56 2003 From: rocky at atipa.com (Rocky McGaugh) Date: Tue, 30 Sep 2003 19:26:56 -0500 (CDT) Subject: [cAos] New Packages for RHEL In-Reply-To: <20030930235622.GC28527@kainx.org> Message-ID: On Tue, 30 Sep 2003, Michael Jennings wrote: > I disagree here. My company and lots of others do quite a bit of > business supporting their distribution of choice for their customers. > We as a company generally use Vermillion because, although there is no > official relationship between Vermillion and the company, we do have > very close personal relationships with its maintainer.... *grin* > > If people need hand-holding, on-call support, remote administration, > etc., they should first find the company with whom they wish to do > their Linux business. Then go with whatever they recommend. Yes, I am sorry. I did in no way mean to discount other professionals such as yourself. Even though I do have some beef with RHAT, I'd still recommend them because I *DO* want them to make money. I do want them to continue to contribute to Linux. -- Rocky McGaugh Atipa Technologies rocky at atipatechnologies.com rmcgaugh at atipa.com 1-785-841-9513 x3110 http://67.8450073/ perl -e 'print unpack(u, ".=W=W+F%T:7\!A+F-O;0H`");' From mej at kainx.org Tue Sep 30 17:35:02 2003 From: mej at kainx.org (Michael Jennings) Date: Tue, 30 Sep 2003 20:35:02 -0400 Subject: [cAos] New Packages for RHEL In-Reply-To: References: <20030930235622.GC28527@kainx.org> Message-ID: <20031001003502.GD28527@kainx.org> On Tuesday, 30 September 2003, at 19:26:56 (-0500), Rocky McGaugh wrote: > Yes, I am sorry. I did in no way mean to discount other > professionals such as yourself. No worries. :) Does Atipa have a Professional Services group? :) > Even though I do have some beef with RHAT, I'd still recommend them > because I *DO* want them to make money. I do want them to continue > to contribute to Linux. As a user, I do want RH to succeed. But I also want SuSE to succeed. And Debian. In fact, I want a good mix of distributions. Otherwise, from an ISV standpoint, we end up being no better off than with Windows and proprietary UNIX. As an employee of a Linux company, I want *Linux* to succeed, not necessarily RedHat. In fact, I want to take as much of RH's business as I can. Same with IBM. I really appreciate both of those companies and everything they've done for Linux...but that doesn't mean I don't want to share in the revenue stream. :) Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) ----------------------------------------------------------------------- "Shh! Be vewy quiet, I'm hunting wuntime errors!" -- Not Elmer Fudd From rocky at atipa.com Tue Sep 30 18:01:11 2003 From: rocky at atipa.com (Rocky McGaugh) Date: Tue, 30 Sep 2003 20:01:11 -0500 (CDT) Subject: [cAos] New Packages for RHEL In-Reply-To: <20031001003502.GD28527@kainx.org> Message-ID: On Tue, 30 Sep 2003, Michael Jennings wrote: > > Does Atipa have a Professional Services group? :) > We do, but we focus on the clustering aspect. I have no problems with referring a customer to where it will most benefit him. > As a user, I do want RH to succeed. But I also want SuSE to succeed. > And Debian. In fact, I want a good mix of distributions. Otherwise, > from an ISV standpoint, we end up being no better off than with > Windows and proprietary UNIX. Windows and UNIX are good from an ISV's pov: long product lifecycles, consistent environment, vendor certification, etc. I wish everything was OSS, but unfortunately it is not. Binary-only kernel modules and glibc changes make it very difficult for ISV's to keep up. How's Vermillion doing with AMD64 and Infiniband support?...:) > As an employee of a Linux company, I want *Linux* to succeed, not > necessarily RedHat. In fact, I want to take as much of RH's business > as I can. Same with IBM. I really appreciate both of those companies > and everything they've done for Linux...but that doesn't mean I don't > want to share in the revenue stream. :) I agree 100%. -- Rocky McGaugh Atipa Technologies rocky at atipatechnologies.com rmcgaugh at atipa.com 1-785-841-9513 x3110 http://67.8450073/ perl -e 'print unpack(u, ".=W=W+F%T:7\!A+F-O;0H`");' From mej at kainx.org Tue Sep 30 18:34:57 2003 From: mej at kainx.org (Michael Jennings) Date: Tue, 30 Sep 2003 21:34:57 -0400 Subject: [cAos] New Packages for RHEL In-Reply-To: References: <20031001003502.GD28527@kainx.org> Message-ID: <20031001013457.GA15426@kainx.org> On Tuesday, 30 September 2003, at 20:01:11 (-0500), Rocky McGaugh wrote: > We do, but we focus on the clustering aspect. I have no problems > with referring a customer to where it will most benefit him. Well, I hope some of the cluster folks at VA found good homes like Atipa.... We had a number of them. :-( (OT: It's an interesting bit of trivia that my spear-heading a project which created a "Cluster Toolkit" CD (with MPICH, HDF, Open DX, etc.) caused me to write a build system to manage the project. That build system was a primitive ancestor of Mezzanine. But I digress....) > Windows and UNIX are good from an ISV's pov: long product > lifecycles, consistent environment, vendor certification, etc. I > wish everything was OSS, but unfortunately it is not. Binary-only > kernel modules and glibc changes make it very difficult for ISV's to > keep up. I agree, which is why Vermillion has a much longer release cycle with more enterprise-class (read: stable and ISV-friendly) features. RH-VALE (RedHat Linux with VA Linux Enhancements, Vermillion's predecessor) was aimed squarely at ISV's like Oracle. (The name of RH-VALE was established after much, much, much haggling between VA's legal department and RedHat's. But they came after VA because it was a company with money; community projects would be decidedly less vulnerable.) There's definitely a good reason for doing one distro that has a faster "churn rate" for desktop users and another that has a slow, extended churn rate for server- and cluster-class applications. That's why I advocate a build/product management system that can support easy customization of the distribution from a fixed base. We can take one or two fixed cores and variations based on community/user needs. > How's Vermillion doing with AMD64 and Infiniband support?...:) *grumble* :-P The biggest hinderance to Vermillion is that there are only a few people who actually work on it, and that I don't have any support from hardware vendors willing to donate hardware. I run builds on my desktop workstation (dual P3-500); rebuilding all of the added/changed packages in Vermillion takes 8-12 hours. You can imagine why I despise updating Mozilla and/or the kernel. :-) The reality is that Mezzanine has a very powerful product description file format that can support any architecture needed, overriding packages, and more. If I had the hardware to do it, multiple arch's would not be a big problem. Actually, the biggest problem would be plugging too much equipment into my poor apartment's wiring. :-] -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) ----------------------------------------------------------------------- "The future is all around us, waiting in moments of transition to be born in moments of revelation." -- G'Kar, Babylon 5 From rocky at atipa.com Tue Sep 30 19:27:50 2003 From: rocky at atipa.com (Rocky McGaugh) Date: Tue, 30 Sep 2003 21:27:50 -0500 (CDT) Subject: [cAos] New Packages for RHEL In-Reply-To: <20031001013457.GA15426@kainx.org> Message-ID: On Tue, 30 Sep 2003, Michael Jennings wrote: > On Tuesday, 30 September 2003, at 20:01:11 (-0500), > Rocky McGaugh wrote: > > How's Vermillion doing with AMD64 and Infiniband support?...:) > > *grumble* :-P > I was not doubting the capabilities of your tool. I cannot resolve http://slugsite.louisville.edu/vermillion/7.3.1/ so i cannot see what glibc you are using, but if it is any earlier than 2.2.5, then you would have to backport a huge amount of code to get AMD64 to work properly. This, for me, is why RHEL2.1 is dead. I was also trying to illustrate that many ISV's and hardware drivers are only targeting RHEL and SLES. Sometimes, there just is no OSS solution, and some of our customers will be locked into certain kernel releases from RHEL or SLES. Having a clone will benefit these strained ISV's also. -- Rocky McGaugh Atipa Technologies rocky at atipatechnologies.com rmcgaugh at atipa.com 1-785-841-9513 x3110 http://67.8450073/ perl -e 'print unpack(u, ".=W=W+F%T:7\!A+F-O;0H`");' From mej at kainx.org Tue Sep 30 19:40:22 2003 From: mej at kainx.org (Michael Jennings) Date: Tue, 30 Sep 2003 22:40:22 -0400 Subject: [cAos] New Packages for RHEL In-Reply-To: References: <20031001013457.GA15426@kainx.org> Message-ID: <20031001024022.GF15426@kainx.org> On Tuesday, 30 September 2003, at 21:27:50 (-0500), Rocky McGaugh wrote: > I was not doubting the capabilities of your tool. I cannot resolve > > http://slugsite.louisville.edu/vermillion/7.3.1/ The mirror got fried (literally). :( Try this one: rsync --bwlimit=10 vermillion.nplus1.net::vermillion/7.3.1/ > so i cannot see what glibc you are using, but if it is any earlier > than 2.2.5, then you would have to backport a huge amount of code to > get AMD64 to work properly. This, for me, is why RHEL2.1 is dead. Vermillion uses glibc 2.2.5. > I was also trying to illustrate that many ISV's and hardware drivers > are only targeting RHEL and SLES. Sometimes, there just is no OSS > solution, and some of our customers will be locked into certain > kernel releases from RHEL or SLES. Having a clone will benefit these > strained ISV's also. I agree that they target RHEL and SLES pretty much exclusively. However, I don't think they're likely to support something without a company behind it. There's no financial benefit in it without huge demand, and community projects have a tough time affording the test suites. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) ----------------------------------------------------------------------- "...in order to secure the safety of the public while traveling on public roads...it shall be unlawful for any person to drive, propel, or run any vehicle in, upon, and along any of the public roads in this county." -- Montgomery County, Mississippi, statute From greg at runlevelzero.net Tue Sep 30 21:09:28 2003 From: greg at runlevelzero.net (Greg Kurtzer) Date: Tue, 30 Sep 2003 21:09:28 -0700 Subject: [cAos] cAos] RHEL Support and compatiability - why In-Reply-To: <20030930234650.GB28527@kainx.org> References: <20030930224708.GB3370@titan.runlevelzero.net> <1064959495.25805.60.camel@opus> <3F6E3C04.1030308@it.swin.edu.au> <4.3.2.7.2.20030929162342.0364f580@imap4.lbl.gov> <20030930045703.GB21853@titan.runlevelzero.net> <86smmeyy31.fsf@unicorn.wl0.org> <4.3.2.7.2.20030929162342.0364f580@imap4.lbl.gov> <20030930234650.GB28527@kainx.org> Message-ID: <20031001040928.GB5747@titan.runlevelzero.net> On Tue, Sep 30, 2003 at 07:46:50PM -0400, Michael Jennings told me: > This is a good chunk of what Mezzanine was designed to do. From the > high level, it manages software products by allowing the build manager > to define products in terms of their components (packages and other > products), building these products by building each component in > turn. However, in terms of actual functionality fleshed out (as > opposed to design goals), it is very much intended to make the > creation and maintenance of "1-off" distributions very easy. > > I've heard cAos already has its own build system, which is fine. But > the simplicity of creating derivatives of the core cAos distribution > is, IMHO, an important consideration. You cannot please all the > people all the time, as we've seen. Mezzanine or a similar system > would make it easy to define several cAos "products" with different > package sets using the same basic components. And if a particular > product didn't meet the needs of a particular user, small departures > should be easy to do, as should keeping the core OS in sync. Our build system is not complete, and I am very interested in Mezzanine. I looked at the site a while ago, and there was not much docs there. Can we schedule some time (phone or IRC) to talk about it? > > I was talking with someone today even about caosel, and the > > redhat-config-* packages, /etc/redhat-release, redhat-logos, > > etc... I am of the opinion that anything named with the RedHat > > trademark should be either not included in the distro or forked with > > a different name. I think that sym links are reasonable like > > csh->tcsh and /etc/redhat-release->/etc/caosel-release. But in the > > end this is up to the caosel maintainers, not I. > > Well, let's not get too paranoid here. All those RedHat config > packages are very nice, and they're all GPL'd. You're going to get > into far more trouble if you start trying to modify them. If we just > leave them be and include them, perhaps with some self-contained > patches of our own, we have every right to do so. RedHat chose to > name the packages as they saw fit, and under the GPL we are guaranteed > the right to modify and distribute changes to said product. As long > as modifications are clearly delineated (and minimal), we'll be fine. I agree with this, but I am still paranoid. Remember, it is not about who is right or wrong it is about who has the best lawyers. I realize that the code is GPL, but the name redhat is a trademark. I don't know if one takes precendent over the other, but it seems like the trademark should not be taken lightly. > Most importantly, until and unless we're prepared to replace them with > GUI configurators of our own, we owe it to our users to maintain the > traditional ease of use that RedHat enjoys. If we get rid of those > things and expect everyone to be config file gurus, we'll end up in > the same rut as Debian. :-) I agree here 100%. This should be discussed further (risk Vs. benefit). Thanks! Greg -- Greg M. Kurtzer http://runlevelzero.net/ http://caosity.org/ http://warewulf-cluster.org/ From rick at linuxmafia.com Tue Sep 30 21:37:34 2003 From: rick at linuxmafia.com (Rick Moen) Date: Tue, 30 Sep 2003 21:37:34 -0700 Subject: [cAos] cAos] RHEL Support and compatiability - why In-Reply-To: <20031001040928.GB5747@titan.runlevelzero.net> References: <1064959495.25805.60.camel@opus> <3F6E3C04.1030308@it.swin.edu.au> <4.3.2.7.2.20030929162342.0364f580@imap4.lbl.gov> <20030930045703.GB21853@titan.runlevelzero.net> <86smmeyy31.fsf@unicorn.wl0.org> <4.3.2.7.2.20030929162342.0364f580@imap4.lbl.gov> <20030930234650.GB28527@kainx.org> <20031001040928.GB5747@titan.runlevelzero.net> Message-ID: <20031001043734.GA20106@linuxmafia.com> Quoting Greg Kurtzer (greg at runlevelzero.net): > I realize that the code is GPL, but the name redhat is a trademark. I don't > know if one takes precendent over the other, but it seems like the trademark > should not be taken lightly. Because of the breadth of Red Hat, Inc.'s contributions, there are already dozens of standard packages festooned with the string "Red Hat" in just about _every_ Linux distribution. Consider sndconfig, for example. The startup screen says: Sound Configuration Utility 0.70 (C) 2000 Red Hat, Inc. The manpage includes: sndconfig sets up the necessary configuration files to use a sound card on a Red Hat system. -- Cheers, The cynics among us might say: "We laugh, Rick Moen monkeyboys -- Linux IS the mainstream UNIX now! rick at linuxmafia.com MuaHaHaHa!" but that would be rude. -- Jim Dennis