Bernhard:
First, thank you for taking the time to reply. A lot of other companies
wouldn't even do that. My comments are below.
On Mon, 3 Jul 2000, Bernhard Rosenkraenzer wrote:
> On Mon, 3 Jul 2000, Michael J. McGillick wrote:
>
> > - Red Hat split the kernel up into multiple packages, instead of just
> > one.
>
> And that makes perfect sense. Nobody will ever need both an SMP kernel and
> a UP kernel at the same time. Many people don't need the PCMCIA stuff
> (which, by the way, is not part of the standard kernel - if you compile
> from source, it's a separate package as well).
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. 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). Why does there
need to be so many RPMS? I've looked at other distributions, like SuSE
where there is one RPM for the stock kernel, if that's what I want
installed.
Maybe I truly don't understand why there are so many different RPMs for
the kernel stuff, headers and pcmcia and stuff, so I will go back and try
to find some documentation on why this is. 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.
>
> > While some feel this was a good thing, how many times have we seen
> > on this list "How do I upgrade my kernel?". How is managing 10 - 12
> > packages easier than installing 1?
>
> You need only one of them, possibly plus one pcmcia package.
>
> > - Bash is still installed by default as the primary system shell, and has
> > not been converted to Bash2. Bash2 is clearly superior to Bash.
>
> We're using bash 2.x in 7.0 (check rawhide).
> Bash 2 wasn't available by the time 6.0 was released; we didn't update in
> a .x release for compatibility reasons. Bash 2.x and 1.x are not fully
> compatible because 2.x is much closer to what POSIX demands.
>
> For example, this works in bash1, but not bash2:
> {
> something
> }
>
> Same for this:
> FILES="";
> for i in $FILES; do something; done
>
> > - egcs is installed instead of gcc-2.95.
>
> Same thing here. gcc 2.95.* is not binary compatible with egcs 1.1.x
> (libstdc++ changes).
> A C++ program compiled with 2.95.* won't run on a system with egcs 1.1.x
> unless it installs its own libstdc++ (yuck!) or is linked statically
> (yuck!).
>
> Since everything that is compiled on 6.* is supposed to run on any other
> 6.* release without needing to mess with libraries, we couldn't upgrade.
>
> 7.0 will have gcc 2.96 (or 2.97 or 3.0, whatever is current by
> then. Rawhide currently has 2.96).
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.
>
> > - Minimal security is in place after an install. Telnet, FTP, etc. are
> > wide open if you happened to have installed those packages.
>
> 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. Funny, but I can then do an
anonymous FTP in to the machine. Also, Telnet comes right up and I get
prompted for a login. I have applied all of the security updates from the
site. True, named does not run by default, but httpd, ftpd and telnetd
do. Why was the option removed from the installer for ntsysv to be run
during the install?
>
> > - 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. 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?
>
> > - Red Hat is not 100% FHS compliant. I'm still checking on this one, but
> > my understanding is that this is the case.
>
> We can't be compatible with a standard that wasn't released when we
> released, can we? FHS 2.1 was released after Red Hat Linux 6.2. Red Hat
> Linux 7.0 will be fully FHS 2.1 compliant. Rawhide already is.
>
Excellent.
> > - There is no telephone technical support.
>
> There is. It's not free though - we have to live from something, and
> selling the distribution rather than offering it for download is
> definitely not the way to go.
> 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. 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.
Great technical support can make up for a lot of problems and frustrations
with an OS such as Linux. A good technical support experience will keep
me going back to a product, even if it doesn't perform the way I think it
should.
>
> > - Customizations and patches original sources. I thought the idea of RPM
> > was to have pristine sources and manage those.
>
> One of the basic reasons why RPM was needed is to manage patches rather
> than having to apply them manually all the time.
>
> > Why are the kernel sources patched then with stuff from Red Hat that has yet
> > to be approved by the group producing the kernel?
>
> The patches are approved by our kernel people, including people like Alan
> Cox, Doug Ledford and Alexander Viro.
>
> > I've seen this with other packages, like
> > Apache as well.
>
> And it makes sense. Seriously, why would you want an apache package that
> doesn't even have the EAPI patches (so you can't run mod_ssl)?
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. 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. I have both standard and secure access from one running
daemon just by installing the package.
I understand that Red hat wouldn't be allowed to ship a version of apache
like this, as the U.S restrictions on the RSA stuff, but, again, why all
the different patches? The standard install of apache allows command line
arguments like --with-eapi, etc. Why did it need to be patched?
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. 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?
>
> There are also some patches that simply don't make sense for the base
> packages, but that are needed to make the package operate better within
> Red Hat Linux, such as adapting path locations.
>
> > - Red Hat appears to be going the route of Microsoft.
>
> This is ENTIRELY untrue. Most of us hate Microsoft as much as other Linux
> developers.
> The day Red Hat becomes like Microsoft, I'm out of here and so are most
> other developers.
>
> > 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.
> does. Don't restart the old RHCE vs. LPI flamewar - we're actually LPI
> members, but we think the LPI requirements are too theoretic.
Not looking to start or restart any flamewars here.
>
> > 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. I haven't checked the
proces recently, but why are you charging that much in the first place. I
thought you said above that you don't make your money on selling the
software, but by providing support contracts.
>
> > customizations to the OS that require Red
> > Hat be installed or packages don't work
>
> So what would that be?
> We're doing no such thing, unless it makes the package work much better on
> Red Hat Linux [such as replacing a hardcoded /opt/kde with /usr], and we
> always release source so people who want to run it on something else won't
> have to modify anything other than packaging.
>
> > I'm looking to put together my own distribution of Linux, and wanted to
> > find out if anyone on the list here would be interested in helping
> > out. My main focus will be on simplicity and security. I'd like to build
> > this from the ground up. I really like the RPM format for packages, so I
> > would like to stick with that mechanism for maintaining packages. I also
> > want 100% FHS compliancy. I'd like to be able to take advantage of things
> > like the newer gcc or bash2.
>
> Already working on that - it's called Red Hat Linux 7.0.
>
> > I need help in writing an installer and hardware detection.
>
> So take a look at the source of our installer and our hardware detection
> tool, kudzu.
> Unlike some others, we GPL everything.
>
> > Again, this email is not meant to belittle the work or efforts done by Red
> > Hat. These are my opinions of what I've seen, and you're free to agree or
> > disagree as you wish.
>
> Sure - but please get your facts right.
>
> LLaP
> bero
>
>
>
>
--
To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
as the Subject.
