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

Re:But..

[Anonymous Coward]

Er...

I was referring to the documented problem that c++ binaries compiled on 7.0 will not ever run on non-redhat 7.x distributions. IE, they will not run on 6.2, and will not run on gcc 3 based systems when they arrive.

Yes, I agree they are including questionable software with the intention of stabalizing that software faster and so they have stable distributions when other distribs are still trying to figure out the newly stable software. This is all fine and dandy, I just wouldn't use unstable software, whether it is because the binaries are unstable because they are a .0 release on an unprepare distribution, or the binaries are unstable because they are a .999 release on a prepared distribution.

But, it appears (see other post) the consensus is to downgrade GCC

Andrew Robertson (paranoid 6.2 user)

Guys, YOU NEED A JOURNALING FILESYSTEM!

[emil]

How am I supposed to convince my management to move Oracle off a 30-gig VxFS and onto RedHat if I still have to deal with fsck?

You should have waited!

Red Hat needs a journaling filesystem with large file support. This is a big disappointment.

Re:Guys, YOU NEED A JOURNALING FILESYSTEM!

[LunaticLeo]

How am I supposed to convince my management to move Oracle off a 30-gig VxFS and onto RedHat if I still have to deal with fsck?

You don't. Linux isn't always better that Solaris or HP/UX . And there is no filesystem on linux as cool as VxFS. Journelling != Logging . Journeling means that every write is repeated a second time. Logging only writes once. Gee what is the slowest operation on RAID-5 ummmmm...WRITING maybe.

I love Linux and think it will take over the world, but it ain't ready to run E10k with 1TB filesystems using Oracle in all it's tweaked out glory.

RedHat 6.2 is a much better product.

[emil]

Anybody doing anything serious with Red Hat is still on 6.2.

Even Red Hat's own high availability and Oracle-optimized releases are 6.2-based.

Without a journaling filesystem, there still really isn't much motivation to upgrade.

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:gcc version 2.96RH???

[mattdm]

cached

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:What's this "Tux"?

[Tet]

do it really matter if your web server can fill a gigabit ethernet pipe?

Until recently, I used to agree with you, as no-one could afford that much bandwidth to the internet. However, that's all changed now, and we're looking at getting a gigabit internet link to the office at work, and the prices are *really* cheap. For high volume sites, a web server like TUX may well be needed.

Re:For all the redhat ppl reading

[Chris Siegler]

With wine you forgot to mention that it doesn't work unless you already have a Windows partition. At least in my experience, without an Windows tree with its dlls, you can't get anything except minesweeper to run.

I'd love to hear from other people that have had better results though.

Compact Flash adapters?

[SpiceWare]

Do Compact Flash Adapters fall under Storage devices?

I'm hacking both of my grandparents' iopeners so they can get email again using any ISP. It would be cool if I could use my existing compact flash cards as "floppies" for putting pictures and software on their systems without having to download them via modem.

Re:Mandrake is already done with 7.1!

[Genom]

Originally, Mandrake was a Redhat base, with bugfixes, some newer stuff, and KDE rather than enlightenment/gnome.

Since then, the've sortof gone their own way - they're still rpm-based, but AFAIK, they're not based on Redhat anymore.

I use Debian myself, though. If someone using Mandrake would correct me if i'm wrong, I'd appreciate it =)

Mod this guy up

[roystgnr]

I'm getting over a hundred kB/sec from ftp.ens.utulsa.edu, which beats the full redhat.com servers and the 10 kB/sec rpmfind.net servers. If you're on ftp.redhat.com, you might want to just grab the MD5SUMS to verify packages with, then move to a less crowded mirror.

Re:Finally, an up 2 date KDE!

[spitzak]

A distribution is not allowed to change /opt, right?

Also there seems to be very strong feelings amoung Linux developers that /opt is a mistake and /usr/local should be used instead. They serve the same purpose and there is no reason for two locations, and /usr/local seems to be winning.

Of course the distribution can't write over /usr/local either.

Re:What about 2.95.3?

[dvdeug]

Yes. 2.95.3 is a minor bugfix release. That means all the problems with 2.95 (C++ incompatibility, etc.) are still there, with the excpetion of a couple major bugs that had easy/small fixes.

Re:What about 2.95.3?

[dvdeug]

Actually, most distributions will just go straight to GCC 3.0. Frankly, I have a hard time believing that a fork of a beta GCC that still isn't released (the release branch of CVS hasn't even bootstraped for days on end recently) is perfect, especially considering that no previous release has ever been perfect.

Just because code is poorly written doesn't mean that gcc can get away with not compiling it. Sucky but standards complaint is still standards compliant code, that needs to be compiled.

Re:Real conclusions

[Kiwi]

You know, there aren't that many DNS servers to choose from. Go read one of the latter lwn.net issues. They summarized the problem quite good. And no djdns is not considered an alternative to bind.

I am working on that particular issue. MaraDNS is a public domain DNS server that I have been working on for the last two months. Currently, MaraDNS has roughtly the functionality of TinyDNS--it works as an authoritative DNS server, but not as a caching DNS server.

A 1.0 release should come out in early June. Look at the roadmap on the MaraDNS web page.

- Sam

Re:Logging filesystem (e.g., reiserfs)?

[Booker]

There may be a 3rd party installer for 7.1+reiserfs, but I know for certain that there is one for SGI's XFS filesystem. See oss.sgi.com/projects/xfs, or search freshmeat for "xfs". Right now it only works with wolverine but that will change shockingly soon. :)

---

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:Red Hat, the only serious distribution.

[Syberghost]

The religon of Islam itself forbits slavery completely.

It also forbids blowing up car bombs on city streets.

-

"Ancient" RPM

[Outland Traveller]

As someone who packages with RPM 3.x regularly, I wish there was better documentation on the changes and new features in RPM 4+. All of the good public documentation for RPM is for version 2.x, and there are a only a few references for 3.x. I haven't been able to find any *usable* documentation for 4.x (No, the changelog is not usable). Is anyone working on this? Why should I stop using my "ancient" RPM version when the new one is undocumented?

-OT

Re:"Ancient" RPM

[bero-rh]

Most of the ancient documentation still applies, since most of the changes were internal (the database format has changed, we're now using db3 instead of db1, stuff like that).

AFAIK our docs people are currently working on updated documentation.

Re:But..

[MSG]

C++ support for GCC has never been that good for exactly those reasons. If Red Hat had used any version of GCC other than egcs 1.1.2 (from 6.2) their C++ binaries would not have been compatible with the older, 6.x versions or the 8.x series which will most likey include gcc 3.0.

Based on that unavoidable problem, and their need to support the Alpha platform, Red Hat's engineers decided to use a version of gcc from CVS, and have done a lot of work to make sure that it's stable. Red Hat 7.0 has been rock steady for me. None of the components have suffered because of gcc 2.96rh. It produces stable binaries. Reports of Red Hat's demise are greatly exaggerated.

But, it appears (see other post) the consensus is to downgrade GCC

This consensus is generally reached by the uninformed. You will only cause yourself headache by doing this.

Re:Use SuSE 7.1?

[rangek]

I used to use Mandrake 7.1 but it seemed a little too proprietary. I'm now using SuSE 7.1

Have you checked out SuSE's licensing? You might want to look at section three of the YaST license.

It is hard to find a Linux distribution more proprietary than that, dontcha think?

Re:Red Hat, the only serious distribution.

[Black Parrot]

> Allah likes his children to only use the works of circumcised men who follow the will of allah. ... So we in syria have started new unix variant.

Trimmed a bit too close with that circumcision knife, eh?

Oh, 'Unix'.

--

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

--

Re:We won't do that

[King Babar]

We think helping GNU parted to get ready is a much nicer way to address this problem.

That would be great. But I have been wondering why parted gets so little recognition these days. When last I used it (to resize a FAT32 partition on an IBM Thinkpad), it Just Worked, which shocked me, considering that nobody in our well-informed Linux users group (MLUG) had apparently ever tried to use it, despite the fact that the "non-destructive resizing" question is a true FAQ.

Re:An open ftp for 7.1

[rc-flyer]

it's there, but the original author seemed to have too much faith in his T-1; the site seems to be slashdotted already.
It is in ftp://ftp.webtrek./pub/mirrors/redhat/linux/7.1/en

Re:For all the redhat ppl reading

[YoJ]

The 7.0 compiler is not reliable. When compiling the NTL libraries, the compiler segfaults. This is bad, compilers are not supposed to crash! Don't tell me that the problem is because the source is no ISO compliant.

Re:even if you thought 7.0 sucked, check this one

[jilles]

I agree. They take a very conservative position towards upgrading. That is good for servers but it really sucks for clients. I love apt-get but I hate to have to point it to obsolete packages. Pointing it to non obsolete packagers automatically makes you a beta tester (which I'm not).

Apperently there are some client oriented debian spinoffs now. I just might try one of them these days.

Re:even if you thought 7.0 sucked, check this one

[jilles]

woody is testing, not stable. And despite rumors on the contrary I have run into trouble using it.

Re:What about 2.95.3?

[avdp]

Or if you read the prior posts, maybe it's YOUR code that sux. Prior versions of gcc were more forgiving with poorly written and/or non-standard compliant code - that doesn't make your code any good.

Revisit your code ASAP and fix it because guess what? RH may be ahead of the rest, but eventually ALL distribution will use this version of gcc.

Re:What about 2.95.3?

[avdp]

I doubt any code is ever perfect - otherwise, why would anyone keep developing it?

But (just like Linux said about 2.4), 2.95.3 is better than it's predecessors, and 3.0 will be better than 2.95.3. But one thing for sure, the people having problems with 2.95.3 will have the same problems with 3.0.

Re:Red Hat, the only serious distribution.

[MindStalker]

Not always, freqently slaves are taken to be rented or sold for sex, it even happends in the US, though significantly less than other countries.

Re:7.1 - GCC version is still 2.96

[Menthos]

Maybe because gcc 2.96 is a better compiler? Bero has a page that you might want to check out.

Problems.

[bogado]

O don't know if it is already to late to report problems here, but I think that this release seawolf is bad in a number of places :

the mouseconfig program creates a /etc/sysconfig/mouse file that the Xconfigurator program thinks it is a bad file.

/etc/init.d/named status does not work. It reports it cannot connect, even though the named is working fine.


--
"take the red pill and you stay in wonderland and I'll show you how deep the rabbit hole goes"

Re:Bad PigleT, Bad! Shame on you

[PigleT]

"what qualifications do you have in the field of software design and verification testing, PigleT?"

What does it matter to you?
As it happens, I have worked in the software testing arena - and I got out pretty fast when I realised it hinges all around the same idea, `official support (with a view to us employing idiots and making lots of money)' rather than clueful knowlege.

FWIW the company for whom I worked in the testing department "supported RH5.2+6.0", and even then they only "supported" Gnome, not KDE, for the front-end GUIs.

"Don't like it? Then go use Debian unstable for all your mission-critical projects. When it breaks, call Debian, not Red Hat."

In nearly 2 years of tracking Debian unstable, I've never yet once had to ask for help in tracking a break, and have no intention of doing so yet.
~Tim
--
.|` Clouds cross the black moonlight,

Re:stupid israeli

[Kartoffel]

That would have been the War of 1812.

Historians cleverly employed an early type of data compression by using the same value for the date and the name of the war ;-)

Re:Mandrake is already done with 7.1!

[jfunk]

stabilitywise Mandrake is shipping known broken components in the kernel (ReiserFS, supermount etc).

I've been using ReiserFS for over a year in SuSE and I haven't had a problem. It is not "known broken." VA seems to trust it enough to store Sourceforge data.

I think everyone will agree that it's Red Hat that have been shipping known broken components in 7.0: gcc, et al.

Also, Red Hat seems to be far behind other distributions in the maintenance of the distribution. The installation and configuration tools are much more mature on Mandrake and SuSE than on Red Hat.

I'm not trying to flame here, but there's this old saying about a pot and a kettle.

Finally, let's include a snippet from my terminal. No it isn't very scientific, AC isn't in there, but...

jfunk@arthur:/usr/src/linux > grep redhat<CREDITS
E: hdeller@redhat.de
E: jakub@redhat.com
E: johnsonm@redhat.com
W: http://www.redhat.com/~johnsonm
E: davem@redhat.com
E: sct@redhat.com
E: dwmw2@redhat.com
jfunk@arthur:/usr/src/linux > grep suse<CREDITS
E: andre@suse.com
E: hohndel@suse.de
E: hubicka@suse.cz
E: aj@suse.de
E: davej@suse.de
W: http://www.suse.de/~davej
E: jack@suse.cz
E: perex@suse.cz
E: pavel@suse.cz
E: mj@suse.cz
E: vojtech@suse.cz

Re:Mandrake is already done with 7.1!

[jfunk]

Your list is bogus

I said it was unscientific and that Alan Cox wasn't on it. Jens Axboe of SuSE isn't on there either.

extremely sensitive to hardware failure - lose a few blocks, and your btree dies.

That's not really true, unless I was dreaming the time the hard drive on my laptop started getting bad blocks. I'm pretty sure that if my btree died, I would have known it.

corrupted data is what you get with the 2.4 kernel SuSE ships.

That's FUD and you know it. I'm on the SuSE english users list and I have heard no such thing.

the SuSE [installer] is really bad

Based on what? What's bad about having Windows partition resizing in it? What's bad about having a list of packages with short descriptions to the right? Icons make no sense because they are all the same. There's nothing you need to graphically differentiate with icons in the installer. It also looks ugly when the package name wraps and there are no short descriptions there.

With the SuSE install, I can make multiple primary partitions. I remember having to write the steps to switch to a console to use fdisk in a paper at work for installing Red Hat.

Have you actually looked at YaST2 and it's design? SuSE customers can do whatever they want with it to make custom installers, etc. Alice is cool, too. I'm even saying this as a Python freak.

Do note that I use both Red Hat and SuSE on a daily basis and I end up doing a lot of installs with both.

An open ftp for 7.1

[X-Nc]

RedHat 7.1 is open and available at ftp://ftp.webtrek.com/pub/mirrors/redhat! Go slashdot the T1 it's on. :-)

---

Re:An open ftp for 7.1

[psergiu]

...NOT

alltrough the transfer rate is great, the iso's are botched (md5sum mismatch)

(I lost 2 hours trying to boot the damn thing :( )


--

Ada95, Bero.

[rjh]

The versions of GNAT that are shipped with Red Hat 7.0 don't work with Red Hat's GCC snapshot[*]. And since you can't recompile GNAT from sources without having a version of GNAT installed to bootstrap itself, that means GNAT is fundamentally and profoundly broken.

This was extremely displeasing to me when I first came across it, because I'm an Ada95 hacker.

[*] No offense meant, guys, but I don't like calling it GCC-2.96; it's not a sanctioned release, so I just feel more comfortable calling it a snapshot. That's not to say I think you guys made the wrong decision; as a C++ hacker, I'm far more pleased with your snapshot than with GCC-2.95.

All this talk about Tux...

[Sylvestre]

Chromium (where I used to work) sells a user space Apache that's as fast as Tux. Too bad I don't work there any more.

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!

[be-fan]

Yahoo. That was soooo funny. Not. It would be, if Windows was actually version 2000.0, but its not, its the version released in the year 2000. I, for one, think this is not at all a bad idea for something like Windows, where major versions are released every few years, and patch-levels are released in service packs. Win2K SP2 is a lot more asthetically pleasing (and informative, since it details the patches installed) than RedHat 7.1 or kernel 2.4.2. There really is no use for the complexity of the three number format (two number are enough to handle most anything pretty well) and stuff like System V R4 or X11 release 5 are just so much more asthetically pleasing. Besides, a version number on a distro is almost 100% useless, since a lot of (I know for sure that at least 90% of you guys have extensively modifed your distros beyond recognition) software on Linux distributions are applied in between version numbers. Thus, the whole arguement over version numbers is more or less moot.

Re:Mandrake is already done with 7.1!

[Nailer]

Likewise, I too have been using ReiserFS with 2.2 for around a year. That said, Civilme on Mandrake's Crashtesters list acknowledges ReiserFS under 2.4 )and perhapds 2.2 - I'm not sure) to be unstable. The message is on the crashtester archives from today, but I've deleted it, so no quote...

Red Hat's gcc was severely broken upon release. But so is the current gcc 1.95. The difference is that 2.95 is currently more broken than 2.96 with all the updates (2.95 can't compile glibc 2.2 on non x86).

I don't think Red Hat should complain Mandrake are `stealing' their compiler. That's *very* weak. Mandrake are more acturately using (and legitimizing) Red Hat's compiler.

Re:Mandrake is already done with 7.1!

[Eil]

If someone using Mandrake would correct me if i'm wrong, I'd appreciate it =)

Nope, you're pretty much exactly right. I think Mandrake is a great distribution, and I'm looking forward to seeing 8.0 in the stores really soon now. Both Gnome and KDE are available in Mandrake, however the distro doesn't seem to place more emphasis on one over the other. But I think if you just choose Newbie Install or whatever, it might put KDE in by default... In any event, I've never had any problems Gnome on Mandrake.

Re:Mandrake is already done with 7.1!

[teg]

Take a look at all the core components, and see whose work it is - it isn't Mandrake. The people who make the it possible work here - no other distribution has a kernel team even remotely comparable to the one we got, and we also have the prime glibc, gcc, gdb, gtk etc. developers working here. FTR, if you look at their beta release, they're even copying our compiler.

As for updates, security in general, etc. you'll notice that RHL is ahead there too. Online updates (up2date) has been around for years. 3D support was added when it was integrated into XFree, and stabilitywise Mandrake is shipping known broken components in the kernel (ReiserFS, supermount etc).

Re:Mandrake is already done with 7.1!

[teg]

Your list is bogus, as quite a few of our kernel hackers don't use their redhat.com addresses their or haver their old addresses in the kernel. Examples are Alan Cox, Al Viro, Doug Ledford, Ben LaHaise, Arjan Van de Ven and Tim Waugh. In fact, the only three of the above who actually work on the kernel are johnsonm, davem and sct.

As for ReiserFS, it had multiple data corruption issues the last two months and it is extremely sensitive to hardware failure - lose a few blocks, and your btree dies. For ext2, you'll typically only loose the files on these blocks.

Wrt. to gcc as shipped in Red Hat Linux 7, there's no doubt this is the best compiler out there currently. The issues are wrt. to binary compatibility with C++ and not sufficient labeling as a release made by Red Hat, not by the gcc steering committee. And even so, this is not data corruption - a bug or two in a app is regrettable, corrupted data unacceptable. And corrupted data is what you get with the 2.4 kernel SuSE ships.

The installation of Red Hat Linux is IMNSHO way ahead of anything else out there - the SuSE one is really bad (and has a non-free license), and I'm not to keen on the Mandrake one either.

Re:Mandrake is already done with 7.1!

[teg]

As for the SuSE installer, that's my personal impression: Nothing else. I don't like it. I've used Red Hat Linux since 2.0ish, and I like our installer very much (I don't miss 40 floppies of slackware:). The only two other installers I've been impressed about in those years are Caldera when they started tetris during install and Corel (apart from it's obvious shortcomings, but it redefines simple). SuSE's installer just seem unpolished and confusing to me.

As for 2.4 kernel, it's not FUD. During heavy load it corrupts your hard drive rather well. Take a look at the last changes for the 2.4 AC kernel, look for corruption and who fixed it and realize SuSEs kernel can destroy your system. No FUD necesarry. We discovered severe disk corruption during testing, and they are present in all vanilla 2.4.x kernels, the previous ac kernels and the kernel SuSE shipped (we tested just for fun). However, SuSE knew their 2.4 kernel was experimental and use 2.2 as default. I'm guessing that because of this, they didn't test it very much.

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:Mandrake is already done with 7.1!

[joestar]

Latest Mandrake releases (e.g. 7.0, 7.1, 7.2 and the newcoming 8.0), are not based on Red Hat at all. The best proof is that they generally introduce new features (such as online updates, USB support, 3D cards support, wheel mouse support, graphical boot, high-level security stuff ...) a long time before Red Hat does. The funny thing is that I generally find (and many people whom I know too) Mandrake more stable than Red Hat at every release (in workstation mode and server as well).

Also Mandrake has made a huge effort on updates (security and bugfixes) which are free and available in real time. The result is that Mandrake, which was the outsider in the Linux-distro game, is gaining huge respectability as an OS. Even Bob Young seems to love Mandrake (read the recent Slashdot article) because this increases the Red Hat potential consumers base for Red Hat derivative products (e.g. not the distro itself)!

The only thing I really don't like in Linux-Mandrake are the colour themes and their icons. I hope it will improve in the future.

Re:Red Hat, the only serious distribution.

[Hard_Code]

Wow, that's ironic, seeing as in the United States, sex trafficking is now considered the third largest source of profits for organized crime, behind only drugs and guns, generating billions of dollars annually.

Re:Smells like BS to me

[Hard_Code]

"Mohammad Ali had 10,000 slaves put to death when he died."

Wow, I knew he was an amazing boxer, but I didn't know he was *that* mean...

install on laptop...

[Hard_Code]

Since Slashdot is naturally my personal Linux support site, let me pose this problem:

ThinkPad 755CX, 24 MB RAM
PCMCIA install through FTP
Error: "You do not have enough RAM to install Red Hat Linux on this machine"

Tried "boot: linux mem=24M", didn't work.

Any ideas?

(RedHat support and searching on the major search engines turns up zilch)

Re:install on laptop...

[bero-rh]

3 possible fixes, but you probably won't like any of them:

1. Get more RAM
2. Install 6.0, then update all packages using rpm -Fvh
3. Boot from a rescue CD, format your filesystem manually, mkdir -p /mnt/whatever/var/lib/rpm; rpm --initdb; rpm -ivh -r /mnt/whatever the packages you need

Anaconda (the installer we've used since 6.1) has a lot of advantages, but its dependency on python and other stuff comes at a price, it's currently quite a memory hog.

That said, I'm running 7.1 on my router (an ancient K5-100 w/ 32 MB RAM) without problems, installed using method #2.

Re:For all the redhat ppl reading

[jovlinger]

No idea if you are a troll or not, but the compiler you ship with 7.0 fails to compile many sources. It is pretty broken.

Regression is a good thing when you've gone too far.

Re:Bad Red Hat, Bad! Shame on you

[jovlinger]

Is the loopback device fixed in the RH 2.4.2? I recall it being pretty much kaput in the vanilla 2.4.2.

Re:For all the redhat ppl reading

[Whelkman]

Only the official IBM kit went away. ODIN (formerly Win-OS/2) is still around and could be just as good (or perhaps better) than WINE.

Re:Red Hat, the only serious distribution.

[be-fan]

Islam isn't a religion of violence. Neither is Christianity, Buddhism, or whatever. However, it is a fact that almost all pervasive religions have been spread through some means of force. The muslims converted parts of Africa and Asia, and the Christians forcibly converted North and South America. There have been tolerant Christain countries (The US for one) and intolerant Christian countries. There have been tolerant muslim countries (early muslic arabic societies and pre WWI Turkey) as well as the muslim parts of the eastern Indian subcontinent, and intolerant muslic societies. This fact is applicable to all religions. Its a sorry truth, but a truth nonetheless.

Re:Will Ship April 23

[treke]

Downloading seawolf isos. Beta 1 was Fisher, Beta 2 was Wolverine. Guessing that seawolf is release.
treke
Fame is a vapor; popularity an accident; the only earthly certainty is oblivion.

A centralized, unsupported package repository.

[Nailer]

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

A centralized repository of packages (unsupported by Red Hat), organized and tested by Open Source maintainers, but providing a wide variety of pakcages.

Users will install unsupported software anyway, but the lack of a single place to find *good* Red Hat packages annoys many Red hat users, myself included (though easily finding the distro better than itys competitors). By using Red Hat's bandwidth and mirroring, it would be *the* first place to look to find packages. With an appropriate warning, up2date could also get packages from these mirrors.

Re:A centralized, unsupported package repository.

[danpbrowning]

rpmfind.net?

Umm Alan doesn't.

[Nailer]

Yes we. Do. We also remeber lan's reply - while Alan works for Red Hat, I doubt he's one to mince words, as would most people who have had some contact with him would attest.

I know who I would trust with my kernel. Can't remember the link - Google is your friend.

Re:Red Hat, the only serious distribution.

[ndfa]

Where my man have you heard of slavery in Islam ? Please go look up a history book to find that long before America decided to free slaves, Prophet Mohammad (Peace be Upon Him) would free any slave that came to his house. The religon of Islam itself forbits slavery completely. If you have heard of such a thing, i fear that it was just more FUD. Dont believe everything you hear, or for that matter a lot of things you see. If you are able to read, why dont you go read about the religon and not just believe any crap someone tells you.

Re:Smells like BS to me

[ndfa]

Well you are not talking about religon then. You are talking about the ppl. that follow it! In that case what you are saying is well...
For all religons there exist men that do bad things, this i agree with.
What I dont agree with is your backward conclusion that since a few ppl. took part in slavery, AND they were in fact followers of a religon, than the religon allows it!

*grin*

[Webmoth]

"...I'm gonna spend all morning deleting this submission *grin*."

I always got the impression that you enjoyed deleting submissions.

~J

Re:Anyone see this in Wired?

[AugstWest]

It's not my page, I just find different links on occasion.

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

Umm Linus thinks there's a problem...

[Arker]

Remember this?

http://www.uwsg.indiana.edu/hypermail/linux/kern el /0012.1/1252.html for the link-shy.

"That old saw about the early bird just goes to show that the worm should have stayed in bed."

Re:It's there

[Chanc_Gorkon]

Sparc's been discontinued with 7.0 (try looking for a 7.0 iso for sparc...ain't no such thing). The latesr sparc iso (from redhat anyway) would be 6.2. Here's a link.

Re:For all the redhat ppl reading

[rasjani]

• Also, inetd.conf has no way of providing information like permitted/rejected IPs.

Really ? Ok, that is true but most programs that are really required to be invoked from inetd are either compiled to use tcpd libs (for example, ssh imho) OR use the tcpd binary which provides mechanism for hosts.allow and host.deny and clearly you know these provide the described functionality. Ok, that leaves out the part of providing information of the use. Lets see how that can be managed.

When daemon spawns, let it be ftp or telnet, and connection is established you can see that from your logs. So, that clears the "allowed ip" part. So, what about denied connections. I can say that i didnt really require such things since i use FIREWALL to block unwanted connections. BUT, if firewalling is out of the questions, we can still rely on the hosts.allow and hosts.deny. For example, line like this in my hosts.allow

• ALL : ALL : spawn (/usr/sbin/safe_finger -l @%h | /bin/mail -s "Port Denial note d %d-%h" root) & : DENY

And ofcourse, i have listed all IP's that i allow connections from (in hosts.allow AND in firewall) and so if somehow someone manages to get past the packet filtering, i still get info about the suspicious activity.

... And all this without xinetd ... Evolving because of stupidity leads nowhere.

--

Re:which 2.4?

[teg]

Does anyone know which version of the 2.4 kernel they are including?

An early 2.4.2ac with _lots_ of bugfixes - the kernel team fixed a couple of file corruption bugs a day for weeks.

Re:It's there

[teg]

There are no iso files for Alpha, as we haven't announced a product for Alpha yet.

As for SPARC, we're not doing distributions of it - just development snapshots. It's just not worth the development, QA and manufacturing effort right now.

Re:What's this "Tux"?

[teg]

Tux isn't khttpd.

Re:Instability...

[teg]

There aren't known stability issues with Red Hat Linux 7 - of course, as with any distribution you should apply the updates for it but few of these are Red Hat specific. With those, it's a great platform with good performance.

Re:�Download and install 2.95.3

[teg]

But why would you want to? The version we ship produces better code, has more bugfixes and less known problems and is binary compatible with the rest of the distrubution.

Using gcc 2.95.3 is setting you up for a world of PM.

Re:which 2.4?

[teg]

The i686 glibc supports the 2.4 feature "floating stacks" - variable stack size for threads. Existing JDKs have a hardcoded assumption of 2 MB, and this limit in strange, weird and unsupported ways.

There are two work arounds for these buggy JDKs:

• Install the i386 glibc, not the i686 glibc. It doesn't require a 2.4 kernel and doesn't have floating stacks.
• Run your JDK with 'LD_ASSUME_KERNEL=2.2.5'.

Either one should work. We also expect fixed JDKs to become available in the not too distant future.

Re:APT-GET in Redhat

[teg]

AFAIR, you get free usage of one system ("trial") but need to pay if you want to add more systems.

Re:APT-GET in Redhat

[teg]

up2date also has functionality not found in apt-get, such as server/client authentication and verification of the origins of the update (the latter may be solved in the rpm version of apt, but standard Debian can't do it - get trojaned packages onto a mirror, and watch people use it)

Re:EXT3?

[teg]

No, our kernel people don't think it's safe - ReiserFS had quite a few bugs fixed the last month or so. And for filesystems, data integrity is an absolute requirement - this is the first distribution with a 2.4 kernel not known to destroy filesystems under load.

It is enabled in the kernel, but not during install.

Re:�Download and install 2.95.3

[teg]

Note that the updates will break some builds - e.g. newer glibc cleaned up some name space polllution ( vs ), this broke compiling for a lot of packages. Both the pollution and the apps depending on it were fixed for Red Hat Linux 7., but this not released for RHL 7 as it didn't affect functionality.

We do mass rebuilds on a regular basis, so the packages should build - if you experience bugs with this, report it in bugzilla

Re:But why not qmail or djbdns?

[teg]

Qmail and djbdns are not open source, - we couldn't even distribute a fixed version of qmail if a security hole appears. This isn't acceptable.

As for netscape, we're on the way of getting rid of it as mozilla improves.

Re:64 GB of RAM

[teg]

Having 64 GB of RAM won't help you with quake III. IA32 is still a 32-bit architecture, so one process can only see 4 GB at a time.

Re:APT-GET in Redhat

[teg]

Since when did debian packages support cryptographic authentication? I'm quite sure that would be a recent addition.

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:Release vs. Beta

[bero-rh]

Easy:

• Bugfixes
• Minor updates (such as KDE 2.1 -> 2.1.1)

We don't introduce any features after the beta cycle. Untested features don't help anyone.

Re:USB?

[bero-rh]

From the kernel's make {menu,x,}config USB section:

Audio devices
Bluetooth devices
Storage devices
Modems
Printers
Keyboards, Mice, Joysticks
DAB (Digital Audio Broadcasting)
Network devices
USB-Parport
USB-Serial converter
various USB scanners and cameras
MP3 players

Re:Do you still need 2 compilers

[bero-rh]

You *can* install it. If you want to use a stoneage compiler with tons of known issues, that's your choice.
You don't need to, though.

Re:Java horked in this one too?

[bero-rh]

This is a bug in the JVM, not in Red Hat Linux.
The JVM can't deal with some of glibc 2.2.2's new features, and since we don't have the source, there's nothing we can do about it (another reason not to use proprietary software unless absolutely necessary).

IIRC, it should work with the i386 version of glibc since (unlike the i686 version) it doesn't support floating stacks.

Check the release notes for details.

Re:APT-GET in Redhat

[bero-rh]

We aren't shipping it, but we've fixed up and extended up2date to provide pretty much the same functionality (and yes, it works in text mode).

Re:One Question Sparc/Sparc64 support?

[bero-rh]

I'm a developer, not a product manager...

But I can tell you that the sparc build machines are still in the build system, so even if there isn't an official product, you can get rawhide.

I don't have a sparc and I'm not in an office with many test machines, so I can't tell you how well it works.

Re:EXT3?

[bero-rh]

It's not in there, simply because it hasn't been ported to kernel 2.4 yet. The current version for 2.2.x kernels is stable though.

It'll almost certainly be in the next version.

Re:gcc version 2.96RH???

[bero-rh]

It's up and running despite the 5515 accesses within the last 15 minutes (great stability test for 7.1, which is already running on the server). It's on a relatively slow line though (connectivity is terribly expensive around here, monopolists suck!), so you might be getting timeouts.

Re:Logging filesystem (e.g., reiserfs)?

[bero-rh]

Not yet - ext3 hasn't been ported to kernel 2.4 yet and reiserfs still hasn't stabilized enough.

This (actually both of these points) will almost certainly change in the next release.

Re:Finally, an up 2 date KDE!

[bero-rh]

We wanted to include KDE 2.0 the last time around - unfortunately, its release schedule didn't go along well with ours. We can't include anything in a release that is released some weeks after we go gold, can we?

We're definitely glad we finally have a version of KDE that doesn't depend on a not-100%-free version of Qt, and especially one that works this well (posting this from Konqueror).

Re:Pricing and features

[bero-rh]

While sabotaging the kernel like that wouldn't be a violation of the GPL (the GPL allows to make any changes, even adding a bluescreen module), it would definitely be a horrible thing to do, and something we'd never do.

This is talking about support as in "you may call our support center and ask the people how to set up software RAID without paying extra".

Of course the normal version supports software RAID, but you're on your own (or need to buy a support contract) if you can't figure out how to set it up.

Re:We won't do that

[bero-rh]

Not really.
I use Konqueror 99% of the time, but if I need to use Java (e.g. for my bank's online banking system), I can't get around Netscape 4.x for now.

The problem is that Konqueror and Mozilla can't handle Java without an installed JVM - and there's no working free JVM out there. (Kaffe is a start, but not really usable yet).

Unlike the various JDKs out there, Netscape 4.x is at least freely redistributable. That's why we're keeping it in for now.

"Install Red Hat Linux, then go download a JDK at xyz.com" is not an option for many people out there - for example in most parts of Europe, people still pay for net connections by the minute. Even if there's no per minute charge, people are still bandwidth imparied even if they need highspeed access. I'm posting this over a 64 kBit/s line by the way - it's the fastest link available around here. My order for a DSL link has been waiting for that evil monopolist for 15 months by now.

#include

Re:Bad Red Hat, Bad! Shame on you

[bero-rh]

The kernel release was "late" for our deadlines. They're not marketing deadlines, but ones that make sense. 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.

You need to make a cut at some point. For us, that's "when it's ready". 2.4.2 with our patches *is* ready for prime time, so there was no need to delay the deadline any more.

Not officially supporting anything that hasn't passed QA isn't corporate idiocy either. It's simply practical. If someone calls support and complains "apache doesn't work", how are they supposed to help the user efficiently if he's using a kernel and glibc we didn't approve or test?

Re:What about 2.95.3?

[bero-rh]

2.95.3 is just 2.95.2 with a couple of fixes for the most critical bugs.
It doesn't address any of the features in 2.96 we need, such as real C++ support or ia64 support.

Re:For all the redhat ppl reading

[bero-rh]

That's because the sources are broken (not ISO C99/ISO C++98 compliant), not because the compiler is broken.

Check http://www.bero.org/gcc296.html for a couple of examples of broken code that used to work with older compilers, and how to fix it.

Re:For all the redhat ppl reading

[bero-rh]

wine: Some of us have sent in a couple of patches, but we're not the big guys behind wine, for the reasons mentioned before. wine is broken by definition (any emulation of an inherently broken API will have to be broken), and we'd rather push native applications than pushing an emulation layer and thereby the broken API it emulates, even though wine is nice to have ATM.

gcc 2.96 can compile code you can use on any other linux distro. The compatibility problem is related to C++ name mangling changes. Those haven't been consistant between any 2 major gcc releases, and that won't change until gcc 3.0 is out.
If you aren't using C++, you won't run into any problems. If you're using C++, either inlcude our libstdc++ in your binary distribution or link statically.

Re:the latest software except....

[bero-rh]

Actually we're pretty much shipping both of them, Netscape 6.01 isn't that different from mozilla 0.7 (just more buggy ;) ).

Replacing one piece of proprietary **** with another is not an option IMO - the right replacements ATM are Konqueror and Mozilla, unless Opera decides to go open source. (Can Opera do anything Konqueror can't do ATM, anyway?)

Re:Will using 386 vers. of glib break anything els

[bero-rh]

No, it'll just slow things down. A lot.
Also, s/glib/glibc/, they're two quite different beasts.

Re:For all the redhat ppl reading

[bero-rh]

No. We're including Qt 2.3.0, Freetype 2.0.1, XFree86 4.0.3 and KDE 2.1.1 + extra fixes.

Anti-Aliasing is turned off by default, but turning it on is as simple as clicking a checkbox in KControl.

Re:Bad Red Hat, Bad! Shame on you

[bero-rh]

We're including both. The old one is called aic7xxx, the new one is aic7xxx_new/aic7xxx_mod.

AFAIK the old (proven stable) one is used by default.

Re:which 2.4?

[bero-rh]

AFAIK with x >= 5, so it's not a problem.
Recent releases of rpm 3.0.x can handle v4 packages.

Re:which 2.4? & SRPMS

[bero-rh]

I can't reproduce the compiler problems you're talking about. We didn't use any non-2.96 compilers for building 7.0 and all errata packages. Chances are you didn't install a required -devel package or you're using nonstandard kernel headers.

As for not getting a response from support, this isn't nice (and I can't verify what's up, I'm in development, not support), but it's understandable.
Unless you've purchased a support contract, you'll only get installation support (even Red Hat has to live of something), and since you think you've found a bug, you should have reported it to our bug tracking system at http://bugzilla.redhat.com/bugzilla/ instead. You usually get replies to bugzilla entries in a reasonable time.

Re:Finally, an up 2 date KDE!

[bero-rh]

And in violation of the FHS... :)
</mode>

The FHS mentions the distribution updates shouldn't touch anything in /opt without prompting the user, and we don't want to break update functionality.

/opt (just like /usr/local) is a good place for KDE if it's installed from source, or from packages not provided by the distribution.

Re:Precisely the problem!

[bero-rh]

You're forgetting that the binary incompatibility things affect any version of gcc.
If you have 2.95 and start updating to 3.0, you'll run into the exact same binary compatibility problems you'll have when you start updating from 2.96 to 3.0.

Same for egcs.

Yes, this sucks. The fix is to use gcc 3.0, which won't be out for a while - we (and probably all the other distributions) will fix it when it's ready. ;)

Re:�Download and install 2.95.3

[bero-rh]

So, where did you report your issues? If you reported them to support, it was simply the wrong place. They should have told you, but they're probably too overloaded at times.

The right place to report bugs is http://bugzilla.redhat.com/bugzilla.

Since we can recompile all SRPMs with our compiler (how do we think we're putting together the distribution? Check the headers in the binaries and you'll see that we do eat our own dogfood), you'll probably get a "RESOLVED: NOTABUG" and a "We can't reproduce this, must be a local configuration issue, make sure you installed the correct version of glibc-devel", but we'd rather get 30 bug reports about things that are actually a local configuration issue than missing one genuine bug report.

Re:For all the redhat ppl reading

[bero-rh]

I've had much better results with the current release (using the wine package from 7.1 Powertools).

I don't have Windows or any of its DLLs, but all the stuff I've tried works almost perfectly (meaning I get occasional glitches in the display, but I can get the work done). It's mostly small tools though, such as a tool for filling out tax froms, an electronic phone book and an electronic map.

Re:For all the redhat ppl reading

[bero-rh]

2.96-81 (from 7.1) fixes every genuine bug people reported to us.
Code that doesn't compile correctly with it will almost certainly not compile with gcc 3.0 when it's released.

As for the (double) and (float) things you're mentioning, we aren't aware of any problems.
What exactly is the problem? Do you have some sample code?

If so, report it at our bug tracking system and/or drop me a message.

Re:the latest software except....

[bero-rh]

Get kmail from the current KDE CVS tree.

Re:RH - alwas live on /.

[bero-rh]

Apache 1.3.19 is included in 7.1 (You can always verify what version of apache and PHP is in the current release by checking what netcraft says about www.bero.org ;) ).

You can download the 7.1 package from ftp (and it should work without changes on 7.0), but there probably won't be an errata release for older versions (since the old one didn't have any major problems, at least none I'm aware of, but I don't maintain the apache package).

Updates will always be available over ftp in addition to RHN, at least for the foreseeable future.

Re:not really on topic.

[bero-rh]

I'm not going to get into any "my distribution is better than yours" flamewars. It should be fairly obvious what I'm using ;), and I'm constantly trying everything else ("stealing" features is part of the job ;) ).

My general recommendation is "try everything, stay with what you like best".

Re:Tax software under Wine

[bero-rh]

Since I'm located in .de, I need to use quite different tools. FTR I used "WISO Steuersparbuch 2000" with the wine package from 7.0 powertools back then. It's still working with the one from 7.1 powertools.
No windows DLLs, just the standard setup from the package.

Re:But why not qmail or djbdns?

[bero-rh]

Bind 9.0 is safer because it was written from scratch with security in mind, unlike the prior versions.

qmail and djbdns are not open source, so we aren't going to ship them unless the license changes.
Netscape will disappear in future releases, so it won't be hypocritical anymore.

Re:BERO - (Experimental) Reiserfs Installer?

[bero-rh]

I'll forward your request to our installer people - can't promise anything though.

Just bootdisks won't do, though - unless I'm badly mistaken, the tools handling filesystem creation and stuff are in the second stage image, meaning you won't get around without modified ISOs.

Re:For all the redhat ppl reading

[bero-rh]

Because it's not really stable yet.

Re:For all the redhat ppl reading

[bero-rh]

No, because even on cards that support it well, Antialiasing can cause some problems and should be disabled by default.

Right now, Xrender is known to choose very poor replacements for bitmapped fonts (that can't be antialiased).

Xrender is pretty much a work in progress. We'll enable it by default when we think it's ready.

(Ok, since I (mostly) control the KDE and Qt packages, make that "when I think it's ready" Send bribery in cash^H^H^H^H^H^H^H^H^H^H^H^H^H^H^Hgood arguments my way. ;) ).

Re:3D

[bero-rh]

I don't have Quake 3, but some of the open source 3D games we're shipping in Powertools (Chromium etc.) are working nicely on my Matrox G400 with hardware acceleration enabled.

Re:Kernel 2.4.3 has ReiserFs included by default

[bero-rh]

We're building the kernel module actually, so you can use it on filesystems you create after the installation.

That doesn't make it stable though.

Yes, it works well under normal circumstances.

But as soon as something odd happens, it breaks badly.
There are still some known cases of ReiserFS causing filesystem corruption under high load, and its userland recovery tools aren't ready for prime time.
Try recovering from a hardware defect (or a simulated one, try dd if=/dev/random of=/dev/hda offset=something count=10) with ReiserFS, try again with ext2. Notice the difference?

I have no doubt that ReiserFS will eventually get there, but it has quite a way to go before it's really stable for production use.

Re:What about DSL and Cable connections?

[bero-rh]

7.1 supports them. Getting a DSL or cable connection up is as easy as calling "internet-config" and filling out a form.

AFAIK we aren't providing support for it at installation time ATM, so you can't run a network install over DSL.

Re:Going home to Debian

[bero-rh]

While Debian is definitely a nice distribution and certainly has some advantages and deserves mentioning and all, please don't spread FUD about Red Hat (or other distributions).

We don't waste all our time looking at stock tickers (actually I have no clue what our current stock price is), and I dare say that redhat-watch-list, redhat-list and all are just as good as their Debian equivalents. I haven't seen any mention of stock on the lists.

Similarily, please provide constructive criticism. Let me know why you claim ISDN didn't work rather than just stating it didn't work. We have isdn-config in 7.0, internet-config in 7.1 - did they give you an error message? Didn't you find them? What's the problem?
It's hard to fix "x doesn't work" if it works perfectly for all of us.

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:For all the redhat ppl reading

[Fjord]

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.

I've read this argument a lot on /. and I have to say I still don't buy it. Why do I think a standard wine installation is a good thing? Because it may make Windows developers seek to be able to run their application on Linux. If there is a layer like wine, that provides 99% of the functionality of windows, then Windows developers may decide to target that 99%. In the extreme case, they will develop under Wine, but in other cases, they will add Wine to their QA cycles.

I don't honestly see an advantage to having companies port their products to linux, when porting them (or designing them) to wine will sufice. At this point, wine can only strengthen our position by giving us more applications. If linux runs 100% of all windows apps, then linux runs more apps than windows (well, apparently there is a linux layer for windows now).

A standard installation and configuration of Wine would really help out.

Re:where ?

[Deadbolt]

You are a god to us as well. Where can we paypal you $10 of beer money for your trouble? :)

Smells like BS to me

[twitter]

All men, of all religions have practiced slavery.

Arab, mostly Islamic, slavers in East Africa were some of the worst. British explorers in the 19th century found the people there overwhelmed and shattered. Mohammad Ali had 10,000 slaves put to death when he died.

Other abductions practiced by men who professed Islam were even more sinister. The pre Napolianic rulers of Egypt were homosexuals who propagated themselves by abducting boys from the Rusian steps. Most of us are familiar with cartoon harems and their eunich gaurds. Think about it a while. The behavior of Turks as they invaded East Europe rivals anthing in the Spanish Inquisition.

All men do such things, regardless of religion. Hindus, Jews, Budists, Shintoist, have all commited attrocities. Only the neo pagans under Hitler or Stalin's neo atheists have proved more cruel.

What's this "Tux"?

[andy@petdance.com]

TUX - world's fastest web server

I must have been under a rock, 'cause I've never heard of Tux.

How much faster than Apache can you want? I mean, unless you're serving porn off a 486, Apache's gotta be fast enough, no?
--

Re:What's this "Tux"?

[pjrc]

This page on the spec.org site shows a comparison of the three servers:

• TUX 1.0 wins with scores 1270, 2200, and 4200 (1, 2, and 4 CPU) on Dell x86 servers
• Zeus 3.3.5 in second place with 1050, 2200, and 3216 on Alpha and RS6000 (2, 6, and 8 CPU)
• poor Microsoft IIS 5.0 in last place, pulling scores of about from 700, 1180, and 1600 on x86 (1, 2, and 4 CPU).

All in all, pretty much what you'd expect: high end performance on high dollar workstation hardware, good performance per dollar on commodity x86 hardware using microsoft....

Except TUX 1.0 comes along with the 4 CPU Dell PC outperforming an 8 CPU RS6000 box, the 2 CPU PC equalling the 6 CPU RS6000, and TUX 1.0 on just two x86 CPU greatly outperforming Microsoft IIS 5.0 running on four x86 CPUs !!

Talk about an upset!

Of course, this is all just benchmarking taken to the extreem... do it really matter if your web server can fill a gigabit ethernet pipe?

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

Well...

[Galvatron]

It IS the latest version of Linux right now, unless someone else also released a new version of a distro today, right?

Seriously though, that's pretty bad. People joke on /. all the time about newbies thinking that Red Hat = Linux, but I never thought a professional magazine would do that...

The only "intuitive" interface is the nipple. After that, it's all learned.

Linux Mandrake!

[Galvatron]

Mandrake has supported ATA/66 since at least 7.1, maybe earlier. I don't know about 2.4.x kernels, but I'm downloading RH 7.1 & will advise.

The only "intuitive" interface is the nipple. After that, it's all learned.

�Download and install 2.95.3

[yerricde]

Does it fix the GCC C++ issues?

Even if it still ships with Red Hat GCC version "2.96," you can still use it to recompile GCC 2.95.3 (last stable version; mirrors here), Linux itself, and your apps.

What about 2.95.3?

[yerricde]

You *can* install [GCC 2.91 as kgcc]. If you want to use a stoneage compiler with tons of known issues, that's your choice.

What about GCC 2.95.3? It fixes the incompatibilities with glibc 2.2. (Given, it wasn't out yet when Red Hat 7.0 was released.) Any big problems with 2.95.3 (official GNU source release) as opposed to 2.96 (RH fork)?

These switches will help immensely

[yerricde]

Are there any switches in RH7.1 gcc-2.96RH which will TELL ME which part of my code is NONCOMPLIANT, POORLY WRITTEN, ETC (all these vague terms).

gcc -Wall -W -pedantic
If you use these switches, it's more likely that

gcc will tell me what is wrong rather than just compiling and then getting runtime garbage

Re:Red Hat, the only serious distribution.

[Mr.Phil]

Moderation Totals:Flamebait=2, Troll=2, Insightful=1, Interesting=1, Informative=2, Funny=5, Overrated=1, Total=14.

Meta Moderators to the Rescue!

Re:EXT3?

[ssimpson]

I'd install this version in a flash, but I understand there is still no ReiserFS as an install option :(

And "no" - I'm not bright enough to install with ext2 and convert! ;)

Re:which 2.4? & SRPMS

[Tassach]

I've heard no end of pissing and moaning about how "buggy" RH 7.0 is. I've been running it since about the first week it was released, and have yet to experience any of the problems people have been bitching about. Most of the bitching sounds like FUD to me; RH is too "popular" and "mainstream" for some people, so they feel that it's necessary to trash-talk it. The ONLY incompatability I've run across so far is Angband. If it really bothered me, I'd debug the problem myself.

Since I use my machine mostly for software development - java servlets and Sybase database stuff mostly. The software that I need -- various JDK's, Sun's Forte for Java IDE, Sybase, Apache + Tomcat, VMware -- are all rock-solid stable under RH 7.0 + KDE 2.1.

I'm a little alarmed to learn that there are some JDK compatability problems in 7.1, so I'll probably be holding off upgrading for a few weeks until this is fixed.

Re:ATA/66 support?

[Nohea]

I use ata/66 with a stock 2.4.3 kernel, no patch. This is on RH 6.2, i don't know if RH 7.1 will have it enabled by default, but i'm guessing it will.

I have HPT366 module enabled in kerkel config, but i saw support for CMD64X too. If you are compliing yr own kernel, you just have to enable it, along w/ a few other things.

Try it and forget 2.2, unless you need a stable server or something like that.

Re:the latest software except....

[Nohea]

Mozilla Mail/News works too, i use it w/ IMAP over SSL.

Damn...

[zaius]

I was just finishing patching 7.0 into a usable state...

Bad Red Hat, Bad! Shame on you

[cr@ckwhore]

Red Hat -- While I'm fairly impressed with the features of the 7.1 release, I'm not exactly thrilled that you went and wrote custom patches for your own kernel. Why bother with the 2.4.2 kernel anyway, because I'm sure most of the bug fixes you were after have probably been fixed in the real 2.4.3 kernel.

Usually, directly following an RH install, the first thing I do is replace the kernel with my own. Now, I'm curious what I'm going to break in RH7.1 by replacing your proprietary kernel. Will you support that? (hardly think so)

Did you submit your "bug fixes" to the real kernel?

Re:even if you thought 7.0 sucked, check this one

[SquadBoy]

This has been true of RH for a *very* long time. Yet another reason to use Debian.

Re:For all the redhat ppl reading

[SquadBoy]

Even though I don't use RH I must say the above is well put. xinetd is a Good Thing. While I disagree with the GCC thing I can see how you might have come to the conclusion that you come to. Everybody, myself included, that I know who uses Wine use the cvs stuff anyway so no problem there. And yes dispite what I may think of many aspects of RH much of the GPLed code that comes from there is good work. Also writing Alan Cox's paycheck has got to be worth something. :) All in all good work.

Security

[Fervent]

Sweet. I was waiting for RedHat to have a solid release with KDE 2.

My only concern: will security be tighter after the 7.0 debacle?

Re:Security

[Fervent]

Sorry, I meant the bug debacle. Although weren't most of the bugs security-related?

Re:APT-GET in Redhat

[JCCyC]

Is it still free (as in beer)? I heard you have to buy a subscription now. If this is so, I'll stay with Red Carpet. Third world income level, you know. ;)

Bad PigleT, Bad! Shame on you

[satch89450]

PigleT sez: "Bullshit. How the heck can a kernel be released `late'?? ... As it is, 2.4.3 has been around since Mar 30; I don't see why one package can't get a proper testing in that amount of time. "

18 days? For a package which requires multiple CD-ROMs to distribute? Especially one as complex as a Unix distribution? Do you have any idea how many opportunities there are for unfortunate interactions? No, let me make this stronger: what qualifications do you have in the field of software design and verification testing, PigleT?

When I was managing DVT for a single product of 45,000 lines of code, the entire testing suite required about 40 days to complete...if there wasn't a problem. Final verification after "the last bug fix" required 10 days. By the way, "day" was defined as 24 hours, and included weekends and holidays, using as much automation as we could muster. The crew was nine people full-time, and about 100 alpha testers, as well as a development corps of about 20 programmers who had their own, separately-developed DVT for design changes.

In some respects, testing a well-designed and well-implemented operating system is easier, because you have far more separation of function; in some respects an OS is far harder because of the unfortunate unforseen interactions that can crop up in any co-ordinated resource management system. Further complicating the DVT of an OS is that the problem set is not under the control of the developing company -- you have applications programs that delight in tripping up even the most careful of OS writers.

Red Hat is trying to sell a supported solution to non-geeks, and in particular to companies more interested in doing what they do -- be that selling toothbrushes, building cars, collecting taxes, shooting metal objects into space, curing cancer -- and not have to worry about every little thing about the OS they are running. In order to meet the needs of their target customers, they have to tread cautiously when putting together their distribution. Like Microsoft, they need to control the cost of technical support, and one way to do that is to test the hell out of the product before putting their name on it. That's the way they decided to do business.

Don't like it? Then go use Debian unstable for all your mission-critical projects. When it breaks, call Debian, not Red Hat.

It's your choice.

Contains TUX - world's fastest web server

[Delirium Tremens]

RedHat finally ships the long awaited TUX server. This is version 2.0 and it holds SPECweb99TM benchmark records for 1, 2, 4, and 8 processor machines.

Re:Contains TUX - world's fastest web server

[Delirium Tremens]

Below is some more info I just summarized from an old Slashdot Story last July. Anybody knows what else we have in Tux 2.0?

1. The various layers of modularity in TUX 1.0 are:

• 'accelerated requests', automated by TUX. (static GETs, etc.)
• 'kernel-space' or 'user-space' TUX modules (no context switching between processes that load CGI-like dynamic libs)
• 'fast socket-redirection to other webservers'
• 'external CGIs' (the usual CGIs)

2. TUX 1.0 uses "per-CPU" Caches. The concept is this: when freeing buffers TUX keeps them in per-CPU pools, and if the same type of buffer gets allocated shortly afterwards TUX picks from the pool that belongs to that CPU. Also, the Object cache is managed by a LRU mechanism, so objects accessed less frequently will get deallocated if memory pressure rises.

New Features in Tux 2.0

[Delirium Tremens]

From the Tux 2.0 Home page:

Enhancements
A number of incremental enhancements have been made:

• True zero-copy disk reads: Whereas TUX 1.0 copied files into a temporary buffer, TUX 2.0 is integrated with the page cache and thus uses zero-copy block I/O.

• Generic zero-copy network writes: TUX 2.0 uses the generic zero-copy TCP framework.

• Zero-copy parsing: Where possible, TUX parses input packets directly. Even in RAM-limited situations, TUX now does full, back-to-back zero-copy I/O.

Other changes include:

• Enhanced user-space utilities and module support.

• Mass virtual hosting support. The host-based virtual server patch has been added to TUX. There is no limit on the number of virtual hosts supported, only RAM and diskspace.

• CGIs can be bound to particular CPUs or can be left unbound.

• A number of bugs were fixed which caused performance problems - TUX 2.0 is now significantly faster than TUX 1.0!

--
And sorry for replying to myself. I didn't have this information in my previous posts.

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.

Use SuSE 7.1?

[crusher-1]

I've heard about too many problems with The RH distro's (like the gcc version in 7.0, etc). I used to use Mandrake 7.1 but it seemed a little too proprietary. I'm now using SuSE 7.1, and though it's not perfect I'm fairly pleased. I might try RH 7.1, but after reading some of the posts about it refusing to see hdd's and cdrom's, I'll wait to see what else shakes out.

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!

Re:What about DSL and Cable connections?

[azrix]

Well, ah, what the fuck are you talking about? Are you talking about installing over Cable? Not sure I could do that with my DSL, but I don't really care to. I just want to actually be able to surf the net and download the occasional .rpm or .tar.gz. I haven't been able to do that under Red Hat 7.0. I was wondering if there was going to be an easier way to setup the connection with Red Hat 7.1.

As for Suse, they haven't broken the GPL as far as I know. But they are acting like a traditional proprietary software company with the non-release of installation iso's of 7.0 and 7.1 and letting the cat out of the bag that the Suse Linux OS and their setup software, YAST, is not under any free software license, but under their own Suse-YAST license. Part of it says that you can't copy and freely redistribute copies of Suse Linux or their YAST setup software. You have to get permission from Suse to do that. I had never heard this until the recent release of 7.1. If you want to read about it check out the news section at LinuxISO.org. It was news to me and completely turned me off to Suse. While this may not contradict the letter of the GPL, in my mind it contradicts the spirit of the GPL, and I don't agree with it.

On a side note, I find it funny that people bash Red Hat, when, as far as I know, all the software they make is under a free software license. Yet, Suse can away with crap like this without anyone saying a thing.