Red Hat Linux 7.1 Release Announcement

Many people have sumitted that Red Hat has announced the release of 7.1. I don't see it on the ftp site yet, but, if I don't post this, I'm gonna spend all morning deleting this submission *grin*. The new features include a 2.4 kernel, USB, Updated XF86, and assorted other stuff of varying importance.

Comments

Real suggestions to improve Red Hat Linux

[emil]

1. We need a journaling file system. NT has had one for years; we are remarkably primitive in this respect. With ReiserFS ready, and XFS/JFS mostly there, there is no reason to wait for ext3. Don't just decide; let your user community have influence on the decision and support your move with performance benchmarks. Make sure it works with large-file support. If you want to sell server operating systems, drop everything else and get this done. This is tarnishing your reputation.
2. The only reason that you don't have a desktop market is that you aren't trying to get one. Please release a desktop version of RedHat with Ximian Nautilus, Wine with DirectX, KDE, Openoffice and anything else that seems appropriate. Businesses are screaming about desktop Windows liscensing costs; take the opportunity to make some money. It's probably even time for separate workstation and server CDs - makes more sense than what you're doing now. If you are spending enough time to make a workstation install, you might as well spend enough time to do it right.
3. If you want to do something like xinetd, then fine, but give the user an install option to choose the standard UNIX behavior. Is inetd a part of POSIX? Is Red Hat 7.x even vaguely POSIX-compliant at this point? The GNU tools have POSIXLY_CORRECT settings; take the hint.
4. Do whatever it takes to RPM to satisfy the apt people. If you were bold enough to rip out inetd, then you should be bold enough to rip out RPM if necessary.
5. By the way, I don't like what you did with INPUTRC. Put it back the way it was. I like vi mode, nobody else does, move it back to skel.
6. In fact, it's time to integrate the Korn shell into the distribution. Bash's limitations remain too severe, and commercial UNIX people write too much for ksh.
7. Never put out a production release that requires more than one compiler again. It's just ugly and a waste of space. A system should be consistent and true to itself.
8. Unless you really plan to give people a kernel version upgrade, don't mix-and-match the kernel components. It's just ugly, and it tarnishes your reputation.

If you do these things, you will no longer have to worry about Mandrake or Suse. They are only successful because they are fixing your mistakes.

Re:Real suggestions to improve Red Hat Linux

[bero-rh]

Thanks for your comment - we always welcome constructive feedback.

For your points:

• journaling file system: We aren't waiting for ext3 specifically (though we still think it'll be the first stable jfs), we're waiting for any stable jfs. Unlike what you claim, our kernel people have found that ReiserFS isn't ready yet, it still caused heavy filesystem corruption under heavy load tests, and its userland recovery tools don't do much beyond a journal replay. Try to simulate a media defect (e.g. dd if=/dev/random of=/dev/hda offset=something count=3) and try to recover from that. With ext2/ext3, you'll lose some data, but a lot of stuff will remain intact. With ReiserFS, you can lose much more.
  Yes, it's getting better and I have no doubt it'll be ready for prime time some time soon, but it's not there yet.
• desktop market I presonally agree pretty much, however, Openoffice is nowhere near ready (have you ever tried selling someone a full-fledged office suite that can't print?), and it'll take quite some work to convince everyone that Linux is ready to replace Windows on the desktop.
  I think that, at least if you use KDE and install Wine from powertools, you already get a very nice desktop OS, but unfortunately I don't make those decisions.
• inetd: It's not that easy for practical purposes. Manipulating the inetd.conf file when you install packages that need to be launched from (x)inetd always has to be some crude hack. xinetd's feature of including all files in a specific directory is very useful there. We could provide an inetd package, but it would be pretty much unsupported because our official packages don't touch inetd.conf. I think it's not worth the trouble.
  Are you aware of the fact that you can just run inetdconvert to translate inetd.conf files to xinetd format?
• rpm: I think the rpm + up2date combo has all the features you need. If you think there's something we need to add, please let me know.
• inputrc: We've had a couple of people complaining about the change, but we've had many more people writing in to let us know we finally got it right. I think this has to be a local configuration thing.
• korn shell: I must admit I've never used any shells but bash and zsh. What exactly are the things you're missing in bash? Is the korn shell under an open source license?
• requiring several compilers: Yes, this was unfortunate... Related to a relatively tight schedule and the fact that we couldn't know too far in advance whether kernel 2.4 would be ready in time for the 7.0 release, so we basically had to prepare for both cases. (The need for kgcc was purely because of kernel 2.2.x bugs). I don't think this will happen again.
• Kernel mixing:Yes, this was a relatively crude hack. Nevertheless, it was the best option we had: With kernel 2.4 not ready for the release, but expected to ship shortly after, we wanted to have a release that will work well if you just update to kernel 2.4 (which we almost achieved). Compiling everything with 2.2 headers in place means it won't be able to use 2.4 specific features even if you install kernel 2.4 -- something we wanted to avoid. And yes, we did (do?) really plan to give people a kernel version upgrade for the 7.0 release, we just expected 2.4 to be ready earlier. Our kernel people say the version we're shipping in 7.1 (meaning 2.4.2+our patches) is the first really usable version of kernel 2.4, because it's the first one that doesn't cause filesystem corruption under heavy load. I don't know if the plan to release a 2.4 update for 7.0 is still current, now that we know 7.1 and a stable 2.4 kernel are appearing at the same time.

Besides, we aren't worrying about Mandrake or Suse - actually we're quite glad they're around. If they play fair [If anyone at Suse is reading this: Please start by putting yast under a reasonable license. Thanks.], everything they do is nice work for us, and we don't even need to pay them for it. ;)

Re:Bad Red Hat, Bad! Shame on you

[tuffy]

If we waited for 2.4.4 and released 7.1 after testing it, 2.4.5 would be current by the time it got out of the door. If we waited for 2.4.5, 2.4.6 would be current.

Obviously, you should wait until the Linux kernel is completely finished before shipping one. Once it reaches version 300.4-complete, then that should be about right.

Not officially supporting anything that hasn't passed QA isn't corporate idiocy either. It's simply practical.

Since RedHat is Linux (according to the press), you're obviously required to support every version of every piece of software that is compatible with Linux. Therefore, omniscience will be a hiring requirement for all support staff.

(but seriously, working on Linux all day must be a lot of fun except for all the stupid questions that pop up...)

Mandrake is already done with 7.1!

[Sylvestre]

How can we look to RedHat for technical leadership when Mandrake has already used this version number?

Re:Mandrake is already done with 7.1!

[bero-rh]

Darn, we forgot.
It'll probably take us years to catch up with the only os that has to be really stable since it already reached version 2000.0.

I'm going to quit my job, we obviously can't get anywhere since we're that far behind. ;)

Re:Do you still need 2 compilers

[bero-rh]

Since we're using kernel 2.4.2 (with many fixes), you won't need kgcc anymore unless you're planning on downgrading the kernel.

The need for kgcc was caused by bugs in 2.2.x kernels, preventing it from compiling with compilers that do the right thing(tm).

Re:gcc version 2.96RH???

[bero-rh]

Sure. See http://www.bero.org/gcc296.html

Re:Do you still need 2 compilers

[bero-rh]

We're keeping kgcc for people who want to run 2.2.x kernels for whatever reason.
It's definitely not needed for 2.4.x kernels - our kernel has passed all stress tests without causing filesystem corruption, crashing, or otherwise acting up oddly.

Also, gcc 2.96 has stabilized a lot between 7.0 and 7.1. (not that the 7.0 version was as bad as some people claim it was).

Re:Bad Red Hat, Bad! Shame on you

[bero-rh]

Our kernel is in no way proprietary. We're shipping the whole source and all of the patches.

We're not using 2.4.3 because it was released way too late. Porting patches and testing take some time.

Some of our fixes are in 2.4.3 (not all of them, simply because they were too late).
And yes, all of our fixes have been submitted to what you call the real kernel.

You can of course build your own kernel and it'll work - but we don't officially support anything that hasn't passed our QA.

Re:For all the redhat ppl reading

[bero-rh]

If you are aware of anything that causes infinite loops or gcc chokes with 2.96-81, please report it, so we can fix it. We're not aware of any big problems in 2.96-81, and we can't fix problems we aren't aware of.

C++ binary compatibility is a joke until gcc 3.0 is released. Handling C++ source isn't. gcc 2.96 does that well, 2.95.3 and earlier don't.

And yes, all of 7.0 was compiled with 7.0 itself.
If you can't get the SRPMs to recompile, it's a local installation issue (missing -devel packages? Modified glibc? Other kernel headers?).
If you find any 7.0 SRPM that can't be compiled on a 7.0 Everything install, let me know and I'll personally fix it, but this shouldn't be the case.

Re:For all the redhat ppl reading

[bero-rh]

Sure you can make a few suggestions... However, I don't think we'll do anything for them:

• xinetd: making the switch was the correct (and IMO overdue) choice, both for ease of use and for security (xinetd implements IP based access control), and for compatibility with the future (xinetd can do IPv6). Handling legacy inetd.conf files is a problem: If a service is described in both, which do you take? Also, inetd.conf has no way of providing information like permitted/rejected IPs.
  If we never dared to change anything because of compatibility issues, we'd still be punching holes in cards for programming.
  You can configure xinetd by hand (my favorite system configuration tool is and will always be vim) - its config files aren't more difficult to understand than inetd.conf. They're just more powerful.
  
  This is very different from changing / to C:\ -
  one was a big step forward, the other would make no sense at all and be a big step backwards.
• wine: We're shipping it on Powertools.
  Putting a lot of resources into wine wouldn't make much sense. First of all, there's two sides to wine. Of course it's nice that I can run a Windoze application on Linux if I need to (I'm doing my tax declarations with wine, for example), but if it runs too well, companies won't see a need to write native Linux applications ("But our Windows version works for you, why should we do anything else?").
  Second, the desktop isn't our primary target, and there's no reason whatsoever to run wine on a server or embedded device.
• gcc: This has been discussed to death many times. Go to http://www.bero.org/gcc296.html and let me know if this doesn't answer your questions.
• What we do at "work": Coding, packaging and fixing bugs. Have you ever used the Linux kernel? glibc? gcc? KDE? GNOME? rpm? If you answered yes to any of those, you've used Red Hat code. (No, I'm not claiming we invented them or did all the work on them, but all of them contain a lot of code we wrote).
  Since everything we do is released under the GPL or LGPL, many people aren't aware of the fact that they're using a lot of our code even if they aren't using Red Hat Linux. (Yes, the same goes for most other distributions to an extent.)

Re:Real conclusions

[bero-rh]

Ok, here's the explanation:

• wu-ftpd: Two of the wu-ftpd core developers (in the new wu-ftpd development group formed after the 2.6.0 release) are Red Hat employees. We've gone through the code a couple of times and we think it's safe now. There's no need to reinvent the wheel if you can fix up the existing one.
  Yes, there are other alternatives, like proftpd or the openbsd ftpd, but they are not necessarily better just because they're different. proftpd has had just as many root exploits, none of the other ftpds has all the features our users have come to expect. Similarily, we don't switch to a tool that has a totally different configuration file unless there are plenty of good reasons to do that (such as inetd->xinetd). AFAIK no alternative ftpd provides an equivalent of kwuftpd, allowing even beginners to configure most of the features.
• bind: The maintainers have noticed this problem themselves - bind 9.0.0 was a complete rewrite without using any old code.
  We're shipping bind 9.1.0 with a lot of fixes from the 9.1.1 branch.
• sendmail: While I personally would like to replace it with postfix, sendmail has matured, and some of the arguments for wu-ftpd apply here too - don't change to something radically different unless there are plenty of good reasons.
  We are shipping both postfix and exim in powertools for people who know what they're doing, though.
• ResierFS: It's not possible to do a ReiserFS only installation at this time because our kernel people have found it to be too unstable. It still caused file system corruption under some circumstances, and we couldn't fix those problems in time. If it stabilizes a bit more, it will be possible in the next version (along with ext3).

Re:What's this "Tux"?

[Cmdr. Marille]

Well TUX is indeed one of the fastest webserver, it's written by Ingo Molnar
what makes it special? Well, It runs in kernel space, that's why it's so fast. It's also not meant to completely replace a full fletched web server like apache.

check out this older slashdot article

Red Hat, the only serious distribution.

[Mohammed Faizal]

I work in Syria, for the army. I install much linux distributions for the army here, as they do not trust american windows security.

Linux is a great OS for army uses. Used throughout the world in the name of Allah.

Microsoft Windows is used by CIA to spy on foreign governments. But, windows better than linux for average man. Here in Syria, windows is totally free, buy it on streets for cheap price. Linux is more expensive than windows, because it is hard to get.

Linux is also against Allah. Allah likes his children to only use the works of circumcised men who follow the will of allah. Linux develepors do not follow the will of Allah, even worse than Microsoft developers. But, there is no pure muslim OS.

So we in syria have started new unix variant. Anyone can work on it, and all source code is free, as long as they are muslim. It will be used in coming jihads against western liberal capitalism.

So please, remember that we Syrians like Red Hat, but Microsoft is cheaper. Please, Americans, make Red Hat cheaper for us in East.

I am hoping to be involved in jihad against america soon. My brother works in a grocery store in philadelphia. He say I get green card. I look forward to money and living somewhere where Red Hat is cheap.

ALLAH AKBAR!