Discuss

discuss@lists.centos.org

5 participants
34752 discussions

Re: [CentOS] CentOS and SL, together?
by Bryan J. Smith <b.j.smith＠ieee.org> 29 May '05

29 May '05

From: Johnny Hughes <mailing-lists(a)hughesjr.com> > Righto ... no JRE redistributes in CentOS ... that is not allowed :) > They also have mp3 stuff ... also not allowed :) If you want an example of what I consider "ignorance," that's it right there. Someone who asks, "why doesn't Red Hat include X," won't get grief. But people who say, "I use Y because it includes X and Red Hat does not," sorry, that's starting to play into that game. I have a rule at my clients: "No Linux CDs are allowed into the building until they are approved -- especially _not_ Knoppix." Why? Because I have to verify they are "pure" Linux and not an indemnification nightmare. > For CentOS-3.x you can get GFS (and RH ClusterSuite) here: > http://bender.it.swin.edu.au/centos-3/ > (there is no GFS/RHCS for RHEL-4 (or CentOS-4) yet) BTW, I haven't looked yet, is Netscape Directory Server available for CentOS? You can get it from the RHN (as well as the "technology preview"), just wondering if it's available for CentOS from another source. > OpenAFS: I'll have to look at the license that it is released under ... > that might be able to be in Extras ... someone want to maintain it :) IBM's IPL, yet another GPL-incompatible license along with IBM's CPL. People claim I have an "agenda" against IBM. No, but I _do_ have an "agenda" to get people to realize that they should hold IBM up against the same standard (and "agenda") they have against Sun. http://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses Now the last time I checked, Red Hat did include the OpenAFS client in the kernel -- at least GPL portions (the history of AFS is a little interest). The OpenAFS server is user-space, so there is not a licensing issue there. I typically just download and build the full IPL licensed client/server from OpenAFS, despite the licensing issues. If it's for private use, you can do this per the GPL -- you just can't redistribute anything that isn't GPL compatible linked against GPL (which is what I make my clients aware of). BTW. If people think "ignorance" is a "harsh word," understand when you are "ignorant" as a consulting engineer with a Professional Engineering license, the term becomes "Professsional Negligence" with the same, _liability_ as an MD. ;-> So I tend to avoid "ignorance" and care about little details. ;-> > Correct ... Pine is non-free license, won't be built for CentOS-4 :) But remember, it's Red Hat's fault. ;-> -- Bryan J. Smith mailto:b.j.smith@ieee.org

3 2

Re: [CentOS] Re: Demonizing generic Linux issues as Fedora Core-only issues -- WAS: Hi, Bryan
by Bryan J. Smith 29 May '05

29 May '05

Even I've left this thread. I guess we're all waiting for Lee to turn Blue. ;-> Or is it Red (Hat)? ;-> Okay Lee, we all agree, Red Hat makes stupid decisions, adopts buggy software - especially the kernel and Red Hat is to blame for the decisions in the kernel, and also stupidly backports fixes instead of adopting newer versions with the fixes. And there is absolutely no need for Red Hat to do so. Happy? -----Original Message----- From: Les Mikesell Date: 05-5-28 0:55 To: CentOS mailing list Subj: Re: [CentOS] Re: Demonizing generic Linux issues as Fedora Core-only issues -- WAS: Hi, Bryan On Fri, 2005-05-27 at 19:13, Lamar Owen wrote: > On Thursday 26 May 2005 14:17, Les Mikesell wrote: > > If you believe that, you have to believe that Red Hat's programmers > > are always better than the original upstream program author. > > For the most part, the Red Hat crew is the best in the business. Or have you > never heard of Jakub Jelinek, Alan Cox, Rick van Riel, and many many other of > the top upstream developers that are employed in some capacity by Red Hat? I think we've beaten these topics to death, but since it is kind of fun if you don't take it too seriously: Which of these guys knows how to make perl do character set conversions correctly better than the perl team? > > I'll > > agree that they are good and on the average do a good job, but > > that stops far short of saying that they know better than the > > perl (etc.) teams what version you should be running. > > The perl team has no business telling me what version I should be running, > either. What version I run is dependent upon many things; one of which is > 'what version does my vendor support?' Sigh... at this point it is "how many versions does the vendor support"? And the issue is that the perl version (among many other things) that does a certain operation correctly is only included with a kernel version that has features missing and broken. > > So, you want a working application, take an incomplete kernel. I > > understand that's the way things are. I don't understand why > > you like it. > > Long term version stability. There has to be a freeze point; Red Hat has > chosen the very documented 2-2-2 6-6-6 scheme, and sticks to its schedule, > for the most part. Or, to put it very bluntly, just exactly which of the > over a thousand packages are worth waiting on? And who decides which package > holds up progress? CIPE, the example used here, is relatively insecure to > begin with and interoperates with nobody. I don't see how you can call setting up a WAN with many CIPE nodes, then finding it unavailable in the next release 'long term stability'. > Better to use IPsec (which > virtually everybody supports to a degree) than a relatively nonstandard VPN > like CIPE (I'd go as far as to say that most of the other VPN solutions are > in the same boat; what's needed on the server side is typically > Microsoft-compatible PPP over L2TP over IPsec, which is so easy to set up on > the Windows client side it isn't even funny). That's why for-purpose > firewall/VPN appliance Linux dists (SmoothWall and Astaro, for instance) are > not using anything but IPsec. I have a SmoothWall box myself, and it Just > Works. Can you run it through NAT routers? I have locations where the end point is already NATed by equipment I don't control. CIPE doesn't mind and the blowfish encryption is pretty CPU-friendly. And again, it might be "long-term stability" if this had already been a choice in several prior versions so you didn't have to upgrade OS revs on machines in several countries on the same day to keep your machines connected. > > Is there a reason that a Centos or third-party repository > > could not be arranged such that an explicit upgrade could be > > requested to a current version which would then be tracked like > > your kernel-xxx-version is when you select smp/hugemem/unsupported? >

4 5

Re: Demonizing generic Linux issues as Fedora Core-only issues -- WAS: Hi, Bryan
by Bryan J. Smith <b.j.smith＠ieee.org> 29 May '05

29 May '05

From: Les Mikesell <lesmikesell(a)gmail.com> > No, I am looking for a solution that provides what a typical user needs, > not what a particular vendor feels like supporting this week. I didn't > really want this to be about motives for vendor's business decisions but > I think Johnny Hughes nailed it in saying the push for 2.6 was because > SLES 9 had it. Their decision wasn't stupid, but my point is that it > wasn't the best thing for some number of their old users. At what point does Red Hat hold off on adopting Linux 2.6? Or GCC 3? Or GLibC 2.0? As I said, there is a chicken-egg issue between "waiting for something to be well-tested with many packages" and "adopting something so it is well-tested with many packages." This existed back in the Red Hat Linux timeframe, and it still exists today. That's why RHEL is essentially based on the ".1" or ".2" release. Then it is kept fairly _static_ over its lifetime for SLA reasons. > However, I also support a number of general-purpose servers and some > desktops where a larger mix of applications need to be integrated > along with a variety of oddball hardware that has, over the years > been connected and supported one way or another. In this scenario > you are very likely to want to upgrade a single application and > find that you can't do it RedHat's-way(tm) because the bundled > upgrade will break something else that you need to keep running. And other "packages" distros don't have this problem? If you find Fedora Core + repositories doesn't solve what you need either, I think someone else pointed out that a "ports" distro, like Gentoo, might be more of what you are looking for. Especially if you're rolling out lots of "bleeding edge" distros. BTW, just so everyone knows, I support Debian, Fedora, Gentoo, NLD, RHEL, SuSE and SLES as a paid consultant. And I've been a maintainer in several projects so I'm not just a "Red Hat-only lacky" as many people believe. In fact, I am a software engineer at many clients (I just get stuck with the IT / configuration management because I seem to know how to do this with Linux better than the others around me). So I'm very partial to using "ports" distributions like Gentoo and BSD. ;-> > Explaining the reason the vendor made the decision that doesn't > work in my case isn't particularly helpful. Understanding why either allows you to: A) See what you can do to get the vendor to change, _or_ B) Better recognizing what you can do to accommodate the vendor I said it before and I'll say it again, one of the reasons I have very much sought after -- almost always by personal reference -- it because I can come in, look at someone's business/engineering model, and then architect a solution that maximizes the application of a solution while mitigating risk to any product changes. Unless you understand how and why the vendor is doing something, you can't either do "A" or "B" and customize the solution one way or another. The last thing my clients want to hear from me is "damn, Microsoft/RedHat/etc... broke your network." Furthermore, when architecting a solution, I can also give the client options and say, "if you go with RHEL, you're going to run into the re-occuring problem of X, Y and Z." In most cases, it helps me eliminate Microsoft from client consideration early on, but in some cases, I actually end up rolling out a completely _non-Red Hat_ solution. > You might as well try to explain to me why upgrading or installing > certain MS products require moving the whole enterprise to Active > Directory first. That's different, although the concepts are similiar. There is no vendor that can provide a solution that doesn't need accommodate at some point in a solution. Fortuntely, we don't have the "on-a-whim" changes in the RHEL space like we do in Windows -- _primarily_ _because_ Red Hat _never_ mixes in "new features" mid-release. But configuration management is _always_ an issue. You are _never_ going to eliminate much of it even in the Linux space. It is a necessary evil that you must do -- and that will vary on the focus of the distro. In fact, not doing configuration management in Linux roll-outs and, essentially, _falsifying_ the savings on Linux with it, is the absolute #1 reason why Linux projects fail. Having a background in defense, I liken this to NASA's COTS (commercial off-the-shelf) adoption in the '90s. After Sojouner (Mars Pathfinder) proved that GNU/VxWorks was a viable platform that cost 1/10th of custom software/hardware development, NASA's nexgen probes started adopting the same platforms/software as Pathfinder. The problem on these other projects is that the 90% savings was no longer applied to just software/hardware, but _all_ aspects of the project's budget. So unlike Sojouner, the QA (quality assurance) budget was cut. So when Mars Polar Lander entered the orbit assuming the units in a register were miles when they were, in fact, kilometers -- because there was not the QA between two engineering teams at two different companies several states away from each other -- I was not surprised one bit. Configuration management is quality assurance. You must do it and there will _never_ be a vendor, distro or other "off-the-shelf" solution that will allow you to avoid doing it. Because a solution is _never_ available that is customized for you and regression tested to work without issue. That's just reality. > I'm not really interested in playing a 'vendor lock-in' game. Okay, this is the typically spiral I see people do. They start talking about "vendor lock-in" with regards to Red Hat, applying their experiences with Microsoft. Sorry, this is _exactly_ the "demonization" I'm talking about. You are comparing the world's greatest, "we lack even proprietary standards" company to Red Hat, the absolute #1 pro-GPL commercial company. So there's _no_ sense in my responding further. -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

Re: CentOS and SL, together? -- GPL, LGPL, kernel and user ...
by Bryan J. Smith <b.j.smith＠ieee.org> 29 May '05

29 May '05

From: Johnny Hughes <mailing-lists(a)hughesjr.com> > Nope ... I can't build that with GNU gcc and against GNU glibc and > release it ... sorry, no OpenAFS :( ??? Actually, you _can_. You just can't link it into the GPL kernel program. [ I'm not posting this to cross you. But someone correct me if I'm wrong. ] There is nothing in the GPL that prevents a GPL compiler from producing non-GPL code. And LGPL can be statically linked against non-GPL compatible code. So that means the OpenAFS _server_, which is user-space, can be built with GPL GCC and dynamically linked against LGPL GLibC. But the OpenAFS _client_, which is kernel-space, cannot be statically linked into the GPL kernel program. [ I believe there is an OpenAFS client that is GPL, missing various IBM code. ] -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

Re: [CentOS] Re: Demonizing generic Linux issues as Fedora Core-only issues -- WAS: Hi, Bryan
by Bryan J. Smith <b.j.smith＠ieee.org> 29 May '05

29 May '05

From: Collins Richey <crichey(a)gmail.com> > It's a little more than that. I find few people who consider RedHat to > be a Demon Evil or that they can't do anything right, but I can > understand the concern about some of their decisions which have made > life difficult for (granted) a few, and it's not really helpful to > demonize those who complain, as Bryan has done. In essence, RedHat is > a business entity, and they make their decisions for business reasons. No offense, but I tire of being the "focal point of example" when all I'm doing is explaining why Red Hat has done something. Especially when one thing that severely dominates the landscape are statements of "Fedora Core / Red Hat-only bugs" which are simply total fabrications. Why am I blamed for pointing out that they are not? Oh, that's right, it's not popular to explain something as not a Red Hat-instigated issue. I seem to remember that same issue in the Windows world as well, where people seem to want to assign blame to Microsoft for everything too. The problem is that when everyone just instantly blames Red Hat for everything, just like Microsoft, it drowns out all those who do have _legitimate_ and _technically_ "well thought out" issues that _could_ be of good consideration for Red Hat. It's hard to make these issues known among a screaming bunch of "bitchers." And that's what it is. Especially when people do not stop to recognize the root causes of the issue. It's not "picking a side" -- it's about stopping and understanding why. Because only when you understand why can you either A) see it changed and, if that is not a solution, B) accommodate it as best as you can. > True enough. My biggest problem, philosophically at least with RedHat, > is the now unified release: what's good for server users is what > Desktop users get. This goes back to the whole eWeek mis-quote of Michael Tiemann where the whole world said Red Hat was "getting out of the desktop market." In reality, I totally agree that it's really not of any interest to Red Hat to keep trying to _sell_ a _product_ that is geared towards all the endless uses of a consumer/custom desktop. It's _cheaper_ and more _effective_ for Red Hat to put people on developing and giving away a distro like Fedora Core. It was a basic admission that Red Hat Linux as a "product" was attempting to please way too many people, and was failing to do so. If you don't like what you see in RHEL/CentOS as standard, your best bet is to get involved with Fedora Core, and attempt to see things included and tested in it first. Just a Bugzilla request, sometimes it's that simple to get what you want -- as long as you're willing to wait out Red Hat's testing cycle. That's the problem, people want it now, and that just ain't gonna happen. ;-> > I'm still looking for the binary distro that has a really stable base but > offers functionality upgrades as they come along. Balance but not > bleeding edge is the name of the game. You're going to be waiting forever. Even if you can somehow have the absolutely most stable package versions from all the various projects, there is no guarantee they will work together well. Only integration testing of all packages as a whole unit do that -- and it's not something that you can do without time and testing. Which is where 2-2-2, 6-6-6 come in better than anything else. > Yes, I know about Gentoo. I've run it almost since inception, and it's > ideal in many respects. Gentoo is a "ports" distro which has _many_advantages_. Unfortunately, maintaining "configuration management" on a ports distro is a bit more involved. I.e., you have basically moved 100% of regression testing onto yourself. ;-> > I've enjoyed this discussion and learned a lot about RedHat that I > didn't know. I thank you for your rational comments. Unlike Bryan, I > think you realize that not everyone who disagrees with RedHat on a > given topic is an ignoramus. Thank you for demonizing me so. The only time I said someone was "ignorant" is when they absolutely refused to stop and understand why Red Hat develops RHEL the way they do, and want to call things "Fedora Core / RHEL-only bugs." In other words, blindly assign blame to Red Hat all-the-time, for everything. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

CentOS-announce Digest, Vol 3, Issue 17
by centos-announce-request＠centos.org 28 May '05

28 May '05

Send CentOS-announce mailing list submissions to centos-announce(a)centos.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request(a)centos.org You can reach the person managing the list at centos-announce-owner(a)centos.org When replying, please edit your Subject line so it is more specific than "Re: Contents of CentOS-announce digest..." Today's Topics: 1. CESA-2004:650 CentOS 3 i386 libxml - security update (Tru Huynh) 2. CESA-2004:650 CentOS 3 x86_64 libxml - security update (Tru Huynh) 3. CESA-2004:638 CentOS 3 i386 gd - security update (Tru Huynh) 4. CESA-2004:638 CentOS 3 x86_64 gd - security update (Tru Huynh) ---------------------------------------------------------------------- Message: 1 Date: Fri, 27 May 2005 15:28:28 +0200 From: Tru Huynh <tru(a)centos.org> Subject: [CentOS-announce] CESA-2004:650 CentOS 3 i386 libxml - security update To: centos-announce(a)centos.org Message-ID: <20050527132828.GA11260(a)sillage.bis.pasteur.fr> Content-Type: text/plain; charset="us-ascii" CentOS Errata and Security Advisory 2005:650 libxml security update for CentOS 3 i386: https://rhn.redhat.com/errata/RHSA-2004-650.html The following updated file has been uploaded and is currently syncing to the mirrors: i386: updates/i386/RPMS/libxml-1.8.17-9.2.i386.rpm updates/i386/RPMS/libxml-devel-1.8.17-9.2.i386.rpm source: updates/SRPMS/libxml-1.8.17-9.2.src.rpm You may update your CentOS-3 i386 installations by running the command: yum update libxml\* Tru -- Tru Huynh (CentOS-3 i386/x86_64 Package Maintenance) http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xBEFA581B

1 0

Re: Re: [CentOS] Re: centos] Kickstart from FTP or USB
by Vladan Nikolic 28 May '05

28 May '05

>Bryan J. Smith wrote: > >>Yes. DHCP is the successor to BOOTP that offers a superset of its >>functionality. But in the original BOOTP functionality, you would pass >>the filename the BOOTP client would retrieve from a TFTP server so it >>could boot. The file was then booted. >> >>This is how we have been installing workstations/servers in the UNIX >>world for 2+ _decades_ -- BOOTP+TFTP (plus, typically, an NFS mount). >>The PC only adopted it in more recent years. >> >>E.g., Microsoft Remote Installation Services (RIS) sets up the same >>thing (although uses a SMB mount after the BOOTP+TFTP). >> >> > >Thanks. > >So I guess I should take this as:- > > No, it is not possible just to put the ks file onto an FTP server along >with the install file. I have to have a proper DHCP server and TFTP. Nope, it's not true. I have ftp server, and in root directory I have all ks files for my servers. It is the same ftp server that servers as repository for ks instalations (every distribution has it's own subfolder). All i have to do is boot server from instalation CD, on boot prompt enter: linux ..ks=ftp://192.168.10.10/ks.cfg .... and in ks.cfg there is something like (i type this from head, search for exact line): url ftp://192.168.10.10/distrib1 and that's it

3 2

Kickstart from FTP or USB
by Lee W 28 May '05

28 May '05

Hey Everyone, I was wondering if anyone has managed to do a network install where the kickstart file is located either on an FTP site (which is also where the packages are stored) or on a USB flash drive. I've tried starting the installer with "linux ks=/dev/sda/ks.cfg" or "linux ks=/dev/sda1/ks.cfg" or "linux ks=ftp://what.ever.Ip.address/pub/ks.cfg" but when the installer starts I just gen error (something) like "null: bad address. I've checked the RH docs and it seems that at the very least the USB method should work. Thanks in advance Regards Lee

5 6

rpm problem after recent yum update
by Ping-Wu Zhang 28 May '05

28 May '05

After a yum update (yesterday), I am now unable to install any rpm package. An example of the error message is duplicated below: %pre(VMwareWorkstation-5.0.0-13124.i386) scriptlet failed, exit status 255 error: install: %pre scriptlet failed (2), skipping VMwareWorkstation-5.0.0-13124 Could anyone help? Thanks in advance.

3 6

XFree86-devel package error
by John Quaglieri 28 May '05

28 May '05

I'm not sure if this has been brought up before, but there is error with the XFree86-devel package on CentOS3. Both gccmakedep and xft-config are broken symlinks to archexec in the folder /usr/X11R6/bin. Is there another RPM that provides archexec? This is not a problem on CentOS4. It does look like RHEL suffers from the same problem. -- Regards, John Quaglieri InterServer, Inc 201-643-0135x101

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss