I think Symantec should start lumping this crap in with viruses and trojans.
They most certainly should. But somehow I don't think they are going to do that. So what can you do about it? If you have legally purcased Symantec Antivirus (or whatever their product is called) and a trojaned CD, then maybe you should inform Symantec about their product not warning you about the trojan. And stop buying Symantec's products, if they don't want to fix it.
CDDA does not use AIFF format. AIFF is an IFF format. I found a few pages with more information about IFF and AIFF. CDDA is different, first of all it is not a file format, it specify the format of the media, and you don't have a file header like AIFF. But both formats are similar in that except from the metadata, they contain just raw uncompressed samples. But you can say that about a lot of formats. There does exist systems, where the driver can convert from CDDA to AIFF as you read the disk (IIRC IRIX does that), of course the conversion is trivial. It basically amounts to just replacing the header.
Softmaker provide the xls files on their web page.
Chosing test files is part of the comparision. I wouldn't be surprised if the result would look differently by trying a set of xls files relevant for your own work. Of course in my case that set would be empty, I can't remember when I last came across an xls file. If I ever need to open such a file it will probably be because somebody email me one, there is no way I'm going to pay this amount of money for a program to read a file somebody send to me. At least I learned one thing from this discussion, if I ever need to read such a file, I should try both gnumeric and ooo.
That may very well be the case. After all the comparision is done by people trying to sell a product. Their product have to be better (in at least one way) than every product they compare themselves to. If they couldn't find any advantage of their own product over gnumeric, it makes sense to exclude gnumeric from the comparision.
I would not be suprised at all to see some heads roll over this
snafu.
I wouldn't be surprised either. But is it really going to be obvious who is responsible? And are random heads going to roll if they can't figure it out?
Right now, I wouldn't want to be in the pants of the engineer responsible for the gaffe...
It is not necesarilly an engineer who is responsible for the mistake. It is not a design flaw, it is a flaw in the manufacturing process. Guess this could possibly have been caused by broken equipment, possibly careless handling.
Thanks for the advice. I will do that in the future instead of the symlink. I'm still going to delete the autorun package though, I don't see much point in having it installed. I just realized the file/etc/skel/.kde/Autostart/Autorun.desktop belonged to the autorun package, so by deleting the autorun package before creating a user, you can completely avoid ~/.kde/Autostart/Autorun.desktop from being created.
No, actually, the solution is to disable AutoStart. It's easy to do.
I did that on my parents Windows 95 system, but it certainly wasn't easy. You see they had made it easy to disable disk change detection. But that is certainly not what you want to do. The correct way to disable autodetection required modification of some key hidden deep down in the registry.
I always considered autorun a bug. And it annoys me, that Red Hat Linux and Fedora Core now have this feature. Fortunately it is easy to disable: rpm -e autorun. And just to shut up kde complaining that it is unable to start autorun, I did this: ln -s/bin/true/usr/bin/autorun. A lot easier than what I had to do on a Windows 95 system.
I find it funny, that AmigaOS had a bug that allowed a carefully crafted floppy to cause automatic execution of code from the floppy. That bug was abused by multiple vira, but it was fixed with AmigaOS 2.0 (around 1990). And five years later Microsoft introduce a similar bug in Windows 95. And today we see this security hole being abused by the music industry.
And what the music industry is doing start looking more and more like vira. It has been suggested they would allow limited copying, but the copy protection code would copy itself to the new CDDA you create. Now if they are really going to do that, where is the difference from a virus?
If nothing else, at least your comment shows how litle information, there really is in a version number. Besides AmigaOS does have another version number system as well. IIRC 2.0 = 37 and 3.0 = 39. So what is the other version number of AmigaOS 4.0? (Until proven wrong, I would like to assume it is 42).
One man couldn't possibly write so much crap in such a short time. I'm sure parts of it must be written by somebody else, and included in the Brown Book with or without permissions.
Performance will not be significantly affected. When the CPU is executing it doesn't need to check instructions as long as they are in the instruction cache, because you wouldn't allow the instruction cache to load from nonexecutable pages. So as long as you don't have any L1-cache misses, there would be no difference at all. Once you miss the L1-cache and have to go through paging to the L2-cache, the hardware will be different, but the NX logic would be pretty simple and mostly relying on paging logic already in place. So also at this point there would be no difference. And I really mean no difference, the same piece of code will execute in exactly the same number of clockcycles in both cases. (As long as there are no bugs causing the code to attempt to execute nonexecutable pages of course). I haven't seen the NX logic, but I guess if you saw the piece of hardware we are discussing and then compared it to the rest of the paging logic, or even the rest of the CPU, I'm sure you would say: "What is all the hype about?"
So the only place where there would be even a theoretical possibility to meassure a difference is the code responsible for creating the page table entries. This is already in one of the expensive code paths, which you avoid as much as possible, so one extra line of C code to set the NX bit shouldn't give a meassurable difference.
somehow there will be an override and the day the override is used the virus
First of all you shouldn't expect the NX bit to do any good against a virus. A worm OTOH might be stoped by the NX bit. OK I'll assume you mean the worm would use a way to override it. If it could be disabled per executable like execshield on Linux, you could only exploit vulnurable programs with the security feature disabled. So if the vulnurable service is running with the security feature enabled, you cannot disable it, unless you already control the machine. So it doesn't help a worm gaining control.
What are the chances the vulnurable service would run with this security feature disabled? Not large, because you would only disable it, if the service didn't work otherwise. And the number of programs breaking in case of Linux is not large. Fedora Core 1 has exec shield which does a best effort at implementing this without specific hardware support. Arjan van de Ven explains that hardly any program broke. Ingo Molnar explains in a bit more detail, that the X module loader was the only program breaking. (Some other programs broke for other reasons). So when it is only one program breaking, you fix it, rather than starging to disable this security feature.
However as Linus has explained, there are ways to exploit a vulnurable service in spite of NX. This specific attack relies on using/bin/sh, which means it wouldn't work against Windows. But anybody who knows as much about Windows as Linus knows about Linux would surely be able to come up with a similar attack against a Windows service. For example there is probably a function you can call to change the protection bits on a memory range. So you first fill code in the buffer, which cannot be executed at the moment, the return address you overwrite with a pointer to this function call, and you provide it parameters specifying to make the buffer executable. The return address from the function call then just needs to point to the buffer.
...as well as knowing the best drivers to use, best graphics options in, say, xf86config...
Instead of knowing the best options, I'd rather know the best choice of GFX hardware. It is well known, that the most popular GFX hardware out there is from vendors that don't give a damn about support. In the not too distant future I will built an AMD64 machine, but I still don't know which GFX hardware to chose.
Apples binary format is designed to maintain 'compatability' with the register set of the 68k processors
I think that was the case when they first started shipping Macs with PPC. But I have never heard about an OS X released for 68k CPUs, so what is it they would be trying to be compatible with? I don't think they really need to remain compatible with 68k or even OS 9. It is up to the software developers anyway, do you think they are going to test it on 68k? And you can't force them to put usable code in the 68k section anyway, so if it really slowed down performance, would application developers put 68k code in their applications? Of course fat binaries doesn't have to hurt performance, you would only load the part you need. You would waste disk space, and installing applications would be slowed down, as the installer would probably copy the entire executable with both the needed half and the unneeded half (OK I know the two sizes are not going to be exactly the same).
they're not using all the PPC registers in a way that is most efficient?
Could be, but what is the most efficient? Is PPC the one with the funny register shifting used for function calls? If that is the case finding the most efficient way to use registers is certainly nontrivial. In particular across context switches it get very tricky.
It seems you don't know what dB means. In fact it seems you don't even know how to spell it. It is a logarithmic scale. Which means absolute silence would actually be minus infinity on a the dB scale. 0dB is some chosen fixpoint, typically the weakest sound which can be heard by the human ear. In other words less than 0dB means a sound so weak that a human cannot hear it. That should be achievable if you can avoid the movable parts.
After you've loaded it, now you've got 2 copies of Open Office/Gnome in RAM.
It doesn't have to be that way. If you use ramfs under Linux, the files are stored directly in the page cache. Which means that if you have the file on your ram filesystem, and the program is running, physically there will only be one instance of the program in RAM. But of course copying the executable to ramfs still means you need to have all of it in RAM, also the parts you don't need. If you run the program from an executable on your hard disk, it loads on demand, which means only those parts of the program, which you use, get loaded. Instead of ramfs you might consider tmpfs. The major difference is, that pages in tmpfs can be swapped out. OK, so maybe you don't want it to be swapped out, but what is the point in having a lot of code in RAM (using only part of it), when you allow the data accessed by this code to be swapped out (AFAIK anonymous mappings are implemented by having an invisible tmpfs in the kernel). If you really don't want to touch disk (and have lots of RAM), you may want to disable swap. At that point ramfs and tmpfs will behave more or less the same, but I guess tmpfs is better supported. Of course disabling swap doesn't ensure your executables and libraries stay in RAM. Instead of all this unnecesarry copying of the executables and libraries to a different filesystem, maybe it would be better to just force them to stay in the cache. You should be able to do that using mlock. Imagine a daemon that simply memory maps all the files you want to keep in cache, and then call mlockall.
At a minimum they should have made the user aware of potential problems at the beginning of installation.
They did.
the problem was known to be a 2.6 problem since December
The bug was opened in February. The comment you are refering to was posted on the day of the release.
the FC2 dev's lame excuse of "didn't happen on our machines".
If you can't reproduce a problem, you cannot fix it. So that is certainly no lame excuse. If you carefully read Comment number 31 you will see, that they did try to fix the problem. And without any accurate bug report, and without a computer to test it on, they couldn't do any better than they did.
They may have belived the problem would only happen if the partition table was already incorrect before installing Fedora. And at that time they didn't know that some Windows installations was actually running with such an incorrect partition table.
A few computers unable to dual boot is not reason enough to hold back the distribution. I run Fedora Core 1 on seven computers, none of those have Windows installed. (I have my own reasons for not upgrading yet, but that has nothing to do with bugs or anything). If the timing hadn't been a bit unfortunate for me, I would probably have started upgrading my machines to Fedora Core 2 as soon as I had completed the download. In that case I would not have liked it to be delayed because of some bug in a Windows version that a few people wanted to dual boot with.
I don't know about authoritive sources.
Asking the BIOS or the drive would be two options. Seems the partition tables that got screwed up respected neither.
I could mention two mainstream BIOS cores that use different CHS translation when given the same drive.
That is another reason the translation is a bad idea. Move that disk between two computers and things will break.
For some reason certain people get really nervous about dropping legacy shit.
Yeah, by now we are carrying around so much crap that it is causing more problems than it solves. If they would just drop that old API and rewrite the BIOS API from scratch. It is only the boot loaders that need to be rewritten anyway. I was happy to learn that AMD64 dropped segmentation and vm86. Who have the guts to replace the old 16-bit BIOS with a new and better designed 64-bit BIOS?
I didn't post anything else on this article.
I guess there are just too many comments for me to keep track of them. Anonymous postings doesn't make it any easier to see which are written by the same person.
but you can't just take the liberty to 'fix'
I already answered that in an earlier comment
The original poster said that MS doesn't adhere to a spec
Well, it is not violating any spec about the MBR format. In fact the MBR properly is correctly formatet, for a wrong geometry. So whoever created the partition table didn't respect any of the authoritative sources for the gemometry, and instead assumed a geometry that most BIOSes pretend to be using.
I think I do understand. I write BIOS code for a living.
The BIOS doesn't have to know anything about partitions. The BIOS just have to load the first sector and execute it, then the OS code will handle partitions. But if you do BIOS code for a living maybe you should tell us why they suck like that. Why was the braindead addressing beyond 256 cylinders ever introduced? Why did they even start to make BIOSes that lied to the OS about the geometry? Why didn't you implement a new API with 16 bit cylinder numbers to access cylinders beyond 1024 instead? You see it is this lying about the geometry that is the root to all the boot problems we are now facing.
how do you think I'm blaming Linux?
So it wasn't you posting all those comments blaming Linux for this?
I don't understand people that write the kind a code that 'fixes' something that they don't own.
Actually it is probably not even fixing anything. It reads the partition table, which contains redundant information (the format always was redundant). It reads the 32 bit start and size fields, which are the only fields you can really trust. The CHS fields have always been wrong in one way or another since some time in the 90s because they did not support more than 504MB. So with a correct and no longer redundant representation of the partitions, it is ready to make whatever modifications it needs to do to the Linux partitions. At this point it doesn't change the Windows partitions at all. Finally it writes the partition table back to disk using the CHS geometry told by the kernel.
You say it is a defacto standard, but you don't understand how much people have been abusing this defacto standard for the last 10 years. Using different geometry in the BIOS API and on the IDE bus was the first mistake. That API was already broken anyway, because it was designed for floppydisks only, and support for more than 256 cylinders was one of ugliest hacks I have ever seen. It should have been redesigned when they started shipping PCs with harddisks. And please stop blaming Linux for the consequences of bad decissions made years before the first Linux version was written.
Windows is the most popular desktop operating system. If Fedora didn't test this, then it's Fedora that's broken and faulty.
What part of "very few people are able to reproduce the problem" was hard to understand? It is not because it wasn't tested. It is just because the problem happens on very few computers, where Windows was somehow misconfigured before Fedora was installed. Windows had a latent problem, that happen to show up when Fedora is installed. There is no way the Fedora developers could have tested this. In fact even after being told about the problem, they have not been able to find a computer where the problem could be reproduced. Blame Microsoft or whoever did the incorrect partitioning of those harddisks eventually leading to a nonbootable system.
So if you want to take any lesson from this, it would be: Shout and shout loud if there is any inconsistency between geometry informations reported from different sources. And that goes both for installer and the running system. Windows should have printed a warning at every boot that there were a potential problem. Actually it seems some people got a warning from the fedora installer and chose to ignore it. So possibly nobody understood the importance of this warning.
Slashdot Mirror
I think Symantec should start lumping this crap in with viruses and trojans.
They most certainly should. But somehow I don't think they are going to do that. So what can you do about it? If you have legally purcased Symantec Antivirus (or whatever their product is called) and a trojaned CD, then maybe you should inform Symantec about their product not warning you about the trojan. And stop buying Symantec's products, if they don't want to fix it.
as the AIFF format found on regular music CDs.
CDDA does not use AIFF format. AIFF is an IFF format. I found a few pages with more information about IFF and AIFF. CDDA is different, first of all it is not a file format, it specify the format of the media, and you don't have a file header like AIFF. But both formats are similar in that except from the metadata, they contain just raw uncompressed samples. But you can say that about a lot of formats. There does exist systems, where the driver can convert from CDDA to AIFF as you read the disk (IIRC IRIX does that), of course the conversion is trivial. It basically amounts to just replacing the header.
Softmaker provide the xls files on their web page.
Chosing test files is part of the comparision. I wouldn't be surprised if the result would look differently by trying a set of xls files relevant for your own work. Of course in my case that set would be empty, I can't remember when I last came across an xls file. If I ever need to open such a file it will probably be because somebody email me one, there is no way I'm going to pay this amount of money for a program to read a file somebody send to me. At least I learned one thing from this discussion, if I ever need to read such a file, I should try both gnumeric and ooo.
Is it open source?
The newsforge review have a pretty clear answer to that question: License Proprietary
Maybe it is too good?
That may very well be the case. After all the comparision is done by people trying to sell a product. Their product have to be better (in at least one way) than every product they compare themselves to. If they couldn't find any advantage of their own product over gnumeric, it makes sense to exclude gnumeric from the comparision.
I would not be suprised at all to see some heads roll over this snafu.
I wouldn't be surprised either. But is it really going to be obvious who is responsible? And are random heads going to roll if they can't figure it out?
Right now, I wouldn't want to be in the pants of the engineer responsible for the gaffe...
It is not necesarilly an engineer who is responsible for the mistake. It is not a design flaw, it is a flaw in the manufacturing process. Guess this could possibly have been caused by broken equipment, possibly careless handling.
Thanks for the advice. I will do that in the future instead of the symlink. I'm still going to delete the autorun package though, I don't see much point in having it installed. I just realized the file /etc/skel/.kde/Autostart/Autorun.desktop belonged to the autorun package, so by deleting the autorun package before creating a user, you can completely avoid ~/.kde/Autostart/Autorun.desktop from being created.
No, actually, the solution is to disable AutoStart. It's easy to do.
/bin/true /usr/bin/autorun. A lot easier than what I had to do on a Windows 95 system.
I did that on my parents Windows 95 system, but it certainly wasn't easy. You see they had made it easy to disable disk change detection. But that is certainly not what you want to do. The correct way to disable autodetection required modification of some key hidden deep down in the registry.
I always considered autorun a bug. And it annoys me, that Red Hat Linux and Fedora Core now have this feature. Fortunately it is easy to disable: rpm -e autorun. And just to shut up kde complaining that it is unable to start autorun, I did this: ln -s
I find it funny, that AmigaOS had a bug that allowed a carefully crafted floppy to cause automatic execution of code from the floppy. That bug was abused by multiple vira, but it was fixed with AmigaOS 2.0 (around 1990). And five years later Microsoft introduce a similar bug in Windows 95. And today we see this security hole being abused by the music industry.
And what the music industry is doing start looking more and more like vira. It has been suggested they would allow limited copying, but the copy protection code would copy itself to the new CDDA you create. Now if they are really going to do that, where is the difference from a virus?
So is now the time to release AmigaOS 4.0?
If nothing else, at least your comment shows how litle information, there really is in a version number. Besides AmigaOS does have another version number system as well. IIRC 2.0 = 37 and 3.0 = 39. So what is the other version number of AmigaOS 4.0? (Until proven wrong, I would like to assume it is 42).
One man couldn't possibly write so much crap in such a short time. I'm sure parts of it must be written by somebody else, and included in the Brown Book with or without permissions.
Performance will not be significantly affected. When the CPU is executing it doesn't need to check instructions as long as they are in the instruction cache, because you wouldn't allow the instruction cache to load from nonexecutable pages. So as long as you don't have any L1-cache misses, there would be no difference at all. Once you miss the L1-cache and have to go through paging to the L2-cache, the hardware will be different, but the NX logic would be pretty simple and mostly relying on paging logic already in place. So also at this point there would be no difference. And I really mean no difference, the same piece of code will execute in exactly the same number of clockcycles in both cases. (As long as there are no bugs causing the code to attempt to execute nonexecutable pages of course). I haven't seen the NX logic, but I guess if you saw the piece of hardware we are discussing and then compared it to the rest of the paging logic, or even the rest of the CPU, I'm sure you would say: "What is all the hype about?"
So the only place where there would be even a theoretical possibility to meassure a difference is the code responsible for creating the page table entries. This is already in one of the expensive code paths, which you avoid as much as possible, so one extra line of C code to set the NX bit shouldn't give a meassurable difference.
somehow there will be an override and the day the override is used the virus
/bin/sh, which means it wouldn't work against Windows. But anybody who knows as much about Windows as Linus knows about Linux would surely be able to come up with a similar attack against a Windows service. For example there is probably a function you can call to change the protection bits on a memory range. So you first fill code in the buffer, which cannot be executed at the moment, the return address you overwrite with a pointer to this function call, and you provide it parameters specifying to make the buffer executable. The return address from the function call then just needs to point to the buffer.
First of all you shouldn't expect the NX bit to do any good against a virus. A worm OTOH might be stoped by the NX bit. OK I'll assume you mean the worm would use a way to override it. If it could be disabled per executable like execshield on Linux, you could only exploit vulnurable programs with the security feature disabled. So if the vulnurable service is running with the security feature enabled, you cannot disable it, unless you already control the machine. So it doesn't help a worm gaining control.
What are the chances the vulnurable service would run with this security feature disabled? Not large, because you would only disable it, if the service didn't work otherwise. And the number of programs breaking in case of Linux is not large. Fedora Core 1 has exec shield which does a best effort at implementing this without specific hardware support. Arjan van de Ven explains that hardly any program broke. Ingo Molnar explains in a bit more detail, that the X module loader was the only program breaking. (Some other programs broke for other reasons). So when it is only one program breaking, you fix it, rather than starging to disable this security feature.
However as Linus has explained, there are ways to exploit a vulnurable service in spite of NX. This specific attack relies on using
In Linux I often use this command when debugging certain problems. How do I do that in Windows?
...as well as knowing the best drivers to use, best graphics options in, say, xf86config...
Instead of knowing the best options, I'd rather know the best choice of GFX hardware. It is well known, that the most popular GFX hardware out there is from vendors that don't give a damn about support. In the not too distant future I will built an AMD64 machine, but I still don't know which GFX hardware to chose.
Apples binary format is designed to maintain 'compatability' with the register set of the 68k processors
I think that was the case when they first started shipping Macs with PPC. But I have never heard about an OS X released for 68k CPUs, so what is it they would be trying to be compatible with? I don't think they really need to remain compatible with 68k or even OS 9. It is up to the software developers anyway, do you think they are going to test it on 68k? And you can't force them to put usable code in the 68k section anyway, so if it really slowed down performance, would application developers put 68k code in their applications? Of course fat binaries doesn't have to hurt performance, you would only load the part you need. You would waste disk space, and installing applications would be slowed down, as the installer would probably copy the entire executable with both the needed half and the unneeded half (OK I know the two sizes are not going to be exactly the same).
they're not using all the PPC registers in a way that is most efficient?
Could be, but what is the most efficient? Is PPC the one with the funny register shifting used for function calls? If that is the case finding the most efficient way to use registers is certainly nontrivial. In particular across context switches it get very tricky.
wow! less than 0db. thats really impressive.
It seems you don't know what dB means. In fact it seems you don't even know how to spell it. It is a logarithmic scale. Which means absolute silence would actually be minus infinity on a the dB scale. 0dB is some chosen fixpoint, typically the weakest sound which can be heard by the human ear. In other words less than 0dB means a sound so weak that a human cannot hear it. That should be achievable if you can avoid the movable parts.
After you've loaded it, now you've got 2 copies of Open Office/Gnome in RAM.
It doesn't have to be that way. If you use ramfs under Linux, the files are stored directly in the page cache. Which means that if you have the file on your ram filesystem, and the program is running, physically there will only be one instance of the program in RAM. But of course copying the executable to ramfs still means you need to have all of it in RAM, also the parts you don't need. If you run the program from an executable on your hard disk, it loads on demand, which means only those parts of the program, which you use, get loaded. Instead of ramfs you might consider tmpfs. The major difference is, that pages in tmpfs can be swapped out. OK, so maybe you don't want it to be swapped out, but what is the point in having a lot of code in RAM (using only part of it), when you allow the data accessed by this code to be swapped out (AFAIK anonymous mappings are implemented by having an invisible tmpfs in the kernel). If you really don't want to touch disk (and have lots of RAM), you may want to disable swap. At that point ramfs and tmpfs will behave more or less the same, but I guess tmpfs is better supported. Of course disabling swap doesn't ensure your executables and libraries stay in RAM. Instead of all this unnecesarry copying of the executables and libraries to a different filesystem, maybe it would be better to just force them to stay in the cache. You should be able to do that using mlock. Imagine a daemon that simply memory maps all the files you want to keep in cache, and then call mlockall.
At a minimum they should have made the user aware of potential problems at the beginning of installation.
They did.
the problem was known to be a 2.6 problem since December
The bug was opened in February. The comment you are refering to was posted on the day of the release.
the FC2 dev's lame excuse of "didn't happen on our machines".
If you can't reproduce a problem, you cannot fix it. So that is certainly no lame excuse. If you carefully read Comment number 31 you will see, that they did try to fix the problem. And without any accurate bug report, and without a computer to test it on, they couldn't do any better than they did.
They may have belived the problem would only happen if the partition table was already incorrect before installing Fedora. And at that time they didn't know that some Windows installations was actually running with such an incorrect partition table.
A few computers unable to dual boot is not reason enough to hold back the distribution. I run Fedora Core 1 on seven computers, none of those have Windows installed. (I have my own reasons for not upgrading yet, but that has nothing to do with bugs or anything). If the timing hadn't been a bit unfortunate for me, I would probably have started upgrading my machines to Fedora Core 2 as soon as I had completed the download. In that case I would not have liked it to be delayed because of some bug in a Windows version that a few people wanted to dual boot with.
I don't know about authoritive sources.
Asking the BIOS or the drive would be two options. Seems the partition tables that got screwed up respected neither.
I could mention two mainstream BIOS cores that use different CHS translation when given the same drive.
That is another reason the translation is a bad idea. Move that disk between two computers and things will break.
For some reason certain people get really nervous about dropping legacy shit.
Yeah, by now we are carrying around so much crap that it is causing more problems than it solves. If they would just drop that old API and rewrite the BIOS API from scratch. It is only the boot loaders that need to be rewritten anyway. I was happy to learn that AMD64 dropped segmentation and vm86. Who have the guts to replace the old 16-bit BIOS with a new and better designed 64-bit BIOS?
I didn't post anything else on this article.
I guess there are just too many comments for me to keep track of them. Anonymous postings doesn't make it any easier to see which are written by the same person.
but you can't just take the liberty to 'fix'
I already answered that in an earlier comment
It shouldn't be necessary to back up your MBR before installing a new OS...
The normal recomendation is to backup everything. That even holds if you are not going to install a new OS.
The original poster said that MS doesn't adhere to a spec
Well, it is not violating any spec about the MBR format. In fact the MBR properly is correctly formatet, for a wrong geometry. So whoever created the partition table didn't respect any of the authoritative sources for the gemometry, and instead assumed a geometry that most BIOSes pretend to be using.
I think I do understand. I write BIOS code for a living.
The BIOS doesn't have to know anything about partitions. The BIOS just have to load the first sector and execute it, then the OS code will handle partitions. But if you do BIOS code for a living maybe you should tell us why they suck like that. Why was the braindead addressing beyond 256 cylinders ever introduced? Why did they even start to make BIOSes that lied to the OS about the geometry? Why didn't you implement a new API with 16 bit cylinder numbers to access cylinders beyond 1024 instead? You see it is this lying about the geometry that is the root to all the boot problems we are now facing.
how do you think I'm blaming Linux?
So it wasn't you posting all those comments blaming Linux for this?
It is safe to ignore, but ignoring may cause (fixable) problems with some boot loaders.
Emphasis mine.
I don't understand people that write the kind a code that 'fixes' something that they don't own.
Actually it is probably not even fixing anything. It reads the partition table, which contains redundant information (the format always was redundant). It reads the 32 bit start and size fields, which are the only fields you can really trust. The CHS fields have always been wrong in one way or another since some time in the 90s because they did not support more than 504MB. So with a correct and no longer redundant representation of the partitions, it is ready to make whatever modifications it needs to do to the Linux partitions. At this point it doesn't change the Windows partitions at all. Finally it writes the partition table back to disk using the CHS geometry told by the kernel.
You say it is a defacto standard, but you don't understand how much people have been abusing this defacto standard for the last 10 years. Using different geometry in the BIOS API and on the IDE bus was the first mistake. That API was already broken anyway, because it was designed for floppydisks only, and support for more than 256 cylinders was one of ugliest hacks I have ever seen. It should have been redesigned when they started shipping PCs with harddisks. And please stop blaming Linux for the consequences of bad decissions made years before the first Linux version was written.
Windows is the most popular desktop operating system. If Fedora didn't test this, then it's Fedora that's broken and faulty.
What part of "very few people are able to reproduce the problem" was hard to understand? It is not because it wasn't tested. It is just because the problem happens on very few computers, where Windows was somehow misconfigured before Fedora was installed. Windows had a latent problem, that happen to show up when Fedora is installed. There is no way the Fedora developers could have tested this. In fact even after being told about the problem, they have not been able to find a computer where the problem could be reproduced. Blame Microsoft or whoever did the incorrect partitioning of those harddisks eventually leading to a nonbootable system.
So if you want to take any lesson from this, it would be: Shout and shout loud if there is any inconsistency between geometry informations reported from different sources. And that goes both for installer and the running system. Windows should have printed a warning at every boot that there were a potential problem. Actually it seems some people got a warning from the fedora installer and chose to ignore it. So possibly nobody understood the importance of this warning.