They dropped some instructions in the floating point unit and the MMU with the 68040 too...
The dropped instructions were emulated in software, and motorola even provided code to do the emulation (which became 680x0.library on the amiga)...
The reason Coldfire can't work that way is because it drops instructions used by the Amiga firmware, such that the firmware would crash before it could load the coldfire.library. Older versions of the Amiga 3000 firmware couldn't support a 68040 or 68060 CPU because they depended on functionality of the 68030's built in MMU that was no longer present in 68040 and above.
On the contrary, competitors can and do reverse engineer binaries, it just becomes more time consuming, but also harder to prove. If someone rips off the source your published and it shows up unchanged in their product its very easy to prove in court.
Having sourcecode would benefit users and the original vendor, and may actually hamper competitors because they have to be careful not to copy existing code.
Open source has often innovated, these days it is stuck copying because there is often no alternative - people are locked in to the existing applications and cloning them is the only way to achieve a user base. And you could argue that commercial software hasn't really innovated in the last few years either.
When you talk about open source copying commercial software, consider that... The first web browsers were open source, commercial browsers copied. Many of the other protocols we take for granted were developed as open source. Bittorrent started out as an open source program.
And much more...
Commercial software need not be closed source, BSDi was distributed with sourcecode, even MS make source available to some of their products, tho on rather inflexible terms...
You just distribute both, the way linux and bsd are currently distributed... If you have source available, then interested parties (vendors of new architectures, pro/power users etc).
Similar thing happened with PowerPC, it was going to be the next big thing... Apple came on board, Microsoft made a version of NT for it, Sun ported Solaris to it...
Motorola's m68k was the last big thing, so they assumed everyone would follow their migration path to PPC... Instead, most players dumped Motorola. They could have extended m68k like Intel has done with x86, the result would still have been messy but not as bad.
IA64 wasn't so much about clock rate, as theoretical instructions per clock... Rather than having multiple cores, the idea was a sort of SIMD throughout the processor... But relying on the compiler to generate optimal code... Assuming you have optimal code, an Itanium should be able to get a lot more work done in a single clock cycle than any x86 chip.
Very little code is written in x86 assembly, the vast majority is written in higher level languages and then compiled or interpreted... When you have the source code, porting it to IA64 is relatively easy. Look at Linux, it runs on a variety of architectures, as do a huge number of applications. Many of the original authors of those apps would never have considered they might be running on IA64, Alpha, Arm, Mips or Sparc someday...
The problem is software being delivered as binaries. Binary software distribution is holding back progress, making it necessary to continue supporting old kludgy architectures instead of making a clean break to something new and modern.
The first Itaniums were pretty much a dismal failure... They ran at around 800mhz, so clocked lower than x86 systems of the time which were around 1.4ghz if i remember (and the mhz myth still very much alive, with intel fuelling it using the p4)... Their x86 support was roughly the speed of a p90 and therefore of little use beyond running one or two small legacy apps. In terms of outright performance they were behind Alpha and Power at the time, so much for this new architecture. And when it came to price and power consumption they were behind everyone else.
When Itanium2 came around it performed a lot better, still guzzled power, and they realised that software emulation of x86 was faster than the hardware support, other than that the chips were still too expensive for what they were.
Now, Itanium is pretty much relegated to the high end niche that Alpha occupied before it was canned.
Itanium suffered from end users being locked in to proprietary binary only software - which only the original vendor could port... Some were unwilling, some didn't see the business case, some demanded that HP/Intel fund the porting, only they couldn't fund everything, so Itanium is left with a very limited set of apps... OSS support was better, but it suffered from the high cost and rarity of the hardware, in that hobbyists had little chance of getting hold of the hardware to play with.
Personally i think HP/Intel would have been better off putting the effort into continued development of Alpha... It already had a software and user base, it already had x86 emulation which performed reasonably well, and it had a legacy behind it of old hardware that was cheaply available to OSS developers. Even today, Alpha versions of Linux seem far more active than the IA64 versions... Plus any customers already using Alpha would not have needed to migrate (and many of them migrated to Sun or IBM).
I don't know about on a mass scale, but i know several people who would rather pirate a game than suffer from DRM... Some of them will also buy the game first, but never actually use the purchased version.
There are many reasons behind this, such as a desire not to infect their systems with drm rootkits and the problems they cause, wanting to play without hunting for the media especially when traveling etc, wanting to let kids play without damaging the media (two fold here, without drm they no longer need the original media and can now copy it to have a disposable backup)...
Well, a VM adapts your native hardware into a single form that software can utilize... Windows does exactly the same, the hardware may differ but the programming interface is largely the same. Both introduce performance losses relative to fully native code.
While cracking the crypto may not be possible, in order for a DRM scheme to function you have to give paying customers the keys... Those customers can just copy the keys and give them to people who haven't paid.
Sky TV have been using the same algorithms, but they keep changing the keys because the keys frequently leak.
Yes, and the quality is really really bad... I would rather burn my songs to CD than use one of those crufty adapters... Tho it may be possible to adapt the cd changed to a line in...
You can dump streaming radio to disk and sync it with your ipod when you get home, assuming your not away from an internet connection for longer than it takes to play a few gigs of audio...
Many site license agreements are actually "upgrade from whatever version of windows came preinstalled on the machine", so strictly speaking you have to buy a preinstalled machine...
There are plenty of benchmarks out there showing Gentoo outperforming similar distributions, tho obviously with a distro as customizable as gentoo it's easy to misconfigure it and get abysmal performance...
It's a combination of compiler - gcc generally produces slower code than MSVC...
And of compiler options - linux apps and common distributions are generally compiled for a 386, and therefore cannot take advantage of modern processor features like SSE. There were benchmarks posted fairly recently, showing ffmpeg performance between windows binaries (compiled for p4 i believe) and the linux binaries supplied with ubuntu... The windows version was considerably quicker. But if you compare a Gentoo system, linux comes out ahead.
For something like media encoding the difference will obviously be bigger, because modern processors have features specifically for accelerating such things, but if you add up the small performance hits taken in all the libraries and background processes a typical system will have running... For firefox, that will be X11, the kernel, libc, zlib, ssl, gtk, libjpeg and probably more... All those slight performance hits can soon add up.
And disturbingly, many distros are still compiled for i386, even those that won't actually run on such systems... Not sure about windows, but i imagine it's compiled for i686 at the least... OSX is compiled for core1 (x86 with sse3).
I think the desktop linux distros should target a p3 as a bare minimum, and leave anything below that to specialized cut down distributions. I doubt many people are running XP on lesser systems, and noone will be running Vista on a P3 let alone anything slower.
Also depends on your CPU... AMD cpus tend to perform considerably faster in 64bit mode while Intel are generally only slightly quicker... Also, gcc generates better code for AMD while Intel concentrate more on their own compiler.
What about compiling firefox using intel's compiler? That's available for linux, and should outperform msvc... What compiler do MS use for their windows mobile systems, and what did they use when nt used to run on alpha/ppc/mips?
It may also have something to do with firefox on windows being built with MSVC, which generally produces faster code than gcc... I believe windows firefox is also compiled for i686 or even pentium3, whereas on linux it's typically compiled for i386.
What would be interesting to see, is optimized builds of firefox compiled with various compilers and options, i'm pretty sure a gentoo box with firefox compiled by intel's compiler could comfortably beat the windows binaries...
Yes, the problem is people using insecure webapps, most of which are written in php... It's not even php which is the problem, rather the apps people are writing with it...
PHP is being used because it has the lowest cost of entry... Linux is being used because the cheapest hosting plans use linux...
People could easily write insecure apps in asp and host them on windows, or they could host insecure php apps on windows, linux is primarily used because of cost.
Slashdot Mirror
They dropped some instructions in the floating point unit and the MMU with the 68040 too...
The dropped instructions were emulated in software, and motorola even provided code to do the emulation (which became 680x0.library on the amiga)...
The reason Coldfire can't work that way is because it drops instructions used by the Amiga firmware, such that the firmware would crash before it could load the coldfire.library. Older versions of the Amiga 3000 firmware couldn't support a 68040 or 68060 CPU because they depended on functionality of the 68030's built in MMU that was no longer present in 68040 and above.
On the contrary, competitors can and do reverse engineer binaries, it just becomes more time consuming, but also harder to prove. If someone rips off the source your published and it shows up unchanged in their product its very easy to prove in court.
Having sourcecode would benefit users and the original vendor, and may actually hamper competitors because they have to be careful not to copy existing code.
Open source has often innovated, these days it is stuck copying because there is often no alternative - people are locked in to the existing applications and cloning them is the only way to achieve a user base. And you could argue that commercial software hasn't really innovated in the last few years either.
When you talk about open source copying commercial software, consider that...
The first web browsers were open source, commercial browsers copied.
Many of the other protocols we take for granted were developed as open source.
Bittorrent started out as an open source program.
And much more...
Commercial software need not be closed source, BSDi was distributed with sourcecode, even MS make source available to some of their products, tho on rather inflexible terms...
You just distribute both, the way linux and bsd are currently distributed...
If you have source available, then interested parties (vendors of new architectures, pro/power users etc).
Similar thing happened with PowerPC, it was going to be the next big thing... Apple came on board, Microsoft made a version of NT for it, Sun ported Solaris to it...
Motorola's m68k was the last big thing, so they assumed everyone would follow their migration path to PPC... Instead, most players dumped Motorola. They could have extended m68k like Intel has done with x86, the result would still have been messy but not as bad.
IA64 wasn't so much about clock rate, as theoretical instructions per clock...
Rather than having multiple cores, the idea was a sort of SIMD throughout the processor... But relying on the compiler to generate optimal code...
Assuming you have optimal code, an Itanium should be able to get a lot more work done in a single clock cycle than any x86 chip.
Very little code is written in x86 assembly, the vast majority is written in higher level languages and then compiled or interpreted... When you have the source code, porting it to IA64 is relatively easy. Look at Linux, it runs on a variety of architectures, as do a huge number of applications. Many of the original authors of those apps would never have considered they might be running on IA64, Alpha, Arm, Mips or Sparc someday...
The problem is software being delivered as binaries. Binary software distribution is holding back progress, making it necessary to continue supporting old kludgy architectures instead of making a clean break to something new and modern.
The first Itaniums were pretty much a dismal failure...
They ran at around 800mhz, so clocked lower than x86 systems of the time which were around 1.4ghz if i remember (and the mhz myth still very much alive, with intel fuelling it using the p4)... Their x86 support was roughly the speed of a p90 and therefore of little use beyond running one or two small legacy apps.
In terms of outright performance they were behind Alpha and Power at the time, so much for this new architecture. And when it came to price and power consumption they were behind everyone else.
When Itanium2 came around it performed a lot better, still guzzled power, and they realised that software emulation of x86 was faster than the hardware support, other than that the chips were still too expensive for what they were.
Now, Itanium is pretty much relegated to the high end niche that Alpha occupied before it was canned.
Itanium suffered from end users being locked in to proprietary binary only software - which only the original vendor could port... Some were unwilling, some didn't see the business case, some demanded that HP/Intel fund the porting, only they couldn't fund everything, so Itanium is left with a very limited set of apps...
OSS support was better, but it suffered from the high cost and rarity of the hardware, in that hobbyists had little chance of getting hold of the hardware to play with.
Personally i think HP/Intel would have been better off putting the effort into continued development of Alpha... It already had a software and user base, it already had x86 emulation which performed reasonably well, and it had a legacy behind it of old hardware that was cheaply available to OSS developers. Even today, Alpha versions of Linux seem far more active than the IA64 versions... Plus any customers already using Alpha would not have needed to migrate (and many of them migrated to Sun or IBM).
I don't know about on a mass scale, but i know several people who would rather pirate a game than suffer from DRM... Some of them will also buy the game first, but never actually use the purchased version.
There are many reasons behind this, such as a desire not to infect their systems with drm rootkits and the problems they cause, wanting to play without hunting for the media especially when traveling etc, wanting to let kids play without damaging the media (two fold here, without drm they no longer need the original media and can now copy it to have a disposable backup)...
Well, a VM adapts your native hardware into a single form that software can utilize...
Windows does exactly the same, the hardware may differ but the programming interface is largely the same. Both introduce performance losses relative to fully native code.
More like going down the freeway at 60mph in first gear where you're right over the redline...
While cracking the crypto may not be possible, in order for a DRM scheme to function you have to give paying customers the keys...
Those customers can just copy the keys and give them to people who haven't paid.
Sky TV have been using the same algorithms, but they keep changing the keys because the keys frequently leak.
Yes, and the quality is really really bad...
I would rather burn my songs to CD than use one of those crufty adapters... Tho it may be possible to adapt the cd changed to a line in...
You can dump streaming radio to disk and sync it with your ipod when you get home, assuming your not away from an internet connection for longer than it takes to play a few gigs of audio...
Many site license agreements are actually "upgrade from whatever version of windows came preinstalled on the machine", so strictly speaking you have to buy a preinstalled machine...
There are plenty of benchmarks out there showing Gentoo outperforming similar distributions, tho obviously with a distro as customizable as gentoo it's easy to misconfigure it and get abysmal performance...
Example:
http://new.isc.org/proj/dnsperf/OStest.html
There were some more, but i couldn't find the urls with a quick google search.
It's a combination of compiler - gcc generally produces slower code than MSVC...
And of compiler options - linux apps and common distributions are generally compiled for a 386, and therefore cannot take advantage of modern processor features like SSE.
There were benchmarks posted fairly recently, showing ffmpeg performance between windows binaries (compiled for p4 i believe) and the linux binaries supplied with ubuntu... The windows version was considerably quicker.
But if you compare a Gentoo system, linux comes out ahead.
For something like media encoding the difference will obviously be bigger, because modern processors have features specifically for accelerating such things, but if you add up the small performance hits taken in all the libraries and background processes a typical system will have running... For firefox, that will be X11, the kernel, libc, zlib, ssl, gtk, libjpeg and probably more... All those slight performance hits can soon add up.
And disturbingly, many distros are still compiled for i386, even those that won't actually run on such systems...
Not sure about windows, but i imagine it's compiled for i686 at the least...
OSX is compiled for core1 (x86 with sse3).
I think the desktop linux distros should target a p3 as a bare minimum, and leave anything below that to specialized cut down distributions. I doubt many people are running XP on lesser systems, and noone will be running Vista on a P3 let alone anything slower.
Also depends on your CPU...
AMD cpus tend to perform considerably faster in 64bit mode while Intel are generally only slightly quicker... Also, gcc generates better code for AMD while Intel concentrate more on their own compiler.
Have you tried the open source ati drivers? I understand the opengl support is not as complete, but perhaps 2d stuff will work better?
What about compiling firefox using intel's compiler? That's available for linux, and should outperform msvc...
What compiler do MS use for their windows mobile systems, and what did they use when nt used to run on alpha/ppc/mips?
But by your reckoning, you should run the windows version, under wine, on linux...
No antivirus, and best possible speed...
There is absolutely no reason why the linux native version should be slower than wine!
It may also have something to do with firefox on windows being built with MSVC, which generally produces faster code than gcc...
I believe windows firefox is also compiled for i686 or even pentium3, whereas on linux it's typically compiled for i386.
What would be interesting to see, is optimized builds of firefox compiled with various compilers and options, i'm pretty sure a gentoo box with firefox compiled by intel's compiler could comfortably beat the windows binaries...
By "black hole" i think he means "something unknown", like a black box... Which you don't have if you are in possession of the source.
Considering most hardware is made in asia anyway, i doubt cuba has much of a problem obtaining computers...
Yes, the problem is people using insecure webapps, most of which are written in php... It's not even php which is the problem, rather the apps people are writing with it...
PHP is being used because it has the lowest cost of entry...
Linux is being used because the cheapest hosting plans use linux...
People could easily write insecure apps in asp and host them on windows, or they could host insecure php apps on windows, linux is primarily used because of cost.