-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 31 May 2011 19:51, Otto Moerbeek <o...@drijf.net> wrote: > On Tue, May 31, 2011 at 07:23:46PM +0000, Christian Weisgerber wrote: > >> Marc Espie <es...@nerim.net> wrote: >> >> > Not surprisingly, a lot of software that claims to be 64 bits- ready isn't. >> > This touches all web navigators, most jit engines, and probably lots more >> > of software (our ports tree version of gnu-grep, for instance). >> >> I don't think a lot suffers from it, but some prominent cases do. >> Three problems have been mentioned: >> >> (1) Truncation of pointers to 32 bits. Our malloc(3) has returned >> addresses >4 GB for some time now on amd64 (and before that on >> other archs like alpha), so I don't expect any new fallout >> there. I seem to remember that we had a rash of ports fixes >> back when this first happened on amd64. >> >> (2) Tagged pointers. A tagged pointer is when you "know" that not >> all the bits in a pointer are used to generate an address and >> you squeeze some other data into the "spare" bits. This blocks >> newer versions of Firefox on sparc64. Mozilla's new JavaScript >> engine uses tagged pointers and those "unused" address bits on >> x86 are actually used on sparc64. >> >> (3) The expectation that, no matter what their absolute address, the >> relative offsets between all your pieces of data fit into 32 >> bits, i.e., all data is within a 4 GB window. That sounds like >> a bizarre requirement, but apparently some JIT engines are >> "optimized" to rely on this. These are the cases that break >> with new vmmap. > > The smart programmers "solve" number (3) by allocating 2G of memory in > advance to store their jit compiled code, so their code can use 32 bit > relative offsets. They say, hey, it's only virtual memory, so it > doesn't take much resources. Often that is true and it seems a smart > idea, but it has the consequence that you lose randomization and > protected memory with page size granularity. Or you are forced to do > all the memory mangement on your own, basically rewriting the memory > management part of the OS in your browser. Suddenly the smart idea > does not sound so smart anymore. > > -Otto > >> >> But, hey, 64-bit desktop machines have only been around since 1993 >> or so, and I guess some of the Mozilla programmers weren't born yet >> when we watched oh-so-clever tagged pointer use blow up at, say, >> the Motorola 68000 to 68020 transition some 25 years ago. >> >> -- >> Christian "naddy" Weisgerber na...@mips.inka.de
Great. Just absolutely fantastic. These people come up with more and more resource intensive ways of doing the same old computing tasks we've been able to do for a decade or more so that the rest of us have to buy newer, fancier, more expensive machines to do the same things we've been able to do for a decade or more. Of course, for a significant portion of the population, "high performance computing" means "a computer I can access from the convenience of my home, rather than having to spend an hour walking to the library and an hour walking back just so I can sign up and wait an hour or two for the chance to use it for 30 minutes and then rush to do the important things, like fill out job applications for blue collar positions for companies who can't be bothered to take paper applications or check to see if I have any important business e-mail from people who are too annoying to send old-fashioned snail mail". For a lot of people, a computer is like a glorified communications device and typewriter. Except a whole lot more expensive. Hence the usefulness of old computers. When everyone else is rushing to get the latest and greatest, it's often possible to get a sufficiently aged computer for very cheap or even free. Of course, the big corporations don't make as much money if people do that. Which probably explains at least some of the bad software. If we make this new software resource intensive and inefficient enough, then people will have to buy newer, more expensive computers in order to run it. But the older software works just fine? Then we'll just have to stop releasing security patches for it. Good thing we didn't write solid, secure code to begin with. Now the hackers (or crackers, or whatever the correct term is) out there will force the laggards to upgrade to newer more expensive hardware than runs newer more expensive more inefficient software than we still support, and the computer industry goes on! Yay hackers! Well, I can understand that line from corporations looking to earn money, but it makes less sense to hear it from not-for-profits like Linux or Firefox. They say we should all upgrade our computers after three years, five years if we want to push it. What they seem to have missed is that it is a recession. A really bad recession. Goodbye art shows! Hello tent cities! Welcome to the most dangerous town in California: stop laying off cops! And that sort of thing.... In other words, lots of people have better things to do with their money than follow the mainstream line about upgrading their hardware. Things like trying to pay the rent, heat the home at least enough to stop the pipes bursting in the winter (could be hard if there's a gas shortage), or, at the very least, pay the grocery bill. Oh, and medical bills. Illnesses and disabilities don't care about recessions. They'll hurt you whether you can afford treatment or not, and of course, insurance companies are even more useless during recessions than they normally are, if there's any room for them to be more useless... so if you have a serious condition, running the latest version of Microsoft Office probably isn't on top of your To-Do list. There's no reason a Pentium II or an m68k can't browse the internet, use e-mail, file online applications, and do word processing. Then can even not-so-important things like play music and videos and a few games that don't go overboard on the graphics. They could when they first came out. Oh, wait, the internet isn't the same as it was when they first came out. Really, much burdensome code does a website need just to give me basic e-mail access or display a text article? I shouldn't even need JavaScript to read a text article. Webmail and text articles aren't state-of- the-art-technology, and they really don't need fancy, state-of-the- art-of-inefficiency code. I really think Firebird was the height of graphical internet browsing. Konqueror 3.x isn't bad either. Of course, these days, to access most of the web without too much JavaScript pain, you either need Firefox + NoScript or something similar, or one JavaScript enabled browser and one JavaScript-free one. And don't even get me started on Flash. I really, really appreciate OpenBSD's excellent support for older hardware. It's quite refreshing to use a modern operating system that takes support for computers like this here powerpc iBook G3 seriously. NetBSD too. (NetBSD's installer did not work as well as OpenBSD's, but they made up for it with really good documentation. Don't get me started on Linux. Debian Linux's installer was a disgrace.) Of course, Firefox is still driving me nuts, but I suppose it or its competitors are going to do that no matter what operating system I run. The whole internet is driving me nuts. Too much JavaScript for silly features! And don't even get me started on Flash websites. I can understand a flash application or a flash video, but your entire menu and text content don't need to be embedded in flash! Thanks for letting us know just how horrible many applications' efficiency on amd64 is. It certainly helps make me feel less left behind here on my 900mHz powerpc. It was a state-of-the-art computer as recently as 2003. No reason it shouldn't be able to do loads of awesome things. I say leave the upgrade fever to the people who actually care about things like fancy 3D graphics games or state-of-the-art movie editing or things like that which actually should be resource intensive. Most people can get on fine without. -----BEGIN PGP SIGNATURE----- Charset: UTF8 Note: This signature can be verified at https://www.hushtools.com/verify Version: Hush 3.0 wsBcBAEBAgAGBQJN5cMbAAoJEKlMTST7VF+oqU0H/R5OXpsHKP1SIREDvLt6kzMHu62z YFlB4Ojm0b8bk3DywISEEUa0dADiwjiQNzI4DC5Jr/wEyt8tkZIv0aupy9uipGq2dthn QqgQUevwnXrxG7mihcV/OZSn75Zxb3bypLTeDb0qQ4fwsCQs6IQ3qlA670rfyfDqDeOt +aKqXAiaEGmnMhjRKZWk2PS+QhDiq2PYAhwfh/oCwfYa8ZzbUwnOu+S09AjtS04Q8457 6qQzDoI8T1x51MDvGipNwBZZZMC5O01LOWAoWOdE/0jkQ8kfSr9lec3cLm9YIyqCaN2g 3PiHjiJMnefKgIZO0zEM9mJds4vyFjnVfCNrDtJPI5I= =lvx6 -----END PGP SIGNATURE-----