CentOS is a really great product, and the package supporters do a bang up job, but the one deficiency I've found is the fact that one can never rely on being able to get updates at any particular time. Whether it's CentOS proper or the Dag additions, something is broke most every time I want to apply updates.
I know this is whin[ge]ing, and I certainly don't have a solution to offer.
If anyone can offer bucks and/or equipment to improved the software distribution process, your karma would get an enormous boost!!!
-- Collins Richey Debugging is twice as hard as writing the code ... If you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan
On Thu, 2005-11-24 at 10:42 -0700, Collins Richey wrote:
CentOS is a really great product, and the package supporters do a bang up job, but the one deficiency I've found is the fact that one can never rely on being able to get updates at any particular time. Whether it's CentOS proper or the Dag additions, something is broke most every time I want to apply updates.
I know this is whin[ge]ing, and I certainly don't have a solution to offer.
If anyone can offer bucks and/or equipment to improved the software distribution process, your karma would get an enormous boost!!!
It's called a local mirror
On Thu, 2005-11-24 at 12:00 -0600, Johnny Hughes wrote:
It's called a local mirror
I have to agree with Johnny. If you're maintaining any number of systems, take it upon yourself to maintain a local mirror and rsync. Tag updates in your YUM (or other) repository appropriately until you have tested them. Then retag them appropriately when you have found a release with packages that are all inter-working well.
No OS solves this completely. Configuration management isn't optional, although I would argue that Linux (especially less changing Enterprise Linux) is as ideal as it can get. If you want some help in this regard, Red Hat's tools with their subscriptions are very helpful.
But, again, it doesn't solve the 3rd party equation. That's what Fedora is trying to do, although most with differ on the results (and even I have to concede there is a lot of room left for improvement).
On 11/24/05, Bryan J. Smith thebs413@earthlink.net wrote:
On Thu, 2005-11-24 at 12:00 -0600, Johnny Hughes wrote:
It's called a local mirror
I have to agree with Johnny. If you're maintaining any number of systems, take it upon yourself to maintain a local mirror and rsync. Tag updates in your YUM (or other) repository appropriately until you have tested them. Then retag them appropriately when you have found a release with packages that are all inter-working well.
Comments for this and the preceding post:
1. Paying for Red Hat does not resolve the problem as I described it. The Red Hat service provides for big bucks very slow, low bandwith access to it's updates. It's like watching paint dry when I have to download updates at work. I'll stick with free but erratic delivery if those are the choices. YOU DO NOT GET WHAT YOU PAY FOR.
2. The local mirror and sync process is certainly an approach if you have the patience (or the right parameters? I have no experience) to keep retrying until you eventually get past the stuck point. Also, I don't have a lot of machines to maintain, and this is only an occasional pain. It's only a real pain when I let a machine (like my laptop) get very back level on maintenance.
3. I started my rant with praise, and I continue the praise. CentOS is one of (if not the) best enterprise Linux offerings. That being said, the software delivery (including Dag which is not a part of CentOS but which is relied on by a lot of folks) is not up to the reliability level that I have experienced elsewhere. For example, I ran Gentoo for years, and I seldom found this type of problem getting updates even though the volume of downloads (source) is much higher than for CentOS and Dag (binary). For example, I've been maintaining a Ubuntu system for several months alongside of CentOS. I very rarely encounter this type of problem with Ubuntu updates.
Please don't waste your breath saying I should go elsewhere. I will continue to use CentOS and to recommend it to my friends. It's a great product.
IMO, this is purely a mechanical problem. Whatever the methods, other FOSS providers manage to avoid this type of erratic delivery. I don't have a clue how. I have no experience setting up or maintaining a system of mirrors.
I'm on the fifth attempt this morning to get through about 200 packages, and I don't think the results would have been much different if I were trying to sync a local mirror. This isn't even the post-new-update-rush, for $DEITY sake.The first 3 attempts hung totally at retrieving a man update. The next attempt waded through about 80 more packages and then hung. The final attempt is trying many mirrors again and not getting there again.
I've changed my mirror settings a few times, but there does not appear to be an ideal solution. Thus my frustration.
-- Collins Richey Debugging is twice as hard as writing the code ... If you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan
Collins Richey wrote:
- The local mirror and sync process is certainly an approach if you
have the patience (or the right parameters? I have no experience) to keep retrying until you eventually get past the stuck point. Also, I don't have a lot of machines to maintain, and this is only an occasional pain. It's only a real pain when I let a machine (like my laptop) get very back level on maintenance
I also don't have very many machines to maintain but I do tend to fiddle and muck around a lot so having a local mirror, stops me from killing the main servers everytime I do a reinstall. In my case there is often 4-5 centos machines running in VMWare whilst I test various stuff.
It only took me about 1/2 an hour to figure out how to rsync with a local mirror and I have never used rsync before. I have copied the command I use to only sync Centos 4, but it may give you a start, I'm guessing some of the more experienced people could come up with a more optimised command line, but this seems to work for me (about 4.5Gb in total):-
rsync -azH -vv --exclude */*/ia64/ --exclude */*/ppc/ --exclude */*/s390/ --exclude */*/s390x/ --exclude */*/alpha/ --exclude */*/x86_64/ --exclude *.iso --exclude isos/ --exclude /2/ --exclude /2.*/ --exclude /3.*/ --exclude /4.0/ --exclude /4.1/ --exclude */addons/ --exclude */contrib/ --exclude */centosplus/ --exclude */extras/ --delete rsync.sunsite.org.uk::sites/msync.centos.org/CentOS/ /mirrors/centos
Since running the local mirror I have had no problems with updating. Before I had lots due to my ISP running a transparent proxy, this problem I believe is documented on the YUM website.
Lee
On Thu, 2005-11-24 at 13:12 -0700, Collins Richey wrote:
Comments for this and the preceding post:
- Paying for Red Hat does not resolve the problem as I described it.
The Red Hat service provides for big bucks very slow, low bandwith access to it's updates. It's like watching paint dry when I have to download updates at work. I'll stick with free but erratic delivery if those are the choices. YOU DO NOT GET WHAT YOU PAY FOR.
First off, I differ with you on the performance.
Secondly, you _will_ get packages that have been integrated tested together. I have no complaints with CentOS repositories in general, but Red Hat is the upstream provider, and they've typically done an excellent job for my systems.
- The local mirror and sync process is certainly an approach if you
have the patience (or the right parameters? I have no experience) to keep retrying until you eventually get past the stuck point. Also, I don't have a lot of machines to maintain, and this is only an occasional pain. It's only a real pain when I let a machine (like my laptop) get very back level on maintenance.
If you have just a couple systems, it's worth the local mirror. I maintain my own Fedora Core, Extras, Livna, CentOS and RHEL mirrors at both home and work. And I put forth nearly *0* manual effort in the process.
It's very nice to have the packages directly to use.
- I started my rant with praise, and I continue the praise. CentOS is
one of (if not the) best enterprise Linux offerings. That being said, the software delivery (including Dag which is not a part of CentOS but which is relied on by a lot of folks) is not up to the reliability level that I have experienced elsewhere. For example, I ran Gentoo
(How come I knew Gentoo was coming? ;-)
for years, and I seldom found this type of problem getting updates even though the volume of downloads (source) is much higher than for CentOS and Dag (binary).
Gentoo is a _ports_ based distribution system, _not_ a packages one. It's like comparing apples and oranges -- Gentoo and Fedora-based (or Debian-based for that matter) are _not_ comparable.
E.g., Gentoo does _not_ maintain some of the software on their site. They reference other sites. It's like buying from a reseller that has various warehouse around the country v. a reseller that drop-ships from other distributors.
If you like Gentoo's approach, you should stick with it. It has many, many advantages. It also throws some things on the end-integrator. I can't tell you which is better for your needs, but just know there are certain things to Gentoo that are not applicable to Fedora, CentOS or even Debian for that matter.
For example, I've been maintaining a Ubuntu system for several months alongside of CentOS. I very rarely encounter this type of problem with Ubuntu updates.
And Ubuntu (and like Gentoo in some places -- although Gentoo's "ports" approach avoids much of it), _illegally_ distributes some packages. Things that you won't find in Debian, Fedora, CentOS, etc... Things you might have to go to DAG or another repository.
You're really crossing a lot of things that CentOS can't address for both legal and design considerations. You can wish and hope and that's all it will ever be.
Please don't waste your breath saying I should go elsewhere. I will continue to use CentOS and to recommend it to my friends. It's a great product.
Then _understand_ some of the limitations of the distribution system with those advantages.
IMO, this is purely a mechanical problem. Whatever the methods, other FOSS providers manage to avoid this type of erratic delivery. I don't have a clue how. I have no experience setting up or maintaining a system of mirrors.
Which is why you are drawing the conclusions you are. As I said before, you're comparing things that work very, very differently -- as well as some of the legal issues CentOS wishes to avoid.
I'm on the fifth attempt this morning to get through about 200 packages, and I don't think the results would have been much different if I were trying to sync a local mirror. This isn't even the post-new-update-rush, for $DEITY sake.The first 3 attempts hung totally at retrieving a man update. The next attempt waded through about 80 more packages and then hung. The final attempt is trying many mirrors again and not getting there again. I've changed my mirror settings a few times, but there does not appear to be an ideal solution. Thus my frustration.
I'm sorry you're frustrated. We all get frustrated at times.
But you're making comparisons that are _not_ just "purely mechanical problem[s]." Please _avoid_ doing that. It does _no_good_ to openly complain about something the project can do nothing about. ;->
-- Bryan
P.S. I too maintain some of the other distros you speak of. There are many differences involved. I'm not going to tell you what to do. I just ask you to remember that you may not be taking everything into consideration that might be involved -- distribution-wise, legal-wise, etc...
Collins Richey wrote:
- Paying for Red Hat does not resolve the problem as I described it.
The Red Hat service provides for big bucks very slow, low bandwith access to it's updates. It's like watching paint dry when I have to download updates at work. I'll stick with free but erratic delivery if those are the choices. YOU DO NOT GET WHAT YOU PAY FOR.
We haven't had any problems with it - we're in Australia and we usually get downloads from RHN going at the maximum speed of our internet connection.
- The local mirror and sync process is certainly an approach if you
have the patience
Maybe try yam (see dag's site)
On Thu, 2005-11-24 at 13:12 -0700, Collins Richey wrote:
On 11/24/05, Bryan J. Smith thebs413@earthlink.net wrote:
On Thu, 2005-11-24 at 12:00 -0600, Johnny Hughes wrote:
It's called a local mirror
I have to agree with Johnny. If you're maintaining any number of systems, take it upon yourself to maintain a local mirror and rsync. Tag updates in your YUM (or other) repository appropriately until you have tested them. Then retag them appropriately when you have found a release with packages that are all inter-working well.
Comments for this and the preceding post:
- Paying for Red Hat does not resolve the problem as I described it.
The Red Hat service provides for big bucks very slow, low bandwith access to it's updates. It's like watching paint dry when I have to download updates at work. I'll stick with free but erratic delivery if those are the choices. YOU DO NOT GET WHAT YOU PAY FOR.
- The local mirror and sync process is certainly an approach if you
have the patience (or the right parameters? I have no experience) to keep retrying until you eventually get past the stuck point. Also, I don't have a lot of machines to maintain, and this is only an occasional pain. It's only a real pain when I let a machine (like my laptop) get very back level on maintenance.
- I started my rant with praise, and I continue the praise. CentOS is
one of (if not the) best enterprise Linux offerings. That being said, the software delivery (including Dag which is not a part of CentOS but which is relied on by a lot of folks) is not up to the reliability level that I have experienced elsewhere. For example, I ran Gentoo for years, and I seldom found this type of problem getting updates even though the volume of downloads (source) is much higher than for CentOS and Dag (binary).
You would be very surprised. We are serving on the mirror.centos.org about 1 TiB of data per day now.
We rank very close to Mandriva and Ubuntu for total traffic on our domain.
For example, I've been maintaining a Ubuntu system for several months alongside of CentOS. I very rarely encounter this type of problem with Ubuntu updates.
OK, I never have problems with updates, but if you do, try a mirror that might be closer to you. My downloads usually happen at 400-800kb/sec and I never have time outs using the standard mirror.centos.org mirrors.
Yum has problems with transparent web proxies and alot of ISPs are starting to use them, maybe that is an issue for you.
There is a list of mirrors here: http://www.centos.org/modules/tinycontent/index.php?id=13
Modify you /etc/yum.repos.d/CentOS-Base.repo
Change the http://mirror.centos.org/centos/ to a link on one of the mirrors that is close to you ... add a second or third mirror for fail over to each repo.
Please don't waste your breath saying I should go elsewhere. I will continue to use CentOS and to recommend it to my friends. It's a great product.
IMO, this is purely a mechanical problem. Whatever the methods, other FOSS providers manage to avoid this type of erratic delivery. I don't have a clue how. I have no experience setting up or maintaining a system of mirrors.
I'm on the fifth attempt this morning to get through about 200 packages, and I don't think the results would have been much different if I were trying to sync a local mirror. This isn't even the post-new-update-rush, for $DEITY sake.The first 3 attempts hung totally at retrieving a man update. The next attempt waded through about 80 more packages and then hung. The final attempt is trying many mirrors again and not getting there again.
I've changed my mirror settings a few times, but there does not appear to be an ideal solution. Thus my frustration.
As I have said, I do not have any issues (except during the 4.2 upgrade) with getting updates.
On Thu, 2005-11-24 at 13:12 -0700, Collins Richey wrote:
On 11/24/05, Bryan J. Smith thebs413@earthlink.net wrote:
IMO, this is purely a mechanical problem. Whatever the methods, other FOSS providers manage to avoid this type of erratic delivery. I don't have a clue how. I have no experience setting up or maintaining a system of mirrors.
I'm on the fifth attempt this morning to get through about 200 packages, and I don't think the results would have been much different if I were trying to sync a local mirror. This isn't even the post-new-update-rush, for $DEITY sake.The first 3 attempts hung totally at retrieving a man update. The next attempt waded through about 80 more packages and then hung. The final attempt is trying many mirrors again and not getting there again.
I've changed my mirror settings a few times, but there does not appear to be an ideal solution. Thus my frustration.
---- FWIW - I set up a new system yesterday with CentOS 4.1 disks and of course then had to update...it was 192 packages. It took a while - no errors.
I then added dag's repository and was able to get what I wanted there.
Dag has told this list that his primary server - heanet is an Apache test site which probably accounts for some if not most of the errors that I have gotten with it reports errors from his repository such as 0 sized repomd. When I need to update things of a critical nature, I disable dag's repo and can update from CentOS no problem.
Yes, there have been times when it's taken a day or two to get everything updated, primarily because of issues with dag repository and it's frustrating but I guess I never saw the need to whine about it and suspect that others feel the same way.
As has been suggested by others, if you feel the need for reliability, you always have the option to create your own mirror and rsync the repositories that you use.
Craig
Thanks to all who responded. CentOS is a great distro, and it's worth the occasional struggle, but it woud be even better without the struggle.
-- Collins Richey Debugging is twice as hard as writing the code ... If you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan
On Thu, 2005-11-24 at 19:46 -0700, Collins Richey wrote:
Thanks to all who responded. CentOS is a great distro, and it's worth the occasional struggle, but it woud be even better without the struggle.
I'm still trying to figure out what you're trying to accomplish with such statements.
Then again, I should probably ask the same thing of myself with regards to responding to you. ;->
On 11/24/05, Bryan J. Smith thebs413@earthlink.net wrote:
On Thu, 2005-11-24 at 19:46 -0700, Collins Richey wrote:
Thanks to all who responded. CentOS is a great distro, and it's worth the occasional struggle, but it woud be even better without the struggle.
I'm still trying to figure out what you're trying to accomplish with such statements.
Then again, I should probably ask the same thing of myself with regards to responding to you. ;->
Simple frustration that [ the | one of the ] [ pick one] best distros does not have the best delivery mechanism. The fact that I have not experienced this type of frustration with other major distros seems to be of no consequence to you, and that's fine. I'm not interested in plugging Gentoo or Ubuntu; I'm merely asserting the fact that I almost never encounter this type of problem when fetching updates for these distros.
Some of the responses - maintain your own mirror or use a different mirror list - are excellent workarounds for my problem, and I will pursue them, but these recommendations ignore the fact that I never needed workarounds for ceratin other distros. If the problem doesn't exist, you don't need a workaround.
We've just about exhausted this thread.
-- Collins Richey Debugging is twice as hard as writing the code ... If you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan
On Thu, 2005-11-24 at 18:12 -0700, Craig White wrote:
On Thu, 2005-11-24 at 13:12 -0700, Collins Richey wrote:
On 11/24/05, Bryan J. Smith thebs413@earthlink.net wrote:
IMO, this is purely a mechanical problem. Whatever the methods, other FOSS providers manage to avoid this type of erratic delivery. I don't have a clue how. I have no experience setting up or maintaining a system of mirrors.
I'm on the fifth attempt this morning to get through about 200 packages, and I don't think the results would have been much different if I were trying to sync a local mirror. This isn't even the post-new-update-rush, for $DEITY sake.The first 3 attempts hung totally at retrieving a man update. The next attempt waded through about 80 more packages and then hung. The final attempt is trying many mirrors again and not getting there again.
I've changed my mirror settings a few times, but there does not appear to be an ideal solution. Thus my frustration.
FWIW - I set up a new system yesterday with CentOS 4.1 disks and of course then had to update...it was 192 packages. It took a while - no errors.
I then added dag's repository and was able to get what I wanted there.
Dag has told this list that his primary server - heanet is an Apache test site which probably accounts for some if not most of the errors that I have gotten with it reports errors from his repository such as 0 sized repomd. When I need to update things of a critical nature, I disable dag's repo and can update from CentOS no problem.
Yes, there have been times when it's taken a day or two to get everything updated, primarily because of issues with dag repository and it's frustrating but I guess I never saw the need to whine about it and suspect that others feel the same way.
As has been suggested by others, if you feel the need for reliability, you always have the option to create your own mirror and rsync the repositories that you use.
There are other Dag mirrors, besides the main one ... specifically here is the ones I like to use:
baseurl=http://dag.linux.iastate.edu/dag/redhat/el$releasever/en/$basearch/dag http://www.mirrorservice.org/sites/apt.sw.be/redhat/el$releasever/en/$basear... http://mirrors.ircam.fr/pub/dag/redhat/el$releasever/en/$basearch/dag/ http://apt.sw.be/redhat/el$releasever/en/$basearch/dag/
On 11/24/05, Johnny Hughes mailing-lists@hughesjr.com wrote:
There are other Dag mirrors, besides the main one ... specifically here is the ones I like to use:
baseurl=http://dag.linux.iastate.edu/dag/redhat/el$releasever/en/$basearch/dag http://www.mirrorservice.org/sites/apt.sw.be/redhat/el$releasever/en/$basear... http://mirrors.ircam.fr/pub/dag/redhat/el$releasever/en/$basearch/dag/ http://apt.sw.be/redhat/el$releasever/en/$basearch/dag/
Thanks again. I'll try them out. Actually, the errors I got earlier today (my laptop updates completed on the 6th try) all seemded to be CentOS rather than Dag packages. I haven't looked at my repos list in some time, especially on the laptop, so that could be a big part of the problem.
-- Collins Richey Debugging is twice as hard as writing the code ... If you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan
On Thu, 2005-11-24 at 10:42 -0700, Collins Richey wrote:
CentOS is a really great product, and the package supporters do a bang up job, but the one deficiency I've found is the fact that one can never rely on being able to get updates at any particular time. Whether it's CentOS proper or the Dag additions, something is broke most every time I want to apply updates. I know this is whin[ge]ing, and I certainly don't have a solution to offer.
I do. If you want CentOS "proper," pay Red Hat for RHEL. That's a solution. Although some might disagree with the value, I very much agree with the value. Both from the standpoint of what they give me from a configuration management standpoint, as well as the number of GPL projects their revenues fund.
Please don't take that the wrong way. I absolutely applaud the CentOS team for the continued and most excellent work, as well as the work done by DAG and others. We are honored by their sacrifices and hard work.
But if you find yourself having repeat issues, and it is really important to you, I have to suggest you consider paying Red Hat. I know some here might disagree, but I have to at least say it.
Of course, I will also point out that if you're wishing for 3rd party repositories to be perfectly aligned with CentOS, going RHEL isn't going to help you much more there either. So that's not quite a "full solution" for you.
If anyone can offer bucks and/or equipment to improved the software distribution process, your karma would get an enormous boost!!!
While I'm sure donations help, it's still "chump change" compared to what Red Hat can pour into its development, testing and other services. For the most part, SRPM rebuilds do come out fine in CentOS. But every now and then, it's not totally clean because there are assumptions or differences in the build system that only the RHEL developers know.
Hm, no problems with updates via normal 4.2 repo config here.
Kai
On Fri, 2005-11-25 at 16:31 +0100, Kai Schaetzl wrote:
Hm, no problems with updates via normal 4.2 repo config here.
Which is why I asked what someone has hoped to accomplish. There are few specifics that have been listed.
1) Most people, Kai and myself included, have had few issues -- other than the earliest 4.2 rebuild (CentOS) that I didn't have with RHEL 4U2.
2) Repository hell affects _most_ other package distros, including Debian. Ubuntu and other Debian-based distros get around them by including software that may not be legally redistributed.
3) Gentoo is a ports distro, and sacrifices fixed releases and configuration management for source-level compatibility. Which is better, I will not say, but for rolling out many systems, Gentoo adds additional configuration management burden for myself.
So in the end, you want to reduce many factors into a single "frustration" of "just fix it" -- when I've seen little of any suggestion.
Which is why you are correct, we've exhausted this thread. You've admitted you don't understand how several things work with regards to redistribution. So it doesn't surprise me that these comments keep coming from people who do not.
On 11/25/05, Bryan J. Smith thebs413@earthlink.net wrote:
On Fri, 2005-11-25 at 16:31 +0100, Kai Schaetzl wrote:
Hm, no problems with updates via normal 4.2 repo config here.
Which is why I asked what someone has hoped to accomplish. There are few specifics that have been listed.
- Most people, Kai and myself included, have had few issues -- other
than the earliest 4.2 rebuild (CentOS) that I didn't have with RHEL 4U2.
I'm happy for you.
- Repository hell affects _most_ other package distros, including
Debian. Ubuntu and other Debian-based distros get around them by including software that may not be legally redistributed.
I haven't experience repository hell, at least not in the single instance of retrieval hell I cited for CentOS yesterday, with Ubuntu. You've lost me when you say that redistribution of illegal software has anything to do with the situation I described. None of the software I retrieve with Ubuntu or CentOS is illegal for redistribution. It's merely the likelihood of occurrence of retrieval hell that I'm discussing.
- Gentoo is a ports distro, and sacrifices fixed releases and
configuration management for source-level compatibility. Which is better, I will not say, but for rolling out many systems, Gentoo adds additional configuration management burden for myself.
Must of us understand the differences between a ports based distro and a binary packages based distro full well, and this has been discussed ad nauseam on many lists and forums. Which approach s better is not the issue; that's a matter of personal preference. t's merely the likelihood of occurrence of retrieval hell that I'm discussing.
So in the end, you want to reduce many factors into a single "frustration" of "just fix it" -- when I've seen little of any suggestion.
Reductio ad absurdam. I started the thread by saying that I don't have a clue how to fix the problem. To restate the obvious. CentOS is a great distro, but from time to time (more frequently than with other distros) I encounter situations where several attempts to retrieve updates are required. I believe that the distro would be even better if such problems did not occur.
I don't have the data to know whether the nature of the problem is too few servers and mirrors, network congestion at the servers and mirrors, software problems of the servers and mirrors, geographic dispersal of the servers and mirrors, equipment failure, planned downtime for equipment that is not communicated to the users, or whatever. Immediately after new releases, I fully expect the CentOS servers and mirrors to be overloaded, and I wait until the overload clears before attempting updates, but I'm quite surprised to encounter this type of delay during supposedly "normal" times.
-- Collins Richey Debugging is twice as hard as writing the code ... If you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan
On Fri, 2005-11-25 at 13:10 -0700, Collins Richey wrote:
I haven't experience repository hell, at least not in the single instance of retrieval hell I cited for CentOS yesterday, with Ubuntu.
And what repositories are you using outside of Ubuntu's repositories? I assume you're just using Ubuntu's official repositories, because they include all sorts of things that CentOS does not.
You don't get repository hell from just the official project's repositories. You start experiencing repository hell when you add repositories.
Now I've come close to no repository hell with Fedora Core + Fedora Extras + Livna.ORG (the last redistributes "legally questionable" packages). But that's Fedora, it's really built around 3rd party repositories, but it still has its repository hell.
Debian users run into the same when they start tapping different repositories for multimedia, etc... Hence why most Debian users start looking at some of the Debian-based distros that just ignore legal issues.
You've lost me when you say that redistribution of illegal software has anything to do with the situation I described.
Exactly. Most end users don't want to know or care about it. Yet it's a primary reason why there is "repository hell." Because those projects and their repositories that want to only distribute what they legally can means you have to go to other repositories to find software.
Hence the resulting problem.
None of the software I retrieve with Ubuntu or CentOS is illegal for redistribution.
CentOS does _not_ redistribute software that cannot be legally redistributed. Debian is the same way, from the official repositories.
However, most of the popular, Debian-based distributions do redistribute software that are "legally questionable." They win praise for this, but they are a major liability nightmare.
It's merely the likelihood of occurrence of retrieval hell that I'm discussing.
In what regard? Other than the recent 4.2 snafus, what retrieve hell have you experienced with _just_ CentOS (_no_ DAG)? I haven't experienced too many performance issues with CentOS either.
Must of us understand the differences between a ports based distro and a binary packages based distro full well, and this has been discussed ad nauseam on many lists and forums. Which approach s better is not the issue; that's a matter of personal preference. t's merely the likelihood of occurrence of retrieval hell that I'm discussing.
But it affects many things, such as repository hell, which you run into when you start tapping things like DAG in addition to CentOS. Things you don't have to do with Gentoo or Ubuntu, because of their difference in approach, design, legal considerations, etc...
Major reasons why I have to be _very_careful_ when I let Gentoo or Ubuntu in the door of a place of business for indemification reasons, but not CentOS, Fedora Core+Extras (although I do _not_ tap Livna.ORG in that case), etc...
Reductio ad absurdam. I started the thread by saying that I don't have a clue how to fix the problem. To restate the obvious. CentOS is a great distro, but from time to time (more frequently than with other distros) I encounter situations where several attempts to retrieve updates are required. I believe that the distro would be even better if such problems did not occur. I don't have the data to know whether the nature of the problem is too few servers and mirrors, network congestion at the servers and mirrors, software problems of the servers and mirrors, geographic dispersal of the servers and mirrors, equipment failure, planned downtime for equipment that is not communicated to the users, or whatever.
So why post this if you don't know how to help?
Immediately after new releases, I fully expect the CentOS servers and mirrors to be overloaded, and I wait until the overload clears before attempting updates, but I'm quite surprised to encounter this type of delay during supposedly "normal" times.
I don't know what to tell you, I haven't.
The reality is that CentOS is pretty popular, and may not have the same support structure of some other projects. I don't know what to tell you other than I've had _no_ issues with RHN -- even right after release.
All I know is that my RHEL3U6 and RHEL4U2 downloads virtually the day after release were coming down at 300KBps (kilo_bytes_ per second) on a business class DSL, and saturating a full T-1 at another location.
CentOS has been fairly good in speed of updates as well. I'm sorry you haven't experienced this -- but you're mixing and matching so many different things and offering no _solid_ insight that I really don't know what you hope to accomplish?
Other than dropping another distro's name, which is all you're doing in the end.
On 11/25/05, Bryan J. Smith thebs413@earthlink.net wrote:
[ very long but not relevant rant about legal/not-legal software snipped ]
In what regard? Other than the recent 4.2 snafus, what retrieve hell have you experienced with _just_ CentOS (_no_ DAG)? I haven't experienced too many performance issues with CentOS either.
Read back through the posts again. I very clearly stated that I was having trouble retrieving CentOS, not Dag packages.
[ more scarcely relevant stuff about repository hell snipped ]
I repeat - no repository hell, none, zip, nada.
I am not experiencing problems with repository interrelationships just pure falure at certain (not easily predictable or repeatable) points retrieving certain packages (one was a man update) from CentOS resulting in abort of 'yum update' and/or total hang of yum (cancel, clear lock and retry). The total process required 6 restarts over a period of several hours, and finally the updates completed. I can't repeat this process because the system in question is now up to date. During this time I received no indication of inability to communicate with other external sites on my other systems that are on the same cable router.
So why post this if you don't know how to help?
Knowledge that a problem exists precedes any attempts to fix it.
I'm quite surprised to encounter this type of delay during supposedly "normal" times.
I don't know what to tell you, I haven't.
The reality is that CentOS is pretty popular, and may not have the same support structure of some other projects.
That's about the most relevant part of this entire diatribe. You haven't experienced the problem, but I did. If CentOS does not have the same structure as some other projects, then what can we do to help improve the structure? If we can't report a problem without a lengthy lecture on the theory of package selection by several different distros which has absolutely no bearing on the ability to retrieve CentOS packages, I suppose we should just ignore the problem.
What I experienced might well be a one-off scenario, but I can't know that without reporting the problem and inquiring if others are experiencing similar problems. I did get a few reports to indicate that no one else appears to be experiencing this problem, and I am thankful for the concrete suggestions for circumventing the problem.
-- Collins Richey Debugging is twice as hard as writing the code ... If you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan
On Fri, 2005-11-25 at 15:42 -0700, Collins Richey wrote:
I am not experiencing problems with repository interrelationships just pure falure at certain (not easily predictable or repeatable) points retrieving certain packages During this time I received no indication of inability to communicate with other external sites on my other systems that are on the same cable router. What I experienced might well be a one-off scenario, but I can't know that without reporting the problem and inquiring if others are experiencing similar problems. I did get a few reports to indicate that no one else appears to be experiencing this problem, and I am thankful for the concrete suggestions for circumventing the problem.
I've seen the same thing since I first started using Centos (just after 4.0 was released). After "yum update" fails, I just hit the up arrow and try again. This has never been enough of a nuisance to complain about it, but since Collins has brought it up, I can confirm that the problem does exist.
Is there any way to have yum keep a verbose debug log that we could use to pinpoint the cause?
-David
Bryan J. Smith wrote:
On Fri, 2005-11-25 at 13:10 -0700, Collins Richey wrote:
I haven't experience repository hell, at least not in the single instance of retrieval hell I cited for CentOS yesterday, with Ubuntu.
And what repositories are you using outside of Ubuntu's repositories? I assume you're just using Ubuntu's official repositories, because they include all sorts of things that CentOS does not.
You don't get repository hell from just the official project's repositories. You start experiencing repository hell when you add repositories.
<much drivel snipped>
Bryan,
I think what Collins was attempting and, in my book did so very well after the 2nd round of responses indicates that the whole problem is of a mechanical nature, just as he stated. You can't obtain *anything* if the connection is not there, whether it be legal, illegal, a port, a binary, a source or anything else. The circuit lets him down. That was pretty obvious. He also stated in his post that he did not have a solution, but wondered if adding equipment would help. I don't know how in the world these simple topics get so convoluted and involved when a simple statement and observation are made. Others may or may not have connectivity problems such as he. I have seen my share of connectivity problems myself, but if it does not work this time, I wait and try again later. There is *nothing* in the whole CentOS distribution that I *have* to have immediately. Maybe nice, but the world is not going to stop if I don't get it.
Collins, I hope I didn't misquote your initial post, but it was pretty simple for me to see it was a connectivity issue, and not at all related to repositories, ports, and sources.
'nuff said......
On 11/25/05, Sam Drinkard sam@wa4phy.net wrote:
Well spoken, Sam, You understood exactly what I was saying.
-- Collins Richey Debugging is twice as hard as writing the code ... If you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan
On Fri, 2005-11-25 at 15:49 -0700, Collins Richey wrote:
On 11/25/05, Sam Drinkard sam@wa4phy.net wrote:
Well spoken, Sam, You understood exactly what I was saying.
-- Collins Richey Debugging is twice as hard as writing the code ... If you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan _______________________________________________
Collins, where are you physically located (what country) so I can see if we can fix you on a stable mirror.
The problem that I think you are having is that mirror.centos.org is a rrdns and I think you are having problems connecting to one (or more) of the several (currently 9) machines.
If we can pick a couple fast, close, local mirrors and setup a fail-over or two for you, I think it will clear up all your problems.
On 11/25/05, Johnny Hughes mailing-lists@hughesjr.com wrote:
Collins, where are you physically located (what country) so I can see if we can fix you on a stable mirror.
The problem that I think you are having is that mirror.centos.org is a rrdns and I think you are having problems connecting to one (or more) of the several (currently 9) machines.
If we can pick a couple fast, close, local mirrors and setup a fail-over or two for you, I think it will clear up all your problems.
Thanks, Johnny, and not only for your on target response. You and the other folks at CentOS do a bang up job.
I'm in Denver, CO, USA.
Part of my problem, I suspect is that I haven't updated the repos specs since I brought the laptop up to 4.1 level. Until the update completed, I was probably also using a downlevel yum now that I think of it.
From what I saw, I agree with your assessment. After I repeated enough
times, I must have connected with a different mirror, but then hit the same or another mirror again later in the process.
I haven't really seen this problem on my desktop machine (same home site) other than when the download storm for 4.2 was in progress. Prior to this, the only trouble I had was with occasional hits on the Dag sites which certainly is no responsibility of yours.
-- Collins Richey Debugging is twice as hard as writing the code ... If you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan
On Fri, 2005-11-25 at 17:54 -0700, Collins Richey wrote:
Part of my problem, I suspect is that I haven't updated the repos specs since I brought the laptop up to 4.1 level. Until the update completed, I was probably also using a downlevel yum now that I think of it. ... I haven't really seen this problem on my desktop machine (same home site) other than when the download storm for 4.2 was in progress. Prior to this, the only trouble I had was with occasional hits on the Dag sites which certainly is no responsibility of yours.
I'm now scratching my head. Given you just recently stated ...
"Read back through the posts again. I very clearly stated that I was having trouble retrieving CentOS, not Dag packages."
So what's the problem that prompts you to bring up another distros in comparison?
On 11/25/05, Bryan J. Smith thebs413@earthlink.net wrote:
So what's the problem that prompts you to bring up another distros in comparison?
Very simple. No hangups in the update retrieval process. In the one case after 3-4 years experience, in the other case after 6 months experience. As I have attempted to make clear at ervery turn to put this thread back on track, this has absolutely nothing to do with the merits of or the package selection philosophy of any these distros. Nor is it to be interpreted as any sort of putdown for CentOS. Nor is it intended to be the basis for any Red Hat vs. CentOS wrangling. It is merely a description of a "mechanical" problem on the one hand and the absence of this type of "mechanical" problem on the other hand. The hope being, in the long run, that this type of information could be of benefit to CentOS in providing good delivery to all.
At least one respondent understood what I was trying to say from the getgo.
As Johnny noted in his most recent posts, this could be difficulty in reaching one or more of the servers in the normal rotation from my site Or it could be something in my yum or repos setup.
Also, Jim was kind enough to point out the yum plugin fastmirrors.
My thanks to all who understood what I was trying to accomplish. I will make the changes Johnny recommended, and I will investigate the yum plugin.
-- Collins Richey Debugging is twice as hard as writing the code ... If you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan
On Fri, 2005-11-25 at 20:03 -0700, Collins Richey wrote:
Very simple. No hangups in the update retrieval process. In the one case after 3-4 years experience, in the other case after 6 months experience.
I'd say you're doing pretty good then.
As I have attempted to make clear at ervery turn to put this thread back on track, this has absolutely nothing to do with the merits of or the package selection philosophy of any these distros.
Then why bring them up? You can't bring up another distro without looking at various things that affect how you get your software. Again, Gentoo often does _not_ host may of its ports, but has you retrieve them from other servers directly.
So far, you've stated: - No issues with CentOS until 4.2 - Various issues with DAG at different times
I don't see a "mechanical" problem here?
About the only thing I saw was the real probability that a mirror is not close to you, or you are defaulting to a mirror far away. Maybe the other distros have a closer mirror. In any case, based on _all_ of what you said, I don't see a problem.
Nor is it to be interpreted as any sort of putdown for CentOS. Nor is it intended to be the basis for any Red Hat vs. CentOS wrangling.
I just merely mentioned that I have received _excellent_ download support from the RHN -- especially when the RHEL3U6 and RHEL4U2 releases came out.
It is merely a description of a "mechanical" problem on the one hand and the absence of this type of "mechanical" problem on the other hand.
Other distros. I fail to see the relevance?
The hope being, in the long run, that this type of information could be of benefit to CentOS in providing good delivery to all.
What "detailed information" did you provide that could help? That's what I'm wondering about!
At least one respondent understood what I was trying to say from the getgo.
Since you have named so little specifics, none of us have much to go on. All we know is that you get your updates without issues from Gentoo and Ubuntu versus CentOS and/or DAG.
As Johnny noted in his most recent posts, this could be difficulty in reaching one or more of the servers in the normal rotation from my site Or it could be something in my yum or repos setup. Also, Jim was kind enough to point out the yum plugin fastmirrors.
And if you gave some _samples_ of some of your issues, I might _also_ give you some insight into why you're running into download issues.
Instead, this is _all_ I had to go on ...
"but the one deficiency I've found is the fact that one can never rely on being able to get updates at any particular time. Whether it's CentOS proper or the Dag additions, something is broke most every time I want to apply updates."
My thanks to all who understood what I was trying to accomplish. I will make the changes Johnny recommended, and I will investigate the yum plugin.
I'm glad you've found something to try.
_Anytime_ you want to cut'n paste some runs, I'll be more than happy to help you resolve them. Until then, meta-discussions and "shots in the dark" is all you'll get.
Bryan J. Smith wrote:
- Repository hell affects _most_ other package distros, including
Debian. Ubuntu and other Debian-based distros get around them by including software that may not be legally redistributed.
Just out of interest what do Debian, Ubuntu and others distribute that is illegal? And even if they do how does having illegal software help get around repository problems?
On Mon, 2005-11-28 at 11:49 +1100, Tim Edwards wrote:
Just out of interest what do Debian,
Debian does _not_. Debian actually has stricter guidelines than Red Hat on a few things marking them "NON-FREE", although they do adhere to the same guidelines on software that creators mark as "non-redistributable" overall.
You have to tap 3rd party Debian repositories, which then results in repository hell. But at least with the official Debian repositories, I'm getting redistributable software.
[ I.e., I professionally deploy Debian as well as Fedora/RHEL/CentOS ]
Ubuntu and others distribute that is illegal?
Many Debian-based distros include Java, Multimedia, ProDVD, etc...
Gentoo gets around some of these by not storing the software on-site, although I've found them guilty of redistributing licenses as well as source code from their repository they do not have the right to do.
And even if they do how does having illegal software help get around repository problems?
Because you only need to go to the _official_ repository. That avoids repository mixing and the resulting "repository hell."
Bryan J. Smith wrote:
Many Debian-based distros include Java, Multimedia, ProDVD, etc...
Gentoo gets around some of these by not storing the software on-site, although I've found them guilty of redistributing licenses as well as source code from their repository they do not have the right to do.
There's nothing necessarily illegal about having Java or Flash.
The Java licence lets you distribute it under certain conditions (http://www.java.com/en/download/license.jsp) and Macromedia allows you to apply to distribute their software (http://www.macromedia.com/licensing/). I find it hard to believe that Ubuntu, Suse, Mandriva, etc. who all distribute Flash and Java packages are illegal. With any of those distros, including Ubuntu, you do have to add extra repositories to get multimedia codecs and DVD playback - they are not in the main repositories. I just don't buy the idea that Centos/RHEL and Debian are the only 'legal' distros out there.
On Mon, 2005-11-28 at 13:05 +1100, Tim Edwards wrote:
I just don't buy the idea that Centos/RHEL and Debian are the only 'legal' distros out there.
The real issue isn't re legal, but actually FOSS. Neither Sun Java nor the Flash plugin are FOSS, and therefore not under consideration for several distros. While RHEL does distribute some packages that aren't FOSS, their distribution rights don't necessarily extend to the CentOS project.
On Sun, 2005-11-27 at 21:22 -0500, Ignacio Vazquez-Abrams wrote:
The real issue isn't re legal,
If you redistribute some things you betcha it's illegal. ;->
but actually FOSS. Neither Sun Java nor the Flash plugin are FOSS, and therefore not under consideration for several distros.
I wasn't even talking the "anal" Debian software guidelines/ classifications. I'm talking vendors who do _not_ allow redistribution of their software under the terms that distros do.
While RHEL does distribute some packages that aren't FOSS, their distribution rights don't necessarily extend to the CentOS project.
Or any other redistribution, hence the issue. Redistributing them _would_ be illegal. ;->
On Monday 28 November 2005 00:43, Bryan J. Smith wrote:
While RHEL does distribute some packages that aren't FOSS, their distribution rights don't necessarily extend to the CentOS project.
Or any other redistribution, hence the issue. Redistributing them _would_ be illegal. ;->
Not all closed-source software is illegal for public distribution.
For example, NVIDIA specifically allows their closed source drivers to be redistributed (for Linux / BSD only): http://www.nvidia.com/object/nv_swlicense.html
It is not legal distribute GPL software everywhere. Not all countries permit their people to run OS's that can tunnel encrypted traffic (squid and SSH), or sniff traffic out of the air (wireless acrd and ethereal).
I'm sure there are a few others. But Fedora/CentOS and Debian are the only ones I know of that have 100% redistributable software.
OpenSUSE is 100% GPL until modified (like Fedora). The fact that 99.9% of its users make it non-GPL compliant so they can play their MP3s and DVDs doesn't change the fact that when you download its all GPL.
And OpenSuSE really needs to address the fact that the SuSE Linux Professional it's based on it's either
Keep in mind where their home base is. Frankly, any move made against them by a US software company would only generate sympathy, and could be potentially unsuccessful given MS's rather poor track record n EU court's lately.
On Tue, 2005-11-29 at 04:59 -0500, ryan wrote:
Not all closed-source software is illegal for public distribution.
I never said they were. In fact, some distros do distribute software that is not fully open source, but is still 100% redistributable. That's not a legal issue for projects.
Remember, the whole reason I even mentioned this was because some distros have a unified set of repositories, and that includes redistribution of items it did _not_ properly license for redistribution.
For example, NVIDIA specifically allows their closed source drivers to be redistributed (for Linux / BSD only): http://www.nvidia.com/object/nv_swlicense.html It is not legal distribute GPL software everywhere. Not all countries permit their people to run OS's that can tunnel encrypted traffic (squid and SSH), or sniff traffic out of the air (wireless acrd and ethereal).
And those laws varying in locale. Whole different issue.
But when you redistribute software without a license, that is a pretty universal issue.
OpenSUSE is 100% GPL until modified (like Fedora). The fact that 99.9% of its users make it non-GPL compliant so they can play their MP3s and DVDs doesn't change the fact that when you download its all GPL.
Actually, Novell/SuSE have _not_ removed all the software from OpenSuSE they have licensed. But they are getting close with 10.0.
Keep in mind where their home base is. Frankly, any move made against them by a US software company would only generate sympathy, and could be potentially unsuccessful given MS's rather poor track record n EU court's lately.
Illegal redistribution is illegal redistribution. It's not debatable.
On Monday 28 November 2005 08:03, Bryan J. Smith wrote:
Keep in mind where their home base is. Frankly, any move made against them by a US software company would only generate sympathy, and could be potentially unsuccessful given MS's rather poor track record n EU court's lately.
Illegal redistribution is illegal redistribution. It's not debatable.
Its very debatable. What is "illegal redistribution" in one country is not in another.
Of course, I'm sure MS doesn't like it when third world countries engage in rampant copying/distribution of Windows and Office - but I bet most of those countries have no laws on their books that make software "piracy" illegal.
What is illegal in Redmond, USA is not necessarily illegal in the rest of the world and vice versa.
On Tuesday 29 November 2005 18:17, ryan wrote:
What is illegal in Redmond, USA is not necessarily illegal in the rest of the world and vice versa.
What is relevant is what is legal for CentOS, not for anyone else. In this case, that would mean the project leads' countries' laws would be in force; the centos.org domain registration is in Great Britain, so British law would apply and would define what is or is not legal.
ryan wrote:
What is illegal in Redmond, USA is not necessarily illegal in the rest of the world and vice versa.
Lamar Owen wrote:
What is relevant is what is legal for CentOS, not for anyone else. In this case, that would mean the project leads' countries' laws would be in force; the centos.org domain registration is in Great Britain, so British law would apply and would define what is or is not legal.
Listen guys, because this is the _last_time_ I'm going to say it.
The _context_ of this _entire_ thread is about what CentOS can and cannot redistribute, which leads to the reason why you have to use DAG or any other repository, which leads to added issues with updates aka "repository hell", etc... 9 times out of 10, when I have an update issue, it is a conflict between 2 or more repositories I did _not_ know about (and it is not quickly
You might want to debate back'n forth, point fingers at Redmond, try to rationalize what is legal/illegal in whatever locale's, etc... But what I've seen CentOS do, and it's the _same_ for Fedora, Debian, etc..., is create a 100% redistributable distro. That way other projects can redistribute it unmodified, I can redistribute it unmodified, etc... that means _leaving_out_ software that must be explicitly licensed for redistribution -- Java, various multimedia, etc...
If you don't like it, _get_over_it_! I honestly think this list is quickly becoming the "bitch about it, even if it won't change for good reason" list -- instead of providing solutions.
I am personally and, more importantly, professionally _thankful_ that CentOS is like this, because it makes it easier for me to avoid indemnification issues. Yes, that nasty word SCO misused and abused (wrongly) _is_ a reality when it comes to redistribution of software you do _not_ have a legal license too. Some distros care, because they care about _your_ legality beyond what they may or may have no licensed. Many do _not_.
Now that's the _context_ of why CentOS leads to using other repositories, and the resulting "repository hell" whether you realize that is the "root cause" of update issues or not. Everything else is arguments about what will _not_ change in CentOS -- let alone Fedora Core/Extras, official Debian repositories, etc... as well. So there is no reason or use to debate it, it will _not_ change.
On Tue, 2005-11-29 at 03:09, Bryan J. Smith wrote:
The _context_ of this _entire_ thread is about what CentOS can and cannot redistribute, which leads to the reason why you have to use DAG or any other repository, which leads to added issues with updates aka "repository hell", etc... 9 times out of 10, when I have an update issue, it is a conflict between 2 or more repositories I did _not_ know about (and it is not quickly
Part of this could be fixed if the third party repositories would make the effort to split items that do/don't replace core components. There are some packages that require updated libraries or versions compiled with non-standard options, but that doesn't apply to anything mentioned so far. A third party repository could work like livna does for fedora, requiring the stock core/extras to also be used for dependencies instead of replacing any stock libraries with potentially incompatible versions. If the apps that actually require conflicting libraries were split out to a different repository you could avoid them unless you were willing to take the risk.
On Tuesday 29 November 2005 09:42, Les Mikesell wrote:
Part of this could be fixed if the third party repositories would make the effort to split items that do/don't replace core components.
Perhaps.
However, if the repository requires those core components, does it matter whether it is in a split-out subrepository or in their main repository? If it is required it is required.
I know a little about this situation, using DAG and KDE-Redhat (my knowledge is far from exhaustive on the subject, but have had my share of 'situations'). KDE-Redhat by nature replaces large swathes of core libraries for the support of the later KDE (which is needed here for the upgraded kstars package, which we use for telescope control). DAG is a mixed bag, but not as intrusive as I found ATrpms to be. The biggest problem with DAG is the experimental apache httpd behind apt.sw.be, DAG's main mirror. I have had issues before with conflicts; when using third-party repos this just about must be expected, unless it is tailored for the core like Karanbir's extras.
One might ask why I run CentOS for stability but KDE-Redhat for a cutting edge feature together; it's called business sense, and using what is best for my needs. I don't want to go through major issues every six months like with Fedora, but I do really need the 3.4 version of kstars for telescope control. Thus far, CentOS4 plus KDE-Redhat has met my needs without being to terribly difficult (the need to download nearly a gigabyte of updates each quarter is disturbing; if Microsoft did this every quarter there would be significant outrage! I believe the scalability of delivering complete RPM updates is poor, and some rpmdelta mechanism needs to be implemented, both for the sake of the mirror's bandwidth and for the user's bandwidth). At least I'm not downloading a set of four CD's with major version upgrades of core components each six months....
On Tue, 2005-11-29 at 08:42 -0600, Les Mikesell wrote:
On Tue, 2005-11-29 at 03:09, Bryan J. Smith wrote:
The _context_ of this _entire_ thread is about what CentOS can and cannot redistribute, which leads to the reason why you have to use DAG or any other repository, which leads to added issues with updates aka "repository hell", etc... 9 times out of 10, when I have an update issue, it is a conflict between 2 or more repositories I did _not_ know about (and it is not quickly
Part of this could be fixed if the third party repositories would make the effort to split items that do/don't replace core components. There are some packages that require updated libraries or versions compiled with non-standard options, but that doesn't apply to anything mentioned so far. A third party repository could work like livna does for fedora, requiring the stock core/extras to also be used for dependencies instead of replacing any stock libraries with potentially incompatible versions. If the apps that actually require conflicting libraries were split out to a different repository you could avoid them unless you were willing to take the risk.
The new protectbase plugin (currently in testing):
http://lists.centos.org/pipermail/centos-devel/2005-November/000947.html
will also help with the issue of third party repos updating core components.
If you use this plugin and set all the centos repos to:
protect=1
and set your 3rd party repos to
protect=0
You will prevent upgrades of core components ...
This might cause an error IF a core component HAS to be upgraded to meet a valid dependency ... but then you could manually do those and exclude them from the core centos repo ... and from that point forward, get those from the 3rd party repo.
Johnny Hughes mailing-lists@hughesjr.com wrote:
The new protectbase plugin (currently in testing):
http://lists.centos.org/pipermail/centos-devel/2005-November/000947.html
will also help with the issue of third party repos updating core components. If you use this plugin and set all the centos repos to: protect=1 and set your 3rd party repos to protect=0 You will prevent upgrades of core components ...
Excellent! I did not know about this YUM plug-in. Yet another thing to go into the generic Enterprise Linux Manager's FAQ yet to be released.
This might cause an error IF a core component HAS to be upgraded to meet a valid dependency ...
But as long as it causes an error, I know about it. That's fine by me, I can manually resolve things in such cases.
but then you could manually do those and exclude them from the core centos repo ... and from that point forward, get those from the 3rd party repo.
Exactly. Is there any chance that the plug-in won't catch something? Or is it pretty absolute, and will always error out?
Again, that's the desired result I want. I don't want it blindly replacing core repository packages.
On Tue, 2005-11-29 at 07:21 -0800, Bryan J. Smith wrote:
Johnny Hughes mailing-lists@hughesjr.com wrote:
The new protectbase plugin (currently in testing):
http://lists.centos.org/pipermail/centos-devel/2005-November/000947.html
will also help with the issue of third party repos updating core components. If you use this plugin and set all the centos repos to: protect=1 and set your 3rd party repos to protect=0 You will prevent upgrades of core components ...
Excellent! I did not know about this YUM plug-in. Yet another thing to go into the generic Enterprise Linux Manager's FAQ yet to be released.
This might cause an error IF a core component HAS to be upgraded to meet a valid dependency ...
But as long as it causes an error, I know about it. That's fine by me, I can manually resolve things in such cases.
but then you could manually do those and exclude them from the core centos repo ... and from that point forward, get those from the 3rd party repo.
Exactly. Is there any chance that the plug-in won't catch something? Or is it pretty absolute, and will always error out?
Again, that's the desired result I want. I don't want it blindly replacing core repository packages.
It has worked quite well for me in testing ...
AS LONG AS ... you remember to set protect=0 for 3rd party apps.
I think protect=1 is assumed if you don't have anything listed for the 3rd party repo ... meaning it will replace core files.
On Tue, 2005-11-29 at 18:17 -0500, ryan wrote:
Its very debatable. What is "illegal redistribution" in one country is not in another.
Please name a country?
Of course, I'm sure MS doesn't like it when third world countries engage in rampant copying/distribution of Windows and Office - but I bet most of those countries have no laws on their books that make software "piracy" illegal.
Bull! They _do_. They just don't enforce them! Lack of enforcement does _not_ mean "legal." Just because the piracy rate in Japan is 92% and places like Singapore is 99% (oh the irony of their "values" ;-) does _not_ mean it's "legal" to illegally copy works.
They just don't enforce it. _Huge_ difference!
What is illegal in Redmond, USA is not necessarily illegal in the rest of the world and vice versa.
But countries that have signed certain international treaties and laws on copyrights with the United States _are_ bound by them. Even China is bound by man agreements they have signed, and their lack of enforcement is a powerful bargaining tool right now with their membership (or potential membership) in various organizations.
Again, we are _way_off_ the path of my _original_ point. You guys can really argue to the point of absolute futility on these matters, but CentOS and its repositories -- like Fedora Core/Extras, official Debian repositories, etc... -- are designed so they are 100% redistributable (and are not necessarily 100% open source, read all the licenses ;-).
That way there are _no_ legal issues with redistribution into another project, for consultants and integrators, etc... If you really "don't care" and just freely redistribute Gentoo, Ubuntu, Knoppix (non-official releases with 100% pure Debian), etc... then please do _not_ step foot in any corporation I consult for or work at. ;->
On Mon, 2005-11-28 at 13:05 +1100, Tim Edwards wrote:
There's nothing necessarily illegal about having Java or Flash.
Java is being illegally redistributed.
The Java licence lets you distribute it under certain conditions (http://www.java.com/en/download/license.jsp) and
Which _no_ distro meets AFAICT. No offense, I'm tired of going over and over this on countless lists. You might think it's just "anal," but when you have to certify distros as being 100% redistributable inside clients and major corporations, then you tend to care. ;->
Macromedia allows you to apply to distribute their software (http://www.macromedia.com/licensing/).
I _never_ said Flash, although there are _some_ questions on Flash's redistribution.
I find it hard to believe that Ubuntu, Suse, Mandriva, etc. who all distribute Flash and Java packages are illegal. With any of those distros, including Ubuntu, you do have to add extra repositories to get multimedia codecs and DVD playback - they are not in the main repositories. I just don't buy the idea that Centos/RHEL and Debian are the only 'legal' distros out there.
I'm sure there are a few others. But Fedora/CentOS and Debian are the only ones I know of that have 100% redistributable software.
Even RHEL is _not_ 100% redistributable, only Red Hat has a license to redistribute some things. And OpenSuSE really needs to address the fact that the SuSE Linux Professional it's based on it's either (and some people are adding things to the repositories that are only going to create headaches for Novell and the project).
Bryan J. Smith wrote:
On Mon, 2005-11-28 at 13:05 +1100, Tim Edwards wrote:
There's nothing necessarily illegal about having Java or Flash.
Java is being illegally redistributed.
By who? Dag has a Jre package for Centos/RHEL, Ubuntu has the java-package from Debian which just runs the Sun Java installer, Mandriva and Suse have their Java packages for paying customers. If its all illegal Sun would have kicked up a fuss long before now, and companies which are very cautious about this kind of thing (eg. Novell doesn't even include MP3 in Suse anymore) would not be going against them.
I'm sure there are a few others. But Fedora/CentOS and Debian are the only ones I know of that have 100% redistributable software.
Even RHEL is _not_ 100% redistributable, only Red Hat has a license to redistribute some things. And OpenSuSE really needs to address the fact that the SuSE Linux Professional it's based on it's either (and some people are adding things to the repositories that are only going to create headaches for Novell and the project).
All these distros (Ubuntu, Mandriva, OpenSuse) come as CDs/DVDs of entirely open source software when you download them. If you pay for the boxed set (Mandriva, Suse) or club membership (Mandriva) you get CDs or DVDs with closed source software in them too - like Java. For all these distros you can optionally add extra repos to get potentially illegal stuff like DVD playing, codecs etc. Same as you do with Centos/RHEL.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, Nov 28, 2005 at 12:38:44AM -0500, Bryan J. Smith wrote:
On Mon, 2005-11-28 at 13:05 +1100, Tim Edwards wrote:
The Java licence lets you distribute it under certain conditions (http://www.java.com/en/download/license.jsp) and
Which _no_ distro meets AFAICT.
Sorry to disagree, Bryan, but when I worked at Conectiva, they used to have an special authorization from Sun for redistribution.
Then again, maybe I'm agreeing with you. Maybe they didn't met the conditions, that is why I needed that authorization.
Best regards,
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
On Mon, 2005-11-28 at 12:16 -0200, Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, Nov 28, 2005 at 12:38:44AM -0500, Bryan J. Smith wrote:
On Mon, 2005-11-28 at 13:05 +1100, Tim Edwards wrote:
The Java licence lets you distribute it under certain conditions (http://www.java.com/en/download/license.jsp) and
Which _no_ distro meets AFAICT.
Sorry to disagree, Bryan, but when I worked at Conectiva, they used to have an special authorization from Sun for redistribution.
Then again, maybe I'm agreeing with you. Maybe they didn't met the conditions, that is why I needed that authorization.
They didn't meet the requirements ... and therefore needed special permission. I asked for special permission too ... but it was denied.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, Nov 28, 2005 at 08:59:06PM -0600, Johnny Hughes wrote:
On Mon, 2005-11-28 at 12:16 -0200, Rodrigo Barbosa wrote:
On Mon, 2005-11-28 at 13:05 +1100, Tim Edwards wrote:
The Java licence lets you distribute it under certain conditions (http://www.java.com/en/download/license.jsp) and
Which _no_ distro meets AFAICT.
Sorry to disagree, Bryan, but when I worked at Conectiva, they used to have an special authorization from Sun for redistribution.
Then again, maybe I'm agreeing with you. Maybe they didn't met the conditions, that is why I needed that authorization.
They didn't meet the requirements ... and therefore needed special permission. I asked for special permission too ... but it was denied.
I remember clearly they had to provide it on a separated, non-downloadable CD. There was other softwares on that CD too, that was not the issue. The main point is that they could not provide the ISO for download.
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Rodrigo Barbosa wrote:
I remember clearly they had to provide it on a separated, non-downloadable CD. There was other softwares on that CD too, that was not the issue. The main point is that they could not provide the ISO for download.
So that's the same thing RedHat is doing with the application disk.
Ralph
On Tue, 2005-11-29 at 11:20 +0100, Ralph Angenendt wrote:
Rodrigo Barbosa wrote:
I remember clearly they had to provide it on a separated, non-downloadable CD. There was other softwares on that CD too, that was not the issue. The main point is that they could not provide the ISO for download.
It was not for download for free (at least the one for RedHat), it is available for customers.
It didn't contain any software, like gcj, that replaces java functionality.
any the most important part, they had special and specific permission to distribute it in that specific manner by sun ... which we can't get.
So that's the same thing RedHat is doing with the application disk.
Correct ... you can provide
Rodrigo Barbosa wrote:
I remember clearly they had to provide it on a separated, non-downloadable CD. There was other softwares on that CD too, that was not the issue. The main point is that they could not provide the ISO for download.
Ralph Angenendt wrote:
So that's the same thing RedHat is doing with the application disk.
Yep, Red Hat and only select others really strive to do keep the 100% redistributable components separate from the non-redistributable components.
It seems Novell does want to do this with SuSE, but as of even OpenSuSE 10.0 (as I've seen it), they have not yet (please correct me if I'm wrong, and 9.3 was the last release that didn't).
Debian has always excelled at marketing everything. But don't confuse their _official_ repository "NON-FREE" category with non-Debian, additional repositories that add stuff to the "NON-FREE" category.
Bryan J. Smith wrote:
Yep, Red Hat and only select others really strive to do keep the 100% redistributable components separate from the non-redistributable components.
It seems Novell does want to do this with SuSE, but as of even OpenSuSE 10.0 (as I've seen it), they have not yet (please correct me if I'm wrong, and 9.3 was the last release that didn't).
Debian has always excelled at marketing everything. But don't confuse their _official_ repository "NON-FREE" category with non-Debian, additional repositories that add stuff to the "NON-FREE" category.
Both Suse and Ubuntu have only Open Source packages on their downloadable CD/DVD images, just like Redhat. In fact you'll find that most, if not all, Linux distros only have open source (ie. redistributable) software in their downloadable versions. As with RHEL or Centos you can add extra repos after the install to get closed-source (eg. Java) or questionable (eg. win32codecs) packages, for example for OpenSuse: http://www.opensuse.org/Package_Repositories
Far from being the exception with a few others, the way that Redhat does it is the rule.
Tim Edwards tim@registriesltd.com.au wrote:
Both Suse and Ubuntu have only Open Source packages on their downloadable CD/DVD images, just like Redhat.
The downloadable SuSE Linux DVD .iso image as of version 9.3 most certainly did _not_! And 10.0 seems to have similar issues, ones that Novell legal is still trying to classify and remove.
OpenSuSE seems to be a good effort in that regard so far. But Novell is still identifying some components that are not 100% redistributable.
In fact you'll find that most, if not all, Linux distros
only
have open source (ie. redistributable) software in their downloadable versions.
This is a common mis-nomer by most Linux users. The indemnification issue is real with a _lot_ of distros. I spent a good part of several weeks in late 2003 at a Fortune 20 company doing a brief for their legal.
As with RHEL or Centos you can add extra repos after the install to get closed-source (eg. Java) or questionable
(eg.
win32codecs) packages, for example for OpenSuse: http://www.opensuse.org/Package_Repositories
And that's where the "repository hell" comes in. ;-> That was the _original_context_ of my _entire_ point.
Those distros where you have 1 repository for everything are the problem. ;->
Far from being the exception with a few others, the way that Redhat does it is the rule.
Fedora and the resulting CentOS from RHEL, yes. But there are things not included in CentOS that RHEL does, because it is not 100% freely redistributable.
Bryan J. Smith wrote:
Tim Edwards tim@registriesltd.com.au wrote:
Both Suse and Ubuntu have only Open Source packages on their downloadable CD/DVD images, just like Redhat.
The downloadable SuSE Linux DVD .iso image as of version 9.3 most certainly did _not_! And 10.0 seems to have similar issues, ones that Novell legal is still trying to classify and remove.
OpenSuSE seems to be a good effort in that regard so far. But Novell is still identifying some components that are not 100% redistributable.
What packages in the downloadable Suse or OpenSuse is not redistributable?
This is a common mis-nomer by most Linux users. The indemnification issue is real with a _lot_ of distros. I spent a good part of several weeks in late 2003 at a Fortune 20 company doing a brief for their legal.
I don't think you've actually tried many other distros have you? When you do you'll find that almost all, at least among the main distros, consist of entirely open source software on their downloadable CDs/DVDs.
And that's where the "repository hell" comes in. ;-> That was the _original_context_ of my _entire_ point.
Those distros where you have 1 repository for everything are the problem. ;->
What distros are there where you have 1 repo for everything? Ubuntu, Suse, Mandriva don't.
Fedora and the resulting CentOS from RHEL, yes. But there are things not included in CentOS that RHEL does, because it is not 100% freely redistributable.
Yes and most other distros are just as redistributable as Centos or Fedora.
Tim Edwards tim@registriesltd.com.au wrote:
What packages in the downloadable Suse or OpenSuse is not redistributable?
Several. It's been about 6 months since I evaluated the 9.3 DVD from SuSE's FTP site. I honestly don't have time to go back through it. But there were several packages that Debian and Fedora would not include.
Some were the emulation and multimedia packages, and it wasn't just a matter of "legally questionable" stuff. Some were things SuSE had licensed proper, so they were legal for SuSE to distribute to you. Before the SuSE Linux 9.3 DVD, SuSE called it the "evaluation version" (that wasn't redistributable) for a reason. But with 9.3, they started making the entire thing available via download as a DVD .iso. And it still included many of these licensed programs by SuSE.
I don't think you've actually tried many other distros have you?
Not in the last year, no. But 2 years ago I got stuck with evaluating about 20 distros that were in use. Knoppix is one I had to stop letting in the door for sure -- especially all the variants people build.
When you do you'll find that almost all, at least among the main distros, consist of entirely open source software on their downloadable CDs/DVDs.
IIRC, not even Fedora is absolutely, 100% OSD compliant open source. Many packages have some restrictions on modification, etc... But they are _all_ 100% redistributable.
What distros are there where you have 1 repo for everything? Ubuntu, Suse, Mandriva don't.
The commercial Mandriva and SuSE, yes. That is what people have constantly been comparing CentOS to on this list.
Last time I checked, Ubuntu has some multimedia and other things in its repositories that Debian does not.
Yes and most other distros are just as redistributable as Centos or Fedora.
So they say. But that's what this is all about. ;->
There's not a week that goes by without someone in some LUG complaining about what Debian, Fedora, CentOS, etc... doesn't have that another distro does.
Bryan J. Smith wrote:
Tim Edwards tim@registriesltd.com.au wrote:
What packages in the downloadable Suse or OpenSuse is not redistributable?
Several. It's been about 6 months since I evaluated the 9.3 DVD from SuSE's FTP site. I honestly don't have time to go back through it. But there were several packages that Debian and Fedora would not include.
Some were the emulation and multimedia packages, and it wasn't just a matter of "legally questionable" stuff. Some were things SuSE had licensed proper, so they were legal for SuSE to distribute to you. Before the SuSE Linux 9.3 DVD, SuSE called it the "evaluation version" (that wasn't redistributable) for a reason. But with 9.3, they started making the entire thing available via download as a DVD .iso. And it still included many of these licensed programs by SuSE.
Unless you can point out some specific examples I'd say you've confused packages that come with the download to packages that people regularly add from well known repos after they've installed. The perfect example of this would be mp3 support.
When you do you'll find that almost all, at least among the main distros, consist of entirely open source software on their downloadable CDs/DVDs.
IIRC, not even Fedora is absolutely, 100% OSD compliant open source. Many packages have some restrictions on modification, etc... But they are _all_ 100% redistributable.
I think the Fedora people would have something to say about that: http://fedora.redhat.com/about/ What exactly is non-open source in Fedora? Not being sarcastic - the Fedora people would be very interested to hear of any packages that aren't open source in their distro. I'd be interested if you could give an example too.
The commercial Mandriva and SuSE, yes. That is what people have constantly been comparing CentOS to on this list.
Last time I checked, Ubuntu has some multimedia and other things in its repositories that Debian does not.
The commercial Mandriva and Suse (I'm assuming you mean Mandrake Corporate Server and SLES) are like RHEL - they have packages for closed-source software included. The downloadable Mandriva and Suse are purely open source, the questionable multimedia stuff is in seperate repos and isn't included on the CDs, nor is closed-source stuff like Java.
greetings,
looks to me like
RE: [CentOS] A minor beef
should be
RE: [CentOS] A MAJOR beef!!!
apologies, couldnt resist!
;->
- rh
-- Robert Hanson - Abba Communications Computer & Internet Services (509) 624-7159 - www.abbacomm.net
On 11/29/05, Robert roberth@abbacomm.net wrote:
greetings,
looks to me like
RE: [CentOS] A minor beef
should be
RE: [CentOS] A MAJOR beef!!!
apologies, couldnt resist!
Excellent sense of humor. My minor beef was answered fairly rapidly, ( and Johnny just put out an excellent summary of needs and how things really work), but like most things these days the thread headed straight OT for 67 posts and ticking. I guess that qualifies as major beef. All we need now is contributions from a packing house <grin>.
-- Collins Richey Debugging is twice as hard as writing the code ... If you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan
Couldn't resist ...
(shades of Wendy's commercials from a long time ago here in the US)
Where's the beef?
(major or minor).
Collins Richey wrote:
On 11/29/05, Robert roberth@abbacomm.net wrote:
greetings,
looks to me like
RE: [CentOS] A minor beef
should be
RE: [CentOS] A MAJOR beef!!!
apologies, couldnt resist!
Excellent sense of humor. My minor beef was answered fairly rapidly, ( and Johnny just put out an excellent summary of needs and how things really work), but like most things these days the thread headed straight OT for 67 posts and ticking. I guess that qualifies as major beef. All we need now is contributions from a packing house <grin>.
-- Collins Richey Debugging is twice as hard as writing the code ... If you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Tue, 2005-11-29 at 22:49 -0500, Joe Landman wrote:
Couldn't resist ...
(shades of Wendy's commercials from a long time ago here in the US)
Where's the beef?
(major or minor).
---- quick - who was the original speaker of the phrase in Wendy's commercials?
answer below...
no peeking...
http://www.tvacres.com/admascots_clarapeller.htm
Craig
On 11/29/05, Robert roberth@abbacomm.net wrote: Excellent sense of humor. My minor beef was answered fairly rapidly, ( and Johnny just put out an excellent summary of needs and how things really work), but like most things these days the thread headed straight OT for 67 posts and ticking. I guess that qualifies as major beef. All we need now is contributions from a packing house <grin>.
It's good that you can have a sense of humor about it. I'm just hitting the delete key more often. The signal to noise ratio reaching a fevered pitch.
Preston
On Wed, 30 Nov 2005, Preston Crawford wrote:
On 11/29/05, Robert roberth@abbacomm.net wrote: Excellent sense of humor. My minor beef was answered fairly rapidly, ( and Johnny just put out an excellent summary of needs and how things really work), but like most things these days the thread headed straight OT for 67 posts and ticking. I guess that qualifies as major beef. All we need now is contributions from a packing house <grin>.
It's good that you can have a sense of humor about it. I'm just hitting the delete key more often. The signal to noise ratio reaching a fevered pitch.
I agree. That thread is not contributing to the quality of this list.
Tim Edwards tim@registriesltd.com.au wrote:
I think the Fedora people would have something to say about that: http://fedora.redhat.com/about/ What exactly is non-open source in Fedora?
I'll go through the full package list in the next few weeks and point a few things out. The key is that they are 100% redistributable, no always open source. There are always going to be binary and other support in packages that are allowed to be redistributed, but they are not available in source.
The commercial Mandriva and Suse (I'm assuming you mean Mandrake Corporate Server and SLES)
No, I mean SuSE Linux Professional, as well as the various Mandriva memberships, allow you to tap such. That's what people compare pure Debian, Fedora, CentOS, etc... to.
That was my original point.
The downloadable Mandriva and Suse are purely open source,
Yes, Mandriva is available in a purely 100% redistributable form. And that form is _different_ than the paid memberships.
No in the case of SuSE, as of the SuSE Linux 9.3 DVD. Novell was still shipping quite a bit, probably for upward compatibility -- and that included the downloadable "FTP DVD" on their site.
the questionable multimedia stuff is in seperate repos and isn't included on the CDs, nor is closed-source stuff like Java.
That might be the case of "pure" OpenSuSE right now. If that is the case, great!
But it wasn't as of SuSE Linux 9.3. And that included the downloadable "FTP DVD" from Novell's site.
I know Novell was trying to be pro-active on this as early as SuSE Linux 9.2. But they didn't make the cut as of 9.3. They were still going through packages, plus they didn't want to break compatibility.
I heard second-hand on SuSE 10.0, so I don't have first-hand knowledge, I have to admit that.
Pissing match snipped.
You're both right. So right that I am no longer reading this list. So would you guys (perhaps the indivdual who claimed he was leaving for good) let the other person have the last word so this thread can die?
Preston
Preston Crawford me@prestoncrawford.com wrote:
Pissing match snipped. You're both right. So right that I am no longer reading this list. So would you guys (perhaps the indivdual who claimed he was leaving for good) let the other person have the last word so this thread can die?
Preston, if I had a dime for every complaint of yours. And you've managed to take some threads a long way too.
On Wed, 30 Nov 2005, Bryan J. Smith wrote:
Preston Crawford me@prestoncrawford.com wrote:
Pissing match snipped. You're both right. So right that I am no longer reading this list. So would you guys (perhaps the indivdual who claimed he was leaving for good) let the other person have the last word so this thread can die?
Preston, if I had a dime for every complaint of yours.
Huh? I don't recall really complaining about the distro. I'm very happy with it. Questions? Yes. Complaints? Not that I recall. Most of my complaints have to do with the way this list goes sometimes.
And you've managed to take some threads a long way too.
The funny thing is you're involved in those threads every time. What do you think the common denominator is? Me or the person who has quit and rejoined the list multiple times? The person who has asked the moderators to make it so he can't post or a general lurker who uses the OS in numerous places and asks questions now and then?
Preston
Preston Crawford me@prestoncrawford.com wrote:
Huh? I don't recall really complaining about the distro. I'm very happy with it. Questions? Yes. Complaints? Not that I recall. Most of my complaints have to do with the way this list
goes
sometimes.
That's what I was refering to. Otherwise, I am in the same boat as yourself, you don't hear me complaining about the distro either. In fact, I've provided suggestion after suggestion to select people.
The funny thing is you're involved in those threads every time.
As of late, yes. As of recent, check the archives, you might be surprised. More in the past, yes. The reality is that they happen _regardless_ of my involvement.
But give me credit. I've listed technical option after technical option after technical option in many. Although after awhile, I do sound like a broken record, I admit.
What do you think the common denominator is?
I see the same 3-4 people questioning _lots_ of things on CentOS. So if you're going to point the finger at me, you've got no less than 3-4 other fingers to use as well. ;->
Me or the person who has quit and rejoined the list
multiple
times?
I have _not_ rejoined multiple times. I've _always_ been on this list! Just because I don't post doesn't mean I'm _not_ helping people off-list. ;->
The person who has asked the moderators to make it so he
can't
post
Actually, that was months ago. As of the past month, I've decided to just post. Some have thanked me. Others have complained.
or a general lurker who uses the OS in numerous places and asks questions now and then?
Dude, check your history in the archives. ;-> You might be a little more objective after doing so. I don't even attempt to be or act "righteous" because I'm not innocent. I suggest you consider the same.
Is this thread serving any useful purpose? _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
No, and it hasn't for a while. So it should die.
Preston
On Mon, Nov 28, 2005 at 12:38:44AM -0500, Bryan J. Smith wrote:
The Java licence lets you distribute it under certain conditions (http://www.java.com/en/download/license.jsp) and
Which _no_ distro meets AFAICT. No offense, I'm tired of going over and
And which most distros _can't_ meet, since that includes restrictions like
- you must distribute it for the sole purpose of running _your_ programs (that is, distributing it to allow other programs to be run violates the license). And these program must "add significant and primary functionality to the Software [Java]". That is, clearly the license forbids distributing the JRE for its own sake, and they've even added language to make clear that just slapping in a few applications that require Java isn't good enough. - you can't include gcc in your distro, since that includes gcj, which could be consiered "additional software intended to replace any component(s) of [Sun's Java]"
Plus,
- you have to accept the responsibility to defend and indemnify Sun against any claim anyone has
which is an impossible burden for any non-gigantic company.
On 11/28/05, Matthew Miller mattdm@mattdm.org wrote:
[ content snipped ]
All of which is why I avoid Java like the plague.
-- Collins Richey Debugging is twice as hard as writing the code ... If you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan
On Sunday 27 November 2005 19:49, Tim Edwards wrote:
Bryan J. Smith wrote:
- Repository hell affects _most_ other package distros, including
Debian. Ubuntu and other Debian-based distros get around them by including software that may not be legally redistributed.
Just out of interest what do Debian, Ubuntu and others distribute that is illegal? And even if they do how does having illegal software help get around repository problems?
Illegal probably isn't the correct word in all cases.
A great example is the RPM libdvdcss - it allows de-encryption of commercial DVDs so that they can played (or illegally copied) under Linux.
It may be a DMCA violation to use libdvdcss since it provides features (like DVD ripping, ignoring of country codes, and screen capture) that can be used to get around DVD-protection schemes.
Interestingly, no one has ever challenged the use of libdvdcss and it probably *isn't* illegal. If it was challenged in court, it would *probably* be ok to use since no one has produced a way to play DVDs under Linux with commercial software....although courts may order some of its features removed (like ignoring country codes).
As if this wasn't a grey enough area already, the DMCA has no authority outside the USA.
In some countries, personal use of strong encryption software is banned. In those countries I assume CentOS is totally illegal out of the box since it ships with OpenSSH, and can not be removed during installation.
Generally, distros like CentOS/Fedora/OpenSUSE/Debian try to stick to all GPL licensed packages in their repos (which is no guarantee that they will be legal everywhere). For a list of RPMs that are fully supported, but kept out of OpenSUSE (SUSE includes them in the boxed version) since they aren't licensed via the GPL see here: http://rpmfind.net/linux/RPM/SUSE_LINUX_10.0.42_(i586).html
This is why no one in the US has gone after anyone posting DeCSS code in this instance libdvdcss.
FYI: http://cyber.law.harvard.edu/openlaw/DVD/NY/appeals/opinion.html
UNITED STATES COURT OF APPEALS FOR THE SECOND CIRCUIT
August Term 2000
Argued: May 1, 2001 Decided: November 28, 2001
Finally Submitted: May 30, 2001
Docket No. 00-9185
- - - - - - - - - - - - - - - - - - - - - - - - - -
UNIVERSAL CITY STUDIOS, INC., PARAMOUNT PICTURES CORPORATION, METRO-GOLDWYN-MAYER STUDIOS INC., TRISTAR PICTURES, INC., COLUMBIA PICTURES INDUSTRIES, INC., TIME WARNER ENTERTAINMENT COMPANY, L.P., DISNEY ENTERPRISES INC., TWENTIETH CENTURY FOX FILM CORPORATION, Plaintiffs-Appellees,
v.
ERIC CORLEY, also known as Emmanuel Goldstein, and 2600 ENTERPRISES INC., Defendants-Appellants,
UNITED STATES OF AMERICA, Intervenor.
. . . . . (way down at the end) . . .
Posting DeCSS on the Appellants' web site makes it instantly available at the click of a mouse to any person in the world with access to the Internet, and such person can then instantly transmit DeCSS to anyone else with Internet access. Although the prohibition on posting prevents the Appellants from conveying to others the speech component of DeCSS, the Appellants have not suggested, much less shown, any technique for barring them from making this instantaneous worldwide distribution of a decryp tion code that makes a lesser restriction on the code's speech component.29 It is true that the Government has alternative means of prohibiting unauthorized access to copyrighted materials. For example, it can create criminal and civil liability for those who gain unauthorized access, and thus it can be argued that the restriction on posting DeCSS is not absolutely necessary to preventing unauthorized access to copyrighted materials. But a content-neutral regulation need not employ the least restrictive means of accomplishing the governmental objective. Id. It need only avoid burdening "substantially more speech than is necessary to further the government's legitimate interests." Id. (internal quotation marks and citation omitted). The prohibition on the Defendants' posting of DeCSS satisfies that standard.30
On 11/28/05 2:08 AM, "ryan" ryanag@zoominternet.net wrote:
On Sunday 27 November 2005 19:49, Tim Edwards wrote:
Bryan J. Smith wrote:
- Repository hell affects _most_ other package distros, including
Debian. Ubuntu and other Debian-based distros get around them by including software that may not be legally redistributed.
Just out of interest what do Debian, Ubuntu and others distribute that is illegal? And even if they do how does having illegal software help get around repository problems?
Illegal probably isn't the correct word in all cases.
A great example is the RPM libdvdcss - it allows de-encryption of commercial DVDs so that they can played (or illegally copied) under Linux.
It may be a DMCA violation to use libdvdcss since it provides features (like DVD ripping, ignoring of country codes, and screen capture) that can be used to get around DVD-protection schemes.
Interestingly, no one has ever challenged the use of libdvdcss and it probably *isn't* illegal. If it was challenged in court, it would *probably* be ok to use since no one has produced a way to play DVDs under Linux with commercial software....although courts may order some of its features removed (like ignoring country codes).
As if this wasn't a grey enough area already, the DMCA has no authority outside the USA.
In some countries, personal use of strong encryption software is banned. In those countries I assume CentOS is totally illegal out of the box since it ships with OpenSSH, and can not be removed during installation.
Generally, distros like CentOS/Fedora/OpenSUSE/Debian try to stick to all GPL licensed packages in their repos (which is no guarantee that they will be legal everywhere). For a list of RPMs that are fully supported, but kept out of OpenSUSE (SUSE includes them in the boxed version) since they aren't licensed via the GPL see here: http://rpmfind.net/linux/RPM/SUSE_LINUX_10.0.42_(i586).html
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 11/24/05, Collins Richey crichey@gmail.com wrote:
CentOS is a really great product, and the package supporters do a bang up job, but the one deficiency I've found is the fact that one can never rely on being able to get updates at any particular time. Whether it's CentOS proper or the Dag additions, something is broke most every time I want to apply updates.
One other thing I haven't seen mentioned in this thread that's worth pointing out is a yum plugin called fastestmirror. You can find it and how to enable it on the yum wiki. It does a good job of getting the packages you need quickly if the only problem is download speed, at the cost of a slight (very slight in my case, less than a second) delay at the beginning. Several of the yum plugins are becoming quite sexy for daily use.
I know this is whin[ge]ing, and I certainly don't have a solution to offer.
If anyone can offer bucks and/or equipment to improved the software distribution process, your karma would get an enormous boost!!!
-- Collins Richey Debugging is twice as hard as writing the code ... If you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- Jim Perrin System Architect - UIT Ft Gordon & US Army Signal Center
-
Bryan J. Smith -
Collins Richey -
Craig White -
David Johnston -
Ignacio Vazquez-Abrams -
Jim Perrin -
Joe Landman -
Johnny Hughes -
Kai Schaetzl -
Lamar Owen -
Lee W -
Les Mikesell -
Matthew Miller -
Preston Crawford -
Ralph Angenendt -
Robert -
Robin Mordasiewicz -
Rodrigo Barbosa -
ryan -
Ryan Lum -
Sam Drinkard -
Steve Bergman -
Tim Edwards