I guess I don't see how it benefits Microsoft to have a large userbase tied onto IE6 and Windows XP, and therefore not buying new versions of Windows/Office/etc.
If IE8 did have an "IE6 compatiblity mode", these folks would still be locked-into MS. Instead they are (slowly) recoding everything to be independent of MS technology.
No, I'm saying you could buy a $600 Nexus One, and sell your iPhone 3GS for $300, and the "stupid tax" is only about a hundred bucks over a subsidized phone.
Nexus One is promoted via banner ads on slashdot versus television and print ads for other major phones. Its obviously being marketed to developers (who can often write it off as a business expense).
Those millions of dollars *will* have to be spent.
Not really. Large banks are still running 1993-era OS/2 applications in virutalization. In some cases the money will be spent, but a certain amount of this stuff will probably live forever under Windows 7's "XP mode". They won't be upgraded until there is some large technological shift away from the browser paradigm.
Microsoft decided to and all sorts of stuff to IE and to ignore web standards
As someone who worked on many "IE only" applications* back in the browser war days, actual proprietary IE features were never used as widely as Slashdot assumes they were. (And many of these features are still supported in IE8.)
The most common issues seem to be cosmetic issues arising from buggy markup, minor javascript issues, and IE6's half-assed support for CSS2. Meaning, a good portion of these "IE6 only" sites could be compatible with modern browsers with just a little elbow grease. (However if you're talking about part of a multi-million enterprise app, that's easier said than done.)
* recall that Netscape had a completely proprietary DOM and even worse HTML/CSS support than IE. So it wasn't really a question of coding to "standards" but avoiding the extensive dev/qa time required to support Netscape.
The core issue is that there is no IE6 compatibility mode. There are modes for IE5 and IE7, but not the version that everyone used.
(It would probably be impossible to create a true "bug-compatible" mode for IE6, considering the vast number of bugs. But MS really screwed people here by giving them no upgrade path other than recoding everything.)
Google purchased Android in 2005. You will notice this report is public information, unlike any iPhones plans at the time, which may not have even been known to the board.
Indeed, the page you linked to mentions MSRS, which was one of the Java applet approaches to AJAX which existed in the "version 4" browser time frame. (XMLHttpRequest only came about after MS pulled MSRS due to the Sun lawsuit over Java.)
As for the lack of understanding of AJAX-like techniques, some theories:
- Netscape 4 and early versions of Mozilla were not stable with heavily dynamic pages, so devs tended to avoid them - Developers did not understand Javascript and DOM in general - real programmers thought it was a toy language, and web designers just copy-pasted menu scripts - Because the techniques were generally used on vertical audience "IE only" sites, only MS-centric devs pouring over the corners of MSDN really knew about them. - Developers need snazzy marketing slogans like "AJAX" before they get interested in something.
Seriously, just because the stereotype of usenet is "dark alley hackerspace" anyoen who has ever even semi-used it knows thats not true.
Usenet providers have marketing themselves as semi-illicit file sharing services for some time, so I can see why people think that way. ("Download ANY file!" was one slogan).
Meanwhile the text groups have no marketing or promotion outside of Google Groups (which is even buried on google.com), which means most people under the age of 40 or so have only heard about it as a source for filez.
Truth - and I think there's a real generational difference here. Twenty years ago, the internet was a rough and tumble place where flame wars were the norm. If you wanted to win an argument, you were expected to play rough, and the Linux/BSD development culture reflected that.
The facebook generation does not like to be confrontational online. If they can't block someone with a touch of the button, they'll simply check out of the conversation.
And the biggest problem is that very few people grow up with a C64 or an Amiga nowadays.
As someone who grew up with Ataris and Apples, I actually think that is a good thing to some degree. For every 1 coding genius that came out of the 8-bit home computer scenes, you also had 10 other self-taught Visual Basic hackers making a mess of everything.
Generally speaking, kids coming out of school nowdays are much more professional and exacting in their approach than young programmers were in my day, probably because they didn't learn programming until they were taught "the right way to do it".
On the flip side of that argument, someone stands to make a lot of money by entering the market and challenging Visa with the selling point of increased security. Are there barriers to entry in that market? Sure.
Except, the potential customers for such a system (banks) are actually the owners of Visa.
Ventura Publisher was the big DOS DTP app and it used GEM as a runtime, as with some other DOS programs. (thankfully I blocked that out and had to refresh my memory on wikipedia.) Keep in mind it took businesses several years to adopt Windows in any real sense.
Insert joke about Amiga being Spanish for 'girlfriend'.
I know where he's coming from. The first time I met some Amigans, they locked me into a room and gave me the hard sell, scientology-style. Throughout the 1990s, they were completely obnoxious online participants, especially when yet another owner of Amiga technology was going bankrupt.
On topic, OS/2 had some real nuts advocating it as well.
Moreover, Apple isn't obligated to do any work to make Adobe's life easier.
I would agree to that, but the point of contention is that Adobe was somehow making Apple's life difficult by targeting Apple's published APIs (which were under active development and promoted personally by Steve Jobs).
If Apple actually had its own strategy straight, none of these 'screwjobs' would have happened - it is entirely the result of their tendency towards secretive out-of-the-blue decisions.
Rather than Adobe dragging their feet, Apple fucked them over when they released developer docs for Carbon 64 and then later cancelled the entire API without any explanation. The Mac Zealot idea that there was some sort of roadmap or plan to transition everyone to Cocoa is simply factually incorrect. Apple just spontaneously did it and without warning their major development shops (even internally).
And I don't see how developers wasting their time with platform churn rather than adding new features and improving the product helps anyone. The platform-purity argument is bunk - the programs really aren't any better for using Cocoa as far as anyone can tell.
Whether or not Apple has a monopoly is particular sub-market is pretty much irrelevant, because anti-trust laws are never enforced until years after the fact. That is, by the time one could legally prove them to be a monopoly, its too late.
Not to break your bubble, but I don't see Microsoft ever really pushing a 'repository' distribution model, or mainstream Windows developers buying into the concept. This approach works for Linux (sorta) because the software is non-commercial, but wouldn't fly in the capitalist anarchy of the Windows ecosystem.
However, for system administrators and developers looking to install commodity software library XYZ, such a tool will be a godsend. I have been complaining for a long time that MS never really understood the 'lego block'-like approach to building up *nix systems, and the appeal that has to the hands-on users. I could even see commercial dev tool vendors jumping on board - there's a gazillion 'components' out there for MS developers, but installation and updating them all is a pain in the ass.
Glad to hear that someone is finally addressing this - it will make my life easier for sure.
Just as a point of fact, DEC did not at all blow-off the x86 market even while they were flailing away on Alpha. They were the #3 commodity server vendor when Compaq (#1) bought them, ahead of both IBM and HP. (Personally speaking, Digital had some serious credibility with us PC guys.)
Furthermore, Compaq cited Digital's services group's expertise with Wintel as one the main reasons they bought the company. I would say of all the old minicomputer companies, Digital did the best job of adapting as anyone. Shame they were absorbed into a brand that was best known for cheap-ass Best Buy PCs. (But still #1 in the server market.)
I think the OP's point was that porting is one thing, maintaining quite is another. There is a laundry list of obscure architectures that old versions of Linux were ported to, but good luck booting a modern kernel on them.
The overall approach sense to me. If you want to verify that no i386isms have slipped into your code, make another architecture part of the build scripts so you have confirmed failures.
Keep in mind that "scientific computing" is entirely marketing work from the manufacturer perspective. If you'll excuse a car analogy, it's like the old automotive maxim of "Win on Sunday, sell on Monday".
Realistically, a fourth-place midrange company (DEC) with a fourth-place architecture (Alpha) was going to get totally murdered by the x86 onslaught. Years of being on top of benchmarks and 64-bit never pushed Alpha past 4th place in the RISC market, and there's zero reasons to think another revision would be any different.
Alpha fans should instead be somewhat releaved they preserved some dignity by waving the white flag first. Like it or not Compaq/DEC is not IBM and could not live another day to fight another RISC fight.
Given how x86 has utterly destroyed the low-end RISC market, I'm going with the MBAs on this one. Had Compaq's engineers had their way, apparently they would have spent billions of dollars to be the last-place player in a dead-end market. No matter how great Alpha was, the marketing problems were probably insurmountable.
The Alpha was supposed to run Unix - Tru64 Unix in particular. Running in a proper 64bit environment the Alpha was an incredible chip.
This is a pretty gross oversimplification. First of all, Microsoft spent a lot of money writing a portable OS partially because the conventional wisdom at the time was that RISC would bury x86. (Keep in mind they could have just kept using OS/2.) Digital also badly needed volume for their chip production and make a somewhat serious attempt at the Windows workstation/server market. That Alpha was pigeonholed as a Unix chip is one of the main reasons it failed.
Slashdot Mirror
I guess I don't see how it benefits Microsoft to have a large userbase tied onto IE6 and Windows XP, and therefore not buying new versions of Windows/Office/etc.
If IE8 did have an "IE6 compatiblity mode", these folks would still be locked-into MS. Instead they are (slowly) recoding everything to be independent of MS technology.
No, I'm saying you could buy a $600 Nexus One, and sell your iPhone 3GS for $300, and the "stupid tax" is only about a hundred bucks over a subsidized phone.
Nexus One is promoted via banner ads on slashdot versus television and print ads for other major phones. Its obviously being marketed to developers (who can often write it off as a business expense).
Those millions of dollars *will* have to be spent.
Not really. Large banks are still running 1993-era OS/2 applications in virutalization. In some cases the money will be spent, but a certain amount of this stuff will probably live forever under Windows 7's "XP mode". They won't be upgraded until there is some large technological shift away from the browser paradigm.
Microsoft decided to and all sorts of stuff to IE and to ignore web standards
As someone who worked on many "IE only" applications* back in the browser war days, actual proprietary IE features were never used as widely as Slashdot assumes they were. (And many of these features are still supported in IE8.)
The most common issues seem to be cosmetic issues arising from buggy markup, minor javascript issues, and IE6's half-assed support for CSS2. Meaning, a good portion of these "IE6 only" sites could be compatible with modern browsers with just a little elbow grease. (However if you're talking about part of a multi-million enterprise app, that's easier said than done.)
* recall that Netscape had a completely proprietary DOM and even worse HTML/CSS support than IE. So it wasn't really a question of coding to "standards" but avoiding the extensive dev/qa time required to support Netscape.
The core issue is that there is no IE6 compatibility mode. There are modes for IE5 and IE7, but not the version that everyone used.
(It would probably be impossible to create a true "bug-compatible" mode for IE6, considering the vast number of bugs. But MS really screwed people here by giving them no upgrade path other than recoding everything.)
I imagine the target market for the AT&T Nexus One are gadgetophiles or developers who are already locked into a 2 year iPhone contract.
Also, considering the resale value of an iPhone, it might not be so stupid if you really wanted to switch.
Google purchased Android in 2005. You will notice this report is public information, unlike any iPhones plans at the time, which may not have even been known to the board.
Indeed, the page you linked to mentions MSRS, which was one of the Java applet approaches to AJAX which existed in the "version 4" browser time frame. (XMLHttpRequest only came about after MS pulled MSRS due to the Sun lawsuit over Java.)
As for the lack of understanding of AJAX-like techniques, some theories:
- Netscape 4 and early versions of Mozilla were not stable with heavily dynamic pages, so devs tended to avoid them
- Developers did not understand Javascript and DOM in general - real programmers thought it was a toy language, and web designers just copy-pasted menu scripts
- Because the techniques were generally used on vertical audience "IE only" sites, only MS-centric devs pouring over the corners of MSDN really knew about them.
- Developers need snazzy marketing slogans like "AJAX" before they get interested in something.
Seriously, just because the stereotype of usenet is "dark alley hackerspace" anyoen who has ever even semi-used it knows thats not true.
Usenet providers have marketing themselves as semi-illicit file sharing services for some time, so I can see why people think that way. ("Download ANY file!" was one slogan).
Meanwhile the text groups have no marketing or promotion outside of Google Groups (which is even buried on google.com), which means most people under the age of 40 or so have only heard about it as a source for filez.
Truth - and I think there's a real generational difference here. Twenty years ago, the internet was a rough and tumble place where flame wars were the norm. If you wanted to win an argument, you were expected to play rough, and the Linux/BSD development culture reflected that.
The facebook generation does not like to be confrontational online. If they can't block someone with a touch of the button, they'll simply check out of the conversation.
And the biggest problem is that very few people grow up with a C64 or an Amiga nowadays.
As someone who grew up with Ataris and Apples, I actually think that is a good thing to some degree. For every 1 coding genius that came out of the 8-bit home computer scenes, you also had 10 other self-taught Visual Basic hackers making a mess of everything.
Generally speaking, kids coming out of school nowdays are much more professional and exacting in their approach than young programmers were in my day, probably because they didn't learn programming until they were taught "the right way to do it".
On the flip side of that argument, someone stands to make a lot of money by entering the market and challenging Visa with the selling point of increased security. Are there barriers to entry in that market? Sure.
Except, the potential customers for such a system (banks) are actually the owners of Visa.
Ventura Publisher was the big DOS DTP app and it used GEM as a runtime, as with some other DOS programs. (thankfully I blocked that out and had to refresh my memory on wikipedia.) Keep in mind it took businesses several years to adopt Windows in any real sense.
Insert joke about Amiga being Spanish for 'girlfriend'.
I know where he's coming from. The first time I met some Amigans, they locked me into a room and gave me the hard sell, scientology-style. Throughout the 1990s, they were completely obnoxious online participants, especially when yet another owner of Amiga technology was going bankrupt.
On topic, OS/2 had some real nuts advocating it as well.
Minix was a classroom OS, not a "viable desktop".
You could also add GEM to your list, as it was mildly popular as a desktop publishing platform in the early 90s.
Just to set the record straight, MonoTouch .NET iPhone dev environment uses 100% native Cocoa widgets. It isn't a cross-platform toolkit.
Moreover, Apple isn't obligated to do any work to make Adobe's life easier.
I would agree to that, but the point of contention is that Adobe was somehow making Apple's life difficult by targeting Apple's published APIs (which were under active development and promoted personally by Steve Jobs).
If Apple actually had its own strategy straight, none of these 'screwjobs' would have happened - it is entirely the result of their tendency towards secretive out-of-the-blue decisions.
Rather than Adobe dragging their feet, Apple fucked them over when they released developer docs for Carbon 64 and then later cancelled the entire API without any explanation. The Mac Zealot idea that there was some sort of roadmap or plan to transition everyone to Cocoa is simply factually incorrect. Apple just spontaneously did it and without warning their major development shops (even internally).
And I don't see how developers wasting their time with platform churn rather than adding new features and improving the product helps anyone. The platform-purity argument is bunk - the programs really aren't any better for using Cocoa as far as anyone can tell.
Whether or not Apple has a monopoly is particular sub-market is pretty much irrelevant, because anti-trust laws are never enforced until years after the fact. That is, by the time one could legally prove them to be a monopoly, its too late.
Not to break your bubble, but I don't see Microsoft ever really pushing a 'repository' distribution model, or mainstream Windows developers buying into the concept. This approach works for Linux (sorta) because the software is non-commercial, but wouldn't fly in the capitalist anarchy of the Windows ecosystem.
However, for system administrators and developers looking to install commodity software library XYZ, such a tool will be a godsend. I have been complaining for a long time that MS never really understood the 'lego block'-like approach to building up *nix systems, and the appeal that has to the hands-on users. I could even see commercial dev tool vendors jumping on board - there's a gazillion 'components' out there for MS developers, but installation and updating them all is a pain in the ass.
Glad to hear that someone is finally addressing this - it will make my life easier for sure.
Just as a point of fact, DEC did not at all blow-off the x86 market even while they were flailing away on Alpha. They were the #3 commodity server vendor when Compaq (#1) bought them, ahead of both IBM and HP. (Personally speaking, Digital had some serious credibility with us PC guys.)
Furthermore, Compaq cited Digital's services group's expertise with Wintel as one the main reasons they bought the company. I would say of all the old minicomputer companies, Digital did the best job of adapting as anyone. Shame they were absorbed into a brand that was best known for cheap-ass Best Buy PCs. (But still #1 in the server market.)
I think the OP's point was that porting is one thing, maintaining quite is another. There is a laundry list of obscure architectures that old versions of Linux were ported to, but good luck booting a modern kernel on them.
The overall approach sense to me. If you want to verify that no i386isms have slipped into your code, make another architecture part of the build scripts so you have confirmed failures.
Keep in mind that "scientific computing" is entirely marketing work from the manufacturer perspective. If you'll excuse a car analogy, it's like the old automotive maxim of "Win on Sunday, sell on Monday".
Realistically, a fourth-place midrange company (DEC) with a fourth-place architecture (Alpha) was going to get totally murdered by the x86 onslaught. Years of being on top of benchmarks and 64-bit never pushed Alpha past 4th place in the RISC market, and there's zero reasons to think another revision would be any different.
Alpha fans should instead be somewhat releaved they preserved some dignity by waving the white flag first. Like it or not Compaq/DEC is not IBM and could not live another day to fight another RISC fight.
Given how x86 has utterly destroyed the low-end RISC market, I'm going with the MBAs on this one. Had Compaq's engineers had their way, apparently they would have spent billions of dollars to be the last-place player in a dead-end market. No matter how great Alpha was, the marketing problems were probably insurmountable.
The Alpha was supposed to run Unix - Tru64 Unix in particular. Running in a proper 64bit environment the Alpha was an incredible chip.
This is a pretty gross oversimplification. First of all, Microsoft spent a lot of money writing a portable OS partially because the conventional wisdom at the time was that RISC would bury x86. (Keep in mind they could have just kept using OS/2.) Digital also badly needed volume for their chip production and make a somewhat serious attempt at the Windows workstation/server market. That Alpha was pigeonholed as a Unix chip is one of the main reasons it failed.