From bogus@does.not.exist.com Mon Aug 31 20:06:37 2009 From: bogus@does.not.exist.com () Date: Tue, 01 Sep 2009 03:06:37 -0000 Subject: No subject Message-ID: for stability. -geoff From bogus@does.not.exist.com Mon Aug 31 20:06:37 2009 From: bogus@does.not.exist.com () Date: Tue, 01 Sep 2009 03:06:37 -0000 Subject: No subject Message-ID: that we wont even be able to legally use the name of ??? Lance -- uklinux.net - The ISP of choice for the discerning Linux user. From bogus@does.not.exist.com Mon Aug 31 20:06:37 2009 From: bogus@does.not.exist.com () Date: Tue, 01 Sep 2009 03:06:37 -0000 Subject: No subject Message-ID: compatible with, so long as they're all the same. Being comparable to the Oracle boxes would be good, though, as would package-level compatibility with a major Linux distro. > 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? Obviously, that space is now up for grabs. There's a chance SuSE can swoop in and steal it, particularly thanks to IBM's commercial support for their distribution. But there's a decent amount of inertia behind RH in terms of installed systems, which is what makes Vermillion such a viable platform for enterprise customers who are currently RedHat users. > 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. That's a matter of policy. If both trees are intended to follow in each other's footsteps over time (much like Debian stable/unstable), transition packages from one to the other as they prove themselves. If both trees have different goals, that strategy might not work. And most importantly, if you intend to follow different variants of the RH distribution (like traditional RHL vs. RHAS), the choice is obvious. Vermillion currently provides a platform geared more toward the enterprise. It got started back before RHAS/RHEL even existed. It provides (IMHO) a nice alternative to traditional RHL because I'm very careful about which RHL "releases" I base it on. For example, the current Vermillion is based on 7.3. > 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. 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. On Tuesday, 30 September 2003, at 18:04:55 (-0400), seth vidal wrote: > I disagree. - RHL had a 6 month release cycle. Well, yes and no. Technically speaking, they did do a release about every 6 months. But anyone who has worked with RH for any appreciable length of time knows that the *.0 releases are actually betas. Now getting a marketing drone to understand this can be next to impossible, as I and my fellow VA software engineers discovered when we spent months trying to tell Marketing that 7.0.1 was going to suck because 7.0 sucked. They finally figured it out, but by that time we already had screen-printed, pre-packaged CD's ready to stick in boxes. (Yes, I still have copies.) > 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. Very possibly not. Remember, each major RH release series tends to have particular glibc, libstdc++, gcc, etc. versions. On Tuesday, 30 September 2003, at 15:47:08 (-0700), Greg Kurtzer wrote: > 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. 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. :-) Regards, Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) ----------------------------------------------------------------------- "Don't go making all these promises you know you cannot keep. There's a time to play a king and a time to be the thief. 'Cause if you're making all these promises you know you cannot keep, you know time will be the thief, and your fallen king will end up alone." -- Savage Garden, "Promises" From bogus@does.not.exist.com Mon Aug 31 20:06:37 2009 From: bogus@does.not.exist.com () Date: Tue, 01 Sep 2009 03:06:37 -0000 Subject: No subject Message-ID: Adobe Acrobat Reader and plugin Macromedia Flash plugin Java (IBM and BEA) and plugin (IBM) Citrix ICA Client Real Player We can't redistribute that. -----Original Message----- From: Mike Jang [mailto:michael at ywow.org] Sent: Sunday, May 09, 2004 12:52 PM To: caos at caosity.org Subject: [cAos] Red Hat Desktop Folks, Is there any thought / discussion about a "rebuild" of the new Red Hat Desktop offering? The Red Hat "starter pack" price of $2500 (I think for a pack of 10 support subscriptions) seems high. Thanks, Mike _______________________________________________ cAos mailing list cAos at caosity.org http://www.caosity.org/mailman/listinfo/caos From tegner at renget.se Sun Aug 9 06:24:12 2009 From: tegner at renget.se (Jon Tegner) Date: Sun, 09 Aug 2009 15:24:12 +0200 Subject: [cAos] temperature sensors, caos nsa Message-ID: <4A7ECDFC.8040106@renget.se> Hi, I'm new to caos nsa, so please excuse me if these are stupid questions/remarks. I have seen that similar issues have been asked before: "Best way to add software not provided by caos" (Dec 2008). From that conversation it seemed the best way was to use src.rpms from Centos 5. In my particular case I need to monitor the temperature sensors on CPU and mainboard. On other systems I have used lm-sensors, but I couldn't find that package in the repositories, I'm just wondering if this functionality exists in some other package, or if I should use the Centos 5 src.rpms? Another point, I have a Swedish keyboard, and that option was not available during the installation. I understand if it is not possible to include keyboard layouts for all languages, but maybe it would be a good idea to add some information about how to set up the correct keyboard layout if it is not included? Anyway, thanks for a distribution which with my limited experience looks great! Regards, /jon From gmkurtzer at gmail.com Mon Aug 31 20:08:13 2009 From: gmkurtzer at gmail.com (Greg Kurtzer) Date: Mon, 31 Aug 2009 20:08:13 -0700 Subject: [Caos] Testing new list services Message-ID: <571f1a060908312008q458b32bei7d4e9be8f8b63296@mail.gmail.com> Hello Everyone. Sorry for the delay on getting the list back up. Please note the new email address to send to the list. Thanks everyone! Greg -- Greg Kurtzer http://www.infiscale.com/ http://www.perceus.org/ http://www.caoslinux.org/