It's actually easier to recompile existing 32-bit x86 for 32-bit ARM than for 64-bit x64, especially if Microsoft released an ARM backend for the visual C compiler. As long as Windows-for-ARM came out before too many applications transitioned to 64-bit only, it's easy to imagine it could succeed.
If they're aiming at the tablet/netbook market, then the lack of hardware drivers won't be a problem, they just need to support the on-board hardware and a few key applications (IE, Office, Flash). Ironically, if Apple's AirPrint takes off, they won't even need printer drivers. if they were able to run.NET, that would give them a lot of compatibility for free, even in-house corporate apps.
The Russian cosmonauts wore the TNK V-1, or "Penguin suit", which used elastic bands that would force the knees to bend up to the chest unless the wearer exerted force.
Let's not forget latency. On modern 3D architectures, there can be several frames between when the game engine processes user input and when the result appears on the screen. Typically the CPU is filling out a display list for frame 3 while the GPU is rendering frame 2, and the display is showing frame 1. And this is over any additional latency in input processing. At 60 fps, 3 frames is under 50 ms, while 30 fps it's 100 ms.
For an amazing display of what low latency is like, try playing something like Kaboom on an Atari connected to an analog tube TV. No buffeting, 60 fps, so only 16 ms between moving the paddle and seeing it move on screen.
For racing games, the latency has a huge impact on the user's ability to control a vehicle without entering oscillation.
Also, depending how far you hold the phone from your eyes, an iPhone game could potentially take up any amount of the visual field. 60 fps is definitely noticeable on an iPhone. Whether or not the tradeoff of reduced graphical detail versus 30 fps is worth it is a very subjective choice, which is why even on home consoles, there is no standard.
Don't forget that the primary reason for the existence of Apple Inc is to facilitate the orderly and systematic transfer of money from the bank accounts of bored yuppies to the account of Steven Jobs.
That was priceless... and probably hits a little close to home for me these days.
As a youth programming C64s in BASIC and a little ASM, part of the appeal was being able to make programs (e.g. games) that weren't too far off in complexity/polish from commercial offerings. Nobody was interested that you could fill the screen with "I LIKE BUTTS", but having a joystick controlled sprite character wandering around shooting things was kind of cool.
I wonder if a better equivalent today would be writing Javascript/HTML in a web browser, or perhaps flash. Much as when I was doing PEEK and POKE in BASIC while pro developers were doing crazy hand-coded assembly hacks to get ultimate performance, the same relationship could exist between Javascript or Actionscript versus C++. Just as cutting my teeth in BASIC helped lay a foundation to eventually learn C/C++ and become a professional software developer, this might be how the next generation will start out. For a kid, getting something interesting to happen when they code is probably the most important thing to get them hooked.
From what I recall of the iPhone/iPad restrictions would allow some sort of web development app to be created as long as it used the Webkit Javascript runtime. I'm not a web developer so I could be way off, but I suspect that even with Apple's restrictions there could be some pretty cool stuff for budding programmers on an iPad. Also, there's no reason Apple couldn't make an iPad version of Xcode that would have the same restrictions as the regular iPad SDK ($99/yr contract, only run on developer iPads, require App Store approval for public release). I think a $499 iPad plus $99/yr is still considerably cheaper in inflation-adjusted dollars than a C64 was in 1984 (>$1200 in todays dollars).
In the previous era of console games before they started supporting patches, games were treated much more like hardware in this sense because once you made the gold master and started printing copies, you couldn't change it. When you compare PC games of that era with console games, the rate of crashes and bugs was much higher on PC games. This was partly, of course because they had to run on a zillion configurations and depend on buggy device drivers, but also because the console makers had fairly rigorous submission testing requirements, and could hold up a game from shipping if it didn't meet these requirements (In the case of 1st party games, of course, there is an inherent conflict of interest there, but typically the approval process was fairly independent of the console makers' publishing arms). By contrast, PC games (like other PC software) have absolutely no oversight, so developers/publishers just do however much or little quality control that they feel they want to.
The PC approach is to let the market reward or punish software companies for how buggy their products are. Unfortunately, so much software uses various means of lock-in to prevent users from switching, that it ends up being a situation where the focus is on getting users to pay for upgrades, sometimes merely to fix things which shouldn't have been broken in the first place, and even that incentive is being removed as more software packages try to force users to constantly upgrade (e.g., make different versions non-interoperable but not sell older versions, so if you add new seats to a company you may be forced to upgrade the whole office)
For software used in high-risk situations (e.g., medical software, aeronautics, space flight), the penalty for failure is high enough that people are willing to pay (and wait) for extensive quality control. For most other software, this is not the case.
I've build a couple of internal GUI tools at work, and I see this all the time among my less-technical coworkers--they just click Ok on anything that pops up without reading it, even if it's an error message, and then come and ask me why is something not working. It's a problem of too many apps crying wolf with too many needless popups and confirmation boxes that have trained people, but it's also just the nature of most people just to keep clicking on different things semi-randomly until they get the result they wanted.
I think the only real solution is better UI design--make things work the way people expect them to, make doing the right thing seem easier and more obvious than doing the wrong thing, try to make dangerous things more buried away, etc.
Probably the only good time to use a popup box if it is a failure state where the app just can't do what is requested, where even if they close the box, they'll keep trying it again and getting the box again, eventually they might read it.
This is one of the things I prefer about OS X, in that it seems much more "quiet" with far fewer popups, flashing task tray notifications, etc. The one exception is the way the System Update icon just keeps bouncing up and down if it has a new update--it would be nice if after ten seconds it would switch to a less annoying animation, or maybe just bounce every now and then, so that if you're in the middle of reading an article or something, you don't feel like you have a two-year-old tugging your pant leg.
As an iPhone developer, and not an Apple beta/seed tester, I was not notified by Apple until 6 PM today that the new firmware was up. The AppleSeed site is not generally available to iPhone developers--we go through a different website. The updated firmware only appeared on the iPhone developer center at about 4 PM today. There were no notices or anything on the website this morning. I'm assuming others had the same experience. It was not at all obvious that the failure was due to expiration, especially since at that time there was nothing new on the developer site, and it was supposed to be a longer expiration period.
Obviously in an ideal world Apple should have released the new version *before* the expiration instead of 8 hours after, but the fact that they didn't bother to tell us is what is very irksome, so likely many people like me wasted time trying to debug the problem this morning. Lame. It would have taken someone at Apple five minutes just to post a notice to the iPod developer site saying what was going on. It's also ridiculous that there are still no developer newsgroups (as far as I know) for iPhone development. Every console maker has private newsgroups (where everyone who has access is under NDA, so you can talk about the tech), and that is always a great resource, and you can avoid making the same mistakes that others did.
I agree--Diamond Age is by far his strongest work! (I liked Zodiac too.) I think Snow Crash is my least favorite of his books--full of bad freshman psycholinguistic crap and a rehash of well-worn cyberpunk ideas. Cryptonomicon was quite enjoyable to read, and really captures what it's like to be in a small startup company, but I think Diamond Age had the most interesting ideas, and is an amazing insight into the various implications of the coming nanotechnological revolution.
I think Stephenson's biggest strength is finding unexpected settings and subcultures in which to set his novels. Who would have thought that undersea cable laying, 17th century monetary policy, or Boston harbor pollution monitoring would make such interesting reading? I am, however, irked by his almost Ayn Randian politics as well as the way he plays fast and loose with the facts, making me feel like each book should come with a companion volume of errata to make sure the reader doesn't accidentally incorporate these into one's worldview...
I think the other posters don't seem to understand the difference between NP and NP-complete. NP complete means that in addition to the answer being verifiable in polynomial time, solving *any* NP-complete problem in polynomial time would provide a polynomial-time solution to all other NP-complete problems. Factoring is in NP, but nobody has yet proven that it is NP-complete. Thus, traveling salesmen and knapsack packers won't be putting quantum computers on their wish lists...
While solving NP-complete in P time with a quantum computer sounds insane, I still find even the factoring thing pretty creepy. I suppose it is really just bringing in all the crazy truths of quantum mechanics up into the human scale where we are forced to deal with their strangeness directly. I still harbor a secret hope that someone will discover that a quantum computer needs energy proportional to 2^N (N = number of qubits), thus making them no more powerful than a classical computer. I have zero evidence to back this up, though!
noun verb noun verb verb noun preposition article noun
Mental language processor exception handling 'verb verb'...aborting. See compiler output for details.
Do you have the 2.3.7 patch to the mental language compiler? Mine gives this parsing: "Peoria cut cable causes; affects phones throughout the state."
(The Peoria chamber of commerce voted to cut funding to several charity groups (causes) that support broken cables and frayed ropes; the flood of calls in opposition to this move triggered outages in the phone system.)
I think it has to be a green felt-tip pen for that to work. Another option is to cryogenically freeze Washington, DC, and then slowly bring it back to room temperature to remove any defects in the crystalline structure from the manufacturing process.
I agree. The Germans, especially BMW, seem to be especially bad at electronics. How many older BMWs *don't* have the "check light" that always flashes because it thinks a brake light is out or something? That said, I think my favorite HVAC was in my old '91 M3--a knob for heat, three sliders for how much air do you want on the windshield, vents, and floor, a fan knob, and push buttons for AC and recirculation. Most other cars have some weird unified selector where things are needlessly interlinked--e.g, air on the windshield secretly turns on the A/C whether you want it to or not, no way to get air in all three vents, etc. BMWs seem to be an odd collection of over-engineered bulletproof bits sitting cheek-by-jowl with fussy error-prone things. I tolerate that in exchange for the brilliant handling and the fact that they seem to make the most fuel-efficient RWD sedans at the moment.
I think the growing proliferation of menu-based interfaces is a huge problem--99% of them are ad-hoc GUI's designed by people with no talent for usability, often running on under-powered CPUs (or with poorly written code) that makes operation sluggish and latent, where the user has to adapt his or her rhythm to the machine. The ideal is for the computer to be 'invisible'. I inherited a manual SLR camera from the 70s--the only evidence of electronics was the little needle for the light meter; it felt completely mechanical in every other way, with nice satisfying clicks on the wheels. One time I opened it up, however, and was surprised to see it stuffed with transistors. In addition to the light meter, the shutter was actually electronic. However, this was completely hidden from the user--the electronics were just doing their job invisibly. I wish more things were built this way.
My understanding is that OHC engines used to be more of a win, but modern materials have allowed pushrod engines to regain much the gap, plus the fact that pushrod engines can be more compact and have fewer parts that can break. There are even pushrod engines that can do 8000 RPM, others that use variable valve timing. Not to mention the powerful Corvette can still get 29 EPA Hwy, while many of its upscale competitors with "high feature" DOHC engines and comparable weight and power get worse fuel economy. I also think the European displacement regulations have caused many makers to focus on displacement over efficiency. Small displacement, high-power turbo engines get horrible gas mileage, especially if you ever use the throttle pedal.
That being said, I find driving a high-revving Honda more satisfying than a low-revving GM stump puller, but that's more aesthetics than logic. And car fanboys will always pick some random differentiating factor to trumpet why their favored type of car is the best, even though in reality any number of designs have been both well- and poorly-executed at different times.
The 'Captain Crunch' scene 'The Cryptonomicon' just about put me off the rest of the novel, and did keep me away from his books written since then.
I actually loved that part. I also loved the totally random digressions about whales and whaling in Moby Dick. But I also thought Diamond Age had a decent ending, and Snowcrash is the book by Stephenson I like the least, so I guess everyone seems to have a different opinion about him. My biggest beef with Stephenson, besides all the completely bullshit pseudolinguistics in Snowcrash, is just how he continually gets facts wrong in his books, and not just to advance the story, so I feel like I'm getting polluted with misinformation whenever I read his books. Maybe he could ship his books with a debriefing pamphlet that would correct all the mistakes that readers would be inclined to believe were true.
I'm not very optimistic about this miniseries, though, even with Stephenson in the credits, seeing how Gibson wrote the screenplay for the piss-poor movie adaption of Johnny Mnemonic. The potential is there, though, because Diamond Age really created a unique world, both in the nanotechnology and in the vision of culture in a world where nations have become obsolete, and a world that might make a better transition to live action film than cyberspace or the metaverse.
The PS2 doesn't have a GPU, just a rasterizer (the GS). The "bigger" vector unit (VU1) is pretty much set up to be used as a conduit between system memory and the GS, so you end up using it as a GPU. So VU1 typically spends its time doing vertex processing, doing transformation, lighting, skinning, and clipping. Because you're writing microcode and handling the memory transfers yourself, it is much more laborious than writing vertex shaders for Xbox or PC, but you also have the flexibility to other things such as dynamic tesselation or higher-order surfaces. It's pretty easy to get good usage out of the VU1--if you've load-balanced your game properly, the VU1 will be crunching vertices for the entire frame, and then immediately start crunching more after the flip.
However, VU0 is much more difficult to utilize--if you look at PA (performance analyzer) scans for many PS2 games, VU0 is idle most of the time. This is partly due to lazy programmers, but also just because the VU0 is very hard to utilize--it has less memory than VU1, and more importantly, unlike the VU1, cannot be easily made to run independently of the main CPU. Therefore, it's hard to use VU0 without lots of handholding by the EE core, and there aren't that many tasks that are well suited for the VU0.
So any normal program will get good usage out of EE and VU1, and neglect VU0. Also, because VU1 is used for vertex processing, there is generally a small amount of code (only a few 'shaders') and a high 'loop count' per shader, which gives a lot of bang for the buck.
On the PS3, however, there already exists a GPU--therefore the thing thats easy to do in parallel--vertex-processing--is already done by a different chip. That leaves everything else, which typically has less of an 'inner loop' form, which means the cost in programmer time becomes much higher. A large chunk of the other game code tends to be your typical branching, cache-smashing, non-math oriented crap that really wants a more PC-style CPU. It's certainly fun to think of ways of making code to run on an SPE, but it's probably not going to make your users as happy as improving AI, making cool effects, reducing bugs, etc.
The PS2 certainly has a high learning curve do to the fact that you basically have to write driver-level software yourself, as opposed to the other consoles which shipped with graphics libraries, and it is a kooky architecture, but that's more of a 'one time' cost you bear on your first PS2 project, and only affects the low-level kernel of your game, which doesn't change as much. You spend some months pounding your head against a desk, but eventually it comes together and you don't have to revisit it that much. I think it is the fact that the 'rest' of the code (usually written by less than hardcore programmers, and for constantly shifting requirements) has to be radically reworked to exploit the PS3 is the big problem.
I wonder if the PS3 will really force more developers to switch from internal engines to licensing commercial engines.
Medicine is most two minutes of questions, two minutes of poking, a minute to write the prescription, then a lifetime of paperwork.
Police work is mostly pulling over bad drivers, arresting the drunk ones, then a lifetime of paperwork.
Lawyering is a lifetime of paperwork.
Flying, even military flying, is mostly just sitting there, staring at the horizon, then checking the instruments occasionally.
Actually, when I was taking flying lessons, I remember there was a lot of paperwork for that too (flight plans, calculating fuel consumption, etc). But yeah, it was actually mostly pretty dull (except landings were fun, especially in a crosswind), and yet stressful, having to be constantly vigilant for something dangerous happening. I decided riding a motorcycle is a better fun/risk ratio, as well as being far cheaper.
That's interesting that there are iPod "customizers". According to this test, the shuffle (1G) is better able to reproduce square waves due to using push-pull transistors instead of capacitors--this is supposed to translate to better bass reproduction, IIRC.
However, since most MP3 player users use lossy compression, the default headphones (if they haven't stepped on them yet) or else a FM transmitter for their car, aren't trained to hear subtle nuances, and listen to music that's been electronically squashed and modified to sound "good" on substandard equipment, the phrase "good enough" probably applies to any half-decent MP3 player for the vast majority of users. They definitely sound far better than the 3rd generation dubbed casette tapes I often listened to in high school, of course rewinding tapes by hand with a pencil in class to save on walkman batteries...
I use a 1G shuffle, but only when I go to the gym, so I'm having to compete with whatever's playing on the radio and the thwap-thwap of the headphone cord tugging on my ear, so it's hardly an audiophile listening experience regardless of the quality of the output stage... I suppose for people who listen to lossless classical music on their iPods in anechoic chambers probably have different needs than I do.
As we progress through time, programmers will simply use higher and higher level languages.
I think there is a continuum that spans making a higher level language to solve a problem, at one extreme, and cobbling together various modules or libraries to solve a problem, on the other. Implementing a solution to a problem as a part of a language is much harder to do well, but it is then easier for the end user to use because as part of the high level language it will interoperate with other parts of the language. Creating some sort of library or app to solve a particular instance of a problem is much easier to do, but then the work of an end user who wants to incorporate it into their application is much harder, and the end result may end up being more ungainly.
Solutions that are widely needed (e.g., network sockets, encryption, matrix algebra, etc) are more likely to be "worth it" for someone to build into a high level language. Tasks that are more specialized are less likely. Tasks that are easy to solve will probably be solved many times. Everyone has to strike their own balance between code reuse and the overhead of adapting existing code which may contain bugs, or at least limitations, unwanted dependencies, and inefficiencies in speed or memory. Sometimes it ends up being easier in the long run to "roll your own", because then you really understand the topic, you will be in a better place for debugging it, and your solution can be optimal for your situation.
Embedded and performance-critical applications (or games) are probably going to do more "rolling your own", or else use a prebuilt framework that is fairly specialized (e.g., Unreal engine) and thus somewhat optimal.
The problem with frameworks, of course, is that the framework wants to dictate the structure of your code, so trying to use two different frameworks that weren't designed to interoperate can lead to a lot of glue code. Designing a really good framework architecture is a very hard problem, so most frameworks are not "really good". Also, using a framework has the disadvantage of making your code locked in to it, and even if it is open source, it might be generally abandoned, so supporting it yourself may not be feasible. This is of course also true of many of the higher level languages. It will also depend on how long the expected lifetime of the code you write is, how many engineers will have to work on it, and what the turnover rate is for engineers.
Often the choice between using a library or making your own is just an educated guess, and you can get screwed either way. The only constant is that over time, the ability of one person to really understand what is going on in the running of a program is diminished...
The end of the article mentioned some Moore's law equivalent for LEDs that would likely reduce the power consumption and heat output to reasonable levels by the time this technology became ready for consumer applications. However, if they really meant it was doubling light output per watt every 12-18 months, at some point that would become a perpetual motion machine, so I'm not sure I really understood this point. IANAEE.
At first I thought it said Opera Bowser which made me think they had some singing game at the Wii launch.
If Nintendo picked opera as the genre for the first Wii singing game, and chose Bowser as the main character, that would be freakin' hilarious.
I can see it now, Bowser as the statue of il Commendatore, dragging the unrepentant Don Giovanni, played of course by Mario who's had his way with one too many Mushroom retainer, off to hell...
I was misinformed, then, or had gotten apples and oranges mixed up--the classic error. I should have remembered "yabloko" (wow, that looks really weird in Roman characters) since I at one point took a little Russian a million years ago. Oh well... thanks for setting the record straight!
I'm not quite sure what you mean by "mitigate their single-threaded nature", but if you run 8 single-threaded processes on an 8 core machine on any modern OS, the OS will end up spreading the workload across all 8 processors without having to do anything special. Normally, the OS will move threads from core to core as it sees fit, depending on the whims of the thread scheduler. However, you can override this (e.g., in XP by using the task manager and setting the processor affinity mask). The main reason to do this is for processes that have special synchronization bugs, but this shouldn't be true for a joe-blow single threaded process.
So while multiple-core machines will not perform single-threaded tasks faster than a single-core machine of the same speed, but if you are running multiple applications you can still saturate all the cores even if all your apps are single-threaded, as long as all the apps you are running have a high ratio of CPU work to disk activity/OS calls (e.g., video compression or encryption or calculating pi, not running MS Word or reindexing your mp3 collection). In practice, this won't happen that often, especially with 4 or 8 cores.
He did, however, seem to have a big thing for 4:3 aspect ratio, regardless of how they were released in theaters, which is what's causing all the flap about his DVDs...
It seems to have been Kubrick's preference for his films to be shown in the 4:3 or "full frame" aspect ratio, because, according to his long-standing personal assistant Leon Vitali, that was the way he composed them through the camera viewfinder and if it were technically still possible to do so, he would have liked them to be shown full frame in cinemas as well. As Vitali said in a recent interview (2): "The thing about Stanley, he was a photographer that's how he started. He had a still photographer's eye. So when he composed a picture through the camera, he was setting up for what he saw through the camera - the full picture. That was very important to him. It really was. It was an instinct that never ever left him. [...] He did not like 1.85:1. You lose 27% of the picture, Stanley was a purist. This was one of the ways it was manifested."
Slashdot Mirror
It's actually easier to recompile existing 32-bit x86 for 32-bit ARM than for 64-bit x64, especially if Microsoft released an ARM backend for the visual C compiler. As long as Windows-for-ARM came out before too many applications transitioned to 64-bit only, it's easy to imagine it could succeed. .NET, that would give them a lot of compatibility for free, even in-house corporate apps.
If they're aiming at the tablet/netbook market, then the lack of hardware drivers won't be a problem, they just need to support the on-board hardware and a few key applications (IE, Office, Flash). Ironically, if Apple's AirPrint takes off, they won't even need printer drivers. if they were able to run
The Russian cosmonauts wore the TNK V-1, or "Penguin suit", which used elastic bands that would force the knees to bend up to the chest unless the wearer exerted force.
Let's not forget latency. On modern 3D architectures, there can be several frames between when the game engine processes user input and when the result appears on the screen. Typically the CPU is filling out a display list for frame 3 while the GPU is rendering frame 2, and the display is showing frame 1. And this is over any additional latency in input processing. At 60 fps, 3 frames is under 50 ms, while 30 fps it's 100 ms. For an amazing display of what low latency is like, try playing something like Kaboom on an Atari connected to an analog tube TV. No buffeting, 60 fps, so only 16 ms between moving the paddle and seeing it move on screen. For racing games, the latency has a huge impact on the user's ability to control a vehicle without entering oscillation. Also, depending how far you hold the phone from your eyes, an iPhone game could potentially take up any amount of the visual field. 60 fps is definitely noticeable on an iPhone. Whether or not the tradeoff of reduced graphical detail versus 30 fps is worth it is a very subjective choice, which is why even on home consoles, there is no standard.
That was priceless... and probably hits a little close to home for me these days.
As a youth programming C64s in BASIC and a little ASM, part of the appeal was being able to make programs (e.g. games) that weren't too far off in complexity/polish from commercial offerings. Nobody was interested that you could fill the screen with "I LIKE BUTTS", but having a joystick controlled sprite character wandering around shooting things was kind of cool.
I wonder if a better equivalent today would be writing Javascript/HTML in a web browser, or perhaps flash. Much as when I was doing PEEK and POKE in BASIC while pro developers were doing crazy hand-coded assembly hacks to get ultimate performance, the same relationship could exist between Javascript or Actionscript versus C++. Just as cutting my teeth in BASIC helped lay a foundation to eventually learn C/C++ and become a professional software developer, this might be how the next generation will start out. For a kid, getting something interesting to happen when they code is probably the most important thing to get them hooked.
From what I recall of the iPhone/iPad restrictions would allow some sort of web development app to be created as long as it used the Webkit Javascript runtime. I'm not a web developer so I could be way off, but I suspect that even with Apple's restrictions there could be some pretty cool stuff for budding programmers on an iPad. Also, there's no reason Apple couldn't make an iPad version of Xcode that would have the same restrictions as the regular iPad SDK ($99/yr contract, only run on developer iPads, require App Store approval for public release). I think a $499 iPad plus $99/yr is still considerably cheaper in inflation-adjusted dollars than a C64 was in 1984 (>$1200 in todays dollars).
In the previous era of console games before they started supporting patches, games were treated much more like hardware in this sense because once you made the gold master and started printing copies, you couldn't change it. When you compare PC games of that era with console games, the rate of crashes and bugs was much higher on PC games. This was partly, of course because they had to run on a zillion configurations and depend on buggy device drivers, but also because the console makers had fairly rigorous submission testing requirements, and could hold up a game from shipping if it didn't meet these requirements (In the case of 1st party games, of course, there is an inherent conflict of interest there, but typically the approval process was fairly independent of the console makers' publishing arms). By contrast, PC games (like other PC software) have absolutely no oversight, so developers/publishers just do however much or little quality control that they feel they want to.
The PC approach is to let the market reward or punish software companies for how buggy their products are. Unfortunately, so much software uses various means of lock-in to prevent users from switching, that it ends up being a situation where the focus is on getting users to pay for upgrades, sometimes merely to fix things which shouldn't have been broken in the first place, and even that incentive is being removed as more software packages try to force users to constantly upgrade (e.g., make different versions non-interoperable but not sell older versions, so if you add new seats to a company you may be forced to upgrade the whole office)
For software used in high-risk situations (e.g., medical software, aeronautics, space flight), the penalty for failure is high enough that people are willing to pay (and wait) for extensive quality control. For most other software, this is not the case.
I've build a couple of internal GUI tools at work, and I see this all the time among my less-technical coworkers--they just click Ok on anything that pops up without reading it, even if it's an error message, and then come and ask me why is something not working. It's a problem of too many apps crying wolf with too many needless popups and confirmation boxes that have trained people, but it's also just the nature of most people just to keep clicking on different things semi-randomly until they get the result they wanted.
I think the only real solution is better UI design--make things work the way people expect them to, make doing the right thing seem easier and more obvious than doing the wrong thing, try to make dangerous things more buried away, etc.
Probably the only good time to use a popup box if it is a failure state where the app just can't do what is requested, where even if they close the box, they'll keep trying it again and getting the box again, eventually they might read it.
This is one of the things I prefer about OS X, in that it seems much more "quiet" with far fewer popups, flashing task tray notifications, etc. The one exception is the way the System Update icon just keeps bouncing up and down if it has a new update--it would be nice if after ten seconds it would switch to a less annoying animation, or maybe just bounce every now and then, so that if you're in the middle of reading an article or something, you don't feel like you have a two-year-old tugging your pant leg.
As an iPhone developer, and not an Apple beta/seed tester, I was not notified by Apple until 6 PM today that the new firmware was up. The AppleSeed site is not generally available to iPhone developers--we go through a different website. The updated firmware only appeared on the iPhone developer center at about 4 PM today. There were no notices or anything on the website this morning. I'm assuming others had the same experience. It was not at all obvious that the failure was due to expiration, especially since at that time there was nothing new on the developer site, and it was supposed to be a longer expiration period.
Obviously in an ideal world Apple should have released the new version *before* the expiration instead of 8 hours after, but the fact that they didn't bother to tell us is what is very irksome, so likely many people like me wasted time trying to debug the problem this morning. Lame. It would have taken someone at Apple five minutes just to post a notice to the iPod developer site saying what was going on. It's also ridiculous that there are still no developer newsgroups (as far as I know) for iPhone development. Every console maker has private newsgroups (where everyone who has access is under NDA, so you can talk about the tech), and that is always a great resource, and you can avoid making the same mistakes that others did.
I think Stephenson's biggest strength is finding unexpected settings and subcultures in which to set his novels. Who would have thought that undersea cable laying, 17th century monetary policy, or Boston harbor pollution monitoring would make such interesting reading? I am, however, irked by his almost Ayn Randian politics as well as the way he plays fast and loose with the facts, making me feel like each book should come with a companion volume of errata to make sure the reader doesn't accidentally incorporate these into one's worldview...
While solving NP-complete in P time with a quantum computer sounds insane, I still find even the factoring thing pretty creepy. I suppose it is really just bringing in all the crazy truths of quantum mechanics up into the human scale where we are forced to deal with their strangeness directly. I still harbor a secret hope that someone will discover that a quantum computer needs energy proportional to 2^N (N = number of qubits), thus making them no more powerful than a classical computer. I have zero evidence to back this up, though!
(The Peoria chamber of commerce voted to cut funding to several charity groups (causes) that support broken cables and frayed ropes; the flood of calls in opposition to this move triggered outages in the phone system.)
I think it has to be a green felt-tip pen for that to work. Another option is to cryogenically freeze Washington, DC, and then slowly bring it back to room temperature to remove any defects in the crystalline structure from the manufacturing process.
I think the growing proliferation of menu-based interfaces is a huge problem--99% of them are ad-hoc GUI's designed by people with no talent for usability, often running on under-powered CPUs (or with poorly written code) that makes operation sluggish and latent, where the user has to adapt his or her rhythm to the machine. The ideal is for the computer to be 'invisible'. I inherited a manual SLR camera from the 70s--the only evidence of electronics was the little needle for the light meter; it felt completely mechanical in every other way, with nice satisfying clicks on the wheels. One time I opened it up, however, and was surprised to see it stuffed with transistors. In addition to the light meter, the shutter was actually electronic. However, this was completely hidden from the user--the electronics were just doing their job invisibly. I wish more things were built this way.
My understanding is that OHC engines used to be more of a win, but modern materials have allowed pushrod engines to regain much the gap, plus the fact that pushrod engines can be more compact and have fewer parts that can break. There are even pushrod engines that can do 8000 RPM, others that use variable valve timing. Not to mention the powerful Corvette can still get 29 EPA Hwy, while many of its upscale competitors with "high feature" DOHC engines and comparable weight and power get worse fuel economy. I also think the European displacement regulations have caused many makers to focus on displacement over efficiency. Small displacement, high-power turbo engines get horrible gas mileage, especially if you ever use the throttle pedal.
That being said, I find driving a high-revving Honda more satisfying than a low-revving GM stump puller, but that's more aesthetics than logic. And car fanboys will always pick some random differentiating factor to trumpet why their favored type of car is the best, even though in reality any number of designs have been both well- and poorly-executed at different times.
I'm not very optimistic about this miniseries, though, even with Stephenson in the credits, seeing how Gibson wrote the screenplay for the piss-poor movie adaption of Johnny Mnemonic. The potential is there, though, because Diamond Age really created a unique world, both in the nanotechnology and in the vision of culture in a world where nations have become obsolete, and a world that might make a better transition to live action film than cyberspace or the metaverse.
However, VU0 is much more difficult to utilize--if you look at PA (performance analyzer) scans for many PS2 games, VU0 is idle most of the time. This is partly due to lazy programmers, but also just because the VU0 is very hard to utilize--it has less memory than VU1, and more importantly, unlike the VU1, cannot be easily made to run independently of the main CPU. Therefore, it's hard to use VU0 without lots of handholding by the EE core, and there aren't that many tasks that are well suited for the VU0.
So any normal program will get good usage out of EE and VU1, and neglect VU0. Also, because VU1 is used for vertex processing, there is generally a small amount of code (only a few 'shaders') and a high 'loop count' per shader, which gives a lot of bang for the buck.
On the PS3, however, there already exists a GPU--therefore the thing thats easy to do in parallel--vertex-processing--is already done by a different chip. That leaves everything else, which typically has less of an 'inner loop' form, which means the cost in programmer time becomes much higher. A large chunk of the other game code tends to be your typical branching, cache-smashing, non-math oriented crap that really wants a more PC-style CPU. It's certainly fun to think of ways of making code to run on an SPE, but it's probably not going to make your users as happy as improving AI, making cool effects, reducing bugs, etc.
The PS2 certainly has a high learning curve do to the fact that you basically have to write driver-level software yourself, as opposed to the other consoles which shipped with graphics libraries, and it is a kooky architecture, but that's more of a 'one time' cost you bear on your first PS2 project, and only affects the low-level kernel of your game, which doesn't change as much. You spend some months pounding your head against a desk, but eventually it comes together and you don't have to revisit it that much. I think it is the fact that the 'rest' of the code (usually written by less than hardcore programmers, and for constantly shifting requirements) has to be radically reworked to exploit the PS3 is the big problem.
I wonder if the PS3 will really force more developers to switch from internal engines to licensing commercial engines.
However, since most MP3 player users use lossy compression, the default headphones (if they haven't stepped on them yet) or else a FM transmitter for their car, aren't trained to hear subtle nuances, and listen to music that's been electronically squashed and modified to sound "good" on substandard equipment, the phrase "good enough" probably applies to any half-decent MP3 player for the vast majority of users. They definitely sound far better than the 3rd generation dubbed casette tapes I often listened to in high school, of course rewinding tapes by hand with a pencil in class to save on walkman batteries...
I use a 1G shuffle, but only when I go to the gym, so I'm having to compete with whatever's playing on the radio and the thwap-thwap of the headphone cord tugging on my ear, so it's hardly an audiophile listening experience regardless of the quality of the output stage... I suppose for people who listen to lossless classical music on their iPods in anechoic chambers probably have different needs than I do.
Solutions that are widely needed (e.g., network sockets, encryption, matrix algebra, etc) are more likely to be "worth it" for someone to build into a high level language. Tasks that are more specialized are less likely. Tasks that are easy to solve will probably be solved many times. Everyone has to strike their own balance between code reuse and the overhead of adapting existing code which may contain bugs, or at least limitations, unwanted dependencies, and inefficiencies in speed or memory. Sometimes it ends up being easier in the long run to "roll your own", because then you really understand the topic, you will be in a better place for debugging it, and your solution can be optimal for your situation.
Embedded and performance-critical applications (or games) are probably going to do more "rolling your own", or else use a prebuilt framework that is fairly specialized (e.g., Unreal engine) and thus somewhat optimal.
The problem with frameworks, of course, is that the framework wants to dictate the structure of your code, so trying to use two different frameworks that weren't designed to interoperate can lead to a lot of glue code. Designing a really good framework architecture is a very hard problem, so most frameworks are not "really good". Also, using a framework has the disadvantage of making your code locked in to it, and even if it is open source, it might be generally abandoned, so supporting it yourself may not be feasible. This is of course also true of many of the higher level languages. It will also depend on how long the expected lifetime of the code you write is, how many engineers will have to work on it, and what the turnover rate is for engineers.
Often the choice between using a library or making your own is just an educated guess, and you can get screwed either way. The only constant is that over time, the ability of one person to really understand what is going on in the running of a program is diminished...
The end of the article mentioned some Moore's law equivalent for LEDs that would likely reduce the power consumption and heat output to reasonable levels by the time this technology became ready for consumer applications. However, if they really meant it was doubling light output per watt every 12-18 months, at some point that would become a perpetual motion machine, so I'm not sure I really understood this point. IANAEE.
Don't forget the echoing footsteps, the whirring elevator, or of course "AIIIIIIIIIGHHHhhhhh...."
I can see it now, Bowser as the statue of il Commendatore, dragging the unrepentant Don Giovanni, played of course by Mario who's had his way with one too many Mushroom retainer, off to hell...
I was misinformed, then, or had gotten apples and oranges mixed up--the classic error. I should have remembered "yabloko" (wow, that looks really weird in Roman characters) since I at one point took a little Russian a million years ago. Oh well... thanks for setting the record straight!
How do you like them napples?
So while multiple-core machines will not perform single-threaded tasks faster than a single-core machine of the same speed, but if you are running multiple applications you can still saturate all the cores even if all your apps are single-threaded, as long as all the apps you are running have a high ratio of CPU work to disk activity/OS calls (e.g., video compression or encryption or calculating pi, not running MS Word or reindexing your mp3 collection). In practice, this won't happen that often, especially with 4 or 8 cores.