On Mon, 3 Jul 2000, Michael J. McGillick wrote:
> First, thank you for taking the time to reply. A lot of other companies
> wouldn't even do that.
See, we aren't Microsoft. ;)
We need user input to improve our distribution - if nobody tells us what
"features" are confusing etc, they'll stay in forever -- we welcome any
constructive criticism.
> Agreed that we don't need all of the extra stuff. But, by splitting
> everything up, if I want to maintain a current database, I need to
> download the updates to all of the packages that I have installed, and
> somehow get them applied.
Alternatively, just let up2date do the work for you.
> It used to be that if I wanted a new version of
> the kernel, I would download the new source, recompile and set up lilo to
> point to both the new kernel and the old (for saftey).
You can still do that.
> Why does there need to be so many RPMS?
The splits make sense... Here's the kernel RPMs we have and their
reasoning:
kernel: Well, quite obvious. You need that.
kernel-BOOT: The kernel used by the installer. You don't need it unless
you want to build your own boot disks, but we're shipping it so
everyone knows what we're doing to the installer. Leaving it out
wouldn't hurt many users, but it would be a Microsoftish approach
(as in, not releasing the full source).
kernel-doc: Documentation - We could put it in the base kenrel package of
course, but many people don't want to play with kernel settings
etc, so it would be useless bloat for them.
kernel-headers: The include files - they are needed for compiling
applications, but not for people who can get by without a
compiler.
Could be part of kernel-source, but if it were, you'd need to
install the whole kernel source to get anything compiled.
kernel-ibcs: Compatibility with other x86 unixes - most people don't need
it, but some rely on it heavily.
kernel-pcmcia-cs: PCMCIA applications - needless to say, 90% of the
users don't need it.
kernel-smp: Multi-processor kernel. Installed automatically on SMP capable
systems, but definitely useless bloat for UP machines.
kernel-source: The full kernel source.
kernel-utils: Tools for tracing kernel bugs (ksymoops)
I don't think that's any unnecessary splits.
> I've looked at other distributions, like SuSE
> where there is one RPM for the stock kernel, if that's what I want
> installed.
There's a difference between shipping a kernel with some well-tested
patches and a kernel with loads of patches that need more
testing/fixing. If we did that, we'd be shipping a stock
(==stable) kernel, as well.
> Again, as an end-user, it's
> much easier for me to understand "This one RPM contains the kernel source
> and stuff" as opposed to more than one.
We don't split the source (except for moving the headers to a separate
package because many people who don't need the full kernel source will
need them - and kernel-source requires the same version of kernel-headers
to be installed, so RPM will tell you when you're doing something wrong).
> Fair enough. I understand that you need to maintain backwards
> compatibility and can't simply adjust stuff in same release levels
> updates. These packages must have come out just before or just after 6.0
> was released, because several other distributions all include Bash 2 and
> gcc-2.95 as standard in their releases.
Several other distributions don't care much about backwards compatibility.
Of course there are arguments for including newer stuff even if they break
something - there are others for not breaking compatibility. The final
decision is pretty much a matter of taste.
> > This is entirely untrue. As of 6.2, telnet-server, wu-ftpd etc are all
> > separate packages and not installed by default unless you're running a
> > server installation.
> > bind and all are not enabled by default.
>
> Well, as a end-user, I did a "full install" of the CD, not knowing exactly
> what I needed to have on the system.
Sure, an "everything" type install installs everything including all
servers.
Most of them are disabled by default; some stuff (like ftp and telnet)
isn't because newbies will have a hard time figuring out how to enable
services that are started by inetd.
We're fixing this in 7.0 by using xinetd which can be configured much more
easily (also by scripts).
> > > - The "public" FTP is incredibly slow.
> >
> > Use a mirror.
>
> When Red Hat releases a security update, it often takes longer than 24
> hours for this update to propogate to a mirror site. It's funny how for
> the longest time, Re Hat's FTP was very fast and accessible. As soon as
> Red Hat started offering "priority access" for customers who bought the
> software, the public site slowed to a crawl.
Don't mix cause and effect here. We did nothing to slow down the normal
ftp servers.
The 6.1 release, which was introduced at the same time as the priority
servers, was the first release to include a graphical installer; with
that, many more people started to realize they don't need to be an expert
to install Red Hat Linux, and we got a number of new users (all of which
use the ftp servers).
Infinite bandwidth on all servers would be nice of course - but not even
M$ could pay infinite bandwidth.
That's what mirrors are there for...
> For the record, I've bought
> almost every release of Red Hat that comes out, but I like to evaluate a
> version before I buy it. Why is it that when companies become big, they
> always forget where they started?
If we forgot, we'd be developing proprietary add-ons the way some others
do. It's much easier to make mony selling something nobody else can sell.
> > Take a look at the support contract offers (this includes developer
> > support!) on redhat.com.
>
> I do technical support for a living. Your "standard" technical support
> for purchasing and getting Red Hat installed is not good.
Can't comment on this as I haven't ever called support. But I know we do
have satisfied support customers (including some who have just the
standard installation support that comes with the package). I guess it's
impossible to please everyone.
> I don't have
> several thousand dollars to spend on a company support contract if I'm an
> end-user. When I call for support for something like Linux, I'm expecting
> that the people on the other end of the line are very familiar with the
> product and can reach beyond the scope of reading a document off to me on
> the phone on what to do to install off the CD-ROM.
You probably just got the wrong person for your problem - someone who can
give you perfect support for installing a web server is possibly not the
best person to ask about support for getting the latest 3D graphics card
to run in fully optimized mode.
Aside from that, there's always the mailing lists.
> Hmm. When I noticed the patches applied to apache in the SRPM, I went to
> the apache website, and downloaded the source. I then went to the mod_ssl
> web site, and followed the document there for compiling apache with
> mod_ssl.
But you had to recompile apache. You don't need to recompile it if you're
using the version we're shipping, which is the point of our patches. You
can't expect the average end-user to know how to compile everything.
> I built an RPM for doing this, and it all works right out of the
> box, without having to apply the 6 other patches Red Hat has in their
> source RPM.
EAPI was just one example of a patch that makes sense.
We don't apply patches without a good reason; if you're in doubt, read
them.
> One of the strong points of RPM is that I should be able to take a SRPM
> and build a new SRPM if a new version of the source code for a particular
> package is released.
One of the other strong points of RPM is that you can put 30 patches in a
package and have them applied automatically for everyone trying to rebuild
it - rather than having to tell users "untar the package, then run patch
-p1 <patch1.patch; patch -p1 <patch2.patch, ...".
> For example, going from apache-1.3.9 to, say
> apache-1.3.12. I shouldn't have to re-create an entire process, and
> understand not only the source code from the package, but are the patches
> from the 1.3.9 SRPM applicable to the new code?
Most of the time they work or can be adapted easily.
> > > RHCE,
> >
> > So what's wrong with that? Just because Microsoft has a similar offer
> > doesn't mean it's bad.
> > We need to tell people how to handle Linux, and that's what RHCE training
> > does.
>
> Red Hat Linux is one release, or style of Linux. It's a bit strong to
> make the statement that someone who has a RHCE would be able to administer
> a Debian, SuSE or Slackware environment, all versions of Linux.
Nevertheless, it's probably the case. The test requires you to fix up some
broken installations (can't go into the details; revealing them would make
the test worthless [people could just memorize what they have to
do]) which is hardly specific to any distribution, to set up a server, and
to answer 50 *technical* questions (It's not an MCSE thing - we don't ask
stuff like "who founded Red Hat and when" - nobody needs to know that in
order to handle Linux), most of which have the same answers in any
distribution. It's possible that there are some questions about handling
rpm which won't help you much if you're using Debian or Slackware of
course, but other than that, I'd say a RHCE can handle Linux in general,
at least with very little extra instructions (like handling dpkg or
pkgadd).
> > > increasing price for the operating system,
> >
> > Actually we just decreased it.
>
> When Red Hat was first released, the cost was minimal. Then all of a
> sudden, it was $79.95 for the OS, and $149.95 for the secure server
> version. I do not know what the release prices will be for 7.0, but when
> you can pick up another distribution for $20.00 - $30.00 for manuals, CD,
> etc., why should I pay that much for Red Hat.
The standard version is MUCH cheaper than $79.95. The Deluxe version,
which is about that price, already includes telephone support and stuff.
Also, you can simply download it or order CDs from Cheapbytes, Linuxmall
or the likes.
> I thought you said above that you don't make your money on selling the
> software, but by providing support contracts.
I'm not one of the financial people - my understanding is that selling CDs
and such is just a minor part of the business.
LLaP
bero
--
To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
as the Subject.
