Slashdot Mirror

← Back to Stories (view on slashdot.org)

Mandrake 8.0 Beta Released

Posted by timothy on from the a-man-a-distribution-a-plant-panama dept.

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.

5 of 300 comments (clear)

  1. Read these articles by deno · · Score: 5

    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: 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.
  2. My problems with Western Digital... by slothbait · · Score: 5

    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

  3. Re:Mandrake 8.0 beta is best for the home by jmv · · Score: 5

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

    --
    Opus: the Swiss army knife of audio codec
  4. Re:Mandrake 8.0 beta is best for the home by jmv · · Score: 5

    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.

    --
    Opus: the Swiss army knife of audio codec
  5. NOT complaining about version bloat by MCZapf · · Score: 5

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