Regarding: _______________ -->My strategy generally is to use a file for swap rather than a partition, even in linux.
What I find curious is that you have a strategy. On what relevant experience do you base this strategy? 1 GB of disk space costs less than $0.50. Set up 3 GB of VM if it makes you feel good. The latte you drink while you set it up costs more than the extra disk space!
So go for it!!! Who cares what you do? Heck, give yourself 10x the RAM and see if it actually makes any difference!!! (it won't) _______________
I have a strategy and I care. I have some 50+ rather individual servers to maintain including constant builds, upgrades, etc., etc. so even a small amount of additional administration overhead is significant (not the disk space which I agree isn't significant).
I prefer to use swap files rather than partitions on my Unix servers (Linux and FreeBSD almost entirely). For me the main difference is that I can have an initialization script (e.g. cfengine driven) set up and even "re-up" swap files automatically vs. setting up a swap partition at build time. My "kickstart" mechanisms aren't as carefree in terms of setting up and managing swap partitions. Since I can't recall the last time anything actually swapped on any of my servers (years ago and just before a crash anyway), I don't think swap makes much difference, so I optimize for the time I have to put into getting it into place - by dealing with it in an automated initialization script and keeping it out of the issues related to partitioning the disks.
R.e. "...the bits are GPLed, there is nothing RH can do to stop you from copying them."
I don't believe the above is true. Redhat has copyright on some of the distribution. E.g. the Redhat logos module. There are other non-GPL parts. Even at that GPL only applies to the source.
There are a number of projects working to essentially rebuild the Redhat Enterprise line without the Redhat copyrighted parts - depending on GPL to avoid legal confrontation with Redhat. I suggest looking into those efforts (e.g. http://www.caosity.org/) if anybody would like to avoid Redhat licensing constraints but still get the advantages of the Redhat integration. I also hope those in the open source community support this effort to exercise the GPL in its strongest test yet.
I'm a system administrator running numerous server systems for a national laboratory. We have observed over recent years that if we want to run open source software (e.g. developed at other laboratories, universities, by the open source community, etc.) then it has typically been developed and tested on Redhat Linux. This and the no cost nature of Redhat Linux until recently has made the choice of server OS an easy one.
Now with the licensing fees being charged by Redhat for your only effectively supported OS, your Enterprise line, I wonder where this "sweet spot" will shift or whether it will disappear altogether. Certainly most of the academic development will not be done on the Redhat Enterprise line. It's too early to say about development done in the open source community, but I would expect that to shift off of Redhat also. We can afford the license fees for now, but if the software development shifts we will have to also.
I realize Redhat was in a difficult spot financially. However, isn't there a danger that shifting and/or destroying that "sweet spot" will have an adverse effect on the Linux community and on Redhat?
When you rose to speak at the recent Linuxworld in San Francisco, I expected you to say something to the effect that "Times are tough and this is what we had to do to stay in business. We're sorry about the possible negative impact on the community." Instead you gave this rousing: Isn't open source wonderful?, We're all in this together, etc. presentation. That seemed a bit hypocrital to me. How did you justify such a presentation given the upcomming end of life for your consumer OS line?
The part I don't understand is how it "works out well for customers too". I work in the server group at NERSC: http://www.nersc.gov/
Our workstation group which has been supporting Redhat for the last few years for our staff is starting to panic looking for an alternative to Redhat after 1/04. They can't accept the limit to 1 year of support.
Our cluster folks (e.g. PDSF: http://pdsf.nersc.gov/ but there are others running Redhat) are really starting to sweat because they have such a huge installed software base (e.g. in the PSDF case in the accelerator community). Even if there was an alternative supported base for them beyond RH 7.3 they would have a difficult time switching (those library issues mentioned elsewhere), but without a supported alternative (read at least 2 years of patches - nobody here actually calls Redhat) they are unsure where to turn. I expect they may end up just continuing to support RH 7.3 themselves. However, that isn't really good for anybody.
Our server group (including me) has to have Oracle support for those systems where the DBAs need Oracle support (at least two system, perhaps three). We are fine paying Redhat for Enterprise licenses on those few systems. You might say that works out well for Redhat, and maybe us. However, what about my kickstart server? What about our testing sytems? What about our failover systems? All licensed for RH Enterprise? OK, I can buy that also - though the cost and administrative burden are getting uncomfortable. However, my big problem is that the original reason I choose Redhat was that it was the sweet spot. Since most everybody else that I cared about was developing on Redhat I could be confident that software I was given and asked to support would run there. Now that model is in question. I and others (this thread) are all looking for an alternative. That doesn't seem to me good for customers of Redhat. Others can of course differ.
It's fine to say "take a chillpill". I'll be happy to as soon as we have a plan in place for 1/04. Please make a suggestion for our workstation group, our cluster folks, and our server team. We are listening intently while following efforts to rebuild RH Enterprise from source (e.g. http://www2.uibk.ac.at/zid/software/unix/linux/rhe l-rebuild-l.html) efforts to continue support for Redhat 7.3 and other options for our future Unix OS needs.
Redhat's new policy toward their 'consumer' OSs is to only provide patch support for 1 year. Since I don't trust a new release on my production servers until it has shaken for about 6 months, this means that I and you (I guess) would be replacing OSs every 6 months in order to keep getting patch support. Is that where you are going tomorrow (1/04) emacnabber?
The reality I believe is that Redhat doesn't know what sort of support they will continue to give for their consumer OSs. They seem to be thinking of them as beta's for the Open Source community. Do you want to run your Universities production services on betas?
I think the term 'support' is being used in multiple senses that may be causing confusion.
What many people are looking for in 'support' is simply patches for bugs and security problems. Even in that limited sense the RH 'consumer' versions (8, 9, 10...) no longer seem adequate for production use (e.g. workstations, clusters, even servers that don't need to run supported third part applications and don't need consulting support). The problem is that they have been cut down to one year of patch support. I won't start using an OS until it has been shaken out for at least 6 months. That would mean that with the Redhat consumer versions I would have to replace my OS every 6 months. I don't believe it's reasonable to treat my users that way.
Regarding Oracle on Debian - You say that 'Most of the vendors of Linux based apps that we have worked with are willing to provide support even with Debian'. Has Oracle given you such support? We've asked Oracle and the answer has been "no". In this case I am talking about the consulting call type of 'support' that our DBAs want to be able to get from Oracle.
R.e.: "Everything else that was proprietary came on a seperate ISO that wasn't part of the distribution."
All those I noted came directly from the RH ES distrubition. As you say, just do rpm -qi on the base installation of the full Redhat ES system.
"There aren't that many that aren't 'source redistributable free'. If they are required, to install another package, I can just build a dummy set. Either by putting in all white images, or doing something terribly clever like switching the red and blue bytes in the color scheme, and release "blue hat"....:-)"
Exactly. Somebody has to do this initial work. That is what I believe the people at University of Innsbruck are working on: http://www2.uibk.ac.at/zid/software/unix/linux/rhe l-rebuild-l.html
Naturally I would hope that even that relatively small amount of work can be done relatively few times. I've spoken with Redhat technical people and they seem to accept this approach as legitimate. However, somebody needs to bounce this approach off of legal@redhat.com. An approach like this certainly puts Redhat's customers in conflict with Redhat's corporate strategy - not a good situation.
However, the more important issue for me is that of getting patch support. Every time Redhat comes out with a security patch (Redhat is notorious for patching existing sources rather than building from later sources - a quite reasonable and conservative approach), I need to get such a patched binary RPM myself. Of course I can try building each such source, but why should all of us in this position have to continue to do that same work over and over again?
I believe it makes sense to come up with a small number (one?) of locations to distrubute such patches. One of course wonders how Redhat will feel about such sites...
I've considered using Redhat in a similar mode. I have only three systems that need to run Oracle. I could run Redhat Enterprise systems (likely ES for which I have one license already) on those boxes and something else (e.g. Redhat 'consumer') on the others.
Of course this is awkward as I would rather be running the same system on more boxes. Also, even my other systems are server 'class' systems where I want effective support. I don't need or want consulting help. I've never gotten that from Redhat. All I need are patches for security problems, etc. The 'support' term seems to have multiple interpretations.
The 'support' model for the Redhat consumer versions for me is broken. New rev.s every 6 months and patches only for a year? I won't trust a distribution until it's been out for 6 months. At that point if I switch to it I only get patch updates for 6 months before I need to switch systems again? I don't think so. How can you live with that thule?
For me the problem is deeper that just the patch support issue. One of the reasons I've been running Redhat recently is that it seems to have become the 'sweet spot' for open source OSs. What I mean by that is that if somebody is going to want to run software on my servers, it is usually configured and tested to run on Redhat. This has been because the Redhat OSs have been free and their patches have been kept effectively updated.
The latest marketing strategy by Redhat has broken that model. Sure, they have the right to try to stay in business at what I consider the bloated level they have reached. Still, they can't write off a change from many years patch support to their free OS's to one year max support as insignificant. They can't expect that beginning to charge $350/yr/box for only patch support on commodity hardware will not make their users have to make some very difficult choices.
Our people who run clusters, those who run workstations, and even those like me who run servers are all scrambling around looking for alternatives to Redhat - with the 12/31/03 deadline for patch support looming.
I believe a significant portion of the Open Source OS community, that part that has taken advantage of Redhat's support services (integration, patches) over these last 3-5 years, is now in crisis. What will emerge I'm not sure. I see numerous possible models:
1. Rebuild Redhat from source model, e.g. http://www2.uibk.ac.at/zid/software/unix/linux/rhe l-rebuild-l.html This approach of course must provide patch support - e.g. take Redhat's patches and compile them from sources. It also has to elimanate or replace the proprietary software in Redhat Enterprise (IBM, Netscape, OMRON, and Redhat) and deal with the numerous other licenses.
2. Get support for Redhat 7.3 (the current sweet spot) continued. Various projects are looking at this direction. Big projects with heavy software investments may be forced to use this model.
3. Find a new Open Source OS distribution that doesn't cost on a per box basis (where both the $ costs and the admin costs are prohibitive in many cases) and comes with adequate patch support. I think both FreeBSD and Debian are legitimate contenders in this space.
What will emerge I'm not sure, but 1/1/04 is coming up pretty darn quick. Each of the alternatives above in some sense puts Redhat in conflict with their customers. For a company that espouses (e.g. most recently at Linuxworld by the Redhat CEO Matthew Szulik) working together with their community, this seems to me a radical and somewhat hypocritical turn about.
(as noted elsewhere) people should be aware of the project at University of Innsbruck to make a version of Redhat Enterprise from source:
http://www2.uibk.ac.at/zid/software/unix/linux/r he l-rebuild-l.html
As important as the initial build is (including the removal or replacement of the proprietary licenses - especially the Redhat Logos), I believe it is at least as important to track the Redhat patches. People may argue that they can do "support" themselves (I have yet to get a call or effective communication through to Redhat), but things like security patch updates are certainly needed. This is a spot where I believe community effort would help.
No Linux distribution, including Redhat, is all GPL. Besides the GPL, BSD, freeware, "Freely Distributable", distributable, 'Public Domain', etc. licensed software there are dozens of other licenses. They include names like MIT, PHP, Apache, W3C, OpenLDAP, X Consortium, MPL, Artistic, etc.
Most seem to have an "open" or free flavor. However, to know one could compile them from source and be free of any Redhat intellectual property issues it seems to me would take some effort.
Beyond those that have a free flavor there are at least:
IBMJava2-JRE Commercial, netscape-common Proprietary, openjade Copyright, OMRON Software Co., and redhat-logos Copyright (C) 1999-2000 Red Hat, Inc. All rights reserved.
A note about that last - in any use of the Redhat packages - e.g. compiled from source - certainly the Redhat logos would have to be removed or replaced.
I don't think it's quite trivial to generate a complete integrated RPM set from Redhat sources. Of course in doing so one would also have to compile any patches from sources (e.g. SRPMs). I've spoke with a couple of Redhat people about this (not yet their legal department) and they seemed to think it was OK.
Anyone interested in this issue should know about the project at the University of innsbruck to recompile Redhat Enterprise from sources:
http://www2.uibk.ac.at/zid/software/unix/linux/rhe l-rebuild-l.html
Slashdot Mirror
Regarding:
_______________
-->My strategy generally is to use a file for swap rather than a partition, even in linux.
What I find curious is that you have a strategy. On what relevant experience do you base this strategy? 1 GB of disk space costs less than $0.50. Set up 3 GB of VM if it makes you feel good. The latte you drink while you set it up costs more than the extra disk space!
So go for it!!! Who cares what you do? Heck, give yourself 10x the RAM and see if it actually makes any difference!!! (it won't)
_______________
I have a strategy and I care. I have some 50+ rather individual servers to maintain including constant builds, upgrades, etc., etc. so even a small amount of additional administration overhead is significant (not the disk space which I agree isn't significant).
I prefer to use swap files rather than partitions on my Unix servers (Linux and FreeBSD almost entirely). For me the main difference is that I can have an initialization script (e.g. cfengine driven) set up and even "re-up" swap files automatically vs. setting up a swap partition at build time. My "kickstart" mechanisms aren't as carefree in terms of setting up and managing swap partitions. Since I can't recall the last time anything actually swapped on any of my servers (years ago and just before a crash anyway), I don't think swap makes much difference, so I optimize for the time I have to put into getting it into place - by dealing with it in an automated initialization script and keeping it out of the issues related to partitioning the disks.
R.e. "...the bits are GPLed, there is nothing RH can do to stop you from copying them."
I don't believe the above is true. Redhat has copyright on some of the distribution. E.g. the Redhat logos module. There are other non-GPL parts. Even at that GPL only applies to the source.
There are a number of projects working to essentially rebuild the Redhat Enterprise line without the Redhat copyrighted parts - depending on GPL to avoid legal confrontation with Redhat. I suggest looking into those efforts (e.g. http://www.caosity.org/) if anybody would like to avoid Redhat licensing constraints but still get the advantages of the Redhat integration. I also hope those in the open source community support this effort to exercise the GPL in its strongest test yet.
I'm a system administrator running numerous server systems for a national laboratory. We have observed over recent years that if we want to run open source software (e.g. developed at other laboratories, universities, by the open source community, etc.) then it has typically been developed and tested on Redhat Linux. This and the no cost nature of Redhat Linux until recently has made the choice of server OS an easy one.
Now with the licensing fees being charged by Redhat for your only effectively supported OS, your Enterprise line, I wonder where this "sweet spot" will shift or whether it will disappear altogether. Certainly most of the academic development will not be done on the Redhat Enterprise line. It's too early to say about development done in the open source community, but I would expect that to shift off of Redhat also. We can afford the license fees for now, but if the software development shifts we will have to also.
I realize Redhat was in a difficult spot financially. However, isn't there a danger that shifting and/or destroying that "sweet spot" will have an adverse effect on the Linux community and on Redhat?
When you rose to speak at the recent Linuxworld in San Francisco, I expected you to say something to the effect that "Times are tough and this is what we had to do to stay in business. We're sorry about the possible negative impact on the community." Instead you gave this rousing: Isn't open source wonderful?, We're all in this together, etc. presentation. That seemed a bit hypocrital to me. How did you justify such a presentation given the upcomming end of life for your consumer OS line?
The part I don't understand is how it "works out well for customers too". I work in the server group at NERSC: http://www.nersc.gov/
e l-rebuild-l.html) efforts to continue support for Redhat 7.3 and other options for our future Unix OS needs.
Our workstation group which has been supporting Redhat for the last few years for our staff is starting to panic looking for an alternative to Redhat after 1/04. They can't accept the limit to 1 year of support.
Our cluster folks (e.g. PDSF: http://pdsf.nersc.gov/ but there are others running Redhat) are really starting to sweat because they have such a huge installed software base (e.g. in the PSDF case in the accelerator community). Even if there was an alternative supported base for them beyond RH 7.3 they would have a difficult time switching (those library issues mentioned elsewhere), but without a supported alternative (read at least 2 years of patches - nobody here actually calls Redhat) they are unsure where to turn. I expect they may end up just continuing to support RH 7.3 themselves. However, that isn't really good for anybody.
Our server group (including me) has to have Oracle support for those systems where the DBAs need Oracle support (at least two system, perhaps three). We are fine paying Redhat for Enterprise licenses on those few systems. You might say that works out well for Redhat, and maybe us. However, what about my kickstart server? What about our testing sytems? What about our failover systems? All licensed for RH Enterprise? OK, I can buy that also - though the cost and administrative burden are getting uncomfortable. However, my big problem is that the original reason I choose Redhat was that it was the sweet spot. Since most everybody else that I cared about was developing on Redhat I could be confident that software I was given and asked to support would run there. Now that model is in question. I and others (this thread) are all looking for an alternative. That doesn't seem to me good for customers of Redhat. Others can of course differ.
It's fine to say "take a chillpill". I'll be happy to as soon as we have a plan in place for 1/04. Please make a suggestion for our workstation group, our cluster folks, and our server team. We are listening intently while following efforts to rebuild RH Enterprise from source (e.g. http://www2.uibk.ac.at/zid/software/unix/linux/rh
http://www.nersc.gov/~jed/
Redhat's new policy toward their 'consumer' OSs is to only provide patch support for 1 year. Since I don't trust a new release on my production servers until it has shaken for about 6 months, this means that I and you (I guess) would be replacing OSs every 6 months in order to keep getting patch support. Is that where you are going tomorrow (1/04) emacnabber?
The reality I believe is that Redhat doesn't know what sort of support they will continue to give for their consumer OSs. They seem to be thinking of them as beta's for the Open Source community. Do you want to run your Universities production services on betas?
I think the term 'support' is being used in multiple senses that may be causing confusion.
What many people are looking for in 'support' is simply patches for bugs and security problems. Even in that limited sense the RH 'consumer' versions (8, 9, 10...) no longer seem adequate for production use (e.g. workstations, clusters, even servers that don't need to run supported third part applications and don't need consulting support). The problem is that they have been cut down to one year of patch support. I won't start using an OS until it has been shaken out for at least 6 months. That would mean that with the Redhat consumer versions I would have to replace my OS every 6 months. I don't believe it's reasonable to treat my users that way.
Regarding Oracle on Debian - You say that 'Most of the vendors of Linux based apps that we have worked with are willing to provide support even with Debian'. Has Oracle given you such support? We've asked Oracle and the answer has been "no". In this case I am talking about the consulting call type of 'support' that our DBAs want to be able to get from Oracle.
R.e.: "Everything else that was proprietary came on a seperate ISO that wasn't part of the distribution."
:-)"
e l-rebuild-l.html
All those I noted came directly from the RH ES distrubition. As you say, just do rpm -qi on the base installation of the full Redhat ES system.
"There aren't that many that aren't 'source redistributable free'. If they are required, to install another package, I can just build a dummy set. Either by putting in all white images, or doing something terribly clever like switching the red and blue bytes in the color scheme, and release "blue hat"....
Exactly. Somebody has to do this initial work. That is what I believe the people at University of Innsbruck are working on: http://www2.uibk.ac.at/zid/software/unix/linux/rh
Naturally I would hope that even that relatively small amount of work can be done relatively few times. I've spoken with Redhat technical people and they seem to accept this approach as legitimate. However, somebody needs to bounce this approach off of legal@redhat.com. An approach like this certainly puts Redhat's customers in conflict with Redhat's corporate strategy - not a good situation.
However, the more important issue for me is that of getting patch support. Every time Redhat comes out with a security patch (Redhat is notorious for patching existing sources rather than building from later sources - a quite reasonable and conservative approach), I need to get such a patched binary RPM myself. Of course I can try building each such source, but why should all of us in this position have to continue to do that same work over and over again?
I believe it makes sense to come up with a small number (one?) of locations to distrubute such patches. One of course wonders how Redhat will feel about such sites...
I've considered using Redhat in a similar mode. I have only three systems that need to run Oracle. I could run Redhat Enterprise systems (likely ES for which I have one license already) on those boxes and something else (e.g. Redhat 'consumer') on the others.
e l-rebuild-l.html This approach of course must provide patch support - e.g. take Redhat's patches and compile them from sources. It also has to elimanate or replace the proprietary software in Redhat Enterprise (IBM, Netscape, OMRON, and Redhat) and deal with the numerous other licenses.
Of course this is awkward as I would rather be running the same system on more boxes. Also, even my other systems are server 'class' systems where I want effective support. I don't need or want consulting help. I've never gotten that from Redhat. All I need are patches for security problems, etc. The 'support' term seems to have multiple interpretations.
The 'support' model for the Redhat consumer versions for me is broken. New rev.s every 6 months and patches only for a year? I won't trust a distribution until it's been out for 6 months. At that point if I switch to it I only get patch updates for 6 months before I need to switch systems again? I don't think so. How can you live with that thule?
For me the problem is deeper that just the patch support issue. One of the reasons I've been running Redhat recently is that it seems to have become the 'sweet spot' for open source OSs. What I mean by that is that if somebody is going to want to run software on my servers, it is usually configured and tested to run on Redhat. This has been because the Redhat OSs have been free and their patches have been kept effectively updated.
The latest marketing strategy by Redhat has broken that model. Sure, they have the right to try to stay in business at what I consider the bloated level they have reached. Still, they can't write off a change from many years patch support to their free OS's to one year max support as insignificant. They can't expect that beginning to charge $350/yr/box for only patch support on commodity hardware will not make their users have to make some very difficult choices.
Our people who run clusters, those who run workstations, and even those like me who run servers are all scrambling around looking for alternatives to Redhat - with the 12/31/03 deadline for patch support looming.
I believe a significant portion of the Open Source OS community, that part that has taken advantage of Redhat's support services (integration, patches) over these last 3-5 years, is now in crisis. What will emerge I'm not sure. I see numerous possible models:
1. Rebuild Redhat from source model, e.g. http://www2.uibk.ac.at/zid/software/unix/linux/rh
2. Get support for Redhat 7.3 (the current sweet spot) continued. Various projects are looking at this direction. Big projects with heavy software investments may be forced to use this model.
3. Find a new Open Source OS distribution that doesn't cost on a per box basis (where both the $ costs and the admin costs are prohibitive in many cases) and comes with adequate patch support. I think both FreeBSD and Debian are legitimate contenders in this space.
What will emerge I'm not sure, but 1/1/04 is coming up pretty darn quick. Each of the alternatives above in some sense puts Redhat in conflict with their customers. For a company that espouses (e.g. most recently at Linuxworld by the Redhat CEO Matthew Szulik) working together with their community, this seems to me a radical and somewhat hypocritical turn about.
(as noted elsewhere) people should be aware of the project at University of Innsbruck to make a version of Redhat Enterprise from source:
r he l-rebuild-l.html
http://www2.uibk.ac.at/zid/software/unix/linux/
As important as the initial build is (including the removal or replacement of the proprietary licenses - especially the Redhat Logos), I believe it is at least as important to track the Redhat patches. People may argue that they can do "support" themselves (I have yet to get a call or effective communication through to Redhat), but things like security patch updates are certainly needed. This is a spot where I believe community effort would help.
No Linux distribution, including Redhat, is all GPL. Besides the GPL, BSD, freeware, "Freely Distributable", distributable, 'Public Domain', etc. licensed software there are dozens of other licenses. They include names like MIT, PHP, Apache, W3C, OpenLDAP, X Consortium, MPL, Artistic, etc. Most seem to have an "open" or free flavor. However, to know one could compile them from source and be free of any Redhat intellectual property issues it seems to me would take some effort. Beyond those that have a free flavor there are at least: IBMJava2-JRE Commercial, netscape-common Proprietary, openjade Copyright, OMRON Software Co., and redhat-logos Copyright (C) 1999-2000 Red Hat, Inc. All rights reserved. A note about that last - in any use of the Redhat packages - e.g. compiled from source - certainly the Redhat logos would have to be removed or replaced. I don't think it's quite trivial to generate a complete integrated RPM set from Redhat sources. Of course in doing so one would also have to compile any patches from sources (e.g. SRPMs). I've spoke with a couple of Redhat people about this (not yet their legal department) and they seemed to think it was OK. Anyone interested in this issue should know about the project at the University of innsbruck to recompile Redhat Enterprise from sources: http://www2.uibk.ac.at/zid/software/unix/linux/rhe l-rebuild-l.html