What's really annoying about it is that if you press OK (or maybe it was called Enter. Basically the big button on the printer), it would go right ahead and print the document rescaled to A4. But you had to be there and know what "PC Load letter" means to do that.
It's actually a sign that you haven't installed Word properly, just used the US defaults instead of picking the correct one for your country. And HP printers don't (or maybe didn't) have the "rescale to fit page" option set by default. Now if you're the sort of person who Googles cryptic error messages and reads all the settings when you install you'll fix it quickly.
But it only takes one non geek in an office to fail to do one of the other of these to gum up the print queue. I've actually seen people walk into the printer room, see the message, swear and reboot the printer and try to print again. Needless to say that means everyone else loses their document. I worked somewhere where I'd see people go into the printer room regularly because "it needed rebooting" until I helped them track it down.
Of course, in a big company all the machines are ghosted with an image containing an OS and Office installed correctly, so you won't see this. But in small companies it causes havoc.
That's what Transmeta did, right? And FX!32 Dec's x86 to Alpha translator was trying to do the same thing. People have tried it, and the results aren't too impressive.
I think the real problem is that there isn't currently a non x86 server class chip which has superior performance even running native code. I guess if some sort of VLIW architecture managed that then we'd see people experiment with JITing x86 to it. But there's always the code size issue - x86 code is compact and you can fit more of it into the same size cache. Translating it in hardware doesn't really have much of a cost in terms of die size. And from a user perspective it's very convenient that you can run old binaries in all processor modes. FX!32 could only do 32 bit user mode stuff from what I can tell. NTVDM had a Insignia derived emulator for Dos and Win16 stuff. But emulating device drivers is probably impossible to do without massive stability issues.
A JITter is bad for caches too. Since you have to JIT basic blocks of code the JIT compiler keeps getting called so it 'pollutes' the cache. In a processor with native x86 support you can spend all your cache on x86 code, but in a Risc chip with a JITer you spend some on native code, which is bigger than the x86 equivalent and some on the JIT compiler itself. Which is not good for performance.
Compared to a Risc chip an x86 compatible always has some overhead. On the 486 there was a big microcode Rom. On modern chips there is the "decode to uops" logic in the pipeline.
My point is that back in the 486 days the microcode Rom took up significant die area. But in a modern chip the whole core takes up a tiny percentage of the die - if you look at a picture it is mostly cache. So you can see that the price for being x86 compatible has dropped to the point where it is negligable.
I don't know about MIPS or PowerPC, but the Alpha port of Windows NT could run X86 binaries. It used FX!32, a Dec written JIT translator.
Incidentally, I've heard that the HAL started losing compatibility after Windows NT4, and was pretty much tied to little-endian even so. At least, this is what a prior, highly-rated Slashdot post that I can't find right now claimed. Well, if he worked for Microsoft and thus actually knew he wouldn't be posting about it on slashdot.
That translation of x86 instructions must have some performance cost to it. What Intel should do is expose both sets of instructions, act like an x86 if the OS expects it, or act RISC-like if the OS expects that. Then everyone can have their Windows installed, and it creates an opening for other operating systems. An OS that uses the native instruction set should be a little faster, giving people a reason to use it over windows. That will encourage MS to port windows the the new instruction set, and voila we are free of x86. Actually Windows NT and its descendents are very portable - they were designed to run on i860, Mips, x86, Alpha and PPC. Even now they run on x86, x64, Itanium and PowerPC (in the XBox 360). All those ports probably made the code quite easy to port to new architectures. It's all the binary application software that isn't. Or rather it probably could be done if you had the source and time to do it, but lots of people have some very old applications that they don't want to buy again. E.g. Photoshop may be portable, but the copy of Photshop CSx I have on my desk isn't. And I don't to use the latest Photoshop version because it's slower and costs a lot of money. It's even worse if the company that made the app is out of business. But I buy a new copy of Windows every couple of years. So your hypothetical dual mode CPU could run Windows 7 natively. Some new apps would be native and some old ones x86. Actually x64 is already like this on Vista on x64 - the kernel is 64 bit and most applications will stay 32 bit, but x64 is no more native to the processor than x86.
The question is whether a processor running its native instruction set would be faster. From what I can tell the native instruction format of a modern x86 is wider than the x86 equivalent. Suppose the uops in the pipeline are 48 bit - a 32 bit constant and a 16 bit instruction. That is quite a bit larger than a typical x86 instruction. Wider instructions take more space in Ram and cache. You don't need to decode them, but the extra time fetching them kills the advantage.
And what is native is very implementation dependent. An AMD chip will have a very different uop format from an Intel one. Actually even between chip generations the uop format might change. Essentially Risc chips tried to make the internal pipeline format the ISA. But in the long run that wasn't good. Original Risc had branch delay slots and later superscalar implementations where branch delays work very differently had to emulate the old behaviour because it was no longer at all native. So if you did this you'd get an advantage for one generation but later generations would be progressively disadvantaged. Or you could keep switching instruction sets. But if most software is distributed as binaries that is impossible.
Kinda makes you wonder how different things might be or how much farther things might've come had a better architecture become the de facto standard of commodity hardware.
I've heard it said that most of the processing of x86 architectures goes to breaking down complex instructions to two or three smaller instructions. That's a lot of overhead over time. Even if programmers broke down the instructions themselves so that they were only using basically a RISC-subset of the x86 instructions, there's all that hardware that still has to be there for legacy and to preserve compatibility with the standard.
But I'm not a chip engineer, so my understanding may be fundamentally flawed somehow. I think the important thing to remember is that total chip transistor counts - mostly used for caches - have inflated very rapidly due to Moores Law. And legacy baggage has grown more slowly. So the x86 compatibility overhead in a modern x86 compatible chip is lower than it was in a 486 for example. Meanwhile the cost of not being x86 compatible has stayed the same. Arm cores are much smaller than x86 for example but most PC like devices still use x86 because most applications and OSs are distributed as x86 code.
Lets not forget the wonderful Itanium processor which was supposed to replace X86 and be the next gen 64-bit king.
How could Intel have got it so wrong? as Linus said "they threw out all of the good bits of X86".
It's good to see however that Intel have now managed to product decent processors now the GHz wars are over. In fact it's been as much about who can produce the lowest power CPU. AMD seem to just have the edge. Not just Itanium. All the x86 alternatives have sunk over the years. Mips, Alpha, PPC. x86 was originally a hack on 8080, designed to last for a few years. All the others had visions of 25 year lifetimes. But the odd thing is that a hack will be cheaper and reach the market faster. An architecture designed to last for 25 years by definition must include features which are baggage when it is released. x86, USB, Dos and Windows show that it's better to optimize something for when it is released. Sure doing this will leave a few holes. But if it succeeds you have the money to fix them. As limited human engineers this seems inelegant. But that's how evolution works.
Maybe having vision is overrated. Evolution has no vision it just hacks stuff blindly. But it designed your brain. Conscious engineers planning for the long term can't do that.
The demise of the x86 general architecture will not begin until Windows goes out of fashion. It's the only major platform strongly tied to that CPU architecture. x86 CPUs have been emulating the x86 instruction set in hardware for many years now. I guess, if they could, Intel / AMD / VIA and others would happily abandon the concept, because it leads to all sorts of complexities. Yeah, they could move to an architecture with a simple, compact instruction set encoding which makes efficient use of the instruction cache and can be translated to something easier to implement on the fly with extra pipeline stages.
But wait, that's exactly what x86 is. In terms of code density it does pretty well compared to Risc. Modern x86s don't implement it internally, they translate it to Riscy uops on the fly and execute those. And over the years compilers have learned to prefer the x86 instructions that are fast in this sort of implementation. And, thanks to AMD it now supports 64 bit natively in its x64 variant. This is important. 64 bit maybe overkill today, but most architectures die because of a lack of address space (see Computer Architecture by Hennessy and Patterson). But 64 bit address spaces will keep x86/x64 going for at least a while.
http://cache-www.intel.com/cd/00/00/01/79/17969_codeclean_r02.pdf If you know that the variable does not need to be pointer polymorphic (scale with the architecture), use the following guideline to see if it can be typed as 32-bit instead of 64-bit. (This guideline is based on a data expansion model of 1.5 bits per year over 10 years.)
IIRC 1.5 bits per year address space bloat is from Hennessy and Patterson.
At this point we have 30 unused bits of address space, assuming current apps need 32GB tops. That gives 64 bit x64 another 20 years lifetime!
They could do that, but they shouldn't misrepresent it as being LGPL. If someone claims that their software is licensed under the LGPL, I assume that I don't have to read their version, since I know the LGPL already. If using a modified version, they should call it something else.
You should do, because the FSF doesn't own the letters 'LGPL'. They could stand for Llama Goober Porky License.
The terms of the GPL or LGPL don't bind the copyright holder. He could license it under GPL or LGPL of the ExtJS public license. Or he could edit out some of the terms of the LGPL, add in a few more and license the code under that.
The debacle last month with ExtJS proved this. They relicensed under GPLv3 and then began trying to demand money for a commercial license from everyone who used their javascript library in a commercial web site, stating that you cannot use their library in your website under the GPL unless you open source all of the code used to generate your website (html, css, js, and any server side code like PHP, Ruby, or Python). That's a brilliant idea on the part of the ExtJS author. Open source you business rules and face angry customers or pay up for a commercial license. Utter genius. And he released it under LGPL first to build up a user base. And he cleverly got people to assign copyright on any submissions to he was the sole copyright holder and could change the license.
twitter strode into the room and told the unvarnished truth, rough diamond that he was. The assembled Microsoft shills jeered at him and he looked crestfallen. Erris watched from the sidelines and then piped up 'he's right, I found this article on MacTrope's journal'. Later they...
Damn you. Now I'm need to overwrite my brain with the backup I made before I started writing this.
So is James Cameron going to make a 3 hour chick flick where a young enlisted man falls in love with a high ranking officer, and they make love in the engine room while the Captain, the officer's life partner, searches frantically for him. Then the submarine starts to sink and the gay enlisted man gives the officer the last life jacket and the officer says, "I'll never let go!" and then he lets go and James Cameron wins 200 more Oscars? It's like a slash fanfic adapted for twitter.
It's blasphemous for non believers to write His name out in full unless you write (sbuh) for Sauce Be Upon Him afterwards. And the penalty for blasphemy is death, just FYI. What country do you come from BTW? As an FSM believer I plan to burn down the embassy and kill everyone inside.
I've had users laminate their user name and password to their laptop palm rest. Security of information is great and all, but in the end, the user is the weakest link. I wonder what would happen if you baggypantsed them?
What about the potential for shorting the company's stock and then using their device to send an email from their account that will make the value drop (if only briefly)? That would be a fun email to try to write.
Yes. Most of these idiotic questions should be answered with "mu." However, that's not a normal answer, so we flood the comments with ridiculous arguments about the stupid question stuck to the submission. Cows must be some wise ass motherfuckers. I went to a field and asked a cow the questions I studied for my Advanced Zen Buddhism class and it got them all right. No more beef for me!
Did I stop submitting when the editors started rephrasing all submissions in the form of catchy imbalanced questions? Is this another Microsoft plot to divide the Open Source movement? FTFY.
You DO realize that Taiwan is a completely separate country from China, right? China won't acknowledge it, but it's undeniable in practice, and recognized as sovereign by the rest of the world. I'm in Taiwan at the moment and love it here. And I've basically hated the Chinese government since Tienanmen. So it's good to hear they're screwing up in electronics.
But despite the fact that Taiwan (the Republic of China) is a de facto independent democracy, it is definitely not recognized as sovereign by the rest of the world. The rest of the world after many temper tantrums from Beijing (that People's Republic of China) accepts that regimes 'One China principle', which means that the unelected government in Beijing, heirs to Mao Zedong one of the greatest mass murderers in history is the legally true representative of all China. And Taiwan has no UN seat.
Then again the US quietly send two aircraft carrier battle groups to patrol off Taiwan during Taiwan's last election, and has told Beijing it will defend Taiwan should Beijing attack. But the US doesn't officially recognize Taiwan as an independent state. What the US does recognize is a bit subtle, but they presumably hope that they can keep Taiwan de facto independent and thus democratic but discourage it from seeking de jure independence until Beijing democratizes. In the meantime they will deter Beijing from attacking it whilst proclaiming they support the One China principle. Of course, One China wouldn't be a bad idea at all if that China was democratic. The Taiwanese could spread their excellent system into the mainland, much like West Germany did following German unification.
Personally, unlike my government and the UN, I regard Taiwan as the One True China, based on the size of the electorate that elected Presidents. Many more people voted for Ma Ying-jeou, President of the Republic Of China than Hu Jintao, President of People's Republic Of China and political legitimacy comes purely from elections.
I can appreciate what you're trying to say, and that this is an issue near and dear to your heart, but it goes against what the guys who actually run the industry are saying. If you have evidence to prove your point, present it. Do you have a link where Michael Dell says that Windows costs $100? When did he say it? The only link I've found on Windows costs is that Dell will discount $50 if you don't have it. And that link states that '$50 is very close to the likely cost'. I posted it, it's the arstechnica link.
But the $50 discount is a marketing decision.
Someone else posted a link that implies the crapware vendors pay them $50-$60.
Slashdot Mirror
What's really annoying about it is that if you press OK (or maybe it was called Enter. Basically the big button on the printer), it would go right ahead and print the document rescaled to A4. But you had to be there and know what "PC Load letter" means to do that.
It's actually a sign that you haven't installed Word properly, just used the US defaults instead of picking the correct one for your country. And HP printers don't (or maybe didn't) have the "rescale to fit page" option set by default. Now if you're the sort of person who Googles cryptic error messages and reads all the settings when you install you'll fix it quickly.
But it only takes one non geek in an office to fail to do one of the other of these to gum up the print queue. I've actually seen people walk into the printer room, see the message, swear and reboot the printer and try to print again. Needless to say that means everyone else loses their document. I worked somewhere where I'd see people go into the printer room regularly because "it needed rebooting" until I helped them track it down.
Of course, in a big company all the machines are ghosted with an image containing an OS and Office installed correctly, so you won't see this. But in small companies it causes havoc.
That's what Transmeta did, right? And FX!32 Dec's x86 to Alpha translator was trying to do the same thing. People have tried it, and the results aren't too impressive.
I think the real problem is that there isn't currently a non x86 server class chip which has superior performance even running native code. I guess if some sort of VLIW architecture managed that then we'd see people experiment with JITing x86 to it. But there's always the code size issue - x86 code is compact and you can fit more of it into the same size cache. Translating it in hardware doesn't really have much of a cost in terms of die size. And from a user perspective it's very convenient that you can run old binaries in all processor modes. FX!32 could only do 32 bit user mode stuff from what I can tell. NTVDM had a Insignia derived emulator for Dos and Win16 stuff. But emulating device drivers is probably impossible to do without massive stability issues.
A JITter is bad for caches too. Since you have to JIT basic blocks of code the JIT compiler keeps getting called so it 'pollutes' the cache. In a processor with native x86 support you can spend all your cache on x86 code, but in a Risc chip with a JITer you spend some on native code, which is bigger than the x86 equivalent and some on the JIT compiler itself. Which is not good for performance.
Umm, no. Is that supposed to be some sort of insult?
Compared to a Risc chip an x86 compatible always has some overhead. On the 486 there was a big microcode Rom. On modern chips there is the "decode to uops" logic in the pipeline.
My point is that back in the 486 days the microcode Rom took up significant die area. But in a modern chip the whole core takes up a tiny percentage of the die - if you look at a picture it is mostly cache. So you can see that the price for being x86 compatible has dropped to the point where it is negligable.
The question is whether a processor running its native instruction set would be faster. From what I can tell the native instruction format of a modern x86 is wider than the x86 equivalent. Suppose the uops in the pipeline are 48 bit - a 32 bit constant and a 16 bit instruction. That is quite a bit larger than a typical x86 instruction. Wider instructions take more space in Ram and cache. You don't need to decode them, but the extra time fetching them kills the advantage.
And what is native is very implementation dependent. An AMD chip will have a very different uop format from an Intel one. Actually even between chip generations the uop format might change. Essentially Risc chips tried to make the internal pipeline format the ISA. But in the long run that wasn't good. Original Risc had branch delay slots and later superscalar implementations where branch delays work very differently had to emulate the old behaviour because it was no longer at all native. So if you did this you'd get an advantage for one generation but later generations would be progressively disadvantaged. Or you could keep switching instruction sets. But if most software is distributed as binaries that is impossible.
I've heard it said that most of the processing of x86 architectures goes to breaking down complex instructions to two or three smaller instructions. That's a lot of overhead over time. Even if programmers broke down the instructions themselves so that they were only using basically a RISC-subset of the x86 instructions, there's all that hardware that still has to be there for legacy and to preserve compatibility with the standard.
But I'm not a chip engineer, so my understanding may be fundamentally flawed somehow. I think the important thing to remember is that total chip transistor counts - mostly used for caches - have inflated very rapidly due to Moores Law. And legacy baggage has grown more slowly. So the x86 compatibility overhead in a modern x86 compatible chip is lower than it was in a 486 for example. Meanwhile the cost of not being x86 compatible has stayed the same. Arm cores are much smaller than x86 for example but most PC like devices still use x86 because most applications and OSs are distributed as x86 code.
How could Intel have got it so wrong? as Linus said "they threw out all of the good bits of X86".
It's good to see however that Intel have now managed to product decent processors now the GHz wars are over. In fact it's been as much about who can produce the lowest power CPU. AMD seem to just have the edge. Not just Itanium. All the x86 alternatives have sunk over the years. Mips, Alpha, PPC. x86 was originally a hack on 8080, designed to last for a few years. All the others had visions of 25 year lifetimes. But the odd thing is that a hack will be cheaper and reach the market faster. An architecture designed to last for 25 years by definition must include features which are baggage when it is released. x86, USB, Dos and Windows show that it's better to optimize something for when it is released. Sure doing this will leave a few holes. But if it succeeds you have the money to fix them. As limited human engineers this seems inelegant. But that's how evolution works.
Maybe having vision is overrated. Evolution has no vision it just hacks stuff blindly. But it designed your brain. Conscious engineers planning for the long term can't do that.
But wait, that's exactly what x86 is. In terms of code density it does pretty well compared to Risc. Modern x86s don't implement it internally, they translate it to Riscy uops on the fly and execute those. And over the years compilers have learned to prefer the x86 instructions that are fast in this sort of implementation. And, thanks to AMD it now supports 64 bit natively in its x64 variant. This is important. 64 bit maybe overkill today, but most architectures die because of a lack of address space (see Computer Architecture by Hennessy and Patterson). But 64 bit address spaces will keep x86/x64 going for at least a while.
http://cache-www.intel.com/cd/00/00/01/79/17969_codeclean_r02.pdf
If you know that the variable does not need to be pointer polymorphic (scale with the architecture), use the following guideline to see if it can be typed as 32-bit instead of 64-bit. (This guideline is based on a data expansion model of 1.5 bits per year over 10 years.)
IIRC 1.5 bits per year address space bloat is from Hennessy and Patterson.
At this point we have 30 unused bits of address space, assuming current apps need 32GB tops. That gives 64 bit x64 another 20 years lifetime!
They could do that, but they shouldn't misrepresent it as being LGPL. If someone claims that their software is licensed under the LGPL, I assume that I don't have to read their version, since I know the LGPL already. If using a modified version, they should call it something else.
You should do, because the FSF doesn't own the letters 'LGPL'. They could stand for Llama Goober Porky License.The terms of the GPL or LGPL don't bind the copyright holder. He could license it under GPL or LGPL of the ExtJS public license. Or he could edit out some of the terms of the LGPL, add in a few more and license the code under that.
...
... but it's not like they could sue him for using a modified version their license as far as I can see.
The FSF won't necessarily approve
http://www.fsf.org/licensing/licenses/gpl-faq.html#ModifyGPL
http://en.wikipedia.org/wiki/Fork_bomb#Example_fork_bombs
twitter strode into the room and told the unvarnished truth, rough diamond that he was. The assembled Microsoft shills jeered at him and he looked crestfallen. Erris watched from the sidelines and then piped up 'he's right, I found this article on MacTrope's journal'. Later they...
Damn you. Now I'm need to overwrite my brain with the backup I made before I started writing this.
It's blasphemous for non believers to write His name out in full unless you write (sbuh) for Sauce Be Upon Him afterwards. And the penalty for blasphemy is death, just FYI. What country do you come from BTW? As an FSM believer I plan to burn down the embassy and kill everyone inside.
http://catb.org/jargon/html/B/baggy-pantsing.html
Read this
http://en.wikipedia.org/wiki/Godel,_Escher,_Bach
that's where I first heard it.
Hand over your Grammar Nazi card at the entrance. Obergruppenführer Coward!
Bad news I'm afraid. You have been reposted. You ship off for youtube.com on the Eastern Front in one hour's time.
Don't look so upset, it happens to the best of us sooner or later. Schnapps?
But despite the fact that Taiwan (the Republic of China) is a de facto independent democracy, it is definitely not recognized as sovereign by the rest of the world. The rest of the world after many temper tantrums from Beijing (that People's Republic of China) accepts that regimes 'One China principle', which means that the unelected government in Beijing, heirs to Mao Zedong one of the greatest mass murderers in history is the legally true representative of all China. And Taiwan has no UN seat.
Then again the US quietly send two aircraft carrier battle groups to patrol off Taiwan during Taiwan's last election, and has told Beijing it will defend Taiwan should Beijing attack. But the US doesn't officially recognize Taiwan as an independent state. What the US does recognize is a bit subtle, but they presumably hope that they can keep Taiwan de facto independent and thus democratic but discourage it from seeking de jure independence until Beijing democratizes. In the meantime they will deter Beijing from attacking it whilst proclaiming they support the One China principle. Of course, One China wouldn't be a bad idea at all if that China was democratic. The Taiwanese could spread their excellent system into the mainland, much like West Germany did following German unification.
Personally, unlike my government and the UN, I regard Taiwan as the One True China, based on the size of the electorate that elected Presidents. Many more people voted for Ma Ying-jeou, President of the Republic Of China than Hu Jintao, President of People's Republic Of China and political legitimacy comes purely from elections.
But the $50 discount is a marketing decision.
Someone else posted a link that implies the crapware vendors pay them $50-$60.
Religion can ask about Gods and Angels. And science can make the angels. And if you're unlucky, Gods too...