9:01 a.m.
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
11:41 a.m.
New subject: APT, Yum and Red Carpet
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
12:01 p.m.
New subject: APT, Yum and Red Carpet
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.
--
Stephen John Smoogen smoogen(a)lanl.gov
Los Alamos National Labrador CCN-5 Sched 5/40 PH: 4-0645 (note new #)
Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545
-- So shines a good deed in a weary world. = Willy Wonka --
1:30 p.m.
New subject: APT, Yum and Red Carpet
seth vidal (skvidal(a)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
1:49 p.m.
New subject: APT, Yum and Red Carpet
seth vidal (skvidal(a)phy.duke.edu) said:
On Thu, 2003-08-14 at 14:30, Bill Nottingham wrote:
> seth vidal (skvidal(a)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
1:38 p.m.
New subject: APT, Yum and Red Carpet
>>>> "seth" == seth vidal
<skvidal(a)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
--
Ed Bailey Red Hat, Inc. http://www.redhat.com/
1:36 p.m.
New subject: APT, Yum and Red Carpet
On Thu, 2003-08-14 at 14:30, Bill Nottingham wrote:
seth vidal (skvidal(a)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
4:14 p.m.
New subject: APT, Yum and Red Carpet
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.
10:16 a.m.
New subject: APT, Yum and Red Carpet
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!)
11:13 p.m.
New subject: APT, Yum and Red Carpet
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.
11:09 p.m.
New subject: APT, Yum and Red Carpet
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.
--
Jesse Keating RHCE MCSE
http://geek.j2solutions.net
Mondo DevTeam (www.mondorescue.org)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
9:54 p.m.
New subject: APT, Yum and Red Carpet
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.
--
Féliciano Matias <feliciano.matias(a)free.fr>
4:54 p.m.
New subject: APT, Yum and Red Carpet
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
4:51 p.m.
New subject: APT, Yum and Red Carpet
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 .
2:37 p.m.
New subject: APT, Yum and Red Carpet
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.
--
William Hooper
4:48 p.m.
New subject: APT, Yum and Red Carpet
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
1:34 p.m.
New subject: APT, Yum and Red Carpet
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.
--
Hoyt
12:53 p.m.
New subject: APT, Yum and Red Carpet
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(a)redhat.com
http://www.redhat.com/mailman/listinfo/rhl-beta-list
3:39 p.m.
New subject: APT, Yum and Red Carpet
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.
--
Jesse Keating RHCE MCSE
http://geek.j2solutions.net
Mondo DevTeam (http://www.microwerks.net/~hugo/)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
3:58 p.m.
New subject: APT, Yum and Red Carpet
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?
--
Bill Anderson
RHCE #807302597505773
bill(a)noreboots.com
2:29 p.m.
New subject: APT, Yum and Red Carpet
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?
--
Stephen John Smoogen smoogen(a)lanl.gov
Los Alamos National Labrador CCN-5 Sched 5/40 PH: 4-0645 (note new #)
Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545
-- So shines a good deed in a weary world. = Willy Wonka --
2:15 p.m.
New subject: APT, Yum and Red Carpet
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?
--
Jesse Keating RHCE MCSE
http://geek.j2solutions.net
Mondo DevTeam (http://www.microwerks.net/~hugo/)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
12:45 p.m.
New subject: APT, Yum and Red Carpet
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.
--
Bill Anderson
RHCE #807302597505773
bill(a)noreboots.com
11:34 a.m.
New subject: APT, Yum and Red Carpet
On Thu, 2003-08-14 at 12:30, Edward C. Bailey wrote:
>>>>> "seth" == seth vidal
<skvidal(a)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
11:30 a.m.
New subject: APT, Yum and Red Carpet
>>>> "seth" == seth vidal
<skvidal(a)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
--
Ed Bailey Red Hat, Inc. http://www.redhat.com/
8:34 p.m.
New subject: APT, Yum and Red Carpet
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
5:11 p.m.
New subject: APT, Yum and Red Carpet
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
5:06 p.m.
New subject: APT, Yum and Red Carpet
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.
--
This is my personal opinion (but it should be yours, too).
4:05 p.m.
New subject: APT, Yum and Red Carpet
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
4 p.m.
New subject: APT, Yum and Red Carpet
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
2:46 p.m.
New subject: APT, Yum and Red Carpet
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
1:26 p.m.
New subject: APT, Yum and Red Carpet
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 ;)
--
This is my personal opinion, though it should be everyones. ;)
1:06 p.m.
New subject: APT, Yum and Red Carpet
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.
--
Jesse Keating RHCE MCSE
http://geek.j2solutions.net
Mondo DevTeam (http://www.microwerks.net/~hugo/)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
12:58 p.m.
New subject: APT, Yum and Red Carpet
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
12:13 p.m.
New subject: APT, Yum and Red Carpet
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....
--
Jesse Keating RHCE MCSE
http://geek.j2solutions.net
Mondo DevTeam (http://www.microwerks.net/~hugo/)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
11:16 a.m.
New subject: APT, Yum and Red Carpet
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!
--
Jesse Keating RHCE MCSE
http://geek.j2solutions.net
Mondo DevTeam (http://www.microwerks.net/~hugo/)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
10:18 a.m.
New subject: APT, Yum and Red Carpet
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
9:34 a.m.
New subject: APT, Yum and Red Carpet
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.
--
Jesse Keating RHCE MCSE
http://geek.j2solutions.net
Mondo DevTeam (www.mondorescue.org)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
7:46 p.m.
New subject: APT, Yum and Red Carpet
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.
--
Féliciano Matias <feliciano.matias(a)free.fr>
6:13 p.m.
New subject: APT, Yum and Red Carpet
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
--
Daniel Veillard | Red Hat Network https://rhn.redhat.com/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
4:36 p.m.
New subject: APT, Yum and Red Carpet
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(a)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 ;-)
4:36 p.m.
New subject: APT, Yum and Red Carpet
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>
--
Jesse Keating RHCE MCSE
http://geek.j2solutions.net
Mondo DevTeam (http://www.microwerks.net/~hugo/)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
4:33 p.m.
New subject: APT, Yum and Red Carpet
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.
2:32 p.m.
New subject: APT, Yum and Red Carpet
On August 12, 2003 12:59 pm, Jesse Keating <hosting(a)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 ;-)
--
http://setiathome.ssl.berkeley.edu/stats/team/team_4504.html
"You only live once, so let's make life EASIER for each other."
LINUX Registered User #193975. AMD-K7 ATHLON CPU power on board.
2:25 p.m.
New subject: APT, Yum and Red Carpet
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.
--
Jesse Keating RHCE MCSE
http://geek.j2solutions.net
Mondo DevTeam (http://www.microwerks.net/~hugo/)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
12:10 p.m.
New subject: APT, Yum and Red Carpet
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.
12:07 p.m.
New subject: APT, Yum and Red Carpet
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
11:59 a.m.
New subject: APT, Yum and Red Carpet
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.
--
Jesse Keating RHCE MCSE
http://geek.j2solutions.net
Mondo DevTeam (http://www.microwerks.net/~hugo/)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
7560
days inactive
7562
days old
48 comments
21 participants
participants (21)
-
Alan Cox -
Bill Anderson -
Bill Nottingham -
Charles Hixsn -
Daniel Veillard -
Edward C. Bailey -
Elton Woo -
Féliciano Matias -
Gerald Henriksen -
Hans Deragon -
Havoc Pennington -
Hoyt -
James Olin Oden -
Jef Spaleta -
Jesse Keating -
Rik van Riel -
seth vidal -
Stephan Schutter -
Stephen Smoogen -
Tim Powers -
William Hooper