Mandrake 8.0 Beta Released

Boiling rumors can now be set aside: Linux-Mandrake's 8.0 beta is ready for grabbing. Before you complain about Version Inflation (Slackware, Red Hat and others should come out with v10 just for fun), read the fine print indicating that by using this beta version, you're surrendering your machine to the winds of time, and French aliens may come kidnap you and your data for sheer sadistic sport. That is, especially if you have a VIA Apollo Pro or KT133 Chipsets and a WD drive greater than 8.4Gb in size. So the real 8.0 isn't ready yet (that will be the time to complain about version inflation proper), but like Red Hat's Fisher, this is a nice way to experience upgrades all around the mulberry bush, including a 2.4 kernel (2.4.2, actually) without building them all yourself.

Comments

Read these articles

[deno]

Civileme has been investigating this for quite some time, and he wrote about it on Mandrakeforum. It looks as if WD has severe QA problems, and this time it got a help from chipset and a bug (or at least lack of workaround) in kernel.

Here are the stories:

• Numerical Analysis & the Walrus
• What Now? WINDisks, of course
• Is this Computer Science or Voodoo?

Civileme even claims that WD drives just fake CRC, but it's difficult to say if there is some truth in this or not. One is sure: these beasts cause a lot of trouble.

My problems with Western Digital...

[slothbait]

Having a WD drive bit me pretty bad about a year ago. A week or so after a kernel recompile, I wound up with filesystem corruption, even though I was running a stable kernel. I take my computer very seriously, and though I was able to recover my important data, losing the filesystem hurt *bad*.

My faith in Linux took a big hit after that. The only explanations for that error were 1) hardware failure (seemed unlikely) or 2) serious kernel bug. I contemplated migrating to FreeBSD, but was informed that much of the IDE code between Linux and BSD is shared, so any fundamental bug would probably follow me to the new platform. So, I just rebuilt my system and carried on.

A few months later I was reading Kernel Traffic, and someone posted a filesystem corruption problem with the exact same symptoms, using the exact same WD hard drive. One of the hackers identified the source of the problem -- it was Western Digital.

Some models of WD drives are advertised as "UDMA compatible". That is, you can enable UDMA and they will run. However, WD is sidestepping the fact that the drives are *not* UDMA "compliant". Apparently a part of the UDMA spec is the transmission of periodic CRC checks to detect and correct errors. Some WD drives will operate in this mode, but blow off the CRC checks. This is suicidal. If the drive is used in UDMA mode (which it claims compatibility with) you *will* get data corruption...it's just a matter of when and how bad.

Thinking back before the failure, sure enough, I had enabled UDMA in the kernel, looking for a speedup from my UDMA "compatible" drive. WD had mislead me in the features of that drive, and it resulted in data loss. I view this as highly irresponsible on their part, and I will certainly not buy from them again.

--Lenny

Fine Print

[Doug Merritt]

Since the ftp site is slashdotted, here's the fine print in question:

Applicability: Linux-Mandrake 8.0 BETA 1 WARNING This BETA has the potential to mis- recognize the drive geometry on systems with VIAApollo Pro or KT133 Chipsets and WD drives greaterthan 8.4Gb in size. This leads to massive andunrecoverable data corruption. Do NOT install or attempt to test with these systems. It relates to recently discovered kernel bug which may be fixed in kernel 2.4.2. We expect to have the fix in place for BETA 2 (Traktopel). Thank you for your patience.

Re:Mandrake 8.0 beta is best for the home

[jmv]

The value of: (int) (((60/6)*0.3) + (10*0.7)) can be either 9 or 10, depending on when the float values are moved in/out the floating point registers (which are 80 bits instead of 64 bits for a double). Your compiler cannot guaranty the result and you should no assume that the result is 10, unless you round to the nearest integer (instead of casting to an int, which is equivalent to a floor).

Therefor, it's not the compilers fault it this problem happens, it's your fault if you make those kind of assumptions (It's the same reason why you should almost never use == when comparing 2 floating point numbers).

Re:Mandrake 8.0 beta is best for the home

[jmv]

OK, let's go... (with my previous 3 * .333333 example)

We'll work in decimal, so transpose this to binary for a real CPU. Let's say your "float" (as stored in memory) has 4 digits and your float registers can hold 6 digits (a double is 64 bits, a register is 80 bits).

If you load .333333 (6 digits in the register) in register and multiply by the 3 that's in memory. The result is .999999. When you store that in memory, it is rounded to 4 digits, giving 1.000, which when converted to int, gives 1.

Now, if you have 3 in the register and multiply by .3333 (4 digits in memory), you get .999900 in the register. When you store that in memory, you get .9999, which once conterted to int gives you 0.

The only thing that changed is what goes to register and what goes to memory. I'm not saying this is exactly what happens in your example, but it's probably something similar.

BTW, if you look at the gcc man page, there's an option called -ffloat-store which deals with registers that are larger than the memory representation of the float number.

Re:What in the hell are you talking about.

[teg]

its the principal behind it. there was no reason for RH to make a stupid move like that at all.

Of course there are reasons:

1. egcs was too old for another cycle, and has its share of bugs
2. 2.95 is very buggy, and can't even compile glibc 2.2 on non-x86
3. The compiler we ship has better performance, IA32 and others
4. The compiler we ship has plenty of bugfixes over the older releases.
5. The compiler we ship has much better C++ standard compliance
6. It supports platforms we find important, like IA64. This way, there is only one compiler across all platform.

On the minus side: C++ isn't binary compatible with other versions of gcc. As we went with glibc 2.2, this wouldn't have been compatible with anything anyway (a combination of gcc and glibc is binary incompatible with any other combination). There has never been C++ binary compatiblity on Linux, and there won't be until gcc 3.0 is released and used.

As you can see above, there is no doubt that on technical merits, this was the choice to do. And we did it. Unfortunately, we could have handled the political situation better. As for the end-user experience, that's irrelevant.

When gcc 3.0 comes out, we intend to switch to that at one point - "when" is dependent on when gcc 3.0 is actually released and how it fits into our cycles, as it will be a binary incompatible change.

PS: Mandrake uses it too.

NOT complaining about version bloat

[MCZapf]

They're using a whole new kernel version. I think that's enough reason to call it Mandrake 8.0.

Re:Sweet.

[Bob Abooey]

I would like to go on record here as saying that debian users are turning into the BSD's of the Linux distro's. They are pompous and annoying and 31337 and probably all descendants of Amiga users.

I am therefore going public with an official statement:

I Bob Abooey, am hereby and do officially proclaim that I will never ever ever, ever, use debian Linux. If debian is the only Linux distro left on earth I will drive to Best Buy and give my last dollar to the wild eyed clerk for a copy of Microsoft Windows. If debian was the only OS left on the planet I will chop down a tree and build an abacas. In fact from this point in time I refuse to even acknowledge the rumor that debian even exists. And lastly, all of you apt-get-morons can kiss my big hairy white arse.


Yours,