1. Retail boxes of Windows from Microsoft will still contain IE. What this is doing is allowing OEM's to put different arrangements of browsers on a retail machine.
2. Yes, one allowed arrangement is "no IE", although that is very unlikely. A far more likely arrangement is "IE and Firefox", something that Microsoft did not allow before or the OEM would lose their volume discount. Note that there are TWO (count em) browsers, although in your fantasy astroturf world the ONLY thing that counts is "IE is removed", despite the fact that you and I both know that nobody is going to do that.
For that matter, OEMs themselves were free to take the hassle/cost of installing a different browser if they so desired.
Actually the 80286 could do full memory protection. The pages were in effect 64K in size. There was certainly some strange stuff so that you were encouraged to keep using the same page, but at the time memory sizes were such that you really wanted to limit how many 64K pages were swapped in.
The problem was that the 8086 version of MSDOS preset the segments to overlap 16 bytes apart, and lots of programs assumed this. If you changed it so the paging was useful then no MSDOS programs could run, which pretty much meant it was a non-starter except for some alternative operating systems that had far less luck than Linux in competing with the juggernaut.
No, the DOS shell (if you mean command.com or cmd.exe) was inspired by the CP/M shell, which was based on RSX style systems. It was modified in some crude ways to look more like a Unix shell.
The NT shell was identical to the MSDOS one so it certainly could not be inspired somehow differently.
Calling the windowing system the "shell" is an interesting different use of the term, but any such shell could not be considered to be derived from either Unix or VMS as they had no such thing.
The NT filenames were copied from Unix, not VMS. So was all the stream I/O and the socket api, and the libc library. Well they were really copied from MSDOS, but that had already been modified extensively to resemble Unix so NT had to resemble Unix as well.
Some aspects of process management were from VMS but I suspect there was just as much variety between Unix's as there was between NT and some Unix here.
I don't know if it is stupidity or Microsoft shills.
However if you read the fa, or even if you think a little bit:
NOBODY IS GOING TO SELL A COMPUTER WITHOUT A BROWSER!
The machine the end user gets will have a browser. Likely more than one. Probably the blue E and the firefox will be on the desktop. The user can click on either one.
This is what Microsoft did not allow before and what they have been forced to allow.
They are still up to the same shit, saying "IE is missing" without saying exactly what they were forced to do.
Microsoft did not allow any *other* browser to be installed in OEM copies.
I think it is Microsoft shenanigans that got it changed to "remove IE". What should be allowed is that an OEM can sell the system preset to use a different browser by default, and remove the 'e' from the desktop and menus. It should not really matter if IE is there.
Doxygen is able to write.chm files, so I think it is sufficiently documented so that another browser could display them.
I think the complaint is more that Microsoft is not providing any means to call another browser. Assuming the file is adequately documented and actually serves some purpose then the browsers should interpret them.
Did ReiserFS gain or lose functionality for the sole reason that the author committed a crime?
Don't be an idiot in your mindless astroturfing. If you looked at the wikipedia article for ReiserFS, it mentions the murder IN THE FIRST PARAGRAPH!!!!
The fact that OOXML article does not even *deny* the Microsoft shenanigans is pretty obvious indication that something is very wrong with it.
Microsoft will *never* be compatible, and they would be overjoyed if ODF wasted the man-years necessary to explicitly state every single bit of the file format no matter how obvious it is.
The problem is that standards have to assume the person reading it *wants* to be compatible with it. I'm sure all computer standards are pretty easy to implement something that technically agrees with what is written but is not compatible. This is the first time that has made a difference, however.
This is in fact why "installation" works on Windows. It has nothing to do with Windows itself, it is because programs include all the libraries they need!
There is a switch to the linker that makes a linux executable act as though LD_LIBRARY_PATH starts with the directory the executable is in. This should be turned on ALL THE TIME by EVERY PROGRAM IN THE WORLD (in fact it should be the default). If you want to say something technically correct about Windows, you can say that it does act this way by default.
Some corrections, although the sentiment is correct:
copy of A to A', ftruncate(A'), write(A'), rename(A' to A), host crash, causes the resulting file to contain A data and not A'
This is not what is wrong. If the file contained the old version of A it would be fine, this is the expected behavior. The problem is that the file contains some partially-written version of A' (usually a zero-length version).
Posix doesn't actually say that rename is a write barrier for data and metadata
Actually POSIX does say exactly that. The hole EXT4 weasels through is that POSIX says "anything can happen when the machine crashes".
apps didn't make use of fdatasync() / fsync() correctly
The apps *were* using these calls correctly, by not calling them. They are very slow and make guarantees that have nothing to do with the desired action, which is an atomic rename.
Posix requires that writing a file and then renaming it to a new location is an ordered atomic operation. Say file B already exists. You write file A, then close it, then rename (mv) it to B. Another program running at the same time opens B and reads it. It will get one of these two results, and NO OTHER RESULT:
1. It sees the old contents of B 2. It sees what was written to A.
EXT4 (before these patches) could result in the following result if your machine crashes and you start it again and look at B:
3. B is empty (also B is various partially-written versions of A, but empty most common).
Now it is true that Posix says that if the machine crashes, all bets are off. So yes EXT4 is being technically correct. But it would be equally technically correct if all the files on the disk were empty so this is pointless.
EXT4 promises to make crashes recoverable. This implies to me that after you recover from a crash, you will be left in a state allowed by POSIX. This means either you get the old contents of B or the new full contents of A, and EXT4 by allowing a different result is breaking it's design and promise.
Actually very early solitarie games certainly *did* have resolution-independent graphics. A few vectors to describe a card image took less space than a bitmap (granted the card images were usually a rectangle with a suit symbol and number). Vectors could easily be scaled to different sizes.
That explanation makes no sense. What Microsoft decided to do is be incompatible with both current ODF files and with the 2.2 spec, as (unless they are idiots) the 2.2 spec will use the same namespace everybody (except Microsoft) is using right now, since otherwise it would be impossible to read/write these files in an upwardly compatible way (of course that is the goal of Microsoft so that is what they did).
This actually may help some, if the news can be gotten to the right people.
Although I'm sure they would have found another excuse, it was in fact a bug in OpenOffice that they turned into the reason they had to be incompatible (OpenOffice does something really stupid when a string is used in an expression, it turns it into zero, rather than either producing an error or seeing if the contents of the string look like a number [Excel and every other ODF program do the second one]). They used this as a reason that Excel had "different" formulas, or that the formulas were "undefined" (they are in fact defined by "do what is obvious, if not obvious then copy Excel").
Pointing out that there are alternative implementations that all agree would help a lot in blocking that incredible deluge of wordy lies from those Microsoft engineers. Though I have to admit they apparently have no shame, I really don't think I could literally lie like that in a phony technical argument on a public web page with my name on it, no matter what I was paid.
I do have to say that the bug report is very informative, especially the comments and how mad users are. OpenOffice are being absolutlely brain-dead, it seems they have no concept of how horrible they are acting. Now, besides making OO spreadsheet absolutely useless, they can now also be blamed for Microsoft finding an excuse for being incompatible with ODF. Thanks a lot guys.
My opinion on this bug:
"1"+1 should either produce 2 or an ERROR. Producing 1 is wrong and there is no possible argument. OOO is WRONG!!!!
I really doubt there are as many number formats as locales, so you hardly need such a complex list. Again check what Excel does. I like the idea of converting the strings to numbers as the sheet is loaded, or maybe when they are referenced, as it will magically fix it when saved.
This is an excellent demonstration of the types of stubborness that software developers sometimes get. Any outside observer would see how obvious the need for a fix is, but they can't see it. And once they say they will not fix it they do not want to admit they were wrong and the refuse and come up with endless convoluted arguments. Open source makes this crap visible, but I can tell you that closed source has exactly the same problem. Open source also meant that Microsoft could directly quote the bullshit arguments and use it as an excuse to make ODF incompatible. I was wondering where they were getting so many pages of plausable-sounding but meaningless bullshit.
I don't understand this thinking. The result of Microsoft's actions is that EVERYBODY will have to use the msoxl namespace, otherwise their saved document will not load into Word. This is absolutely useless for differentiating formula types because only one namespace can actually be used!
And OpenOffice has a BUG!!!! If they really said "automatic string conversions are harmful" then OpenOffice should produce an error message. It does not do this, therefore it is a bug! Also claiming that commas vs periods are a problem does not mean that a string containing *neither* a comma or period should fail!
I am absolutely astonished by the convoluted reasoning being used by astroturfers here to excuse this completely evil and devious scheme by Microsoft. You guys should be crowing to the skies about OpenOffice having a bug. But no instead this is somehow some kind of "defined behavior" or whatever stupid reason you can come up with to blather on and on with pages of inanity desiged to convince the PHB that this is not an evil scheme. This is disgusting and I don't understand how you can live with yourselves, prostituting yourselves like this.
Here if the PROPER solution:
1. OpenOffice copies whatever the fuck Excel does with strings. Either the string is marked with the locale that it was loaded from, or the current locale is used, or it is always C, or whatever. They can thank Microsoft for their diligent bug search that located this bug, Microsoft must have put big bucks into this team that found as many bugs as they could.
2. Microsoft has to stop this transparent bullshit. Those people writing the blogs should be ashamed of themselves and any antitrust fine should be taken out of their paychecks. They should take the clever age plugin (BSD code that they wrote themselves!) and use it for the office import/export.
3. When the programs handle formulas differently, you find out what the majority does, and you change the minority to match (unless the majority does something so stupid that you can convince the majority to change). This is how standards evolve.
Yes Adobe is probably (intentionally or not) detecting whether the file was written by their own software and only speeding up the linearization in that case.
I'm guessing that other PDF readers can be faster with these linear files, and speed up on both Adobe's output and the output of these other tools? Or is it more like nobody else has figured out how to take advantage of linearized files to speed themselves up?
Slashdot Mirror
Oh my god, you are really getting desperate, huh?
1. Retail boxes of Windows from Microsoft will still contain IE. What this is doing is allowing OEM's to put different arrangements of browsers on a retail machine.
2. Yes, one allowed arrangement is "no IE", although that is very unlikely. A far more likely arrangement is "IE and Firefox", something that Microsoft did not allow before or the OEM would lose their volume discount. Note that there are TWO (count em) browsers, although in your fantasy astroturf world the ONLY thing that counts is "IE is removed", despite the fact that you and I both know that nobody is going to do that.
For that matter, OEMs themselves were free to take the hassle/cost of installing a different browser if they so desired.
You blew it there. That is a LIE.
Actually the 80286 could do full memory protection. The pages were in effect 64K in size. There was certainly some strange stuff so that you were encouraged to keep using the same page, but at the time memory sizes were such that you really wanted to limit how many 64K pages were swapped in.
The problem was that the 8086 version of MSDOS preset the segments to overlap 16 bytes apart, and lots of programs assumed this. If you changed it so the paging was useful then no MSDOS programs could run, which pretty much meant it was a non-starter except for some alternative operating systems that had far less luck than Linux in competing with the juggernaut.
No, the DOS shell (if you mean command.com or cmd.exe) was inspired by the CP/M shell, which was based on RSX style systems. It was modified in some crude ways to look more like a Unix shell.
The NT shell was identical to the MSDOS one so it certainly could not be inspired somehow differently.
Calling the windowing system the "shell" is an interesting different use of the term, but any such shell could not be considered to be derived from either Unix or VMS as they had no such thing.
The NT filenames were copied from Unix, not VMS. So was all the stream I/O and the socket api, and the libc library. Well they were really copied from MSDOS, but that had already been modified extensively to resemble Unix so NT had to resemble Unix as well.
Some aspects of process management were from VMS but I suspect there was just as much variety between Unix's as there was between NT and some Unix here.
I don't know if it is stupidity or Microsoft shills.
However if you read the fa, or even if you think a little bit:
NOBODY IS GOING TO SELL A COMPUTER WITHOUT A BROWSER!
The machine the end user gets will have a browser. Likely more than one. Probably the blue E and the firefox will be on the desktop. The user can click on either one.
This is what Microsoft did not allow before and what they have been forced to allow.
They are still up to the same shit, saying "IE is missing" without saying exactly what they were forced to do.
Microsoft did not allow any *other* browser to be installed in OEM copies.
I think it is Microsoft shenanigans that got it changed to "remove IE". What should be allowed is that an OEM can sell the system preset to use a different browser by default, and remove the 'e' from the desktop and menus. It should not really matter if IE is there.
Doxygen is able to write .chm files, so I think it is sufficiently documented so that another browser could display them.
I think the complaint is more that Microsoft is not providing any means to call another browser. Assuming the file is adequately documented and actually serves some purpose then the browsers should interpret them.
Did ReiserFS gain or lose functionality for the sole reason that the author committed a crime?
Don't be an idiot in your mindless astroturfing. If you looked at the wikipedia article for ReiserFS, it mentions the murder IN THE FIRST PARAGRAPH!!!!
The fact that OOXML article does not even *deny* the Microsoft shenanigans is pretty obvious indication that something is very wrong with it.
Microsoft will *never* be compatible, and they would be overjoyed if ODF wasted the man-years necessary to explicitly state every single bit of the file format no matter how obvious it is.
The problem is that standards have to assume the person reading it *wants* to be compatible with it. I'm sure all computer standards are pretty easy to implement something that technically agrees with what is written but is not compatible. This is the first time that has made a difference, however.
I have Maya 5 from 6 years ago and it is working fine on Ubuntu 9.04.
Sounds like KDE modified Qt.
Our plain Qt 4.3.3 application if interrupted shows this on the stack:
#0 0xb805e430 in __kernel_vsyscall () /lib/tls/i686/cmov/libc.so.6
#1 0xb762ddf1 in select () from
#2 0x08a9e6c4 in QEventDispatcherUNIX::select ()
#3 0x085cb93e in QEventDispatcherX11::select ()
#4 0x08a9f880 in QEventDispatcherUNIXPrivate::doSelect ()
#5 0x08a9fd36 in QEventDispatcherUNIX::processEvents ()
#6 0x085cbb56 in QEventDispatcherX11::processEvents ()
#7 0x08a7b571 in QEventLoop::processEvents ()
#8 0x08a7b89a in QEventLoop::exec ()
#9 0x08a7db92 in QCoreApplication::exec ()
Thank you.
This is in fact why "installation" works on Windows. It has nothing to do with Windows itself, it is because programs include all the libraries they need!
There is a switch to the linker that makes a linux executable act as though LD_LIBRARY_PATH starts with the directory the executable is in. This should be turned on ALL THE TIME by EVERY PROGRAM IN THE WORLD (in fact it should be the default). If you want to say something technically correct about Windows, you can say that it does act this way by default.
Some corrections, although the sentiment is correct:
copy of A to A', ftruncate(A'), write(A'), rename(A' to A), host crash, causes the resulting file to contain A data and not A'
This is not what is wrong. If the file contained the old version of A it would be fine, this is the expected behavior. The problem is that the file contains some partially-written version of A' (usually a zero-length version).
Posix doesn't actually say that rename is a write barrier for data and metadata
Actually POSIX does say exactly that. The hole EXT4 weasels through is that POSIX says "anything can happen when the machine crashes".
apps didn't make use of fdatasync() / fsync() correctly
The apps *were* using these calls correctly, by not calling them. They are very slow and make guarantees that have nothing to do with the desired action, which is an atomic rename.
The rename is precisely what is broken in EXT4!
EXT4 is broken.
Posix requires that writing a file and then renaming it to a new location is an ordered atomic operation. Say file B already exists. You write file A, then close it, then rename (mv) it to B. Another program running at the same time opens B and reads it. It will get one of these two results, and NO OTHER RESULT:
1. It sees the old contents of B
2. It sees what was written to A.
EXT4 (before these patches) could result in the following result if your machine crashes and you start it again and look at B:
3. B is empty (also B is various partially-written versions of A, but empty most common).
Now it is true that Posix says that if the machine crashes, all bets are off. So yes EXT4 is being technically correct. But it would be equally technically correct if all the files on the disk were empty so this is pointless.
EXT4 promises to make crashes recoverable. This implies to me that after you recover from a crash, you will be left in a state allowed by POSIX. This means either you get the old contents of B or the new full contents of A, and EXT4 by allowing a different result is breaking it's design and promise.
Actually very early solitarie games certainly *did* have resolution-independent graphics. A few vectors to describe a card image took less space than a bitmap (granted the card images were usually a rectangle with a suit symbol and number). Vectors could easily be scaled to different sizes.
That explanation makes no sense. What Microsoft decided to do is be incompatible with both current ODF files and with the 2.2 spec, as (unless they are idiots) the 2.2 spec will use the same namespace everybody (except Microsoft) is using right now, since otherwise it would be impossible to read/write these files in an upwardly compatible way (of course that is the goal of Microsoft so that is what they did).
What happens when Microsoft plays foul with ODF?
This actually may help some, if the news can be gotten to the right people.
Although I'm sure they would have found another excuse, it was in fact a bug in OpenOffice that they turned into the reason they had to be incompatible (OpenOffice does something really stupid when a string is used in an expression, it turns it into zero, rather than either producing an error or seeing if the contents of the string look like a number [Excel and every other ODF program do the second one]). They used this as a reason that Excel had "different" formulas, or that the formulas were "undefined" (they are in fact defined by "do what is obvious, if not obvious then copy Excel").
Pointing out that there are alternative implementations that all agree would help a lot in blocking that incredible deluge of wordy lies from those Microsoft engineers. Though I have to admit they apparently have no shame, I really don't think I could literally lie like that in a phony technical argument on a public web page with my name on it, no matter what I was paid.
The earth's temperature is 375 degrees kelvin. Reducing that 1% means you reduce it 3.75 degrees.
You seem to think absolute zero is when ice freezes?
Aluminum is used in roof paint all the time.
I have a big can of it in the garage.
I do have to say that the bug report is very informative, especially the comments and how mad users are. OpenOffice are being absolutlely brain-dead, it seems they have no concept of how horrible they are acting. Now, besides making OO spreadsheet absolutely useless, they can now also be blamed for Microsoft finding an excuse for being incompatible with ODF. Thanks a lot guys.
My opinion on this bug:
"1"+1 should either produce 2 or an ERROR. Producing 1 is wrong and there is no possible argument. OOO is WRONG!!!!
I really doubt there are as many number formats as locales, so you hardly need such a complex list. Again check what Excel does. I like the idea of converting the strings to numbers as the sheet is loaded, or maybe when they are referenced, as it will magically fix it when saved.
This is an excellent demonstration of the types of stubborness that software developers sometimes get. Any outside observer would see how obvious the need for a fix is, but they can't see it. And once they say they will not fix it they do not want to admit they were wrong and the refuse and come up with endless convoluted arguments. Open source makes this crap visible, but I can tell you that closed source has exactly the same problem. Open source also meant that Microsoft could directly quote the bullshit arguments and use it as an excuse to make ODF incompatible. I was wondering where they were getting so many pages of plausable-sounding but meaningless bullshit.
I don't understand this thinking. The result of Microsoft's actions is that EVERYBODY will have to use the msoxl namespace, otherwise their saved document will not load into Word. This is absolutely useless for differentiating formula types because only one namespace can actually be used!
And OpenOffice has a BUG!!!! If they really said "automatic string conversions are harmful" then OpenOffice should produce an error message. It does not do this, therefore it is a bug! Also claiming that commas vs periods are a problem does not mean that a string containing *neither* a comma or period should fail!
I am absolutely astonished by the convoluted reasoning being used by astroturfers here to excuse this completely evil and devious scheme by Microsoft. You guys should be crowing to the skies about OpenOffice having a bug. But no instead this is somehow some kind of "defined behavior" or whatever stupid reason you can come up with to blather on and on with pages of inanity desiged to convince the PHB that this is not an evil scheme. This is disgusting and I don't understand how you can live with yourselves, prostituting yourselves like this.
Here if the PROPER solution:
1. OpenOffice copies whatever the fuck Excel does with strings. Either the string is marked with the locale that it was loaded from, or the current locale is used, or it is always C, or whatever. They can thank Microsoft for their diligent bug search that located this bug, Microsoft must have put big bucks into this team that found as many bugs as they could.
2. Microsoft has to stop this transparent bullshit. Those people writing the blogs should be ashamed of themselves and any antitrust fine should be taken out of their paychecks. They should take the clever age plugin (BSD code that they wrote themselves!) and use it for the office import/export.
3. When the programs handle formulas differently, you find out what the majority does, and you change the minority to match (unless the majority does something so stupid that you can convince the majority to change). This is how standards evolve.
Okay I understand now.
Yes Adobe is probably (intentionally or not) detecting whether the file was written by their own software and only speeding up the linearization in that case.
I'm guessing that other PDF readers can be faster with these linear files, and speed up on both Adobe's output and the output of these other tools? Or is it more like nobody else has figured out how to take advantage of linearized files to speed themselves up?
The wikipedia page says the GPL "pdfopt" program can do this linearization.
If you assume that loading a file and saving it should not change the data, then it is far easier to save the data.
If you think loading and saving should throw away unknown data then you are a bad programmer.