Well, at least 500 million of them are. 30% of Indians consume meat regularly (for some self-identified definition of 'regularly'). Somewhere between 20-42% (depending on whose study you trust) Indians are vegetarian. There are, however, almost certainly more vegetarians in India than there are people in the USA.
It's not bullshit. If you ate nothing but salad every day, you're not going to get the same nutrition that you would from eating a lot of meats.
False dichotomy. If you ate nothing but steak every day then you'd also be dead in short order. If you eat a moderately balanced diet then you'll be fine. For a vegetarian, the big issue is making sure that you get the full set of amino acids. If you eat cheese, that's done. If you're a vegan it's a bit harder, but eating both rice and lentils will give you them all, as will several other well-known pairs. You have to have a pretty monotonous diet as a vegetarian to avoid getting all of the nutrients that you need.
Mind you, the same is true for omnivores, and in the USA a lot of them seem to manage to suffer from malnutrition (and obesity at the same time), so perhaps it is too much to expect...
True, although I've found that attempting to rewrite a system is a good way of determining how complex it really needs to be. In the end, it doesn't matter if you actually use the rewrite, or even if you finish it. Once you've spent a bit of time on it, you have a much better idea of how the original system should have been designed, and that can help refactoring immensely.
That depends on whether it actually needs to be that complex. Implementing a project that is 200KLoC is not the same as implementing something that is functionally equivalent to an existing codebase that has grown to 200KLoC. If the project is as described, I wouldn't be surprised if it could be implemented in under 20KLoC, possibly less if there are some existing libraries that can be used.
It's a very old saying that the first 90% of the project takes the first 90% of the time, and the remaining 10% takes the other 90%. When dealing with old codebases, however, 90% is often good enough. I've seen programs that were written with one set of requirements and then those changed. They ended up with massive abstraction layers to support multiple back ends. Then 5-10 years later they were using the abstraction layer to abstract a single implementation. And the abstraction layer wasn't a good fit for the front or the back. A rewrite can just omit the abstraction layer entirely, significantly reducing complexity. Sometimes this makes the code harder to refactor in the future, but often it's easier to then insert a new abstraction layer than to try to adapt an existing one.
Actually, you've hit the major problem right on the head. You're not going to want to transmit from close to the stock exchange, you're going to want to receive close to the stock exchange so that you can forward your instructions directly into their computer system. The problem is (in the absence of commercially available neutronium), the neutrino comms equipment is going to be bigger than the computer running your trading algorithms. In which case, you may as well just move it there instead of installing the relay.
Neutrino comms for HFT is solving a problem that doesn't exist. The problem it would solve is doing HFT from a long way away from the exchange, but no one actually does that...
How would that work? Valve isn't going to be writing drivers, they're just going to be bundling third-party ones, and Ubuntu already bundles all of the ones that have redistribution rights. This entire story is moot. There are two possible reasons for Valve to do a Linux port. The first is to appeal to existing Linux users. They won't do this by saying 'we support your OS. Well, actually, we don't, we support a similar OS, but it's like your OS and you can install it for free!' The second is to make it cheaper for companies to make Steam-powered consoles. I suspect this is more likely - I wouldn't be surprised if we see cheap Chinese-made consoles hitting the market running a basic Linux install with Steam set to launch full screen on boot and used as the application manager / installer. In this case, it's also pointless to ship their own distro: OEMs will want to use their own and will strip out everything except the drivers their hardware needs, basic libraries, X, and Steam.
The way drivers work in Linux and BSD, aren't accommodating to "binary blobs" since they can be broken with even minor updates
FreeBSD guarantees a stable KBI across minor revisions, and we require strong justifications for breaking it between minor revisions (which means that often kernel modules will work between major revisions, we just don't guarantee it). After 10.0, we're looking at providing longer-term support for a subset of KPIs.
It's not just killing products that suck, it's killing feature creep. The counter example from Microsoft is the team of people responsible for the shutdown menu in Vista. A total UI clusterfuck. That sort of thing would never have happened at a company like Apple or Palm back in the day because they had someone who would be using the prototypes from the start who was sufficiently influential to say 'this sucks, fix it'. Focus groups are really good at generating products that have all of the features that everyone wants, but don't expose them in a way that anyone wants. Lots of people complained about the early iPods because they lacked a load of features that Steve Jobs didn't think were important. The features that he did were there and worked well (apparently he doesn't listen to much classical music: the display didn't get the ability to show the composer until the fourth generation), and that was enough to get a lot of sales. It's not enough to completely dominate a market - Apple has only ever done that when the market is sufficiently young that there are no other companies catering to other niches - but you can probably do that if you design different product lines for individuals in different demographics.
Apple had the same advantage that Palm had before them: someone willing to say 'no, this sucks' and be listened to. There's a story about the first iteration of the Palm Pilot, where the CEO saw it and decided it was too big. He got a block of balsa wood cut that was just small enough to fit in his shirt pocket and gave it to the product development team with an edict that the final version must be no bigger than that. Without someone like that, they'd have ended up with something too big to be conveniently carried. Steve Jobs had the same role at Apple: it wasn't producing great products, or products that could not be improved, it was to produce products that were definitely useful. As long as 'how Steve Jobs would use it' and 'how a normal human would use it' weren't too far apart, it worked well. Sometimes, it didn't - there were a few flops along the way - but a product designed for a specific user is far more likely to be useable in general than one designed for some set of focus-group set of requirements plus any features that engineers thought they could sneak in.
His graph shows the Napoleonic wars and World War II as points of relatively low violence, so the solution is obvious: you can avoid the next wave of violence by going to war with China.
In that case, just pause and rewind. Anyone using an intrinsically interactive medium (i.e. face-to-face) and not allowing interaction should be replaced by a video recording.
That's the real reason for taking notes. I knew someone who took notes in lectures and then threw them away at the end. The point of the notes wasn't to refer to later - handouts and books are better for that - it was to force his brain to focus on the key points. He'd jot down key words and phrases, and the act of doing that meant that he was forcing his brain to identify what the key concepts were as they were introduced. So, to answer the original question, it doesn't matter what you take notes on. You can use a pen with no ink and 'write' on the desk if you want and it will do you as much good.
I found that trying to think of an intelligent question worked just as well. In a good lecture, you never get around to asking them, because the good questions that you will think of in one part are answered in the next. In more interactive sessions, you need to because the person giving the lecture is using them to check that you understand the material.
This isn't new, it predates computers by a long way. Copyright has always had the notion of a derived work. If someone wrote a story and you write a story that is more or less the same as theirs but with a few tweaks, then that can still be copyright infringement. If, however, you write one that just has a similar setting, then that's fine. If you're reusing the characters and the setting, then it starts to get into the grey area.
I thought you were joking, but it turns out that they really do charge that much for a last-generation i7, 2GB of RAM and an 80GB hard disk with integrated graphics. In contrast, Dell charges $100 less for a current-generation i7, 8GB of RAM, a 1TB hard drive an a discrete GPU with 1GB of RAM. Even Apple only charges $50 more for a Mac Mini with a quad i7, two 500GB hard disks, and 4GB of RAM, and that's with the more expensive components aimed at laptops.
It was the point of both OpenGL and Direct3D, but it's largely deemphasised now because GPUs are really fast. If you compare an early GeForce to something like a TNT with a decent CPU, there wasn't a huge amount of benefit from doing the transform and lighting in hardware, because a decent CPU could do it almost as fast. Even things like texturing were faster in hardware, but an optimised software implementation was just about usable. A modern GPU, however, is a highly programmable stream processor. Your GPU code is just a load of little programs, with very few branches, that run multiple instances in parallel and stream massive amounts of data. Your CPU is a processor optimised for running a single program or a small group of (often totally independent) programs with lots of branches and a memory access pattern optimised for locality of reference. The latter is a big issue: CPUs expect memory that you've just used to be used again, so they have lots of cache, GPUs don't so they have small buffers and stream GBs of data from memory, through a shader program, and back out to memory again.
This means that a software implementation is almost always unusably slow. There is also the problem that modern GPUs and CPUs have entirely different memory and communicate over a PCIe bus. The bus speed usually doesn't matter: you copy a load of data to VRAM at program start and then just reference it. Even the shader code is often copied across into a big code buffer and you just launch it by passing a few pointers across the bus. If you use CPU fallback, then you're having to move large amounts of data from the GPU to the CPU and back again. This can be so expensive that it's often faster to use a pure-CPU implementation than a mixed CPU-GPU one. And the pure-CPU implementation is much too slow for modern games.
DirectX, as of version 10 (I think, possibly earlier) removed the emulation paths and your card must support the baseline for the current DirectX version entirely or you can't run games designed for that version at all. Previous versions had a load of feature test bits that let check if bits were implemented in hardware or software and disable some code paths if not. OpenGL has a similar baseline, but also has an extension mechanism, so you can query whether the hardware supports some features and enable extra features if it does.
OpenGL runs in a surface (I believe that is the terminology used for a driver independent window) on Windows since Vista, so it should work in Windowed mode, but will have a performance hit
Not a significant one. A surface is just a texture and render-to-texture is cheap on modern GPUs (it's basically how you do everything, from double buffering through reflections to windowing). The windowing system then just runs a little bit of GPU code to composite the resulting windows. You have two places for overhead in this model. The first is that the other windows are in VRAM. This likely costs you 8-16MB of VRAM, maybe a bit more. Not really noticeable on a GPU with 256MB-1GB of VRAM. The second is that the window server will be stealing a little bit of GPU time to render the windows. This typically involves rendering something on the order of 100 textured triangles... on a GPU rated to push out billions of textured triangles per second.
expect a performance hit up to about 20% for context switching and compositing with DirectX based windows (as it is today)
If the performance hit is really that high, then Microsoft has done something badly wrong, at least on modern GPU hardware. The cost of context switching is nil, as the GPU has its own MMU and can support at least 8 contexts in hardware, so your window server will always be in the GPU's TLB and not need any bus traffic. I'd accept that for older hardware, where a GPU context switch meant dumping the contents of VRAM to main memory and then pushing it back, but that hasn't been the case for a few years. With a lot of SoCs, the GPU uses the same MMU as the CPU, so there's about the same cost for a GPU context switch as a CPU one, and you do one of those every 10ms...
opengl32.dll in the Windows directory is usually the software stub driver that will call down to a real driver if it can find one. It's also relatively common (or, at least, used to be - it has been about a decade since I last used Windows, so I might be talking nonsense) for drivers to ship their own opengl32.dll so that they didn't have to fit their OpenGL implementation into Microsoft's driver architecture so closely. The OpenGL DLL doesn't need to talk to any other DLLs except the one that implements the interface to the kernel (and every Metro app must talk to that, or it would never be able to do anything). It is, however, possible that the Metro stuff gets a system call whitelist so can't call into the graphics driver directly (although that would make Direct2D and Direct3D hard to implement).
That said, it's largely irrelevant: things that rely heavily on 3D acceleration are not likely to want to be Metro applications.
When android development was started, there weren't ANY devices available that would run it.
Yes there were, although they were clunky developer boards with touchscreens attached. Once there was a shipping version, future versions were developed on the hardware that the current generation used, until new hardware was built, and then development continued there. In contrast, WebOS was shipped on several devices, none of which can run the new version, and there are no new devices available to replace them.
Nostalgia is as much about the path as the destination. I wouldn't be doing the things I am now with modern hardware if I hadn't learned on those old 8- and 16-bit machines. Having to work around the resource limitations of the machines of the era was a valuable learning experience. Sure, now I'm happy to have a machine that's several orders of magnitude more powerful. Sure, I can do things on it in a few minutes of effort that would have been completely impossible on a C64. And no, I definitely wouldn't want to go back... but none of that means that I'm not glad that I had those experiences in the '80s.
Things were very different in the UK. It was competing against the BBC Model B (later the Master) at the high end and against the Sinclair Spectrum and ZX81 (which completely owned the market prior to the C64's launch), the Amstrad CPC (a bit later), and possibly an Acorn Atom or Electron at the low end. Schools all bought BBCs because there was government funding that paid 50% of the cost of any computer that met a fairly strict set of requirements (e.g. a dialect of BASIC with full support for structured programming) and the BBC was the only computer to meet those requirements for a while and then the cheapest.
The C64 became very popular later on, when shops like Argos were selling them for £50 (a PC cost about £1000 then, and an Amiga or modern Acorn machine around £300-500). Supermarkets also had a load of C64 games on cassette for 50p-£3, so people amassed huge collections of them.
If you want to create games of the same sort of complexity now, then you don't use DirectX or OpenGL, you use Flash. Or possibly HTML 5 canvas and JavaScript. And drawing with these is even easier: you can actually draw your sprites in a drawing tool and then you only need to write code for animating them. The underlying system handles compositing, so all that you need to do to move a sprite is set its coordinates. With HTML5, making a smiley face bounce across the screen is about a dozen lines of HTML and a dozen lines of JavaScript, and most of the HTML is boilerplate that is the same for any web page.
If you want something even simpler, take a look at Squeak eToys - a fully introspective object-oriented development environment where seven year olds with no experience in programming can get car sprites racing around their screen in an afternoon.
It doesn't even need to be bad. The fact that it's a dead platform that is only supported as the result of a lawsuit ought to set off warning bells for anyone considering buying it. As soon as the agreement expires, it's going to be dropped. It's also likely to be a wake-up call for anyone still using Itanium: if even Oracle (a company well known for being motivated solely by money and willing to support anything if they think there's a dollar in it) won't support it without legal pressure, then no one else is going to either.
At this point, the only possible reason for using Itanium is that you have a large OpenVMS deployment. If you're running any flavour of UNIX on Itanium, you should ask yourself why you didn't migrate away at the last upgrade cycle. Or the one before that...
Slashdot Mirror
Well, at least 500 million of them are. 30% of Indians consume meat regularly (for some self-identified definition of 'regularly'). Somewhere between 20-42% (depending on whose study you trust) Indians are vegetarian. There are, however, almost certainly more vegetarians in India than there are people in the USA.
It's not bullshit. If you ate nothing but salad every day, you're not going to get the same nutrition that you would from eating a lot of meats.
False dichotomy. If you ate nothing but steak every day then you'd also be dead in short order. If you eat a moderately balanced diet then you'll be fine. For a vegetarian, the big issue is making sure that you get the full set of amino acids. If you eat cheese, that's done. If you're a vegan it's a bit harder, but eating both rice and lentils will give you them all, as will several other well-known pairs. You have to have a pretty monotonous diet as a vegetarian to avoid getting all of the nutrients that you need.
Mind you, the same is true for omnivores, and in the USA a lot of them seem to manage to suffer from malnutrition (and obesity at the same time), so perhaps it is too much to expect...
You're right, but that would be speculative
True, although I've found that attempting to rewrite a system is a good way of determining how complex it really needs to be. In the end, it doesn't matter if you actually use the rewrite, or even if you finish it. Once you've spent a bit of time on it, you have a much better idea of how the original system should have been designed, and that can help refactoring immensely.
That depends on whether it actually needs to be that complex. Implementing a project that is 200KLoC is not the same as implementing something that is functionally equivalent to an existing codebase that has grown to 200KLoC. If the project is as described, I wouldn't be surprised if it could be implemented in under 20KLoC, possibly less if there are some existing libraries that can be used.
It's a very old saying that the first 90% of the project takes the first 90% of the time, and the remaining 10% takes the other 90%. When dealing with old codebases, however, 90% is often good enough. I've seen programs that were written with one set of requirements and then those changed. They ended up with massive abstraction layers to support multiple back ends. Then 5-10 years later they were using the abstraction layer to abstract a single implementation. And the abstraction layer wasn't a good fit for the front or the back. A rewrite can just omit the abstraction layer entirely, significantly reducing complexity. Sometimes this makes the code harder to refactor in the future, but often it's easier to then insert a new abstraction layer than to try to adapt an existing one.
Actually, you've hit the major problem right on the head. You're not going to want to transmit from close to the stock exchange, you're going to want to receive close to the stock exchange so that you can forward your instructions directly into their computer system. The problem is (in the absence of commercially available neutronium), the neutrino comms equipment is going to be bigger than the computer running your trading algorithms. In which case, you may as well just move it there instead of installing the relay.
Neutrino comms for HFT is solving a problem that doesn't exist. The problem it would solve is doing HFT from a long way away from the exchange, but no one actually does that...
How would that work? Valve isn't going to be writing drivers, they're just going to be bundling third-party ones, and Ubuntu already bundles all of the ones that have redistribution rights. This entire story is moot. There are two possible reasons for Valve to do a Linux port. The first is to appeal to existing Linux users. They won't do this by saying 'we support your OS. Well, actually, we don't, we support a similar OS, but it's like your OS and you can install it for free!' The second is to make it cheaper for companies to make Steam-powered consoles. I suspect this is more likely - I wouldn't be surprised if we see cheap Chinese-made consoles hitting the market running a basic Linux install with Steam set to launch full screen on boot and used as the application manager / installer. In this case, it's also pointless to ship their own distro: OEMs will want to use their own and will strip out everything except the drivers their hardware needs, basic libraries, X, and Steam.
The drivers for gaming-related devices have got to be pretty awful on FreeBSD if nobody seems to use it at all for games, only servers
nVidia ships blob drivers for FreeBSD.
Yet they don't make the (blob) drivers for BSD either
Yes they do, at least for x86 and x86-64.
The way drivers work in Linux and BSD, aren't accommodating to "binary blobs" since they can be broken with even minor updates
FreeBSD guarantees a stable KBI across minor revisions, and we require strong justifications for breaking it between minor revisions (which means that often kernel modules will work between major revisions, we just don't guarantee it). After 10.0, we're looking at providing longer-term support for a subset of KPIs.
It's not just killing products that suck, it's killing feature creep. The counter example from Microsoft is the team of people responsible for the shutdown menu in Vista. A total UI clusterfuck. That sort of thing would never have happened at a company like Apple or Palm back in the day because they had someone who would be using the prototypes from the start who was sufficiently influential to say 'this sucks, fix it'. Focus groups are really good at generating products that have all of the features that everyone wants, but don't expose them in a way that anyone wants. Lots of people complained about the early iPods because they lacked a load of features that Steve Jobs didn't think were important. The features that he did were there and worked well (apparently he doesn't listen to much classical music: the display didn't get the ability to show the composer until the fourth generation), and that was enough to get a lot of sales. It's not enough to completely dominate a market - Apple has only ever done that when the market is sufficiently young that there are no other companies catering to other niches - but you can probably do that if you design different product lines for individuals in different demographics.
Apple had the same advantage that Palm had before them: someone willing to say 'no, this sucks' and be listened to. There's a story about the first iteration of the Palm Pilot, where the CEO saw it and decided it was too big. He got a block of balsa wood cut that was just small enough to fit in his shirt pocket and gave it to the product development team with an edict that the final version must be no bigger than that. Without someone like that, they'd have ended up with something too big to be conveniently carried. Steve Jobs had the same role at Apple: it wasn't producing great products, or products that could not be improved, it was to produce products that were definitely useful. As long as 'how Steve Jobs would use it' and 'how a normal human would use it' weren't too far apart, it worked well. Sometimes, it didn't - there were a few flops along the way - but a product designed for a specific user is far more likely to be useable in general than one designed for some set of focus-group set of requirements plus any features that engineers thought they could sneak in.
His graph shows the Napoleonic wars and World War II as points of relatively low violence, so the solution is obvious: you can avoid the next wave of violence by going to war with China.
weird that Windows, of all platforms, has the best handwriting recognition
Why? Microsoft has tried to push Windows on stylus-based tablets twice in the past. The first time in 1991, then again in 2002.
In that case, just pause and rewind. Anyone using an intrinsically interactive medium (i.e. face-to-face) and not allowing interaction should be replaced by a video recording.
That's the real reason for taking notes. I knew someone who took notes in lectures and then threw them away at the end. The point of the notes wasn't to refer to later - handouts and books are better for that - it was to force his brain to focus on the key points. He'd jot down key words and phrases, and the act of doing that meant that he was forcing his brain to identify what the key concepts were as they were introduced. So, to answer the original question, it doesn't matter what you take notes on. You can use a pen with no ink and 'write' on the desk if you want and it will do you as much good.
I found that trying to think of an intelligent question worked just as well. In a good lecture, you never get around to asking them, because the good questions that you will think of in one part are answered in the next. In more interactive sessions, you need to because the person giving the lecture is using them to check that you understand the material.
This isn't new, it predates computers by a long way. Copyright has always had the notion of a derived work. If someone wrote a story and you write a story that is more or less the same as theirs but with a few tweaks, then that can still be copyright infringement. If, however, you write one that just has a similar setting, then that's fine. If you're reusing the characters and the setting, then it starts to get into the grey area.
I don't recall a single 32-bit desktop in the 80s
Clearly you were not in the UK. Acorn's line of desktop computers from the Archimedes in 1987 onwards were 32-bit, with ARM CPUs.
I thought you were joking, but it turns out that they really do charge that much for a last-generation i7, 2GB of RAM and an 80GB hard disk with integrated graphics. In contrast, Dell charges $100 less for a current-generation i7, 8GB of RAM, a 1TB hard drive an a discrete GPU with 1GB of RAM. Even Apple only charges $50 more for a Mac Mini with a quad i7, two 500GB hard disks, and 4GB of RAM, and that's with the more expensive components aimed at laptops.
It was the point of both OpenGL and Direct3D, but it's largely deemphasised now because GPUs are really fast. If you compare an early GeForce to something like a TNT with a decent CPU, there wasn't a huge amount of benefit from doing the transform and lighting in hardware, because a decent CPU could do it almost as fast. Even things like texturing were faster in hardware, but an optimised software implementation was just about usable. A modern GPU, however, is a highly programmable stream processor. Your GPU code is just a load of little programs, with very few branches, that run multiple instances in parallel and stream massive amounts of data. Your CPU is a processor optimised for running a single program or a small group of (often totally independent) programs with lots of branches and a memory access pattern optimised for locality of reference. The latter is a big issue: CPUs expect memory that you've just used to be used again, so they have lots of cache, GPUs don't so they have small buffers and stream GBs of data from memory, through a shader program, and back out to memory again.
This means that a software implementation is almost always unusably slow. There is also the problem that modern GPUs and CPUs have entirely different memory and communicate over a PCIe bus. The bus speed usually doesn't matter: you copy a load of data to VRAM at program start and then just reference it. Even the shader code is often copied across into a big code buffer and you just launch it by passing a few pointers across the bus. If you use CPU fallback, then you're having to move large amounts of data from the GPU to the CPU and back again. This can be so expensive that it's often faster to use a pure-CPU implementation than a mixed CPU-GPU one. And the pure-CPU implementation is much too slow for modern games.
DirectX, as of version 10 (I think, possibly earlier) removed the emulation paths and your card must support the baseline for the current DirectX version entirely or you can't run games designed for that version at all. Previous versions had a load of feature test bits that let check if bits were implemented in hardware or software and disable some code paths if not. OpenGL has a similar baseline, but also has an extension mechanism, so you can query whether the hardware supports some features and enable extra features if it does.
OpenGL runs in a surface (I believe that is the terminology used for a driver independent window) on Windows since Vista, so it should work in Windowed mode, but will have a performance hit
Not a significant one. A surface is just a texture and render-to-texture is cheap on modern GPUs (it's basically how you do everything, from double buffering through reflections to windowing). The windowing system then just runs a little bit of GPU code to composite the resulting windows. You have two places for overhead in this model. The first is that the other windows are in VRAM. This likely costs you 8-16MB of VRAM, maybe a bit more. Not really noticeable on a GPU with 256MB-1GB of VRAM. The second is that the window server will be stealing a little bit of GPU time to render the windows. This typically involves rendering something on the order of 100 textured triangles... on a GPU rated to push out billions of textured triangles per second.
expect a performance hit up to about 20% for context switching and compositing with DirectX based windows (as it is today)
If the performance hit is really that high, then Microsoft has done something badly wrong, at least on modern GPU hardware. The cost of context switching is nil, as the GPU has its own MMU and can support at least 8 contexts in hardware, so your window server will always be in the GPU's TLB and not need any bus traffic. I'd accept that for older hardware, where a GPU context switch meant dumping the contents of VRAM to main memory and then pushing it back, but that hasn't been the case for a few years. With a lot of SoCs, the GPU uses the same MMU as the CPU, so there's about the same cost for a GPU context switch as a CPU one, and you do one of those every 10ms...
opengl32.dll in the Windows directory is usually the software stub driver that will call down to a real driver if it can find one. It's also relatively common (or, at least, used to be - it has been about a decade since I last used Windows, so I might be talking nonsense) for drivers to ship their own opengl32.dll so that they didn't have to fit their OpenGL implementation into Microsoft's driver architecture so closely. The OpenGL DLL doesn't need to talk to any other DLLs except the one that implements the interface to the kernel (and every Metro app must talk to that, or it would never be able to do anything). It is, however, possible that the Metro stuff gets a system call whitelist so can't call into the graphics driver directly (although that would make Direct2D and Direct3D hard to implement).
That said, it's largely irrelevant: things that rely heavily on 3D acceleration are not likely to want to be Metro applications.
When android development was started, there weren't ANY devices available that would run it.
Yes there were, although they were clunky developer boards with touchscreens attached. Once there was a shipping version, future versions were developed on the hardware that the current generation used, until new hardware was built, and then development continued there. In contrast, WebOS was shipped on several devices, none of which can run the new version, and there are no new devices available to replace them.
Nostalgia is as much about the path as the destination. I wouldn't be doing the things I am now with modern hardware if I hadn't learned on those old 8- and 16-bit machines. Having to work around the resource limitations of the machines of the era was a valuable learning experience. Sure, now I'm happy to have a machine that's several orders of magnitude more powerful. Sure, I can do things on it in a few minutes of effort that would have been completely impossible on a C64. And no, I definitely wouldn't want to go back... but none of that means that I'm not glad that I had those experiences in the '80s.
Things were very different in the UK. It was competing against the BBC Model B (later the Master) at the high end and against the Sinclair Spectrum and ZX81 (which completely owned the market prior to the C64's launch), the Amstrad CPC (a bit later), and possibly an Acorn Atom or Electron at the low end. Schools all bought BBCs because there was government funding that paid 50% of the cost of any computer that met a fairly strict set of requirements (e.g. a dialect of BASIC with full support for structured programming) and the BBC was the only computer to meet those requirements for a while and then the cheapest.
The C64 became very popular later on, when shops like Argos were selling them for £50 (a PC cost about £1000 then, and an Amiga or modern Acorn machine around £300-500). Supermarkets also had a load of C64 games on cassette for 50p-£3, so people amassed huge collections of them.
If you want to create games of the same sort of complexity now, then you don't use DirectX or OpenGL, you use Flash. Or possibly HTML 5 canvas and JavaScript. And drawing with these is even easier: you can actually draw your sprites in a drawing tool and then you only need to write code for animating them. The underlying system handles compositing, so all that you need to do to move a sprite is set its coordinates. With HTML5, making a smiley face bounce across the screen is about a dozen lines of HTML and a dozen lines of JavaScript, and most of the HTML is boilerplate that is the same for any web page.
If you want something even simpler, take a look at Squeak eToys - a fully introspective object-oriented development environment where seven year olds with no experience in programming can get car sprites racing around their screen in an afternoon.
It doesn't even need to be bad. The fact that it's a dead platform that is only supported as the result of a lawsuit ought to set off warning bells for anyone considering buying it. As soon as the agreement expires, it's going to be dropped. It's also likely to be a wake-up call for anyone still using Itanium: if even Oracle (a company well known for being motivated solely by money and willing to support anything if they think there's a dollar in it) won't support it without legal pressure, then no one else is going to either.
At this point, the only possible reason for using Itanium is that you have a large OpenVMS deployment. If you're running any flavour of UNIX on Itanium, you should ask yourself why you didn't migrate away at the last upgrade cycle. Or the one before that...