Granted on you giving my opinions what weight they deserve, it is, after all, your email. When you responded to me in the first place however, it had seemed that you ignored the content and intent of my response to you... namely that while I use email to get work done, you use it to proselytize, and at the same time call the user an idiot... regardless of the reason he or she may be using said mail client.
As for your second point, I am NOT defending the "idiocy" of anything. I am attacking your method of pointing out problems as in itself causing an obfuscation. While Microsoft may be guilty of everything you want to throw the book at them for, if you are going to accuse them of something, at least provide examples that are meaningful and accurate.
Base64 encoding IS a standard. It may be stupid to use it for email text content, but that doesn't change the fact that it is a standard. Your reference to the definition in RFC 822 of what a message is is also confusing the matter, since your first RFC 1341 reference also CLEARLY states that:
...This document redefines the format of message bodies to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information.
Furthermore, the very RFC you are quoting (1341) mentions Base64 encoding as example usage in many places throughout the text of it. The RFC in fact *describes* the usage of base64. So you aren't making any point here stating that it's against the letter of the MIME standards.
That wasn't my point. I didn't say you couldn't be annoyed by it. I was taking exception to you bouncing email because of how it's encoded. I was taking exception to you complaining about Microsoft not using published standards, when that encoding method (regardless of how inanely it is used) IS a published standard. You damage your own rant.
Hmm, well, if you read like you say you read, you would realize that Windows ME (which sucked, all things considered, but please get it right as to WHY it sucked) didn't say you had no access to the command line. It said you couldn't BOOT to the commandline instead of booting straight into Windows ME. Which is true... as it was shipped.
And have you LOOKED at MSDN without a subscription? Without giving them ANY money, there is a hell of a lot of information up there freely available. You don't even have to sign up for the free access.
So while I'm using my email client (whatever the hell it may be) to get work done, you are using it to waste time proselytizing, when the encoding method is detailed RIGHT IN THE EMAIL MESSAGE. The problem in this case isn't the sending client, it's the receiving client. Are you using an early version of pine or something?
That said, the reviewer seems to have his own conceit shoed pretty far up his ass. Aside from boiling down plot to small sentences, which sadly can be done to really any story, he continually harps on that -oid versus -ile suffix with regards to the Naxid. This, aside from detracting from the wonderful vitriol that otherwise fills this review, is done incorrectly.
-ile, according to Mirriam-Webster:
Main Entry: 1-ile
Function: adjective suffix
Etymology: Middle English, from Middle French, from Latin -ilis
: tending to or capable of
versus
-oid, same source:
Main Entry: 2-oid
Function: adjective suffix
Etymology: Middle French & Latin; Middle French -oide, from Latin -oides, from Greek -oeidEs, from -o- + eidos appearance, form -- more at WISE
: resembling : having the form or appearance of
The author of the book got it right... they ARE insectoid. I have nothing to say for the author of the review.
Gotta wonder what it's like to be a Windows developer working at Apple. Do they have to come in a odd times so they don't get lynched? Do they feel unclean, sullied? Or does Apple farm the development off site, so as not to worry about such things?
Hmmm, all nice points, but: Ford's bumpers, while at the same height for safety reasons don't interoperate with Chevy... e.g., you can't simply take the bumper off the Ford and put it on the Chevy without modifying it. All computers run on the same electricity, the fuel type makes no nevermind. Limits as far as size goes is *somewhat* analagous to being limited by the available resources on the computers you're working with. As those resources grow, the size of the software (cars) running on it increases; only legislation keeps cars and trucks from getting bigger, as well as practicality. License plates are not generated by Ford to be put on Chevies and Toyotas. The Government makes them, and that would be closer to a processor serial number than a product feature. Headlights at a certain height... and yet they still vary widely. Seen a jeep lately? In any case, AGAIN, Ford ain't makin headlights for Chevy, we count ourselves lucky when one kind of headlight fits in multiple different vendor types. Similar tires? Like you said, they don't HAVE to, and the manufacturers are STILL not makin tires for other manufacturer's cars.
And to address your last point: While I agree Microsoft may be abusive (based on all the hearsay I have), unless you are talking about a regulated industry (software is not) there is no such thing as an illegal monopoly in the U.S. People don't understand that antitrust refers to existing monopolies using their power to unfairly create ANOTHER monopoly. Which I would also agree that they have done. But there are no "rules of the industry" they are violating. They may be violating civil or criminal law though. As to the BF Goodrich and GY HAVING to make tires of a certain size to work with a particular car; well this is a different ball of wax, they are COMPONENT companies, not car manufacturers themselves. Kind of a silly example, really. What you did not give was an answer to the question you quoted.
Since we've started to address the issue of HOW to change, and WHAT to change, people who read may begin to realize it's not as simple as IT administrators and MCSEs saying, "OH! What was I thinking? I'll convert this all right now."
It gets far more complex than that. While monoculture itself certainly can and does lead to an environment where one vulnerability hits everyone, it is neverhteless true that every OS has its vulnerabilities, and aside from the OS vulnerabilities, every application running on the OSes have their vulnerabilities. If you get rid of OS monoculture, what do you do about application monoculture? If you force Microsoft to interoperate with various Unix flavors, why doesn't the newest Sendmail exploit not affect everyone, especially if they use the same source? It's not a simple answer.
Also, while not everyone who picks Microsoft as a target to bash is indulging in sour grapes complaining, the quote "Microsoft should not be allowed to release Office for any one platform, such as Windows, until it releases comparable Linux and Mac OS versions." certainly tends to make one think that in this case, they are. After all, what industry in the US is required, *required!* to make components that work with their competitors?
Slashdot Mirror
Edible RFID tags! BRILLIANT, man, brilliant!
Granted on you giving my opinions what weight they deserve, it is, after all, your email. When you responded to me in the first place however, it had seemed that you ignored the content and intent of my response to you... namely that while I use email to get work done, you use it to proselytize, and at the same time call the user an idiot... regardless of the reason he or she may be using said mail client.
...This document redefines the format of message bodies to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information.
As for your second point, I am NOT defending the "idiocy" of anything. I am attacking your method of pointing out problems as in itself causing an obfuscation. While Microsoft may be guilty of everything you want to throw the book at them for, if you are going to accuse them of something, at least provide examples that are meaningful and accurate.
Base64 encoding IS a standard. It may be stupid to use it for email text content, but that doesn't change the fact that it is a standard. Your reference to the definition in RFC 822 of what a message is is also confusing the matter, since your first RFC 1341 reference also CLEARLY states that:
Furthermore, the very RFC you are quoting (1341) mentions Base64 encoding as example usage in many places throughout the text of it. The RFC in fact *describes* the usage of base64. So you aren't making any point here stating that it's against the letter of the MIME standards.
That wasn't my point. I didn't say you couldn't be annoyed by it. I was taking exception to you bouncing email because of how it's encoded. I was taking exception to you complaining about Microsoft not using published standards, when that encoding method (regardless of how inanely it is used) IS a published standard. You damage your own rant.
Hmm, well, if you read like you say you read, you would realize that Windows ME (which sucked, all things considered, but please get it right as to WHY it sucked) didn't say you had no access to the command line. It said you couldn't BOOT to the commandline instead of booting straight into Windows ME. Which is true... as it was shipped. And have you LOOKED at MSDN without a subscription? Without giving them ANY money, there is a hell of a lot of information up there freely available. You don't even have to sign up for the free access.
So while I'm using my email client (whatever the hell it may be) to get work done, you are using it to waste time proselytizing, when the encoding method is detailed RIGHT IN THE EMAIL MESSAGE. The problem in this case isn't the sending client, it's the receiving client. Are you using an early version of pine or something?
That said, the reviewer seems to have his own conceit shoed pretty far up his ass. Aside from boiling down plot to small sentences, which sadly can be done to really any story, he continually harps on that -oid versus -ile suffix with regards to the Naxid. This, aside from detracting from the wonderful vitriol that otherwise fills this review, is done incorrectly. -ile, according to Mirriam-Webster: Main Entry: 1-ile Function: adjective suffix Etymology: Middle English, from Middle French, from Latin -ilis : tending to or capable of versus -oid, same source: Main Entry: 2-oid Function: adjective suffix Etymology: Middle French & Latin; Middle French -oide, from Latin -oides, from Greek -oeidEs, from -o- + eidos appearance, form -- more at WISE : resembling : having the form or appearance of The author of the book got it right... they ARE insectoid. I have nothing to say for the author of the review.
Actually, that 512 file limit is only enforced by the boot record and the device READING the FAT. It's not an inherent limitation in FAT itself.
"internal Windows settings?" That's like calling daemons internal Unix settings. They are separate programs. Turning them on and off isn't even HARD.
Gotta wonder what it's like to be a Windows developer working at Apple. Do they have to come in a odd times so they don't get lynched? Do they feel unclean, sullied? Or does Apple farm the development off site, so as not to worry about such things?
Hmmm, all nice points, but:
Ford's bumpers, while at the same height for safety reasons don't interoperate with Chevy... e.g., you can't simply take the bumper off the Ford and put it on the Chevy without modifying it.
All computers run on the same electricity, the fuel type makes no nevermind.
Limits as far as size goes is *somewhat* analagous to being limited by the available resources on the computers you're working with. As those resources grow, the size of the software (cars) running on it increases; only legislation keeps cars and trucks from getting bigger, as well as practicality.
License plates are not generated by Ford to be put on Chevies and Toyotas. The Government makes them, and that would be closer to a processor serial number than a product feature.
Headlights at a certain height... and yet they still vary widely. Seen a jeep lately? In any case, AGAIN, Ford ain't makin headlights for Chevy, we count ourselves lucky when one kind of headlight fits in multiple different vendor types.
Similar tires? Like you said, they don't HAVE to, and the manufacturers are STILL not makin tires for other manufacturer's cars.
And to address your last point: While I agree Microsoft may be abusive (based on all the hearsay I have), unless you are talking about a regulated industry (software is not) there is no such thing as an illegal monopoly in the U.S. People don't understand that antitrust refers to existing monopolies using their power to unfairly create ANOTHER monopoly. Which I would also agree that they have done. But there are no "rules of the industry" they are violating. They may be violating civil or criminal law though. As to the BF Goodrich and GY HAVING to make tires of a certain size to work with a particular car; well this is a different ball of wax, they are COMPONENT companies, not car manufacturers themselves. Kind of a silly example, really.
What you did not give was an answer to the question you quoted.
Since we've started to address the issue of HOW to change, and WHAT to change, people who read may begin to realize it's not as simple as IT administrators and MCSEs saying, "OH! What was I thinking? I'll convert this all right now." It gets far more complex than that. While monoculture itself certainly can and does lead to an environment where one vulnerability hits everyone, it is neverhteless true that every OS has its vulnerabilities, and aside from the OS vulnerabilities, every application running on the OSes have their vulnerabilities. If you get rid of OS monoculture, what do you do about application monoculture? If you force Microsoft to interoperate with various Unix flavors, why doesn't the newest Sendmail exploit not affect everyone, especially if they use the same source? It's not a simple answer. Also, while not everyone who picks Microsoft as a target to bash is indulging in sour grapes complaining, the quote "Microsoft should not be allowed to release Office for any one platform, such as Windows, until it releases comparable Linux and Mac OS versions." certainly tends to make one think that in this case, they are. After all, what industry in the US is required, *required!* to make components that work with their competitors?