Hans Deragon wrote:
However, apt has synaptic available as GUI. I am not aware of a GUI for yum. For a desktop machine, a GUI is a must.
It's deceptive to think just about end-user oriented feature sets, when deciding on future development paths. One could argue that yum has a technical advantage in terms of long term development inside rhl, because its using the same python bindings that the current redhat tools use to interact with the rpmdb. There is a definite development advantage with code reuse. So if you want the redhat tools to be repository aware, make use of the technology that fits best with the redhat tools.
One could also argue that the redhat tools should be pitched, but anyone arguing that would have to be pretty persuasive, or would have to have really good timing to change the momentum surrounding the development of the redhat tools (like anaconda and r-c-p).
The long term solution is of course bribing the repository technology developers into sitting down over some pizza,beer and KK doughnuts and hashing out a repository metadata standard so repos are as tool neutral as possible.
But there is a deeper issue in your comment. For a nontechnical user's desktop machine a GUI is a must...that is surely a truism. But now you have to ask yourself the question...what is redhat's timeline for seriously targeting non technical home desktops? I personally don't think this little hiccup about which choice of repo technology gets bolted into rhl is going to matter on the same timescale of other relevant issues which would make linux a prefered solution in the mainstream nontechnical desktop market.
--jef"Jef to Magic8Ball: Is the next release going to target desktop users like Jef's mom Magic8ball to Jef: Outlook not so good"spaleta
Jef Spaleta wrote:
Hans Deragon wrote:
However, apt has synaptic available as GUI. I am not aware of a GUI for yum. For a desktop machine, a GUI is a must.
It's deceptive to think just about end-user oriented feature sets, when deciding on future development paths. One could argue that yum has a technical advantage in terms of long term development inside rhl, because its using the same python bindings that the current redhat ...
I wouldn't go so far as to say that it is a must... but synaptic is a tremendous advance over dselect. The function that they both preform, which is a must, is to allow you to find a package without knowing exactly what it's name is in advance. (If you do, then apt-get is a lot faster. A LOT!)
Jef Spaleta wrote:
Hans Deragon wrote:
However, apt has synaptic available as GUI. I am not aware of a GUI for yum. For a desktop machine, a GUI is a must.
It's deceptive to think just about end-user oriented feature sets, when deciding on future development paths. One could argue that yum has a technical advantage in terms of long term development inside rhl, because its using the same python bindings that the current redhat tools use to interact with the rpmdb. There is a definite development advantage with code reuse. So if you want the redhat tools to be repository aware, make use of the technology that fits best with the redhat tools.
apt/synaptic is already developped by debian users. It is code already reused from another distribution. But you have a point to some extent.
One could also argue that the redhat tools should be pitched, but anyone arguing that would have to be pretty persuasive, or would have to have really good timing to change the momentum surrounding the development of the redhat tools (like anaconda and r-c-p).
The long term solution is of course bribing the repository technology developers into sitting down over some pizza,beer and KK doughnuts and hashing out a repository metadata standard so repos are as tool neutral as possible.
But in the short term, yum is now part of severn. Since it will be the default with the system, it will eventually become the standard. As soon as RH offers the chance for people to create repositories, the number of public repositories will explode. By the time we decide for a standard, yum repositories would have become the defacto standard.
Unless, we remove it and do not include anything except up2date for the next release...
But there is a deeper issue in your comment. For a nontechnical user's desktop machine a GUI is a must...that is surely a truism. But now you have to ask yourself the question...what is redhat's timeline for seriously targeting non technical home desktops? I personally don't think this little hiccup about which choice of repo technology gets bolted into rhl is going to matter on the same timescale of other relevant issues which would make linux a prefered solution in the mainstream nontechnical desktop market.
Red Hat developped up2date-gnome. If they spent the effort for creating a GUI for RHN, then it means that they identified the need for a GUI to install packages. Red Hat targets semi-technical environment, not only tech-savy desktop users. Business men, lawyers, accountants, offices could use RHL. Secretaries would want to install software, but not with a command line.
Best regards, Hans Deragon -- Consultant en informatique/Software Consultant Deragon Informatique inc. Open source: http://www.deragon.biz http://swtmvcwrapper.sourceforge.net mailto://hans@deragon.biz http://autopoweroff.sourceforge.net
On Tuesday 12 August 2003 09:41, Hans Deragon wrote:
Red Hat developped up2date-gnome. If they spent the effort for creating a GUI for RHN, then it means that they identified the need for a GUI to install packages. Red Hat targets semi-technical environment, not only tech-savy desktop users. Business men, lawyers, accountants, offices could use RHL. Secretaries would want to install software, but not with a command line.
In a real corporate environment, Secretaries don't have the access required to install software. Giving a secretary root on a box is just insane. Corporate images are developed, deployed and only updated when there is a true business need. Allowing users to install software willy nilly just causes huge headaches, leads to virus infection and system instability. While there is some argument for having a nice gui frontend to installing software, it doesn't quite click in the real corporate environment.
But in the short term, yum is now part of severn. Since it will be the default with the system, it will eventually become the standard. As soon as RH offers the chance for people to create repositories, the number of public repositories will explode. By the time we decide for a standard, yum repositories would have become the defacto standard.
This is one of the exact reasons why we've started figuring out a standard repository format for all pkg tools. I don't care if yum is a 'standard' or not. I'd like it to be reasonable for me to keep on developing yum w/o having to mess about with 4 different repository formats on a mirror. From what I can tell the ximian, red hat and apt people agree. So we're working on consensus to solve our problems together.
It probably won't be available for severn but I'd like for it be available before the beta for the version after cambridge.
-sv
In a real corporate environment, Secretaries don't have the access required to install software. Giving a secretary root on a box is just
I wish 8)
insane. Corporate images are developed, deployed and only updated when there is a true business need. Allowing users to install software willy nilly just causes huge headaches, leads to virus infection and system instability. While there is some argument for having a nice gui frontend to installing software, it doesn't quite click in the real corporate environment.
Over 90% of companies are *small business*. Most of them either use consultants or have relatively lightly trained staff for whom making the computers work is often just part of their job and in many cases not part of any official job description at all.
Its also not just a case of "root" either, on a really locked down system with something like SELinux or RSBAC installed you not only don't give people root you make it impossible for anything to create executables or any scripts for shells to be run unless they have been "blessed" by some sysadmin controlled tool. That turns "I got this cool screensaver.." into "I got this cool screensaver but it wont run" which allows the sysadmin to explain to the staff member why not and why that wont be changing.
These admins referenced in the text would never know how to -- or why to use SE Linux. The sugestion that, most administrators out there are very lightly skilled, is true. This has held true for all of my years as a small business consultant. The more GUI tools that RedHat can provide the better for them and their clients.
./SLS
On Tue, 12 Aug 2003, Alan Cox wrote:
In a real corporate environment, Secretaries don't have the access required to install software. Giving a secretary root on a box is just
I wish 8)
insane. Corporate images are developed, deployed and only updated when there is a true business need. Allowing users to install software willy nilly just causes huge headaches, leads to virus infection and system instability. While there is some argument for having a nice gui frontend to installing software, it doesn't quite click in the real corporate environment.
Over 90% of companies are *small business*. Most of them either use consultants or have relatively lightly trained staff for whom making the computers work is often just part of their job and in many cases not part of any official job description at all.
Its also not just a case of "root" either, on a really locked down system with something like SELinux or RSBAC installed you not only don't give people root you make it impossible for anything to create executables or any scripts for shells to be run unless they have been "blessed" by some sysadmin controlled tool. That turns "I got this cool screensaver.." into "I got this cool screensaver but it wont run" which allows the sysadmin to explain to the staff member why not and why that wont be changing.
-- Rhl-beta-list mailing list Rhl-beta-list@redhat.com http://www.redhat.com/mailman/listinfo/rhl-beta-list
On Tuesday 12 August 2003 13:53, Stephan Schutter wrote:
The more GUI tools that RedHat can provide the better for them and their clients.
Novelle seems to want to take this apporoach with their iteration of Linux http://newsforge.com/article.pl?sid=03/08/09/1329244
As long a there are CLI tools as well, it shoudl all work out.
On Tuesday 12 August 2003 10:10, Alan Cox wrote:
Over 90% of companies are *small business*. Most of them either use consultants or have relatively lightly trained staff for whom making the computers work is often just part of their job and in many cases not part of any official job description at all.
Funny to hear this from an @redhat person, especially when almost all of these *small businesses* will be unable to afford RHEL products and will be forced to look elsewhere for their Linux fix.
Seems that the focus of Red Hat is getting blurred again. Are you focusing on providing a product for the big businesses, or for the general masses? Can't really please both IMHO.
On August 12, 2003 12:59 pm, Jesse Keating hosting@j2solutions.net wrote:
Giving a secretary root on a box is just insane. Corporate images are developed, deployed and only updated when there is a true business need. Allowing users to install software willy nilly just causes huge headaches, leads to virus infection and system instability. While there is some argument for having a nice gui frontend to installing software, it doesn't quite click in the real corporate environment.
True. And though I would still vote for a more user friendly interface, I'm sure that most linux users would NOT want linux to become "Microsoft Windows", where, if something goes wrong, the user hasn't a clue in hell what to do, and winds up reinstalling and rebooting his/her system a nauseam.
I strongly feel that is is WORTH the EFFORT to learn linux, and learn the underpinnings, so that one knows what to do in case of hardware failure, or the (more frequent) human failure...
Elton ;-)
Agreed. Both are needed... CLI for Enterprise and GUI for Others...
On Tue, 12 Aug 2003, HoytDuff wrote:
On Tuesday 12 August 2003 13:53, Stephan Schutter wrote:
The more GUI tools that RedHat can provide the better for them and their clients.
Novelle seems to want to take this apporoach with their iteration of Linux http://newsforge.com/article.pl?sid=03/08/09/1329244
As long a there are CLI tools as well, it shoudl all work out.
Well, I disagree... for the 90% there is RHL 9.0 etc. and for 10% there is the enterprise solution. In an enterprise allmost all the cost is project related and management related; perhaps less than 10% is related to hardwre and software. A couple of k's is nothing to a multi milion dollar project. I work for a large corp. and there are no projects smaller than several milion dollars. What does matter in my environment is the promises (read support) that comes with the vendor of the software.
Please keep in mind that small businesses need to see an easy migration path from MS Small Business Server 2000/2003 (SQL, Exchange, Backoffice etc.) and they care not much for CLI or scriptability. To them manageability = a GUI way to do stuff. CLI and Scripting = expensive contractors.
The exact oposite is true of my world.
RedHat provides 2 lines of product for this reason. They both have their short comings, but show a lot of promise... not enough GUI on one hand and dificult to integrate with the existing Win32 env. and AD on the other.
On Tue, 12 Aug 2003, Jesse Keating wrote:
On Tuesday 12 August 2003 10:10, Alan Cox wrote:
Over 90% of companies are *small business*. Most of them either use consultants or have relatively lightly trained staff for whom making the computers work is often just part of their job and in many cases not part of any official job description at all.
Funny to hear this from an @redhat person, especially when almost all of these *small businesses* will be unable to afford RHEL products and will be forced to look elsewhere for their Linux fix.
Seems that the focus of Red Hat is getting blurred again. Are you focusing on providing a product for the big businesses, or for the general masses? Can't really please both IMHO.
On Tue, 12 Aug 2003, Elton Woo wrote: This is true for administrators but not home users. The consumer market will give you money if you give them what they want, else, they will give you nothing. I can tell you that they do not want to learn Linux... I do; I am an admin and an enthusiast.
On August 12, 2003 12:59 pm, Jesse Keating hosting@j2solutions.net wrote:
Giving a secretary root on a box is just insane. Corporate images are developed, deployed and only updated when there is a true business need. Allowing users to install software willy nilly just causes huge headaches, leads to virus infection and system instability. While there is some argument for having a nice gui frontend to installing software, it doesn't quite click in the real corporate environment.
True. And though I would still vote for a more user friendly interface, I'm sure that most linux users would NOT want linux to become "Microsoft Windows", where, if something goes wrong, the user hasn't a clue in hell what to do, and winds up reinstalling and rebooting his/her system a nauseam.
I strongly feel that is is WORTH the EFFORT to learn linux, and learn the underpinnings, so that one knows what to do in case of hardware failure, or the (more frequent) human failure...
Elton ;-)
On Tuesday 12 August 2003 14:33, Stephan Schutter wrote:
Well, I disagree... for the 90% there is RHL 9.0 etc. and for 10% there is the enterprise solution. In an enterprise allmost all the cost is project related and management related; perhaps less than 10% is related to hardwre and software. A couple of k's is nothing to a multi milion dollar project. I work for a large corp. and there are no projects smaller than several milion dollars. What does matter in my environment is the promises (read support) that comes with the vendor of the software.
The problem is, the company I work for caters to these smaller companies, and provides systems w/ Linux pre-installed and all the support they need to get up and running. It's becoming increasingly harder and harder to provide this service based on Red Hat Linux. As Red Hat strips more and more server quality stuff out of the distro (tunable kernel VM, ipvs, etc...) and as their business take a stance that makes it impossible to OEM the RHL product it seems to me that unless you are a multimillion dollar business, you don't matter to RH, likewise if you don't sell products to multimillion dollar businesses then you as a provider don't matter to RH. It's getting to the point that as a company, we'll have to switch to some lower quality product to be able to have the relationship necessary to OEM their product and it just stinks. </rant>
On Tue, Aug 12, 2003 at 01:07:22PM -0400, seth vidal wrote:
But in the short term, yum is now part of severn. Since it will be the default with the system, it will eventually become the standard. As soon as RH offers the chance for people to create repositories, the number of public repositories will explode. By the time we decide for a standard, yum repositories would have become the defacto standard.
This is one of the exact reasons why we've started figuring out a standard repository format for all pkg tools. I don't care if yum is a 'standard' or not. I'd like it to be reasonable for me to keep on developing yum w/o having to mess about with 4 different repository formats on a mirror. From what I can tell the ximian, red hat and apt people agree. So we're working on consensus to solve our problems together.
Standard are best done as data format or protocols. Standardizing on API is dangerous. Standardizing on tools is just bad practice >:-> Seth approach is the Right one IMHO, the one ensuring interoperability and then tools can then compete for being the best from an user need point of view and in an open field.
Daniel
Le mar 12/08/2003 à 21:25, Jesse Keating a écrit :
On Tuesday 12 August 2003 10:10, Alan Cox wrote:
Over 90% of companies are *small business*. Most of them either use consultants or have relatively lightly trained staff for whom making the computers work is often just part of their job and in many cases not part of any official job description at all.
Funny to hear this from an @redhat person, especially when almost all of these *small businesses* will be unable to afford RHEL products and will be forced to look elsewhere for their Linux fix.
Server RHEL for small business $349/year http://www.redhat.com/software/rhel/es/ Workstation RHEL for small business $179/year http://www.redhat.com/software/rhel/ws/
And you get 5 years support : http://www.redhat.com/apps/support/errata/rhlas_errata_policy.html
But you can use RHL for free with one year support.
Seems that the focus of Red Hat is getting blurred again. Are you focusing on providing a product for the big businesses, or for the general masses? Can't really please both IMHO.
On Tuesday 12 August 2003 17:46, Féliciano Matias uttered:
http://www.redhat.com/software/rhel/es/ Workstation RHEL for small business $179/year http://www.redhat.com/software/rhel/ws/
And you get 5 years support : http://www.redhat.com/apps/support/errata/rhlas_errata_policy.html
But you can use RHL for free with one year support.
This doesn't work for us, since our company's "gimmik" is that we provide the support for the end user. Also, many of our customers require functionality of AS, but can't afford the price. There seems to be way too much stripped out of ES to make it a viable platform.
RHL will no longer be a supported OS.
On Wed, 2003-08-13 at 10:34, Jesse Keating wrote:
On Tuesday 12 August 2003 17:46, Féliciano Matias uttered:
http://www.redhat.com/software/rhel/es/ Workstation RHEL for small business $179/year http://www.redhat.com/software/rhel/ws/
And you get 5 years support : http://www.redhat.com/apps/support/errata/rhlas_errata_policy.html
But you can use RHL for free with one year support.
This doesn't work for us, since our company's "gimmik" is that we provide the support for the end user. Also, many of our customers require functionality of AS, but can't afford the price. There seems to be way too much stripped out of ES to make it a viable platform.
The AS and ES package sets will be identical in the next release (aside from redhat-release etc.). See: http://www.redhat.com/archives/taroon-beta-list/2003-July/msg00003.html
Tim
On Wednesday 13 August 2003 08:18, Tim Powers wrote:
The AS and ES package sets will be identical in the next release (aside from redhat-release etc.). See: http://www.redhat.com/archives/taroon-beta-list/2003-July/msg00003.ht ml
Ah, ok. It wasn't clear from the release, just seemed like it would be this way for Beta 1, not necessarily the release. This does change some things and I'll bring it up to my management. Thanks!
On Tue, 2003-08-12 at 15:36, Jesse Keating wrote:
On Tuesday 12 August 2003 14:33, Stephan Schutter wrote:
Well, I disagree... for the 90% there is RHL 9.0 etc. and for 10% there is the enterprise solution. In an enterprise allmost all the
The problem is, the company I work for caters to these smaller companies, and provides systems w/ Linux pre-installed and all the support they need to get up and running. It's becoming increasingly harder and harder to provide this service based on Red Hat Linux. As Red Hat strips more and more server quality stuff out of the distro (tunable kernel VM, ipvs, etc...) and as their business take a stance that makes it impossible to OEM the RHL product it seems to me that unless you are a multimillion dollar business, you don't matter to RH, likewise if you don't sell products to multimillion dollar businesses then you as a provider don't matter to RH. It's getting to the point that as a company, we'll have to switch to some lower quality product to be able to have the relationship necessary to OEM their product and it just stinks.
</rant>
For some reason, I think you answered your own rant. You feel like you are having to make a choice of whether to make a lower quality product (w/o Red Hat) for small businesses to make ends meet. I doubt very much that Red Hat is in any different position. From what I can infer they have aimed for a higher quality product for people who will pay for it, and a community product to try and meet the needs of people who wont pay for it.
On Wednesday 13 August 2003 10:01, Stephen Smoogen wrote:
For some reason, I think you answered your own rant. You feel like you are having to make a choice of whether to make a lower quality product (w/o Red Hat) for small businesses to make ends meet. I doubt very much that Red Hat is in any different position. From what I can infer they have aimed for a higher quality product for people who will pay for it, and a community product to try and meet the needs of people who wont pay for it.
A community project is one thing, but when what goes into the community project is dictated by marketing to ensure that the community project won't compete in any way with the "higher quality product" there seems to be problems. Requests for Opteron support, ipvs support and other such things in the community project get denied because these types of things are an "enterprise" level technology, and thus you _have_ to use RHEL in order to get them. It seems that more and more server software will be removed from RHLP in order to "not compete" with RHEL, making RHLP a nonviable platform for smaller businesses who require server technology, but can't afford the AS or even ES premium. $370~ per system, per year is a very heafty price tag for a small business, especially when one of the "selling points" of Linux was that of lower costs....
won't compete in any way with the "higher quality product" there seems to be problems. Requests for Opteron support, ipvs support and other such things in the community project get denied because these types of
Actually opteron support is one thing most of us are expecting will appear in the community RHLP space pretty rapidly.
RHEL in order to get them. It seems that more and more server software will be removed from RHLP in order to "not compete" with RHEL, making RHLP a nonviable platform for smaller businesses who require server
There are ten children in a playground with a GPL'd ball, one of them storms off taking his ball with him. Because its a GPL'd ball the other kids all have one too.
One of the major goals of RHLP is to get closer to base - which means the 2.6 kernel tree has ipvs in base. The update tool can also pull from third party repositories of your choice.
RHEL is about quality Red Hat support, testing, slow rates of change and errata that are just minimal tested fixes. RHLP is about being close to the community releases, tracking new releases when they are available and getting the latest and greatest out there, while trying to ensure it actually works.
Some of the package choices are down to deadlines, others to maintainability and - much a relic from the older setup, supportability.
Alan
On Wednesday 13 August 2003 10:58, Alan Cox wrote:
One of the major goals of RHLP is to get closer to base - which means the 2.6 kernel tree has ipvs in base. The update tool can also pull from third party repositories of your choice.
RHEL is about quality Red Hat support, testing, slow rates of change and errata that are just minimal tested fixes. RHLP is about being close to the community releases, tracking new releases when they are available and getting the latest and greatest out there, while trying to ensure it actually works.
Some of the package choices are down to deadlines, others to maintainability and - much a relic from the older setup, supportability.
If this is actually true, great, but I've already been told that things like the Opteron support would not be included by Red Hat because it would compete w/ the RHEL product, and I fear that future software will get the same treatment. I guess time will tell, but it's hard to express that to the powers that be.
On Wed, 13 Aug 2003, Jesse Keating wrote:
A community project is one thing, but when what goes into the community project is dictated by marketing to ensure that the community project won't compete in any way with the "higher quality product" there seems to be problems. Requests for Opteron support, ipvs support and other such things in the community project get denied because these types of things are an "enterprise" level technology,
That is simply not true. Some of these features are not in Red Hat's repository because we haven't gotten the time to integrate them.
Nobody is stopping you from integrating these features yourself. People can point their up2date at your apt/yum repository and use the packages you are making available.
Lets face it, Red Hat is a company with finite resources and the wishlist of all Linux users together is close to infinite [1]. What is needed isn't Red Hat doubling the amount of work done, but users getting the opportunity to do part of the work themselves, together.
This model has worked very well for the development of open source programs, so I (personally) expect it to also work for a linux distribution. The success of freshrpms and fedora is certainly suggesting that the model works...
Rik van Riel [0] The more things software does "almost right", the larger the wishlist grows. Eg. when software does 10 things "almost right" and gets fixed to do all of them right, you end up with a piece of software that does 100 things "almost right" and a wish list that is 10 times as big as it used to be. Because of this I tend to view any kind of software wishlist as infinite ;)
Jesse Keating said:
On Tuesday 12 August 2003 17:46, Féliciano Matias uttered:
http://www.redhat.com/software/rhel/es/ Workstation RHEL for small business $179/year http://www.redhat.com/software/rhel/ws/
And you get 5 years support : http://www.redhat.com/apps/support/errata/rhlas_errata_policy.html
But you can use RHL for free with one year support.
This doesn't work for us, since our company's "gimmik" is that we provide the support for the end user.
If you provide support, what does it matter if Red Hat provides support or not?
Also, many of our customers require functionality of AS, but can't afford the price. There seems to be way too much stripped out of ES to make it a viable platform.
Any company that "needs" Cluster support doesn't qualify as a "small business" in my book.
RHL will no longer be a supported OS.
From everything I've seen, the RHLP we get errata for at least one year.
Now if you are complaining about not having a SLA, see the first point.
That is simply not true. Some of these features are not in Red Hat's repository because we haven't gotten the time to integrate them.
Nobody is stopping you from integrating these features yourself. People can point their up2date at your apt/yum repository and use the packages you are making available.
Lets face it, Red Hat is a company with finite resources and the wishlist of all Linux users together is close to infinite [1]. What is needed isn't Red Hat doubling the amount of work done, but users getting the opportunity to do part of the work themselves, together.
Then in this vein there needs to be a change in the trademark policy OR RHLP needs to have the red hat branding stripped from it so others can put it on servers/systems they sell w/o having to worry when the lawyers will come for them.
I'd recommend that all of the red hat log and artwork and other things that are trademarked be extracted to separate packages(this includes all of the branding in anaconda) so people like jesse can safely deploy it on servers they sell w/o the risk of being sued.
-sv
On Wed, Aug 13, 2003 at 03:46:31PM -0400, seth vidal wrote:
Then in this vein there needs to be a change in the trademark policy OR RHLP needs to have the red hat branding stripped from it so others can put it on servers/systems they sell w/o having to worry when the lawyers will come for them.
I'd recommend that all of the red hat log and artwork and other things that are trademarked be extracted to separate packages(this includes all of the branding in anaconda) so people like jesse can safely deploy it on servers they sell w/o the risk of being sued.
This is supposed to be true already; trademarks should be either in redhat-logos or anaconda-images, not in any other package. Replacing those could be made easier by introducing some standard replacement packages.
I would agree that the trademark policy probably needs revisiting for the project.
Havoc
This is supposed to be true already; trademarks should be either in redhat-logos or anaconda-images, not in any other package. Replacing those could be made easier by introducing some standard replacement packages.
Well - it seems to me that the trademark policy requires removing any place it says 'red hat'
I thought that was in a lot more places than just the images - especially for the text installer.
I would agree that the trademark policy probably needs revisiting for the project.
who should we talk to about getting this re-addressed?
-sv
On Wed, 2003-08-13 at 17:43, Alan Cox wrote:
I would agree that the trademark policy probably needs revisiting for the project.
who should we talk to about getting this re-addressed?
We know 8)
Should this be followed with a 'neener neener neener'? ;)
-sv
Then in this vein there needs to be a change in the trademark policy OR RHLP needs to have the red hat branding stripped from it so others can put it on servers/systems they sell w/o having to worry when the lawyers will come for them.
You can strip it yourself. Its been made reasonably easy to do. There is a good reason for keeping some kind of RH branding for RHLP base - amongst other things so people know they are getting RHLP not "Seth's hacks".
Exactly how all that fits trademark policies is something we are still trying to finalize but its non trivial to do right .
You can strip it yourself. Its been made reasonably easy to do. There is a good reason for keeping some kind of RH branding for RHLP base - amongst other things so people know they are getting RHLP not "Seth's hacks".
This sounds like an argument against the ability to modify a program and have it keep the same name under the gpl.
Exactly how all that fits trademark policies is something we are still trying to finalize but its non trivial to do right .
ok - I'll be interested to hear the outcome.
thanks, -sv
On 13 Aug 2003, seth vidal wrote:
Exactly how all that fits trademark policies is something we are still trying to finalize but its non trivial to do right .
ok - I'll be interested to hear the outcome.
Personally I think it is important that it will be useful for other companies to help developing the project. The more people help out, the more useful the distribution will be.
On Wed, 2003-08-13 at 18:06, Rik van Riel wrote:
On 13 Aug 2003, seth vidal wrote:
Exactly how all that fits trademark policies is something we are still trying to finalize but its non trivial to do right .
ok - I'll be interested to hear the outcome.
Personally I think it is important that it will be useful for other companies to help developing the project. The more people help out, the more useful the distribution will be.
Well I'm thinking more along the lines of s/companies/universities/ but take it as you will.
-sv
On Wed, 13 Aug 2003, Alan Cox wrote:
Then in this vein there needs to be a change in the trademark policy OR RHLP needs to have the red hat branding stripped from it so others can put it on servers/systems they sell w/o having to worry when the lawyers will come for them.
You can strip it yourself. Its been made reasonably easy to do. There is a good reason for keeping some kind of RH branding for RHLP base - amongst other things so people know they are getting RHLP not "Seth's hacks".
And what's wrong with Seth's Hacks (-;
...james
Le mer 13/08/2003 à 16:34, Jesse Keating a écrit :
On Tuesday 12 August 2003 17:46, Féliciano Matias uttered:
http://www.redhat.com/software/rhel/es/ Workstation RHEL for small business $179/year http://www.redhat.com/software/rhel/ws/
And you get 5 years support : http://www.redhat.com/apps/support/errata/rhlas_errata_policy.html
But you can use RHL for free with one year support.
This doesn't work for us, since our company's "gimmik" is that we provide the support for the end user. Also, many of our customers require functionality of AS, but can't afford the price. There seems to be way too much stripped out of ES to make it a viable platform.
RHL will no longer be a supported OS.
one year only.
You can buy 1 RHEL and install it in all yours computers. Next install yum in each. Fetch src.rpm errata from ftp.redhat.com site and rebuild i386.rpm packages. Create a yum repository with those packages.
But it's not courteous in relation with RedHat.
On Wednesday 13 August 2003 19:54, Féliciano Matias wrote:
one year only.
Depends on what you mean by support. By support, I mean the ability for my company to call up Red Hat, say we have a problem w/ package foo, it's causing bar, and get some help to work around and/or fix package foo. RHLP will _not_ have any support options, be it email, web, or phone. Period. This has already been stated.
The "trick" you mention w/ purchasing one and installing many is not only shadey, but doesn't work when we have plenty of customers who buy only one system, or two. The cost doesn't even out.
On Wed, 13 Aug 2003 10:13:42 -0700, you wrote:
A community project is one thing, but when what goes into the community project is dictated by marketing to ensure that the community project won't compete in any way with the "higher quality product" there seems to be problems. Requests for Opteron support, ipvs support and other such things in the community project get denied because these types of things are an "enterprise" level technology, and thus you _have_ to use RHEL in order to get them. It seems that more and more server software
I think we need to remember that the Cambridge and Cambridge++ releases, while part of the new Red Hat Linux Project, will not be the first "community" releases (in that the content of them is still entirely Red Hat decided).
It will be the following release (guessing around April 2004) that will be the first community release where the community will have had the ability to include packages maintained by the community, and for that matter include non-IA32 architectures maintained by the community like AMD64 if the community decides to support them.
"seth" == seth vidal skvidal@phy.duke.edu writes:
This is supposed to be true already; trademarks should be either in redhat-logos or anaconda-images, not in any other package. Replacing those could be made easier by introducing some standard replacement packages.
seth> Well - it seems to me that the trademark policy requires removing any seth> place it says 'red hat'
Not necessarily -- that would imply that nobody could refer to our company as "Red Hat", for example. The use to which the words comprising a trademark are put also has a bearing on the matter. Otherwise, there are companies producing feed and irrigation equipment (iirc) that would be knocking on our door, as their use of the words "Red Hat" no doubt predate ours... :-)
Ed
On Thu, 2003-08-14 at 12:30, Edward C. Bailey wrote:
"seth" == seth vidal skvidal@phy.duke.edu writes:
This is supposed to be true already; trademarks should be either in redhat-logos or anaconda-images, not in any other package. Replacing those could be made easier by introducing some standard replacement packages.
seth> Well - it seems to me that the trademark policy requires removing any seth> place it says 'red hat'
Not necessarily -- that would imply that nobody could refer to our company as "Red Hat", for example. The use to which the words comprising a trademark are put also has a bearing on the matter. Otherwise, there are companies producing feed and irrigation equipment (iirc) that would be knocking on our door, as their use of the words "Red Hat" no doubt predate ours... :-)
No it doesn't - I don't mean anyplace - but for example - if anaconda refers to red hat linux as what you are installing that would seem to fall under the trademark constraints.
-sv
On Wed, 2003-08-13 at 08:34, Jesse Keating wrote:
On Tuesday 12 August 2003 17:46, Féliciano Matias uttered:
http://www.redhat.com/software/rhel/es/ Workstation RHEL for small business $179/year http://www.redhat.com/software/rhel/ws/
And you get 5 years support : http://www.redhat.com/apps/support/errata/rhlas_errata_policy.html
But you can use RHL for free with one year support.
This doesn't work for us, since our company's "gimmik" is that we provide the support for the end user. Also, many of our customers require functionality of AS, but can't afford the price. There seems to be way too much stripped out of ES to make it a viable platform.
If *you* are doing the support, why pay for RH support? Why not take the publicly available SRPMs for AS, and build it yourself? Then install that and provide the support you would otherwise provide.
Depending on *which* functionality in AS you need, this should work quite well for you.
seth vidal (skvidal@phy.duke.edu) said:
No it doesn't - I don't mean anyplace - but for example - if anaconda refers to red hat linux as what you are installing that would seem to fall under the trademark constraints.
All the product name stuff is extracted out of anaconda source itself.
Bill
On Thu, 2003-08-14 at 14:30, Bill Nottingham wrote:
seth vidal (skvidal@phy.duke.edu) said:
No it doesn't - I don't mean anyplace - but for example - if anaconda refers to red hat linux as what you are installing that would seem to fall under the trademark constraints.
All the product name stuff is extracted out of anaconda source itself.
boot disks too?
-sv
"seth" == seth vidal skvidal@phy.duke.edu writes:
... seth> Well - it seems to me that the trademark policy requires removing any seth> place it says 'red hat' ... seth> No it doesn't - I don't mean anyplace - but for example - if anaconda seth> refers to red hat linux as what you are installing that would seem to seth> fall under the trademark constraints.
Ah, so "any place" does not mean "anyplace". I see... :-)
That said, your example is correct; I thought you were talking about things like man pages by Red Hatters, and containing "Red Hat, Inc." in them, or even mentions of how some random feature changed with Red Hat Linux 6.1 or something similar...
Ed
seth vidal (skvidal@phy.duke.edu) said:
On Thu, 2003-08-14 at 14:30, Bill Nottingham wrote:
seth vidal (skvidal@phy.duke.edu) said:
No it doesn't - I don't mean anyplace - but for example - if anaconda refers to red hat linux as what you are installing that would seem to fall under the trademark constraints.
All the product name stuff is extracted out of anaconda source itself.
boot disks too?
It's on the boot disks, yes. Product name is set at tree composition time, unless I forgot something.
Bill
On Thursday 14 August 2003 10:45, Bill Anderson wrote:
If *you* are doing the support, why pay for RH support? Why not take the publicly available SRPMs for AS, and build it yourself? Then install that and provide the support you would otherwise provide.
Depending on *which* functionality in AS you need, this should work quite well for you.
Because we provide systems to thousands of customers. I can't imagine the features that each and every one of them will need, so I'd have to pull ALL the features of AS, and at that point, whats the use?
But you seem to be wanting Red Hat to do this for free for you...
On Thu, 2003-08-14 at 13:15, Jesse Keating wrote:
On Thursday 14 August 2003 10:45, Bill Anderson wrote:
If *you* are doing the support, why pay for RH support? Why not take the publicly available SRPMs for AS, and build it yourself? Then install that and provide the support you would otherwise provide.
Depending on *which* functionality in AS you need, this should work quite well for you.
Because we provide systems to thousands of customers. I can't imagine the features that each and every one of them will need, so I'd have to pull ALL the features of AS, and at that point, whats the use?
On Thursday 14 August 2003 12:29, Stephen Smoogen wrote:
But you seem to be wanting Red Hat to do this for free for you...
Not necessarily, I'd just like them to stop removing already existing features in RHL.
On Thu, 2003-08-14 at 13:15, Jesse Keating wrote:
On Thursday 14 August 2003 10:45, Bill Anderson wrote:
If *you* are doing the support, why pay for RH support? Why not take the publicly available SRPMs for AS, and build it yourself? Then install that and provide the support you would otherwise provide.
Depending on *which* functionality in AS you need, this should work quite well for you.
Because we provide systems to thousands of customers. I can't imagine the features that each and every one of them will need, so I'd have to pull ALL the features of AS, and at that point, whats the use?
Maybe you are misunderstanding how the SRPMS system for AS works. The only thin not included in AS SRPMS are the proprietary things RH distributes. All the functionality you appear to be talking about (i.e. "in RHL") is already there. So you build *one* distribution set based off the AS SRPMS and use that.
At that point you have everything that AS has except the proprietary stuff you'd have to pay to redistribute or the client needs to pay to license *anyway*. Unless your clients need those (two, IIRC) pieces of software (which you/they would need to license anyway), the SRPM-build method meets those needs.
The point is you do it once and get what you are griping about. Since you don't need support from RH but want AS, this appears to be an easy solution for an RHCE. This is part of what providing support means. When you take it on as opposed to letting RH do it, surely you expect to do some additional work.
RHAS as currently *released* is based on 7.1-7.2 time frame RHL release, not current RHL. So there *will* be a feature-set difference. Comparing AS to the other capabilities released at the time, As has *more* features --ones that were *added* to AS to make it AS, not the other way around.
I am, however, very curious to see your list of "removed" features. Care to share?