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: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: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: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