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. ;)

even if you thought 7.0 sucked, check this one out

[mattdm]

Point oh releases, by definition, break things and cause confusion. This point-one is really nice -- very stable and well-put-together all around.

Re:which 2.4?

[Chang]

They are shipping kernel 2.4.2

I'm running an updated Wolverine beta which is pretty close to 7.1 and I haven't had any problems installing "older" RPMS.

Kudo's to NVIDIA for releasing their binary only driver wrapped into a source RPM. Very nifty for people who like to run custom kernels or beta versions.

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...)

Re:ATA/66 support?

[Black Parrot]

I don't know the difference (if any) between ATA/* and UDMA/*, but I notice this in the announcement:

- IDE UltraDMA/66 and UltraDMA/100 contoller support

I have an ATA/100 card, and one ATA/100 disk on the card and another on my m.b., and the 2.4.0 kernel that shipped with the first Red Hat 7.1 beta recognized them fine without any extra effort on my part.

FWIW, /sbin/hdparm -T -t shows about 170 MB/sec for reading the disk cache, and about 30 MB/sec for buffered reads off the disk itself.

(I tried to post other useful snippets from my logs and program outputs, but Robs lame lameness filter is hyperactive today, and keeps rejecting my posts.)

--

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. ;)

Anyone see this in Wired?

[AugstWest]

from a link on the homepage saying "Latest version of Linux is released":

Linux 7.1 ready to roll: Red Hat Linux 7.1, the latest version of the company's popular open source server operating environment, is on the market, Red Hat said Monday.

Red Hat Linux 7.1 includes a new 2.4 kernel with improved SMP support said to enhance performance on Intel multi-processor platforms. Red Hat Linux 7.1 also delivers new configuration tools designed to help users set up and administer DNS, Web and print servers.

This release features Red Hat Network connectivity, including software manager.

See? Red Hat == Linux.

You /.-ers think you're SO smart.

The good guys

[Eil]

I've read this whole thread and I haven't seen anyone else say this yet, so I'm going to.

Thank you, people from Red Hat for your input and patience in this /. thread. You took a quite a lot of criticism from some of the people here and responded professionally. While I'm not a user of the Red Hat distro, I appreciate all the work that you people put into it because it ultimately means better open source software for the rest of us.

note: I'm not trying to whore extra karma, I just haven't yet noted anyone else showing their appreciation for the fact that a couple RH employees have been so straight forward and open in this discussion.

Re:rsync mirrors?

[sheckard]

rsync://csociety-ftp.ecn.purdue.edu::redhat/redhat /linux/7.1/en

Re:What's this "Tux"?

[teg]

There's no point running the overhead of Apache for serving static files and that's about all that Tux is good for.

Tux handles dynamic content just fine - in fact, it's a large part of the specweb benchmarks.

Re:For all the redhat ppl reading

[teg]

Which brings me to another question: wtf haven't you people jumped into wine?

It's included in Red Hat Powertools 7.1

That said, I will be happy if gcc-2.95.x is in there.

Of course not:

• What we ship is better, and has fixes, C++ compliance and performance well above 2.95.x
• We need to stay compatible with our own RHL 7, and thus couldn't have downgraded

The next compiler change will occur at Red Hat Linux 8, and we expect it to include gcc 3. Regressing isn't a good thing

Re:which 2.4?

[bero-rh]

Kernel: It's 2.4.2 with a lot of patches (mostly bugfixes, including one for a filesystem corruption bug).

RPM: It uses the same v4 package format 7.0 used. The packages won't work on ancient versions of rpm (3.0.x, x 5), which doesn't matter because at least AFAIK there's no distribution out there that uses rpm 3.0.x and glibc 2.2.x (which is needed anyway).

We won't do that

[bero-rh]

Red Hat does not ship proprietary software (with the sole exception of Netscape which was still needed until not too long ago; the last piece of proprietary **** will disappear in one of the next releases, when Konqueror and Mozilla can replace it completely), so we won't ever include PM unless they decide to opensource it, which is unlikely.
We think helping GNU parted to get ready is a much nicer way to address this problem.

Re:Release vs. Beta

[bero-rh]

The FS corruption problems have been fixed. Tracking them down was rather difficult, that's why the release is this late after the beta.
We don't ship releases with known corruption problems.

Re:Bad Red Hat, Bad! Shame on you

[bero-rh]

Obviously, you should wait until the Linux kernel is completely finished before shipping one.

Yes, quite right... We should probably buy out the CIA and have them shoot Linux, Alan and those other ****ing *****s who keep throwing new code at the Kernel rather than just letting our marketing guys say "It's finished".
Please don't tell management, since I'm a developer, if they decide to take that approach, it might cost me my job or more. ;)

omniscience will be a hiring requirement for all support staff

Again, don't tell management. I don't want to be moved off to support. ;))

seriously, working on Linux all day must be a lot of fun

It sure is. That's why many of us keep rejecting better paid jobs and it's why I'm here, reading /. in a Konqueror session and hacking on 7.2 stuff in a konsole right next to it, at 9 pm on a public holiday while I'm on vacation. ;)

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

devfs

[BlowCat]

An empty 7.1 directory has been seen on mirrors for days, so I expected it to be released soon.

In the meantime I tried their latest beta, Wolverine. To my great surprise, is supports kernels with devfs, although not without glitches.

Another nice thing - it installs in text mode on top of VESA framebuffer. I think it's 100x37 characters or so - more space on screen to select packages and partition the hard drives.

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!