You mean, having a 16-bit cpu support a FULL MEGABYTE instead of the usual 64Kb of Ram? In 1979? Pure evil.
In 1979, in a rather crufty way... As opposed to the 68000 which was also released in 1979, that supports 16 FULL MEGABYTES of ram, and doing so using 32 bit addressing such that even tho only 24 address lines are connected, unless you do something crufty like use the upper 8 bits for storing data (as some software did) your code for the 68000 should run just fine on the 68020 which could support up to 4GB of ram.
M68k was indeed cleaner, but Motorola chose cleanliness and dropped 68k in order to create PPC, while Intel went for backwards compatibility... The end result was that while the m68k was a very widely used processor, most of the vendors who had been using them switched to something else rather than PPC, which starved PPC of customers and ultimately of development.
Had Motorola continued with 68k it might have been a different story, an extended 68k while still crufty would probably still have been better than an extended x86.
Incidentally, Intel were not alone in selling a separate FPU... Motorola made the 68881 and 68882 FPUs for the 68k range, and it was not until the 68040 that they integrated the FPU. The 68040 FPU was also cut down relative to the 68882, as it removed some of the instructions and required software emulation in order to support software written for the 68882.
Multi core CPUs were first introduced by AMD, Intel came later and their first dual cores were quite a half assed effort being basically two complete processors on a single package.
Prior to that, there were machines with multiple processors, but they were targeted at servers and highend workstations, lowend windows 9x based workstations obviously couldnt take advantage of multiple cpus (not that it stopped stupid people from buying them anyway and running win9x on them).
The x86 emulator Alpha had did work well, but it also significantly reduced performance.. The idea that the ppro offered 90% of the performance of the alpha was based on running emulated code, where the ppro was considerably less than 90% of the price of the alpha.
Running native alpha code, the alpha was still miles ahead of the ppro especially for floating point code, but obviously this advantage was wasted if you were running emulated x86 code... If you were running one of the few native nt/alpha applications, or were running a unix platform on which you had compiled native binaries of everything then there were still huge performance advantages over the ppro.
Incidentally, running Alpha/NT had upsides too, it always seemed to be a LOT more stable than the x86 version, and booted much faster.
If you read the article, Bell keeps on going back to the manufacturing process as Intel's main advantage. He says things like, "our competitors are going to have trouble making it to the 9nm scale." That's where their advantage is, and he knows it.
So basically he has a more efficient engine, but rather than give customers a more efficient car he adds lots of unnecessary weight that provides no benefit to users, so that the overall package isn't any better than what everyone else is offering.
If he put that more efficient engine, in a car as lightweight as everyone else's then customers would benefit from a superior product.
What killed them was the binary-only nature of most windows software... At a time, MIPS, PPC and Alpha were all considerably faster than x86, but except for a few specialist applications none of the existing windows software ran on them, making the hardware utterly useless.
There is no incentive for a software developer, especially a commercial one to port to a platform with very few users, and there is no incentive for an end user to buy a platform for which there is no software.
I don't remember seeing NT for PPC or MIPS being used anywhere, and I only ever saw Alpha or IA64 versions being used for 3d renderfarms and sql databases...
PPC, MIPS and Alpha all saw somewhat more success as Linux servers (IBM still sell POWER based boxes with Linux and there are still embedded MIPS boxes around), because with the vast majority of applications coming with sourcecode you are not beholden to the original author to port them.
None of this considers the fact that Intel has the best fab technology in the world. This means their processors will be a generation more efficient than everyone else's, which is probably more than enough to counter any "x86 tax" which the instruction set incurs.
So build up an advantage on manufacturing process, but instead of producing cpus as efficient as anyone else's but also on a more efficient process, pushing the cutting edge forwards and giving customers the absolute best product they can... They throw away the advantage to consumers by hobbling themselves with an inferior instruction set, so customers miss out on the advantages that the smaller process should bring.
MS might have more money to throw at marketing, but Nokia already had a lot of contacts among the mobile operators, and most people buy their phones through the operators... Ofcourse, this only works to a point - you still have to have phones people want to buy.
Old firefox/chrome are quite standards compliant, so unless you are using new features everything will look the same anyway... If you are using those new features, then HTML is designed to degrade gracefully and so should still work but just look less pretty. This is why many sites work in text browsers like lynx or links.. Also, the vast majority of firefox or chrome users tend to upgrade to current versions.
IE on the other hand has broken implementations, which will result in very non graceful errors, totally broken/unusable functionality or major rendering errors.
As such, making the site work in IE is considerably more work than allowing it to degrade gracefully in a standards compliant browser.
When it comes to old browsers which require explicit work to support, IE is about the only one that is still being used anywhere... The others, eg netscape are so rare as to get lost in the noise... They're not going to expend any effort to support browsers which are used by 0.00001% of users.
IE is about the only browser which is both non standard enough to require extra work to support, and widely used enough that doing that extra work is economically viable...
They chose to code their site to standards, and that then covered any properly written browser... They had to do a lot of extra work to support IE7, and i imagine any other non standard browser that didn't have such a user base would simply not work at all. It's only fair that users who are more expensive to support, have to pay more to cover the extra support they require.
The alternatives are either:
Everyone else subsidises the extra development work required to support nonstandard browsers... They simply don't support non standard browsers at all, which will make the (usually fairly technically ignorant) users of those browsers just think the site is broken.
And where is this logged? Most such logging seems to be done at the application level, which works fine when the normal users access data in the normal way.
What happens when an admin (or a hacker) accesses the database directly? What if they go in at the filesystem level? What if they take the data from the backups?
If your logging, who controls the logging? Do the logs reside on the same box, or on a box with shared authentication?
Ultimately there will be someone in such a position that they can either bypass the logs, or modify the logs, who you will have to trust... Most places seem naive to this and assume just because they access the data through the normal route, that there isn't any alternative way to get it.
It's fairly common for people to be fired, and then a month or two taken back on at a higher rate (or as a high rate contractor) because the company realised they did actually need them after all.
Not just risk, if you got rid of an employee because they did something bad, it can actually in your interest for them to start working for a competitor... If they screwed you, chances are they will screw them at some point too.
If you develop code on your own time, you need to make it clear up front that it's your code, and under what terms you are willing to let the company use it...
If you setup monitoring, who controls it? If you setup logging, who admins the systems and has sufficient access to bypass the logging? What about people with physical access?
A lot of these logging schemes are very naive, for instance a web application that logs all the data you access "through the web interface", but it does nothing for someone who gets access to the data at the database or filesystem level, and the same people who have access to the db/fs level also have access to the logs anyway so could easily modify them.
Also 99% of company networks are based on the classic design, extremely insecure internally with a firewall to hide the insecure mess from the internet... If you're inside, even if you have no network privileges whatsoever you can usually gain access to anything you want in a few minutes given appropriate knowledge. I have done countless pentests where all you get given is an ethernet port, and within an hour we have access to everything (start with domain admin which is easy to get, and anything thats not connected to the windows domain you just keylog the admin workstations which usually are on the domain)... I have yet to pentest a company where it wasn't possible to do this in short order.
There is a downside, in that you will never have the cutting edge equipment... You will always be behind the curve. How much this matters of course is down to personal taste, and is less important for mature technology when even a couple of years old is still fully usable.
Weren't most of the chips socketted on the C64? At least they were on the earlier models of Amiga... You could pull out and replace most of the chips, making the systems quite easily user serviceable.
The other macbook pro models might be a better fit, however:
Power users who want the ability to change ram/disks etc, are also likely to want the higher resolution display. I liked the larger screen of the 17" version, its never going to be hugely portable but is still a good machine to use around the house.
As a user of the previous model of 17" macbook pro, what i wanted to see this time was the same 17", but with the high dpi display and a current model processor/gpu... However the way Apple are going, i will have to consider a different brand for my next laptop. Similarly, at work we currently use macbooks but having an easily replaceable drive is essential for us so it looks like a change is on the cards there too.
Also consider Babylon 5 came out in 1993, so assuming the cgi was done a year before release of the show, they would probably have been using Amigas considerably faster than the original 68000, and it was also possible to cluster lightwave rendering over a number of systems.
When i bought my last laptop, it came with 4gb and buying 8gb cost at least $400 anywhere you looked... A year down the line 8gb was under $100 and i bought it, soldered ram would have made this impossible and i would either have had to stick to 4gb, or pay a huge premium to get 8gb up front.
Well, the desktop/laptop market disappearing is their biggest threat... Even if they are grossly incompetent, they have enough inertia in these markets that they can coast for a long time before they die... On the other hand, they are nothing in the tablet/phone markets right now, if the desktop/laptop market disappears then microsoft would be pretty screwed.
Selling into a market where the majority of customers are locked in it's hard to fail regardless of how incompetent you are... Xbox lost money for a long long time before it started making any, and has been the least reliable console of its generation. As for still selling 7 years later, age doesn't matter with consoles, its the fact that none of the competitors has come out with a next generation unit yet.
Aside from the fact that AMD/Intel haven't had competitive mobile cpus, x86 has more legacy cruft to carry around than ARM so all else (eg manufacturing process) being equal, ARM will always have an advantage.
Windows also expects not just an x86 cpu, but an ibm compatible system... The really low power x86 designs are different enough that they are not compatible at the kernel level, linux has been modified to run on them but i don't believe windows has and it may cause problems for drivers etc too...
Windows has been available for touch devices for a long time, but compared to the ipad those devices are big, expensive, have poor battery life and the vast majority of apps people would want to run on a windows device are not suited to a touch ui.
Selling an incompatible device under the windows brand will dilute the brand, users will buy it expecting it to be compatible with x86 windows applications, and be annoyed to find that it's not... Aside from that, it will also dilute the brand and force people obtaining software to find out which version of windows it's for. No doubt MS are hoping to trick users into buying it this way, knowing that their existing lock-in will ensure that very few x86 windows users jump ship over the annoyance.
Making the OS expensive on ARM isn't going to force OEMs to ship premium devices... There's no point having a premium device with no apps... When you're coming from behind, you have to do with android and hp did, sell em cheap... If cheap enough, people will buy them even if they are inferior, and this will create a market for people to write apps towards.
Making the software expensive could also cause OEMs to cut down on the hardware in order to meet price targets, which given that windows will almost certainly be heavier weight than ios or android this will result in really terrible tablets which are still more expensive as well as slower than the cheapest and nastiest android devices.
Slashdot Mirror
You mean, having a 16-bit cpu support a FULL MEGABYTE instead of the usual 64Kb of Ram? In 1979? Pure evil.
In 1979, in a rather crufty way... As opposed to the 68000 which was also released in 1979, that supports 16 FULL MEGABYTES of ram, and doing so using 32 bit addressing such that even tho only 24 address lines are connected, unless you do something crufty like use the upper 8 bits for storing data (as some software did) your code for the 68000 should run just fine on the 68020 which could support up to 4GB of ram.
M68k was indeed cleaner, but Motorola chose cleanliness and dropped 68k in order to create PPC, while Intel went for backwards compatibility...
The end result was that while the m68k was a very widely used processor, most of the vendors who had been using them switched to something else rather than PPC, which starved PPC of customers and ultimately of development.
Had Motorola continued with 68k it might have been a different story, an extended 68k while still crufty would probably still have been better than an extended x86.
Incidentally, Intel were not alone in selling a separate FPU... Motorola made the 68881 and 68882 FPUs for the 68k range, and it was not until the 68040 that they integrated the FPU. The 68040 FPU was also cut down relative to the 68882, as it removed some of the instructions and required software emulation in order to support software written for the 68882.
Multi core CPUs were first introduced by AMD, Intel came later and their first dual cores were quite a half assed effort being basically two complete processors on a single package.
Prior to that, there were machines with multiple processors, but they were targeted at servers and highend workstations, lowend windows 9x based workstations obviously couldnt take advantage of multiple cpus (not that it stopped stupid people from buying them anyway and running win9x on them).
The x86 emulator Alpha had did work well, but it also significantly reduced performance.. The idea that the ppro offered 90% of the performance of the alpha was based on running emulated code, where the ppro was considerably less than 90% of the price of the alpha.
Running native alpha code, the alpha was still miles ahead of the ppro especially for floating point code, but obviously this advantage was wasted if you were running emulated x86 code... If you were running one of the few native nt/alpha applications, or were running a unix platform on which you had compiled native binaries of everything then there were still huge performance advantages over the ppro.
Incidentally, running Alpha/NT had upsides too, it always seemed to be a LOT more stable than the x86 version, and booted much faster.
If you read the article, Bell keeps on going back to the manufacturing process as Intel's main advantage. He says things like, "our competitors are going to have trouble making it to the 9nm scale." That's where their advantage is, and he knows it.
So basically he has a more efficient engine, but rather than give customers a more efficient car he adds lots of unnecessary weight that provides no benefit to users, so that the overall package isn't any better than what everyone else is offering.
If he put that more efficient engine, in a car as lightweight as everyone else's then customers would benefit from a superior product.
What killed them was the binary-only nature of most windows software...
At a time, MIPS, PPC and Alpha were all considerably faster than x86, but except for a few specialist applications none of the existing windows software ran on them, making the hardware utterly useless.
There is no incentive for a software developer, especially a commercial one to port to a platform with very few users, and there is no incentive for an end user to buy a platform for which there is no software.
I don't remember seeing NT for PPC or MIPS being used anywhere, and I only ever saw Alpha or IA64 versions being used for 3d renderfarms and sql databases...
PPC, MIPS and Alpha all saw somewhat more success as Linux servers (IBM still sell POWER based boxes with Linux and there are still embedded MIPS boxes around), because with the vast majority of applications coming with sourcecode you are not beholden to the original author to port them.
None of this considers the fact that Intel has the best fab technology in the world. This means their processors will be a generation more efficient than everyone else's, which is probably more than enough to counter any "x86 tax" which the instruction set incurs.
So build up an advantage on manufacturing process, but instead of producing cpus as efficient as anyone else's but also on a more efficient process, pushing the cutting edge forwards and giving customers the absolute best product they can... They throw away the advantage to consumers by hobbling themselves with an inferior instruction set, so customers miss out on the advantages that the smaller process should bring.
MS might have more money to throw at marketing, but Nokia already had a lot of contacts among the mobile operators, and most people buy their phones through the operators... Ofcourse, this only works to a point - you still have to have phones people want to buy.
There's a few important differences here...
Old firefox/chrome are quite standards compliant, so unless you are using new features everything will look the same anyway... If you are using those new features, then HTML is designed to degrade gracefully and so should still work but just look less pretty. This is why many sites work in text browsers like lynx or links..
Also, the vast majority of firefox or chrome users tend to upgrade to current versions.
IE on the other hand has broken implementations, which will result in very non graceful errors, totally broken/unusable functionality or major rendering errors.
As such, making the site work in IE is considerably more work than allowing it to degrade gracefully in a standards compliant browser.
When it comes to old browsers which require explicit work to support, IE is about the only one that is still being used anywhere... The others, eg netscape are so rare as to get lost in the noise... They're not going to expend any effort to support browsers which are used by 0.00001% of users.
IE is about the only browser which is both non standard enough to require extra work to support, and widely used enough that doing that extra work is economically viable...
Well it depends how they do it...
They chose to code their site to standards, and that then covered any properly written browser...
They had to do a lot of extra work to support IE7, and i imagine any other non standard browser that didn't have such a user base would simply not work at all. It's only fair that users who are more expensive to support, have to pay more to cover the extra support they require.
The alternatives are either:
Everyone else subsidises the extra development work required to support nonstandard browsers...
They simply don't support non standard browsers at all, which will make the (usually fairly technically ignorant) users of those browsers just think the site is broken.
So does firefox, and i imagine chrome uses something similar. Both of these work on XP, and OSX, and Linux...
And where is this logged?
Most such logging seems to be done at the application level, which works fine when the normal users access data in the normal way.
What happens when an admin (or a hacker) accesses the database directly?
What if they go in at the filesystem level?
What if they take the data from the backups?
If your logging, who controls the logging?
Do the logs reside on the same box, or on a box with shared authentication?
Ultimately there will be someone in such a position that they can either bypass the logs, or modify the logs, who you will have to trust... Most places seem naive to this and assume just because they access the data through the normal route, that there isn't any alternative way to get it.
It's fairly common for people to be fired, and then a month or two taken back on at a higher rate (or as a high rate contractor) because the company realised they did actually need them after all.
Not just risk, if you got rid of an employee because they did something bad, it can actually in your interest for them to start working for a competitor... If they screwed you, chances are they will screw them at some point too.
If you develop code on your own time, you need to make it clear up front that it's your code, and under what terms you are willing to let the company use it...
If you setup monitoring, who controls it?
If you setup logging, who admins the systems and has sufficient access to bypass the logging?
What about people with physical access?
A lot of these logging schemes are very naive, for instance a web application that logs all the data you access "through the web interface", but it does nothing for someone who gets access to the data at the database or filesystem level, and the same people who have access to the db/fs level also have access to the logs anyway so could easily modify them.
Also 99% of company networks are based on the classic design, extremely insecure internally with a firewall to hide the insecure mess from the internet... If you're inside, even if you have no network privileges whatsoever you can usually gain access to anything you want in a few minutes given appropriate knowledge. I have done countless pentests where all you get given is an ethernet port, and within an hour we have access to everything (start with domain admin which is easy to get, and anything thats not connected to the windows domain you just keylog the admin workstations which usually are on the domain)... I have yet to pentest a company where it wasn't possible to do this in short order.
There is a downside, in that you will never have the cutting edge equipment... You will always be behind the curve. How much this matters of course is down to personal taste, and is less important for mature technology when even a couple of years old is still fully usable.
Weren't most of the chips socketted on the C64? At least they were on the earlier models of Amiga... You could pull out and replace most of the chips, making the systems quite easily user serviceable.
The other macbook pro models might be a better fit, however:
Power users who want the ability to change ram/disks etc, are also likely to want the higher resolution display.
I liked the larger screen of the 17" version, its never going to be hugely portable but is still a good machine to use around the house.
As a user of the previous model of 17" macbook pro, what i wanted to see this time was the same 17", but with the high dpi display and a current model processor/gpu...
However the way Apple are going, i will have to consider a different brand for my next laptop. Similarly, at work we currently use macbooks but having an easily replaceable drive is essential for us so it looks like a change is on the cards there too.
Also consider Babylon 5 came out in 1993, so assuming the cgi was done a year before release of the show, they would probably have been using Amigas considerably faster than the original 68000, and it was also possible to cluster lightwave rendering over a number of systems.
When i bought my last laptop, it came with 4gb and buying 8gb cost at least $400 anywhere you looked... A year down the line 8gb was under $100 and i bought it, soldered ram would have made this impossible and i would either have had to stick to 4gb, or pay a huge premium to get 8gb up front.
Well, the desktop/laptop market disappearing is their biggest threat... Even if they are grossly incompetent, they have enough inertia in these markets that they can coast for a long time before they die...
On the other hand, they are nothing in the tablet/phone markets right now, if the desktop/laptop market disappears then microsoft would be pretty screwed.
Selling into a market where the majority of customers are locked in it's hard to fail regardless of how incompetent you are...
Xbox lost money for a long long time before it started making any, and has been the least reliable console of its generation. As for still selling 7 years later, age doesn't matter with consoles, its the fact that none of the competitors has come out with a next generation unit yet.
Well, the problems for MS are...
Aside from the fact that AMD/Intel haven't had competitive mobile cpus, x86 has more legacy cruft to carry around than ARM so all else (eg manufacturing process) being equal, ARM will always have an advantage.
Windows also expects not just an x86 cpu, but an ibm compatible system... The really low power x86 designs are different enough that they are not compatible at the kernel level, linux has been modified to run on them but i don't believe windows has and it may cause problems for drivers etc too...
Windows has been available for touch devices for a long time, but compared to the ipad those devices are big, expensive, have poor battery life and the vast majority of apps people would want to run on a windows device are not suited to a touch ui.
Selling an incompatible device under the windows brand will dilute the brand, users will buy it expecting it to be compatible with x86 windows applications, and be annoyed to find that it's not... Aside from that, it will also dilute the brand and force people obtaining software to find out which version of windows it's for. No doubt MS are hoping to trick users into buying it this way, knowing that their existing lock-in will ensure that very few x86 windows users jump ship over the annoyance.
Making the OS expensive on ARM isn't going to force OEMs to ship premium devices... There's no point having a premium device with no apps... When you're coming from behind, you have to do with android and hp did, sell em cheap... If cheap enough, people will buy them even if they are inferior, and this will create a market for people to write apps towards.
Making the software expensive could also cause OEMs to cut down on the hardware in order to meet price targets, which given that windows will almost certainly be heavier weight than ios or android this will result in really terrible tablets which are still more expensive as well as slower than the cheapest and nastiest android devices.