A refreshing read. Even if Miguel-bashing is a popular sport, he has some very valid points. And its great to read people who write outside the group-think.
So summing up, from the 12 points in stephane's post
OOXML is kludgy in the dependencies between XML files, uses ugly representations to store dates, does not store full precision for numbers, uses a stupid representation for repeat formulas, and has multiple flavors for storing similarly-formatted text. However, appart from being difficult to implement, tedious, and ugly, it need not be evil.
The 'OMG only English is saved' problem is bogus. OOXML does the right thing here. As does ODF, IIRC.
Excel currently produces VML chunks, which should be deprecated according to OOXML. VML is yet another 'feature' that would-be OOXML implementers would have to duplicate. As with Excel messing around (regenerating) open packaging on save, these are (possibly intentional) bugs in Excel, not OOXML. BIFF is also irrelevant to OOXML as a spec.
Excel saves password-protected documents as OLE2 objects; this is bad. Also, Excel still slightly incompatible with older versions, news at 11.
After reading Stephane's list and Miguel's comments, you get a much better idea of what is wrong and the mix between 'ugly', 'bad', and 'perfectly fine'. It is a lot better to bash MS on account of actual problems with the spec than to bash them as a knee-jerk response. Miguel's role as a devil's advocate is invaluable. Keep it up, Miguel.
First you build gcc with icc. This is icc_gcc.
Then you build another copy of gcc with gcc. This is gcc_gcc.
Now you have two gccs with different code generated by different compilers.
So now you take both of those, and build the gcc source with both icc_gcc and gcc_gcc. Both should generate the same code. If they don't, something's fishy.
Very nice approach. I'd give you mod points if I had them. This can effectively guarantee that a toolchain you can build is free from binary-only evil.
Of course, you still can't know if any given gcc is also free from evil, since the 'evil gcc' could refuse to inject anything into the programs it is compiling unless an arbitrary number of restrictions is satisfied. For instance, only on April 1st, or only when certain code pattern is compiled.
I am a teaching assistant at a CS department. We have a homebrew source-code plagiarism detection system that works fine, but only performs static analysis (that is, does not execute the code). In my experience, you don't need to trace programs to find if they are source-code plagiarized. In a typical 1000-line C or Java program, - It takes a long amount of time to copy+paste+rename+recomment+reengineer the code so that it escapes detection - You have to be good at the reengineering step if you want to avoid automatic detection (we use a lexer to ignore variable names, comments and whitespace). - If you fall short of a very good reingeneering, your code will be flagged by the system and manually inspected. And, if your renaming and recommenting is not good, you get called to the office to explain what happened.
There is a very interesting thing about plagiarism in a large assignment population. Once you have copied your code from someone, you may disguise your similarity to the original, but the reengineering you introduce to do so will also draw you away from the general population (think common programming idioms; nobody writes i=i+1 in a C for loop). Statistical copy detection is a lot easier than relying on one-vs-one distances.
We are not witch-hunters, all our students know what we use, and have access to the (LGPL'd) source-code (of course, students can't do statistical copy detection, because they don't have the samples; but they can read about it). We tell them just how we are going to apply the copy detection program. The rate of plagiarism has fallen to very low levels (the few who don't heed the warning) since we started using it systematically. Academic plagiarism detection, if well implemented, is not "shadenfreude" - it is levelling the playing field.
Still, the seams are no fun. With that resolution, if it were feasible to use tiled back-projection, the display would have a much higher resolution than most IMAX theaters - which use about 70 M pixels per frame, according to Wikipedia. Representing maps or textual information on a tiled display makes it much, much harder to read.
I also wonder if there are real applications that need that huge amount of detail *everywhere*. I would think that having a few high-resolution areas for detail work (basically where people can still walk up and read) and lower-resolution areas for overview (up where only really tall or short people can actually read anything) could be a nice compromise to save costs.
Even if the feat is the possibility of pushing all those pixels to the screens rather than the screen-engineering itself, I still have to wonder what real-world applications they forsee.
Slashdot Mirror
So summing up, from the 12 points in stephane's post
After reading Stephane's list and Miguel's comments, you get a much better idea of what is wrong and the mix between 'ugly', 'bad', and 'perfectly fine'. It is a lot better to bash MS on account of actual problems with the spec than to bash them as a knee-jerk response. Miguel's role as a devil's advocate is invaluable. Keep it up, Miguel.
First you build gcc with icc. This is icc_gcc. Then you build another copy of gcc with gcc. This is gcc_gcc.
Now you have two gccs with different code generated by different compilers.
So now you take both of those, and build the gcc source with both icc_gcc and gcc_gcc. Both should generate the same code. If they don't, something's fishy.
Very nice approach. I'd give you mod points if I had them. This can effectively guarantee that a toolchain you can build is free from binary-only evil.
Of course, you still can't know if any given gcc is also free from evil, since the 'evil gcc' could refuse to inject anything into the programs it is compiling unless an arbitrary number of restrictions is satisfied. For instance, only on April 1st, or only when certain code pattern is compiled.
I am a teaching assistant at a CS department. We have a homebrew source-code plagiarism detection system that works fine, but only performs static analysis (that is, does not execute the code). In my experience, you don't need to trace programs to find if they are source-code plagiarized. In a typical 1000-line C or Java program,
- It takes a long amount of time to copy+paste+rename+recomment+reengineer the code so that it escapes detection
- You have to be good at the reengineering step if you want to avoid automatic detection (we use a lexer to ignore variable names, comments and whitespace).
- If you fall short of a very good reingeneering, your code will be flagged by the system and manually inspected. And, if your renaming and recommenting is not good, you get called to the office to explain what happened.
There is a very interesting thing about plagiarism in a large assignment population. Once you have copied your code from someone, you may disguise your similarity to the original, but the reengineering you introduce to do so will also draw you away from the general population (think common programming idioms; nobody writes i=i+1 in a C for loop). Statistical copy detection is a lot easier than relying on one-vs-one distances.
We are not witch-hunters, all our students know what we use, and have access to the (LGPL'd) source-code (of course, students can't do statistical copy detection, because they don't have the samples; but they can read about it). We tell them just how we are going to apply the copy detection program. The rate of plagiarism has fallen to very low levels (the few who don't heed the warning) since we started using it systematically. Academic plagiarism detection, if well implemented, is not "shadenfreude" - it is levelling the playing field.
Still, the seams are no fun. With that resolution, if it were feasible to use tiled back-projection, the display would have a much higher resolution than most IMAX theaters - which use about 70 M pixels per frame, according to Wikipedia. Representing maps or textual information on a tiled display makes it much, much harder to read.
I also wonder if there are real applications that need that huge amount of detail *everywhere*. I would think that having a few high-resolution areas for detail work (basically where people can still walk up and read) and lower-resolution areas for overview (up where only really tall or short people can actually read anything) could be a nice compromise to save costs.
Even if the feat is the possibility of pushing all those pixels to the screens rather than the screen-engineering itself, I still have to wonder what real-world applications they forsee.