But you will always get poorly coded software that instead of harmlessly displaying the contents of a file, will be overflowable or trickable in some way to actually execute the file contents instead. For instance, it should be as safe to browse a website as it is to watch television, you should be able to view content, without risk that a hostile page will sieze control of your machine and force it to execute hostile code, often without you even realising whats going on.
This is because theres no comeback with buggy software, people EXPECT buggy software, and they will buy it anyway and just wait for the patch to come out... So theres no financial reason for a business to spend extra money thoroughly debugging their code.. However with hardware, you may have to replace thousands of items.. all of which cost money, whereas the cost of distributing a patch is negligible, especially since third parties will often mirror it for you and reduce your bandwidth costs.
Some of us have very comfortable car seats, air conditioning, awesome sound system etc... The seats in my car are the best seats i own by far, if i could put one on a rotating stand then i would sit at my desk in one.. A car sound system is often easier to tweak to your needs because you always sit in the same position relative to the speakers.
X11 is good in this respect, while an app can request to open a window without borders, the window manager doesnt have to honor this request, on the other hand you can configure any app to open without borders.. which is usefull for some programs as it gives you a little more space to work with.
A problem X11, with its varying window managers does not have. If i see a window open which has windows style borders and widgets it`s most obviously fake. So we have yet another argument against a monoculture.
But it has height to it, unlike a highway.. so in the evenings and early morning it casts a much wider shadow which makes it much more visible from above.
Not only that, but win2k doesnt show a bluescreen by default, it simply resets the machine instantly.. you have to configure it to disable the bluescreen. They did this to try and fool people into thinking it doesnt bluescreen anymore, but why the hell should an os spontaneously reboot? Whats more, a forced reboot, such as when you install directx, is little better than a crash especially if your trying to do something else at the time. The directx "reboot now" requests always sits above other windows, does not have a "reboot later" options and cant be closed, it sits there until you actually reboot, how annoying is that.
The genesis was VERY popular in the UK, ofcourse it was sold as the "megadrive" there, and was the dominant platform until the playstation took over.. Amiga was very much alive at the time too.. atari yeah, they were on their way out.. with their last ditch effort the jaguar, also based on an m68k chip.. Sun and DEC, not sure about sgi and hp tho... both dropped m68k because motorola told them it was nearing its end of life, they tried ppc, which was motorola`s official migration path, but chose to develop their own next generation processors instead. At the time intel had no monopoly, i would wager that more m68k chips were being sold than x86 ones.
Which is exactly why itanium has failed sofar, and companies are still buying sparc/power/mips/parisc/alpha/x86 based machines instead, all of which are proven technologies. I still think the idea to develop itanium atall was a stupid one, and they (intel/hp) would have been better off sticking with the alpha. Ofcourse there are still plenty of people with less than half a brain.
But with the 68020 and 68030 there was the possibility of an external FPU, the 68881 or 68882. I believe many machines had the socket to accept one, but simply didnt ship with one by default because very little software took advantage of it, infact m68k FPU`s were always more common on the Amiga platform, where 3d rendering was more popular. Running a mac emulator on an amiga always seemed very fast, faster even than a real mac using the same cpu... and this while running the emulation environment as a process under a multitasking os
Infact, the M68k architecture would have been a far more logical architecture to continue and extend than x86, and dumping m68k in favor of ppc was a major error on the part of motorola, and resulted in huge financial losses to motorola and countless other companies. Back in the days, m68k was the most commonly used architecture out there, sure x86 was used in ibm compatibles but not much else.... m68k was in macs, amigas, atari, the sega genesis, sun, sgi workstations etc, and countless embedded products and even cray supercomputers. There was a whole range, with the cutting edge chips being used in the high end servers, while the slightly older chips were mass produced cheaply for end user machines and games consoles. Had the m68k range continued to be developed, its likely the performance would be on a par or greater than x86, and many of these companies would still be using them.. whats more we would likely have userspace binary compatibility between most of the unix vendors, even if the kernel and driver sets were different. With this in mind, i can really see intel losing out to AMD bigtime in the near future. Ofcourse in an ideal world, we could drop obsolete architectures and move immediately to new more modern and better thought out designs, or atleast have chips which are designed with future expansion in mind, rather than the "push the limit just out of reach, reach it next month" mentality of intel.
Exactly, anyone who disregards vendor security notices and consequently gets hacked should be blamed for negligence, if you connect a machine to a public network it is your duty to take reasonable measures to ensure that it doesnt get compromised and possibly used for furthur crimes, just like a gun or car owner is responsible for keeping it out of the hands of criminals. Similarly software and hardware vendors should also be held liable for flaws in their products, and even more so if vulnerabilities are not fixed in a timely manner, and customers notified of the availability of fixes. Think of this like someone who owns a gun, if you leave your front door unlocked and your gun placed on a table then your negligent, if you lock your front door and keep your gun in a locked cabinet, and someone goes to the trouble of breaking the locks open, then your a victim of a crime. If the crook breaks in because the brand of lock you use is known to be inferior and easy to pick, then the lock vendor should be accountable.
You will be losing out quite a bit in the performance stakes by using gcc, forte provides much better performance on every machine where i`ve used it. True, a lot of open source software uses gcc extensions and thus wont compile with forte, but it would be better to produce in house software in portable C whenever possible, as this would give you the best flexibility if you do decide to replace the solaris boxes. As for the JVM, yes it sucks, the linux one sucks too... seeing how hard sun push java you`d expect them to ensure that atleast their own machines were capable of running it well, but thats simply not the case. A lot of software installers, forte comes to mind, are written in java... and as a result are incredibly slow and buggy. But you cant fault the actual code put out by forte.... gcc seems unable to output code for a v8 sparc, on the machines i`m using here it generates code which crashes with illegal instruction, and in virtually all benchmarks forte beats it hands down.
Exactly, 6.4 was the last useable version. I saw a friends machine with both 6.4 and 7 installed, 7 couldnt play most avi (divx?) files without stuttering sound and jerky screen updates. The same files played fine in 6.4 on the same machine.
Superior to other platforms? try the solaris or hp-ux versions of ie, they suck.. badly, theyre slow and unstable and only the sparc version of solaris is supported, why? because microsoft refuse to acknowlege that x86 machines will run any os that isnt produced by them.
Well i have an ATI FireGL 2, the version on a 64bit pci card. There are binary drivers for x86 linux, x86 windows and HP-UX on PA-RISC. However since the only machine i have with 64bit pci is an Alpha, i`m somewhat screwed.
Because as we all know, it`s not morally wrong if it has big money backing it, or its not harming those with big money. The side with the most money will usually get their way. Large corporations dont care if you shoot a few people, and gun companies want to continue selling guns. People don`t matter. However a product that could potentially hurt sales for a large influential company, well that`s a whole different matter.
It truly is a corrupt world we live in. Corporate dictatorship, atleast with saddam you have a single target to assassinate.
It may not work on newer computers right now, but by releasing the source someone will do that work for them, thus they hope to increase sales of the game, even if only slightly.
Download john the ripper (www.openwall.com) and compile it first with the generic target, second with the generic-x86 and third with x86-mmx and perform benchmarks. Reading those benchmarks will show you the benefits of optimization, the mmx version is over 500% faster on my athlon system, and the generic C version is still somewhat slower than the x86 hand optimized one, so clearly compilers have a way to go still. Aside from anything else, its likely that your debian box is compiled with gcc 2.95.3, a somewhat older and proven to generate slower code, than the gcc 3.2 used by gentoo. As gcc improves so the optimization difference will too, binaries targetting a 386 will never take advantage of mmx, sse, 3dnow etc... Do you think intel/amd were on crack when they created these extensions? If they werent going to provide some performance benefit, there would have been absoloutely no point including them, and restricting yourself to backwards compatible binaries means you cant take advantage of these features without bloated fat binaries.
Some optimizations are tradeoffs, most often in compile time, some such as the gcc flag -fomit-frame-pointer make debugging somewhat more difficult, but if you intend to USE a program rather than debug it, it seems worthwhile. -ffast-math cuts a few corners to speed up floating point math, which works fine in most programs because they dont require the full ieee spec precision. However many optimizations are not tradeoffs, different processors have different execution patterns, they execute different instructions at different speeds, can process multiple instructions at once, have pipelines of various lengths and caches of various sizes. If you take these all into account, the compiler can do it`s best to ensure there are the minimum number of cache misses, pipeline stalls and NOP`s fed through other execution units. The only reason the differences are not much larger, is because x86 cpu`s are designed heavily with backwards compatibility in mind, mainly because most of these chips spend their whole lives running old code.
Slashdot Mirror
But you will always get poorly coded software that instead of harmlessly displaying the contents of a file, will be overflowable or trickable in some way to actually execute the file contents instead.
For instance, it should be as safe to browse a website as it is to watch television, you should be able to view content, without risk that a hostile page will sieze control of your machine and force it to execute hostile code, often without you even realising whats going on.
This is because theres no comeback with buggy software, people EXPECT buggy software, and they will buy it anyway and just wait for the patch to come out... So theres no financial reason for a business to spend extra money thoroughly debugging their code..
However with hardware, you may have to replace thousands of items.. all of which cost money, whereas the cost of distributing a patch is negligible, especially since third parties will often mirror it for you and reduce your bandwidth costs.
Itanium on the other hand, is on a LOT LESS systems than AMD chips.
Some of us have very comfortable car seats, air conditioning, awesome sound system etc...
The seats in my car are the best seats i own by far, if i could put one on a rotating stand then i would sit at my desk in one..
A car sound system is often easier to tweak to your needs because you always sit in the same position relative to the speakers.
X11 is good in this respect, while an app can request to open a window without borders, the window manager doesnt have to honor this request, on the other hand you can configure any app to open without borders.. which is usefull for some programs as it gives you a little more space to work with.
A problem X11, with its varying window managers does not have. If i see a window open which has windows style borders and widgets it`s most obviously fake.
So we have yet another argument against a monoculture.
But it has height to it, unlike a highway.. so in the evenings and early morning it casts a much wider shadow which makes it much more visible from above.
Not only that, but win2k doesnt show a bluescreen by default, it simply resets the machine instantly.. you have to configure it to disable the bluescreen. They did this to try and fool people into thinking it doesnt bluescreen anymore, but why the hell should an os spontaneously reboot?
Whats more, a forced reboot, such as when you install directx, is little better than a crash especially if your trying to do something else at the time. The directx "reboot now" requests always sits above other windows, does not have a "reboot later" options and cant be closed, it sits there until you actually reboot, how annoying is that.
The genesis was VERY popular in the UK, ofcourse it was sold as the "megadrive" there, and was the dominant platform until the playstation took over.. Amiga was very much alive at the time too.. atari yeah, they were on their way out.. with their last ditch effort the jaguar, also based on an m68k chip..
Sun and DEC, not sure about sgi and hp tho... both dropped m68k because motorola told them it was nearing its end of life, they tried ppc, which was motorola`s official migration path, but chose to develop their own next generation processors instead.
At the time intel had no monopoly, i would wager that more m68k chips were being sold than x86 ones.
Which is exactly why itanium has failed sofar, and companies are still buying sparc/power/mips/parisc/alpha/x86 based machines instead, all of which are proven technologies.
I still think the idea to develop itanium atall was a stupid one, and they (intel/hp) would have been better off sticking with the alpha.
Ofcourse there are still plenty of people with less than half a brain.
But with the 68020 and 68030 there was the possibility of an external FPU, the 68881 or 68882. I believe many machines had the socket to accept one, but simply didnt ship with one by default because very little software took advantage of it, infact m68k FPU`s were always more common on the
Amiga platform, where 3d rendering was more popular.
Running a mac emulator on an amiga always seemed very fast, faster even than a real mac using the same cpu... and this while running the emulation environment as a process under a multitasking os
Well he did say the code generator was pretty clueless, so it wouldnt surprise me atall :P
Infact, the M68k architecture would have been a far more logical architecture to continue and extend than x86, and dumping m68k in favor of ppc was a major error on the part of motorola, and resulted in huge financial losses to motorola and countless other companies. Back in the days, m68k was the most commonly used architecture out there, sure x86 was used in ibm compatibles but not much else.... m68k was in macs, amigas, atari, the sega genesis, sun, sgi workstations etc, and countless embedded products and even cray supercomputers. There was a whole range, with the cutting edge chips being used in the high end servers, while the slightly older chips were mass produced cheaply for end user machines and games consoles. Had the m68k range continued to be developed, its likely the performance would be on a par or greater than x86, and many of these companies would still be using them.. whats more we would likely have userspace binary compatibility between most of the unix vendors, even if the kernel and driver sets were different. With this in mind, i can really see intel losing out to AMD bigtime in the near future.
Ofcourse in an ideal world, we could drop obsolete architectures and move immediately to new more modern and better thought out designs, or atleast have chips which are designed with future expansion in mind, rather than the "push the limit just out of reach, reach it next month" mentality of intel.
Exactly, anyone who disregards vendor security notices and consequently gets hacked should be blamed for negligence, if you connect a machine to a public network it is your duty to take reasonable measures to ensure that it doesnt get compromised and possibly used for furthur crimes, just like a gun or car owner is responsible for keeping it out of the hands of criminals.
Similarly software and hardware vendors should also be held liable for flaws in their products, and even more so if vulnerabilities are not fixed in a timely manner, and customers notified of the availability of fixes.
Think of this like someone who owns a gun, if you leave your front door unlocked and your gun placed on a table then your negligent, if you lock your front door and keep your gun in a locked cabinet, and someone goes to the trouble of breaking the locks open, then your a victim of a crime.
If the crook breaks in because the brand of lock you use is known to be inferior and easy to pick, then the lock vendor should be accountable.
You will be losing out quite a bit in the performance stakes by using gcc, forte provides much better performance on every machine where i`ve used it. True, a lot of open source software uses gcc extensions and thus wont compile with forte, but it would be better to produce in house software in portable C whenever possible, as this would give you the best flexibility if you do decide to replace the solaris boxes.
As for the JVM, yes it sucks, the linux one sucks too... seeing how hard sun push java you`d expect them to ensure that atleast their own machines were capable of running it well, but thats simply not the case. A lot of software installers, forte comes to mind, are written in java... and as a result are incredibly slow and buggy. But you cant fault the actual code put out by forte....
gcc seems unable to output code for a v8 sparc, on the machines i`m using here it generates code which crashes with illegal instruction, and in virtually all benchmarks forte beats it hands down.
Exactly, 6.4 was the last useable version.
I saw a friends machine with both 6.4 and 7 installed, 7 couldnt play most avi (divx?) files without stuttering sound and jerky screen updates. The same files played fine in 6.4 on the same machine.
Superior to other platforms?
try the solaris or hp-ux versions of ie, they suck.. badly, theyre slow and unstable and only the sparc version of solaris is supported, why? because microsoft refuse to acknowlege that x86 machines will run any os that isnt produced by them.
Well i have an ATI FireGL 2, the version on a 64bit pci card. There are binary drivers for x86 linux, x86 windows and HP-UX on PA-RISC. However since the only machine i have with 64bit pci is an Alpha, i`m somewhat screwed.
Not to mention the fact that binary-only drivers prevent me from using their cards in non x86 workstations, arent nvidia cards quite popular on macs?
Because as we all know, it`s not morally wrong if it has big money backing it, or its not harming those with big money.
The side with the most money will usually get their way.
Large corporations dont care if you shoot a few people, and gun companies want to continue selling guns. People don`t matter.
However a product that could potentially hurt sales for a large influential company, well that`s a whole different matter.
It truly is a corrupt world we live in. Corporate dictatorship, atleast with saddam you have a single target to assassinate.
Hmm, if FPU speed is so important... i will try compiling this on my alphastation :)
It may not work on newer computers right now, but by releasing the source someone will do that work for them, thus they hope to increase sales of the game, even if only slightly.
Well their security track record leaves their customers very much open.
I beg to differ:
There was no such thing as an email virus before microsoft email clients.
Download john the ripper (www.openwall.com) and compile it first with the generic target, second with the generic-x86 and third with x86-mmx and perform benchmarks.
Reading those benchmarks will show you the benefits of optimization, the mmx version is over 500% faster on my athlon system, and the generic C version is still somewhat slower than the x86 hand optimized one, so clearly compilers have a way to go still.
Aside from anything else, its likely that your debian box is compiled with gcc 2.95.3, a somewhat older and proven to generate slower code, than the gcc 3.2 used by gentoo.
As gcc improves so the optimization difference will too, binaries targetting a 386 will never take advantage of mmx, sse, 3dnow etc... Do you think intel/amd were on crack when they created these extensions? If they werent going to provide some performance benefit, there would have been absoloutely no point including them, and restricting yourself to backwards compatible binaries means you cant take advantage of these features without bloated fat binaries.
Some optimizations are tradeoffs, most often in compile time, some such as the gcc flag -fomit-frame-pointer make debugging somewhat more difficult, but if you intend to USE a program rather than debug it, it seems worthwhile. -ffast-math cuts a few corners to speed up floating point math, which works fine in most programs because they dont require the full ieee spec precision. However many optimizations are not tradeoffs, different processors have different execution patterns, they execute different instructions at different speeds, can process multiple instructions at once, have pipelines of various lengths and caches of various sizes. If you take these all into account, the compiler can do it`s best to ensure there are the minimum number of cache misses, pipeline stalls and NOP`s fed through other execution units.
The only reason the differences are not much larger, is because x86 cpu`s are designed heavily with backwards compatibility in mind, mainly because most of these chips spend their whole lives running old code.