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).
> 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).
> - 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.
> - The "public" FTP is incredibly slow.
Use a mirror.
> - 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.
> - 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.
> - 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)?
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. Don't restart the old RHCE vs. LPI flamewar - we're actually LPI
members, but we think the LPI requirements are too theoretic.
> increasing price for the operating system,
Actually we just decreased it.
> 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.