"Just imagine how much further along projects like KDE, Python, Perl, and Ruby would be if effort and expertise hadn't been wastefully siphoned off to GNOME and Mono."
This might be a reasonable argument to make if OSS was a corporation and one made up entirely of paid employees, but since it is not, no "siphoning" took place. People freely chose what they wanted to contribute their time and code to. They weren't the default property of any project. It was their time to "waste" whether they contributed that time to GNOME or KDE.
Any MS patents Mono might violate aren't going to be described as if they are restricted to.Net, they would be described as broadly as possible. So unless Mono implements some functionality that no other library or framework possesses, Mono is not uniquely vulnerable to patent problems from MS.
"Apple paid Xerox for the rights to commercialize their technology"
I've done a fair amount of searching and never found a link to a legal document that says anything of the sort. Do you have a link? If your research source is a good one, you should be able to tell us what specific rights were granted, for how long, was it an exclusive agreemtent etc.
Although those stock options would be a big deal to a small company like Apple, it would be chump-change for a major corporation like Xerox. There's no way they would turn over their rights to Apple for such a paltry sum. It would be a reasonable amount, however, for a company of Xerox's size to bother with a tour to "inspire" Apple engineers without actually giving up any IP.
If Xerox had actually sold their rights to Apple, Apple would have immediately presented the document to the court to prove Xerox's case had no merit and the case would have been summarily dismissed on those grounds (the case was dismissed because too much time had elapsed).
Likewise, if Apple had actually purchased the rights to Xerox's work, they would have introduced this as evidence in the case agains MS, but they didn't.
So really there's no rational basis for the claim that Xerox sold their IP to Apple.
I'm not sure. Clearly the second statement turned out to be true provided that you don't follow the definition of "sexual relations" favored by a 13 year-old future republican kid who brags that he's not a virgin because he felt a girl up.
Sorry to burst your bubble, but Apple didn't pay Xerox for their technology although there is some lore that they paid for a tour. Given that Xerox later sued Apple and and Apple never produced a document indicating that they had purchased any rights, it's very likely that the story about Apple buying the rights to Xerox's ideas is probably just that - a story and nothing more.
The more important point is that Gates couldn't have significantly increased the number beyond 640K even if he wanted to do to the limitations of the processor and the need for address space to be reserved for other purposes. So anyone who mentions the "quote" to imply that Gates was an idiot for choosing the 640K limit is either ignorant or is deliberately attempting to mislead.
This limit is really more the responsiblity of Intel's for designing the world's ugliest processor architecture (now and forever) and IBM for choosing it.
Usually that phrase would apply to a company that once had a major percentage of a market and holds it no longer. The Mac never had a big piece of the market and I'll bet that the Apple II had a much larger market share than the Mac has ever enjoyed.
What legendary rock-n-roll song was used at the gala release celebration for OS/2? Oh, that's right, there was no celebration. OS/2's number one reason for failing was that IBM didn't make much of an effort to make it a success.
I think it's instructive to remember that there are far more minimally successful or unsuccessful Apple products than there are very successful Apple products. Actually, the iPod is the only one that is a market leader.
So the odds that this product will be a big winner are not that high if Apple's overall performance is considered.
Probably not very often on today's general purpose processors, but of course the hardware is "rigged" in favor of compilers. The price that is paid is that these processors aren't suitable for hard real-time programming because their timing isn't deterministic. If you use a PC for a hard real-time system (no matter what OS you use, if any) you have to push the hard RT stuff to hardware.
"Intel desktop and workstation microprocessors, or any superscalar microprocessors for that matter, are a great example. The programmer (or compiler) writes a single-threaded assembly language program for an extremely simple machine that is basically a fiction. The assembly programmer gets to think in terms of ISA abstractions like "the EAX register" when in the real microprocessor, with its superscalar pipelines, out-of-order execution, branch prediction, and so forth, there really isn't anything you could reasonably point to and say, "This is the EAX register." The microprocessor is a dizzyingly complex hardware simulation of the simple machine that software programmers use as their mental model of "the hardware.""
This sort of "fiction" is a fundamental requirement of these devices to be classified as microprocessors; otherwise you'd have to perform "programming" by doing digital logic design or microcoding. It's like saying that car manufactures accomodate drivers legacy expectations by providing wheels for the car.
In addition, a number of these added features don't really preserve legacy expectations anyway. Hard real-time software can't really be written for most modern processors because the execution time of a particular section of code is not deterministic.
"P.S. I admit I don't know anything about Intel's introduction of segmentation, but reading what Wikipedia says, it seems like the key selling point of segmentation was the ease of porting old software."
Given the fact that the 8086/8088 couldn't natively run 8085 programs, I don't think backward compatibility was a major goal. If you have to translate instructions anyway, changing from an 8 bit address to 16 bit address isn't that much harder.
I used to wish that there were more hardware resources available to get the job done in a reasonable time-frame. Now that I got my wish and hardware is so cheap and capable, my hard-won assembly language skills are mostly obsolete.
"Considering that hardware designers have been leaning over backwards for years to help software programmers stick with one fairly easy programming model, I wouldn't be too quick to blame the hardware industry. They know which side their bread is buttered on. The hardware company that requires the least adaptation from software developers has the advantage, just like the software company that requires the least change and adaptation from users always has the advantage."
I didn't see the "leaning over backwards" you refer to. What hardware improvements have hardware designers avoided because it would have caused the current programming model to change? You don't have to look any further than the x86 architecture with its segmented memory to conclude that ease of programming has never been a key goal at Intel.
"I've never had a choice; my first professional job was at a Java shop that used multithreaded servers, and at my current gig one of my ongoing tasks is to add multithreading to single-threaded C++ apps so that our customers get as much power as possible out of their multi-CPU workstations."
One advantage of server apps is that they inherently lend themselves to a mutithreading approach since each request can be seen as a seperate unit of work. As you probably know, the challenge comes when no such natural break-down is apparent.
Yes, linux is very secure, but too bad it doesn't have a GUI or any drivers except for the console. You can't have a different definition of what linux is when you're talking about functionality than you do when you talk about vulnerabilities.
"When technology hits a dead end on one track, the industry goes looking for another track where progress can be made."
There are two different industries involved here: the hardware processor industry and the software industry. It looks like the former is looking for the latter to bail it out. Multicore isn't really a new track, it's more of a repackaging effort.
"I'm going to pursue the low-hanging fruit elsewhere."
I think all the discussion over this issue suggests that it isn't low-hanging fruit.
"When they do knock it down, I'll be right behind you, and what will I have lost?"
As always, it depends. If you and your co-workers don't make any additional mistakes due to the added complexity, probably nothing bad will happen. Obviously if multicore doesn't actually add a lot of multithreading to your project because you're already using it extensively, it won't have any effect at all.
I see multicore as a plan B strategy because chip makers can't provide the super high speed processors the market really wants. If new technologies that let us break through the current speed barrier become practical, the interest in multicore and the associated "everything needs to be multithreaded" philosophy will fade away.
"Gigahertz are out and cores are in. Programmers must begin to develop applications that take full advantage of the increasing number of cores present in modern computers."
The marketplace wants and needs new technologies for more powerful processors. Multicore serves the needs of chip makers, not their customers. Making all software multi-threaded is trying to solve the wrong problem. It's going to result in lower-quality software without a significant increase in performance.
Why should we believe that the work ethic of early employees would be better than those who come later? I've worked both at startups and large established companies and I haven't seen any significant difference in the dedication of workers.
I have no problem with WINE being described as a project that allows some Windows applications to run under Linux. The problem is that it is often promoted as a general solution to running Windows applications on Linux, which it is not.
"100% pure Java" was a logo program that Sun created that was supposed to certify that a qualifying application "conforms to the Java ideal of universal portability". I assume that the word "ideal" was used because Sun realized that Java apps couldn't actually achieve universal portability. Like many others, I suspected that its main purpose was to discredit MS's JVM and Java apps that were based on it.
Slashdot Mirror
"The whole point of .Net was get something there while it fucked over Sun."
Your confusing Sun's philosophy with MS. Sun's philosophy has (until recently) been to fuck MS. MS's philosophy is to make money.
"Just imagine how much further along projects like KDE, Python, Perl, and Ruby would be if effort and expertise hadn't been wastefully siphoned off to GNOME and Mono."
This might be a reasonable argument to make if OSS was a corporation and one made up entirely of paid employees, but since it is not, no "siphoning" took place. People freely chose what they wanted to contribute their time and code to. They weren't the default property of any project. It was their time to "waste" whether they contributed that time to GNOME or KDE.
Any MS patents Mono might violate aren't going to be described as if they are restricted to .Net, they would be described as broadly as possible. So unless Mono implements some functionality that no other library or framework possesses, Mono is not uniquely vulnerable to patent problems from MS.
If the iPhone is not a big hit, will it kill Apple's momentum?
"Apple paid Xerox for the rights to commercialize their technology"
I've done a fair amount of searching and never found a link to a legal document that says anything of the sort. Do you have a link? If your research source is a good one, you should be able to tell us what specific rights were granted, for how long, was it an exclusive agreemtent etc.
Although those stock options would be a big deal to a small company like Apple, it would be chump-change for a major corporation like Xerox. There's no way they would turn over their rights to Apple for such a paltry sum. It would be a reasonable amount, however, for a company of Xerox's size to bother with a tour to "inspire" Apple engineers without actually giving up any IP.
If Xerox had actually sold their rights to Apple, Apple would have immediately presented the document to the court to prove Xerox's case had no merit and the case would have been summarily dismissed on those grounds (the case was dismissed because too much time had elapsed).
Likewise, if Apple had actually purchased the rights to Xerox's work, they would have introduced this as evidence in the case agains MS, but they didn't.
So really there's no rational basis for the claim that Xerox sold their IP to Apple.
I'm not sure. Clearly the second statement turned out to be true provided that you don't follow the definition of "sexual relations" favored by a 13 year-old future republican kid who brags that he's not a virgin because he felt a girl up.
Yes, and it was an IBM design decision anyway and had nothing to do with MS.
Sorry to burst your bubble, but Apple didn't pay Xerox for their technology although there is some lore that they paid for a tour. Given that Xerox later sued Apple and and Apple never produced a document indicating that they had purchased any rights, it's very likely that the story about Apple buying the rights to Xerox's ideas is probably just that - a story and nothing more.
The more important point is that Gates couldn't have significantly increased the number beyond 640K even if he wanted to do to the limitations of the processor and the need for address space to be reserved for other purposes. So anyone who mentions the "quote" to imply that Gates was an idiot for choosing the 640K limit is either ignorant or is deliberately attempting to mislead.
This limit is really more the responsiblity of Intel's for designing the world's ugliest processor architecture (now and forever) and IBM for choosing it.
Usually that phrase would apply to a company that once had a major percentage of a market and holds it no longer. The Mac never had a big piece of the market and I'll bet that the Apple II had a much larger market share than the Mac has ever enjoyed.
What legendary rock-n-roll song was used at the gala release celebration for OS/2? Oh, that's right, there was no celebration. OS/2's number one reason for failing was that IBM didn't make much of an effort to make it a success.
I think it's instructive to remember that there are far more minimally successful or unsuccessful Apple products than there are very successful Apple products. Actually, the iPod is the only one that is a market leader.
So the odds that this product will be a big winner are not that high if Apple's overall performance is considered.
"How often can you still "beat the compiler"."
Probably not very often on today's general purpose processors, but of course the hardware is "rigged" in favor of compilers. The price that is paid is that these processors aren't suitable for hard real-time programming because their timing isn't deterministic. If you use a PC for a hard real-time system (no matter what OS you use, if any) you have to push the hard RT stuff to hardware.
"Intel desktop and workstation microprocessors, or any superscalar microprocessors for that matter, are a great example. The programmer (or compiler) writes a single-threaded assembly language program for an extremely simple machine that is basically a fiction. The assembly programmer gets to think in terms of ISA abstractions like "the EAX register" when in the real microprocessor, with its superscalar pipelines, out-of-order execution, branch prediction, and so forth, there really isn't anything you could reasonably point to and say, "This is the EAX register." The microprocessor is a dizzyingly complex hardware simulation of the simple machine that software programmers use as their mental model of "the hardware.""
This sort of "fiction" is a fundamental requirement of these devices to be classified as microprocessors; otherwise you'd have to perform "programming" by doing digital logic design or microcoding. It's like saying that car manufactures accomodate drivers legacy expectations by providing wheels for the car.
In addition, a number of these added features don't really preserve legacy expectations anyway. Hard real-time software can't really be written for most modern processors because the execution time of a particular section of code is not deterministic.
"P.S. I admit I don't know anything about Intel's introduction of segmentation, but reading what Wikipedia says, it seems like the key selling point of segmentation was the ease of porting old software."
Given the fact that the 8086/8088 couldn't natively run 8085 programs, I don't think backward compatibility was a major goal. If you have to translate instructions anyway, changing from an 8 bit address to 16 bit address isn't that much harder.
I used to wish that there were more hardware resources available to get the job done in a reasonable time-frame. Now that I got my wish and hardware is so cheap and capable, my hard-won assembly language skills are mostly obsolete.
"Jumping directly into the center of a loop"
Not to mention jumping directly into the middle of an instruction. Oops. Did I say that out loud?
"Considering that hardware designers have been leaning over backwards for years to help software programmers stick with one fairly easy programming model, I wouldn't be too quick to blame the hardware industry. They know which side their bread is buttered on. The hardware company that requires the least adaptation from software developers has the advantage, just like the software company that requires the least change and adaptation from users always has the advantage."
I didn't see the "leaning over backwards" you refer to. What hardware improvements have hardware designers avoided because it would have caused the current programming model to change? You don't have to look any further than the x86 architecture with its segmented memory to conclude that ease of programming has never been a key goal at Intel.
"I've never had a choice; my first professional job was at a Java shop that used multithreaded servers, and at my current gig one of my ongoing tasks is to add multithreading to single-threaded C++ apps so that our customers get as much power as possible out of their multi-CPU workstations."
One advantage of server apps is that they inherently lend themselves to a mutithreading approach since each request can be seen as a seperate unit of work. As you probably know, the challenge comes when no such natural break-down is apparent.
"linux kernel with a bash shell"
Yes, linux is very secure, but too bad it doesn't have a GUI or any drivers except for the console. You can't have a different definition of what linux is when you're talking about functionality than you do when you talk about vulnerabilities.
"When technology hits a dead end on one track, the industry goes looking for another track where progress can be made."
There are two different industries involved here: the hardware processor industry and the software industry. It looks like the former is looking for the latter to bail it out. Multicore isn't really a new track, it's more of a repackaging effort.
"I'm going to pursue the low-hanging fruit elsewhere."
I think all the discussion over this issue suggests that it isn't low-hanging fruit.
"When they do knock it down, I'll be right behind you, and what will I have lost?"
As always, it depends. If you and your co-workers don't make any additional mistakes due to the added complexity, probably nothing bad will happen. Obviously if multicore doesn't actually add a lot of multithreading to your project because you're already using it extensively, it won't have any effect at all.
I see multicore as a plan B strategy because chip makers can't provide the super high speed processors the market really wants. If new technologies that let us break through the current speed barrier become practical, the interest in multicore and the associated "everything needs to be multithreaded" philosophy will fade away.
"Gigahertz are out and cores are in. Programmers must begin to develop applications that take full advantage of the increasing number of cores present in modern computers."
The marketplace wants and needs new technologies for more powerful processors. Multicore serves the needs of chip makers, not their customers. Making all software multi-threaded is trying to solve the wrong problem. It's going to result in lower-quality software without a significant increase in performance.
Why should we believe that the work ethic of early employees would be better than those who come later? I've worked both at startups and large established companies and I haven't seen any significant difference in the dedication of workers.
I have no problem with WINE being described as a project that allows some Windows applications to run under Linux. The problem is that it is often promoted as a general solution to running Windows applications on Linux, which it is not.
"100% pure Java" was a logo program that Sun created that was supposed to certify that a qualifying application "conforms to the Java ideal of universal portability". I assume that the word "ideal" was used because Sun realized that Java apps couldn't actually achieve universal portability. Like many others, I suspected that its main purpose was to discredit MS's JVM and Java apps that were based on it.
Aren't a lot of coding conventions really just "neatness" applied to the programming domain?