"Microsoft research does try to tackle such problems, the dilemma is that their work, as far as I can tell, seems to get ignored when it comes to product development and marketing."
That's exactly what happened with PARC at Xerox.
"What we need is a model of concurrency, and a programming language to support it, that makes programming concurrent systems easy, and make reasoning about it easy."
I think a lot of the problems we have with concurrency today are actually the result of trying to trying to include threading in programming languages. For example, Java threads are much harder to get right than most OS threads simply because the language hides the true nature of the threading as it is implemented in the underlying system. So you have to use special rules (such as assuming both that you can be preempted at any time and that you will never be preempted) not enforced by the language in order to get your threaded code to work the same on different OS's.
"Micro$oft hires (or tries to hire) as many top PhD, visionaries, mangers, etc. as they can for a very specific reason. To take them off the market and keep the competition from getting them.
Sure, that's a real plausible theory. Given my personal experience with "visionaries", I'd say the best way to compete is to make sure they work for your competitors.
"In the interim, it's a shame Bell Labs has gone from world leader to nothing... budget cuts, etc. (Lucent)... there was some real research there, and lots of it was shared with the world."
Many great technologies were created by monopolies: AT&T, XEROX, IBM. When you have nearly unlimited cash, you can afford to spend money on research even if the practical applications are years away. As these companies lost their dominant market share, their research declined as well.
Well, if kernel developers are pussies, than who the hell needs them? We'll just go back to waiting for HURD. After all, their manliness is all that really matters.
"what the agreement does is allow Novell programmers to KNOWINGLY put patented stuff for Microsoft compatibility into their products, even the OSS ones and know M$ won't DMCA them. "
It does nothing of the sort. Novell programmers can't legally do this, have no reason to do this, and have absolutely no obligation to do this under the agreement. As I've said before, compatibility can either be achieved without violating patents or it can't. This agreement doesn't change the patent facts (whatever they are). It merely states that the two companies won't sue each other's customers for patent violation, that's all.
I was just suggesting that a non-ASCII XML would be better. I didn't expect you to start using a hypothetical standard immediately. I have no expectation that such a standard will be widely used because there are strong cultural taboos against it in the programming world, particularly in the UNIX commmunity that created the web standards.
I guess my post wasn't that clear, since several people thought I was suggesting that source code should be written without ASCII. I meant data (but alas, I didn't use that word). Nevertheless, I found your post interesting.
I didn't really mean to suggest that source code should be represented in a different binary format (i.e. non-ASCII), but that data be represented in a more efficient form.
Given how fast browsers were adopted by almost all platforms suggests to me that resisting binary formats is primarily a cultural issue among programmers than rather than a technical or practical one. I come from an embedded background, so it's not a problem for me.
1. Representation schemes that are designed with specific knowledge of the type of data that is going to be represented compress better than a general purpose compression algorithm..
2. Broswers don't accept zipped pages, so the file would have to be manually unzipped before presentation to the broswer.
3. Broswers could be modified for either a binary HTML or to accept a zipped page, but there would be more run-time processing involved to unzip than there would be to natively support a binary HTML.
Of course ASCII (or UNICODE for that matter) is a binary standard as well. So special tools called text editors were created so that people could read it.
There are more sophisticated binary standards that are more efficient than ASCII and it wouldn't take a lot of effort to create viewers/editors for them as well. Of course most markup documents would be significantly smaller if tags didn't have to be S-P-E-L-L-E-D O-U-T character by character. Each HTML tag could be encoded in just two bytes with lots of room to spare.
It always fascinates me that we have no problem making customers use a new specialized tool like a browser, but it's taboo to use a non-ASCII tool for development. So we continue to structure our data as if it were going to be processed by a VT100.
By your definition hearing isn't lossless either. The practical definition of lossless is that no information is lost as part of a compression process. When the difference between the orginal recording and a lossy representation can't be detected by the human ear, than it won't matter, but we are a long way from that on most portable devices.
Insightful? If you're going to test Vista on a hardware configuration that doesn't meet its system requirements, why not test it on an iPod? The results would be equally useful. Don't forget the obligatory install of RedHat Linux on the iPod too (you know: "to enhance the comparison").
This reminds me of a PC Magazine cover many years ago that asked the question "Do you really need a 286?".
When you can search through a full disk to find all the files that contain a particular string and have the complete list pop-up before you can lift your finger off the Enter key I'd say computers are fast enough.
"Ever wonder if this was MS's plan all along? Not to win?"
A love how pure speculation is now piled on top of the previous pure speculation. Look, I can do it too:
I wonder if it was RMS's plan all along for Novell to lose this case so that IBM could win it's case so Novell would be tempted to make a deal with MS, so Linus would adopt GPLv3 so MS would have to...
Why don't you send an email to the governor? After all there's no point in studying the matter since you already know that adopting ODF will benefit the citizens of Massachusetts.
I think that's a pretty big stretch. I seriously doubt a court would buy the idea that you were guilty of knowing infringement of any and all MS patents on the basis of an agreement not to sue between Novell and MS. It's a bit like IBM claiming that you knowingly infringed on one of their patents simply because you were aware that they have more patents than anyone else. The relationship is too indirect. Most likely MS (or IBM) would have to prove that you had knowlege that you were infringing on the specific patent in question.
You seem to be confusing trade secrets with patents. You can't use the "clean room" approach to avoid a patent issue. Either interoperability can't be acheived without violating MS patents or it can be. Whether Novell coders do or do not get specifications is irrelevent to the patent issue. You don't need to know anything about how Amazon implemented their one-click functionality to violate the one-click patent.
Slashdot Mirror
(Not Invented By Microsoft) so naturally IBM would prefer it.
I wasn't aware that file formats could have all those flaws. Perhaps you didn't even read the summary.
Actually, I think it would be great if Tannenbaum were to come out in support of GPLv3. That should make the fanboys' heads spin 360 degrees.
"Microsoft research does try to tackle such problems, the dilemma is that their work, as far as I can tell, seems to get ignored when it comes to product development and marketing."
That's exactly what happened with PARC at Xerox.
"What we need is a model of concurrency, and a programming language to support it, that makes programming concurrent systems easy, and make reasoning about it easy."
I think a lot of the problems we have with concurrency today are actually the result of trying to trying to include threading in programming languages. For example, Java threads are much harder to get right than most OS threads simply because the language hides the true nature of the threading as it is implemented in the underlying system. So you have to use special rules (such as assuming both that you can be preempted at any time and that you will never be preempted) not enforced by the language in order to get your threaded code to work the same on different OS's.
"Micro$oft hires (or tries to hire) as many top PhD, visionaries, mangers, etc. as they can for a very specific reason. To take them off the market and keep the competition from getting them.
Sure, that's a real plausible theory. Given my personal experience with "visionaries", I'd say the best way to compete is to make sure they work for your competitors.
"In the interim, it's a shame Bell Labs has gone from world leader to nothing... budget cuts, etc. (Lucent)... there was some real research there, and lots of it was shared with the world."
Many great technologies were created by monopolies: AT&T, XEROX, IBM. When you have nearly unlimited cash, you can afford to spend money on research even if the practical applications are years away. As these companies lost their dominant market share, their research declined as well.
Well, if kernel developers are pussies, than who the hell needs them? We'll just go back to waiting for HURD. After all, their manliness is all that really matters.
If you're talking about a non-programming or non-IT job, the HR person interviewing you might ask "what's a Linux? Some kind of car?"
For a lot of companies that use only Windows, Linux is a hobby with as much significance to their work as knitting or scuba diving.
"what the agreement does is allow Novell programmers to KNOWINGLY put patented stuff for Microsoft compatibility into their products, even the OSS ones and know M$ won't DMCA them. "
It does nothing of the sort. Novell programmers can't legally do this, have no reason to do this, and have absolutely no obligation to do this under the agreement. As I've said before, compatibility can either be achieved without violating patents or it can't. This agreement doesn't change the patent facts (whatever they are). It merely states that the two companies won't sue each other's customers for patent violation, that's all.
I stand corrected.
I was just suggesting that a non-ASCII XML would be better. I didn't expect you to start using a hypothetical standard immediately. I have no expectation that such a standard will be widely used because there are strong cultural taboos against it in the programming world, particularly in the UNIX commmunity that created the web standards.
I guess my post wasn't that clear, since several people thought I was suggesting that source code should be written without ASCII. I meant data (but alas, I didn't use that word). Nevertheless, I found your post interesting.
I didn't really mean to suggest that source code should be represented in a different binary format (i.e. non-ASCII), but that data be represented in a more efficient form.
Given how fast browsers were adopted by almost all platforms suggests to me that resisting binary formats is primarily a cultural issue among programmers than rather than a technical or practical one. I come from an embedded background, so it's not a problem for me.
1. Representation schemes that are designed with specific knowledge of the type of data that is going to be represented compress better than a general purpose compression algorithm..
2. Broswers don't accept zipped pages, so the file would have to be manually unzipped before presentation to the broswer.
3. Broswers could be modified for either a binary HTML or to accept a zipped page, but there would be more run-time processing involved to unzip than there would be to natively support a binary HTML.
"I'm pretty sure not one of my customers ever got a browser to read my documentation; I wrote it in HTML because they've all got browsers already."
You're missing the point. Until about a decade ago almost nobody had a browser.
Of course ASCII (or UNICODE for that matter) is a binary standard as well. So special tools called text editors were created so that people could read it.
There are more sophisticated binary standards that are more efficient than ASCII and it wouldn't take a lot of effort to create viewers/editors for them as well. Of course most markup documents would be significantly smaller if tags didn't have to be S-P-E-L-L-E-D O-U-T character by character. Each HTML tag could be encoded in just two bytes with lots of room to spare.
It always fascinates me that we have no problem making customers use a new specialized tool like a browser, but it's taboo to use a non-ASCII tool for development. So we continue to structure our data as if it were going to be processed by a VT100.
By your definition hearing isn't lossless either. The practical definition of lossless is that no information is lost as part of a compression process. When the difference between the orginal recording and a lossy representation can't be detected by the human ear, than it won't matter, but we are a long way from that on most portable devices.
Insightful? If you're going to test Vista on a hardware configuration that doesn't meet its system requirements, why not test it on an iPod? The results would be equally useful. Don't forget the obligatory install of RedHat Linux on the iPod too (you know: "to enhance the comparison").
My point is that we are a long, long, way from PCs being as fast as you could wish for.
This reminds me of a PC Magazine cover many years ago that asked the question "Do you really need a 286?".
When you can search through a full disk to find all the files that contain a particular string and have the complete list pop-up before you can lift your finger off the Enter key I'd say computers are fast enough.
"Ever wonder if this was MS's plan all along? Not to win?"
...
A love how pure speculation is now piled on top of the previous pure speculation. Look, I can do it too:
I wonder if it was RMS's plan all along for Novell to lose this case so that IBM could win it's case so Novell would be tempted to make a deal with MS, so Linus would adopt GPLv3 so MS would have to
Why don't you send an email to the governor? After all there's no point in studying the matter since you already know that adopting ODF will benefit the citizens of Massachusetts.
If posting as an AC implies BS, what should we make of you?
I think that's a pretty big stretch. I seriously doubt a court would buy the idea that you were guilty of knowing infringement of any and all MS patents on the basis of an agreement not to sue between Novell and MS. It's a bit like IBM claiming that you knowingly infringed on one of their patents simply because you were aware that they have more patents than anyone else. The relationship is too indirect. Most likely MS (or IBM) would have to prove that you had knowlege that you were infringing on the specific patent in question.
You seem to be confusing trade secrets with patents. You can't use the "clean room" approach to avoid a patent issue. Either interoperability can't be acheived without violating MS patents or it can be. Whether Novell coders do or do not get specifications is irrelevent to the patent issue. You don't need to know anything about how Amazon implemented their one-click functionality to violate the one-click patent.