Note that that's 'unlimited' (no tethering, fair use policy applies). If you want a data plan for things that actually use data, £12.50/month buys you 3GB (must be consumed within one month) from giffgaff. They lost my custom when they put their call and text fees up from 8p/minute, 4p/text to 10p/minute, 5p/text and then plastered misleading price comparisons all over their web site implying that everyone else is more expensive than them. I switched to a provider that was still offering the 8p/4p price.
Oh, hey, he criticised a woman, he must be sexist! Except that a big part of what made Janeway so irritating was that lots of other science fiction shows manage to portray female leaders who actually worked as characters. The two that immediately come to mind are Susan Ivanova from Babylon 5 and Samantha Carter from Stargate SG-1. I'd be tempted to add Elisabeth Lockley from Babylon 5, but she was only in the fifth season and suffered from the fact that the backdrop was the fifth season of Babylon 5, which was about 60% filler. Delenn (also from B5) is also an obvious choice. Space Above and Beyond had Capt. Shane Vansen, their squad leader, who portrayed a female leader in a far more overtly military role, and she worked well too.
Part of the problem with Janeway was that her character felt a bit too twentieth century: like a woman in a traditionally male role thinking she had something to prove. You'd have thought that this kind of thing would have died out by the time Enterprise is set, let alone Voyager. And, indeed, other shows managed it. Ivanova never seemed to be overcompensating: she demanded respect because she felt she'd earned it.
Intel killed Alpha and PA-RISC by promising Itanium. They won there through political tactics, not through any technical advantages. Sun and Oracle between them tried very hard to kill SPARC using their awesome mismanagement superpowers, but haven't quite failed yet. PowerPC still dominates in automotive and a few other embedded industries, MIPS is in pretty much every router and a lot of other embedded systems, and ARM basically owns the mobile markets and has a large part of the embedded market. You could possibly claim that Intel beat ARM on the desktop, but it would be more accurate to say that Microsoft beat Acorn on the desktop and Intel went along for the ride.
That 10% becomes a lot more important going forward. The current buzzword in the semiconductor industry is dark silicon. To keep within the same thermal envelope (power dissipation per unit area), you need to have more transistors idle and in a low-power state in every subsequent generation. If you add complex vector instructions, for example, they're great because they give a big speedup when they're in use and draw almost no power when they aren't. The same with things like AES encryption. The instruction decoder, however, is something that you can't ever turn off. Xeons try to: they cache decoded micro-ops in tight loops, but this means that they have some extra SRAM for the micro-op cache and a micro-op decoder that must always be powered, and these between them take more power than an ARM decoder, and a big fat decoder that must be active all of the time.
Intel had an advantage over other RISC architectures (and Itanium) in terms of instruction density, which meant that they needed to waste a lot more die space with instruction cache than x86 to get the same fetch performance, but ARM is already about as dense as x86 and Thumb-2 is typically 5-10% denser, so Intel is on the losing side of this comparison for the first time.
The process advantage is something that Intel has had over AMD, but it's not something that they have to the same degree over some of the foundries that produce ARM chips. They're on 22nm, and the faster ARM SoCs are made on a 25nm process: that's nowhere near the kind of process advantage Intel is accustomed to. In terms of fab R&D, the industry is almost split into two camps, Intel on one side and everyone else pooling resources on the other side.
Actually, Intel has been doing this for about two years now. Not only will they license the Atom core to you, they'll also fab the resulting SoC for you at a relatively low rate. So far, I'm not aware of any companies that have taken advantage of this, because they'd effectively be in the position of competing with people both up and down the supply chain from them. This is why ARM has made a point of not producing chips: it would make their licensees very nervous. This is part of the reason for ARM's strategy with ARMv8: they're intentionally not releasing a core for licensing until after some of their partners have done so, to encourage a more diverse ecosystem (the success of XScale and Snapdragon in the past have shown them that this is useful). They win either way: they get a small amount for every ARM-compliant CPU designed by third parties and a larger amount for every ARM-designed CPU, but the more ARM chips in the world the more money they get.
Using the example of a browser, his goal is use nested sandboxes
To clarify: CHERI does not require a full ordering of trust. Part of the goal is to allow mutually distrusting parts of the program to communicate and to limit the scope of a compromise if one of the parts is problematic.
'Dark silicon' is a stupid idea. Going down that route is just evidence that you're too stupid to do power management correctly on chip.
It's fairly unusual that someone writes something in their first sentence that indicates that they have no idea what they're talking about and then goes on for four more paragraphs. Dark silicon is real and is a very important problem. The issue is that process improvements mean that we can fit more and more transistors in the same area, but the power consumption (and therefore heat dissipation) per transistor does not reduce at the same rate. This means that, to fit within the same power envelope, you have actively use a lower percentage of the die area with each generation. This means that it's worth spending transistors optimising for specialist tasks and that's why we're seeing more CISCy designs appear. Everyone in a computer architecture course has a good laugh at the extreme-CISC VAX having an evaluate-polynomial instruction, but RISC ARMv8 has a perform-an-iteration-of-AES instruction.
The rest of your post also indicates a complete lack of understanding of the issues. Reading any paper published on IC power management in the last decade should give you some idea of why.
Not necessarily. I am the person working on the compiler(s) he's talking about, and chronologically it goes more CPU, assembler, OS, compiler, CPU, OS... Before the compiler can do anything interesting, for example, the OS must be modified to understand the extra CPU state (context switch code, in particular). Both the OS and compiler design then feed back into the CPU design. One of the nicest things about this project is that we can modify any part of the stack, so the hierarchy isn't nearly as apparent as it normally is, where you're modifying one component and the other two are fixed.
I work with Robert on this project. Sandboxes, as implemented by things like Chrome, have serious scalability issues. Each process needs its own page tables and TLB entries, for example, and this, combined with things like cache footprints, mean that it's not possible with current hardware to do the kinds of thing that we'd like to be able to. Chrome, for example, stops using sandboxes once you have more than about 20 tabs open for this reason, but in an ideal world, every image and every would be decoded in a separate sandbox (protecting you against bugs in libpng, libjpeg, and so on), every JavaScript scope (one per tab plus one per web worker) would be in a sandbox (protecting you against bugs in the JavaScript JIT), and so on. It's easy to imagine a typical web browser wanting a few thousand short-lived sandboxes in typical operation, and that's just for a single application. Trying to create them all using fork() or similar mechanisms will completely kill performance, so we're implementing a more fine-grained approach. The hardware's working now, so we should start trickling out more detailed publications over the next year.
I mostly work on the language side (Robert mostly does the OS bit) - the thing that got me back into academia was the ability to do language and compiler design and modify the ISA when I find things that would make life easier. I've recently started hacking a bit on the hardware though - last week I made some tweaks to the branch predictor that gave us about a 3.5% overall speedup, which made me happy as it was my first bit of hardware design.
I haven't watched the talk, but I suspect Robert also talked a bit about Capsicum, which is the pure-software approach to sandboxing that the same group implemented before I arrived. Capsicum is now shipping in FreeBSD and it's not exactly like chroot - it provides a finer-grained set of rights on file descriptors and prevents a process from creating new ones, meaning that the parent process can exactly define what parts of the system a child can touch. The Chrome sandboxing back end using Capsicum is only about 100 lines of code, which is an order of magnitude smaller than either of the Linux back ends (both of which are an order of magnitude smaller than the Windows one) and provides better isolation.
I don't remember exactly where, but the Basilisk II site linked to it in the forums along with instructions for extraction. It's pretty easy once you've got a m68K Mac (or a PPC Mac with the emulator). Just run the installer and it self-extracts and says 'sorry, this is the wrong kind of Mac' but leaves the ROM image where it did the extraction.
First, when you buy the game you get both the Windows and Mac versions, so if you are using an old and unsupported version of OS X then you can still use the Windows installer under WINE and then play the games under DOSBox or ScummVM.
Second, you're paying for the Mac installer, that comes with DOSBox or ScummVM preconfigured. Several of the games I've already bought from GOG now have Mac versions, and if I want to play them again then I can just grab the Mac version next time, rather than having to run the installer in WINE and then set up DOSBox of ScummVM to point to that install. So, I'm paying nothing more, but getting a lot more convenience. Sounds like a win to me...
Actually, it does. There is a firmware update available that contains a self-extracting installer that contains the ROM. Unfortunately, there's a slightly bootstrapping problem, because it's a Classic m86K binary, so you need to have working emulation before you can get the ROM.
Just avoid Ubuntu. I have one machine running Ubuntu, which is a little ARM-based laptop. Unlike most other machines, Canonical was paid by the manufacturer to support Ubuntu on this device. So how did that work? Well, on boot udevd jumps to using 100% of the CPU and the only way of getting a vaguely responsive system is to kill it. Unity is painfully slow and uses up so much RAM that even running a single large application (e.g. LibreOffice or FireFox) causes thrashing. Oh, and most of the system dialogs don't fit on the vertical space - this, remember, on a system where the justification for all of the recent UI fuckups was to produce something that worked on small form-factor devices...
It's worth tweaking the DOSBox configuration for any GOG game. They pick pretty conservative settings. I noticed some games were looking a bit worse than I'd expect and found that they're using the fastest scaling algorithm for point-and-click games. Switching to hq3x made the output a lot nicer.
The old games run in ScummVM or DOSBox, both of which use something newer (e.g. OpenGL) for the final pixels-on-the-screen bit of the emulation, so they don't depend on 256 colour modes. The main difference from the Windows version is that they now have Mac installers. I found it slightly irritating that I needed to use WINE to install a game that I was going to run with a native DOSBox or ScummVM, and this has now been fixed. A lot of the newer games also work with WINE, but they're probably not going to get Mac installers until they've been tested.
It's a bit hit and miss. For example, I just finished Broken Sword 4 (released 2007, bought by me from GOG), on OS X with WINE. I use WineSkin, which lets you create.app wrappers for Windows programs and easily switch between different versions of WINE. With the latest versions of WINE (on a quad 2.2GHz i7) it is slow and laggy, the CPU is at 100%, and periodically the sound gets broken and you get loud noise from the speakers. With the Crossover games engine (also the open source version, also installed by WineSkin) it works fine, but I'd tried five other versions of WINE before I found that one.
That said, I usually buy games when they're discounted at $2.99, so if some don't work yet then I'm happy to wait for WINE to catch up.
GLIDE stomped the living shit out of OpenGL and as far as I know there wasn't any "MiniGL" at the time
GLIDE was basically a hacked-up subset of OpenGL. MiniGL is the name given to the subset, without the GLIDE API weirdness - i.e. the subset of OpenGL that the VooDoo could support in hardware. It was used by games like GLQuake.
because even at that point in the game Kronos was dropping the ball when it came to OpenGL by focusing more on CAD than gaming
Kronos didn't exist until about a decade later. Back then there was the OpenGL Architecture Review Board, which was a fairly open process. Vendors proposed extensions in their own namespace (e.g. NV_), once two or more vendors supported the same extension they were moved to the EXT_ namespace and proposed to the ARB. They'd then typically be in the next version of the standard with the ARB_ namespace and in the version after that as a part of the core functionality.
Of course the ARB was focussing on CAD at this time because that was the only existing market for 3D hardware. The PowerVR and 3dfx cards were high-end gaming accelerators and were so expensive that very few people had them even among gamers. They were a tiny niche. More mainstream graphics accelerators, like the Mach64 and the S3 ViRGE were even less capable.
In the first iterations, Direct3D was basically a toy. Very few games used it before DirectX 3, and even those mostly used the software pipeline - I could play most Direct3D games on my father's laptop, which had no 3D acceleration. The Microsoft OpenGL software implementation was a lot slower, and so no one used it for games that needed to run without hardware support. If you were willing to require a 3D card, OpenGL was a better choice, but that limited your market a lot. Most games that went this route wrote their own software pipeline, which typically performed better than the Direct3D HEL, and used OpenGL when there was compatible hardware available (and got better performance there than the Direct3D HAL). Direct3D was a complete bitch to program for until DirectX 5, when it started to look a bit more like OpenGL.
DirectX had one major advantage over OpenGL: it was not just a 3D API. Pretty much any Windows game used DirectX for window and display mode management, input, sound, and often networking and video decoding. Once you're using all of these things, Direct3D seemed like a natural fit to slot into the rest of the code.
ROI is very difficult to calculate for infrastructure like this. I used the channel tunnel as an example in an earlier post. It will probably be another 15-25 years before the investors make their money back on that, so by some metrics it's not a good investment. But that doesn't take into account the secondary benefits. How much extra profit was made by companies in the UK and France being able to send people and equipment to each other very quickly? That's much harder to calculate: every business passenger on the Eurostar is working for a company that thinks that sending them is more valuable than the cost of the ticket, so that gives you an absolute lower bound, but the upper bound is mucuh harder to find.
Is it? That's $100,000/rider, which sounds like a lot, but that's also including a lot of capital investment. In the UK, commuter rail tickets can cost over £5000 ($8000), so that's about 8% of the cost, but that cost only has to cover maintenance, not construction. For an infrastructure project on this scale, break even is typically meant to be somewhere in the 10-25 year mark. If they're still constructing infrastructure, then that's quite plausible.
For comparison, the channel tunnel cost £9.5bn to build, and finished in 1994. Eurostar made its first operating profit in 2007 and the only reason it is nominally in the black is that they effectively sold most of the company to the banks that loaned them the money. They're making something like £150m/year in operating profit (most of which goes towards financing their debt), and so it will take them a very long time to make back the initial investment. The banks are making around a 2.5-3% annual return on investment in terms of interest on the debt, but they also own the majority of a profitable company with a very valuable asset, so they have a very good long-term investment.
More importantly, a large piece of infrastructure was built and is getting regular use. Last year, around 17 million people used the channel tunnel (plus a load of freight), and that has a huge economic impact on Britain and France. It's now feasible for someone who works in London to go to Paris or Brussels for a meeting and be back the same day, for example. But if you'd done the same sums that you just did for its 1994 then you'd have seen a £9.5bn investment for 0.3 million passengers. That's £31,500/passenger, or around $50,000/passenger. In other words, about half the per-passenger cost of the Chinese high speed rail network. Clearly a waste of money...
That's the point. You don't want hoarding for a functional currency, you want circulation. A small amount of inflation is a good thing, because it encourages people not to hoard money (they'll end up with less than they started with), but to invest it in real things instead. You want famers to be buying seed to plant and upgrading their equipment so that they can produce more next year, you don't want them to be hoarding gold coins that go up in value. In a healthy economy, the currency depreciates slowly, so that it works as a medium for interchange (people are willing to accept it in payment because it won't go down a noticeable amount before they spend it), but not as a store of wealth.
If you talk to archeologists, you'll hear that this is a very common occurrence. Technology is always improving, and over time it becomes easier to non-destructively examine a site. This makes it very difficult to decide when it's the correct time to start a dig. If you wait a few years, you'll probably get more information out, but if you wait forever then you won't get any. It's quite common to excavate a small part of a site and leave the rest for future archeologists.
You misread. You are not imposing extra conditions on people who receive the code, you are accepting extra conditions imposed by the person to whom you give the code. This is permitted by the GPL, because copyright law does not make it possible to impose this restriction.
Slashdot Mirror
Note that that's 'unlimited' (no tethering, fair use policy applies). If you want a data plan for things that actually use data, £12.50/month buys you 3GB (must be consumed within one month) from giffgaff. They lost my custom when they put their call and text fees up from 8p/minute, 4p/text to 10p/minute, 5p/text and then plastered misleading price comparisons all over their web site implying that everyone else is more expensive than them. I switched to a provider that was still offering the 8p/4p price.
Oh, hey, he criticised a woman, he must be sexist! Except that a big part of what made Janeway so irritating was that lots of other science fiction shows manage to portray female leaders who actually worked as characters. The two that immediately come to mind are Susan Ivanova from Babylon 5 and Samantha Carter from Stargate SG-1. I'd be tempted to add Elisabeth Lockley from Babylon 5, but she was only in the fifth season and suffered from the fact that the backdrop was the fifth season of Babylon 5, which was about 60% filler. Delenn (also from B5) is also an obvious choice. Space Above and Beyond had Capt. Shane Vansen, their squad leader, who portrayed a female leader in a far more overtly military role, and she worked well too.
Part of the problem with Janeway was that her character felt a bit too twentieth century: like a woman in a traditionally male role thinking she had something to prove. You'd have thought that this kind of thing would have died out by the time Enterprise is set, let alone Voyager. And, indeed, other shows managed it. Ivanova never seemed to be overcompensating: she demanded respect because she felt she'd earned it.
That 10% becomes a lot more important going forward. The current buzzword in the semiconductor industry is dark silicon. To keep within the same thermal envelope (power dissipation per unit area), you need to have more transistors idle and in a low-power state in every subsequent generation. If you add complex vector instructions, for example, they're great because they give a big speedup when they're in use and draw almost no power when they aren't. The same with things like AES encryption. The instruction decoder, however, is something that you can't ever turn off. Xeons try to: they cache decoded micro-ops in tight loops, but this means that they have some extra SRAM for the micro-op cache and a micro-op decoder that must always be powered, and these between them take more power than an ARM decoder, and a big fat decoder that must be active all of the time.
Intel had an advantage over other RISC architectures (and Itanium) in terms of instruction density, which meant that they needed to waste a lot more die space with instruction cache than x86 to get the same fetch performance, but ARM is already about as dense as x86 and Thumb-2 is typically 5-10% denser, so Intel is on the losing side of this comparison for the first time.
The process advantage is something that Intel has had over AMD, but it's not something that they have to the same degree over some of the foundries that produce ARM chips. They're on 22nm, and the faster ARM SoCs are made on a 25nm process: that's nowhere near the kind of process advantage Intel is accustomed to. In terms of fab R&D, the industry is almost split into two camps, Intel on one side and everyone else pooling resources on the other side.
Actually, Intel has been doing this for about two years now. Not only will they license the Atom core to you, they'll also fab the resulting SoC for you at a relatively low rate. So far, I'm not aware of any companies that have taken advantage of this, because they'd effectively be in the position of competing with people both up and down the supply chain from them. This is why ARM has made a point of not producing chips: it would make their licensees very nervous. This is part of the reason for ARM's strategy with ARMv8: they're intentionally not releasing a core for licensing until after some of their partners have done so, to encourage a more diverse ecosystem (the success of XScale and Snapdragon in the past have shown them that this is useful). They win either way: they get a small amount for every ARM-compliant CPU designed by third parties and a larger amount for every ARM-designed CPU, but the more ARM chips in the world the more money they get.
No, no idea. If it's anything to do with IC design, then I'd suggest that you start polishing your CV...
"Mr. Watson, come here - I want to see you"
Given that both John and Robert Watson have doctorates, why would either be addressed as Mr?
Using the example of a browser, his goal is use nested sandboxes
To clarify: CHERI does not require a full ordering of trust. Part of the goal is to allow mutually distrusting parts of the program to communicate and to limit the scope of a compromise if one of the parts is problematic.
'Dark silicon' is a stupid idea. Going down that route is just evidence that you're too stupid to do power management correctly on chip.
It's fairly unusual that someone writes something in their first sentence that indicates that they have no idea what they're talking about and then goes on for four more paragraphs. Dark silicon is real and is a very important problem. The issue is that process improvements mean that we can fit more and more transistors in the same area, but the power consumption (and therefore heat dissipation) per transistor does not reduce at the same rate. This means that, to fit within the same power envelope, you have actively use a lower percentage of the die area with each generation. This means that it's worth spending transistors optimising for specialist tasks and that's why we're seeing more CISCy designs appear. Everyone in a computer architecture course has a good laugh at the extreme-CISC VAX having an evaluate-polynomial instruction, but RISC ARMv8 has a perform-an-iteration-of-AES instruction.
The rest of your post also indicates a complete lack of understanding of the issues. Reading any paper published on IC power management in the last decade should give you some idea of why.
Not necessarily. I am the person working on the compiler(s) he's talking about, and chronologically it goes more CPU, assembler, OS, compiler, CPU, OS... Before the compiler can do anything interesting, for example, the OS must be modified to understand the extra CPU state (context switch code, in particular). Both the OS and compiler design then feed back into the CPU design. One of the nicest things about this project is that we can modify any part of the stack, so the hierarchy isn't nearly as apparent as it normally is, where you're modifying one component and the other two are fixed.
I work with Robert on this project. Sandboxes, as implemented by things like Chrome, have serious scalability issues. Each process needs its own page tables and TLB entries, for example, and this, combined with things like cache footprints, mean that it's not possible with current hardware to do the kinds of thing that we'd like to be able to. Chrome, for example, stops using sandboxes once you have more than about 20 tabs open for this reason, but in an ideal world, every image and every would be decoded in a separate sandbox (protecting you against bugs in libpng, libjpeg, and so on), every JavaScript scope (one per tab plus one per web worker) would be in a sandbox (protecting you against bugs in the JavaScript JIT), and so on. It's easy to imagine a typical web browser wanting a few thousand short-lived sandboxes in typical operation, and that's just for a single application. Trying to create them all using fork() or similar mechanisms will completely kill performance, so we're implementing a more fine-grained approach. The hardware's working now, so we should start trickling out more detailed publications over the next year.
I mostly work on the language side (Robert mostly does the OS bit) - the thing that got me back into academia was the ability to do language and compiler design and modify the ISA when I find things that would make life easier. I've recently started hacking a bit on the hardware though - last week I made some tweaks to the branch predictor that gave us about a 3.5% overall speedup, which made me happy as it was my first bit of hardware design.
I haven't watched the talk, but I suspect Robert also talked a bit about Capsicum, which is the pure-software approach to sandboxing that the same group implemented before I arrived. Capsicum is now shipping in FreeBSD and it's not exactly like chroot - it provides a finer-grained set of rights on file descriptors and prevents a process from creating new ones, meaning that the parent process can exactly define what parts of the system a child can touch. The Chrome sandboxing back end using Capsicum is only about 100 lines of code, which is an order of magnitude smaller than either of the Linux back ends (both of which are an order of magnitude smaller than the Windows one) and provides better isolation.
I don't remember exactly where, but the Basilisk II site linked to it in the forums along with instructions for extraction. It's pretty easy once you've got a m68K Mac (or a PPC Mac with the emulator). Just run the installer and it self-extracts and says 'sorry, this is the wrong kind of Mac' but leaves the ROM image where it did the extraction.
First, when you buy the game you get both the Windows and Mac versions, so if you are using an old and unsupported version of OS X then you can still use the Windows installer under WINE and then play the games under DOSBox or ScummVM.
Second, you're paying for the Mac installer, that comes with DOSBox or ScummVM preconfigured. Several of the games I've already bought from GOG now have Mac versions, and if I want to play them again then I can just grab the Mac version next time, rather than having to run the installer in WINE and then set up DOSBox of ScummVM to point to that install. So, I'm paying nothing more, but getting a lot more convenience. Sounds like a win to me...
Actually, it does. There is a firmware update available that contains a self-extracting installer that contains the ROM. Unfortunately, there's a slightly bootstrapping problem, because it's a Classic m86K binary, so you need to have working emulation before you can get the ROM.
Just avoid Ubuntu. I have one machine running Ubuntu, which is a little ARM-based laptop. Unlike most other machines, Canonical was paid by the manufacturer to support Ubuntu on this device. So how did that work? Well, on boot udevd jumps to using 100% of the CPU and the only way of getting a vaguely responsive system is to kill it. Unity is painfully slow and uses up so much RAM that even running a single large application (e.g. LibreOffice or FireFox) causes thrashing. Oh, and most of the system dialogs don't fit on the vertical space - this, remember, on a system where the justification for all of the recent UI fuckups was to produce something that worked on small form-factor devices...
It's worth tweaking the DOSBox configuration for any GOG game. They pick pretty conservative settings. I noticed some games were looking a bit worse than I'd expect and found that they're using the fastest scaling algorithm for point-and-click games. Switching to hq3x made the output a lot nicer.
The old games run in ScummVM or DOSBox, both of which use something newer (e.g. OpenGL) for the final pixels-on-the-screen bit of the emulation, so they don't depend on 256 colour modes. The main difference from the Windows version is that they now have Mac installers. I found it slightly irritating that I needed to use WINE to install a game that I was going to run with a native DOSBox or ScummVM, and this has now been fixed. A lot of the newer games also work with WINE, but they're probably not going to get Mac installers until they've been tested.
It's a bit hit and miss. For example, I just finished Broken Sword 4 (released 2007, bought by me from GOG), on OS X with WINE. I use WineSkin, which lets you create .app wrappers for Windows programs and easily switch between different versions of WINE. With the latest versions of WINE (on a quad 2.2GHz i7) it is slow and laggy, the CPU is at 100%, and periodically the sound gets broken and you get loud noise from the speakers. With the Crossover games engine (also the open source version, also installed by WineSkin) it works fine, but I'd tried five other versions of WINE before I found that one.
That said, I usually buy games when they're discounted at $2.99, so if some don't work yet then I'm happy to wait for WINE to catch up.
GLIDE stomped the living shit out of OpenGL and as far as I know there wasn't any "MiniGL" at the time
GLIDE was basically a hacked-up subset of OpenGL. MiniGL is the name given to the subset, without the GLIDE API weirdness - i.e. the subset of OpenGL that the VooDoo could support in hardware. It was used by games like GLQuake.
because even at that point in the game Kronos was dropping the ball when it came to OpenGL by focusing more on CAD than gaming
Kronos didn't exist until about a decade later. Back then there was the OpenGL Architecture Review Board, which was a fairly open process. Vendors proposed extensions in their own namespace (e.g. NV_), once two or more vendors supported the same extension they were moved to the EXT_ namespace and proposed to the ARB. They'd then typically be in the next version of the standard with the ARB_ namespace and in the version after that as a part of the core functionality.
Of course the ARB was focussing on CAD at this time because that was the only existing market for 3D hardware. The PowerVR and 3dfx cards were high-end gaming accelerators and were so expensive that very few people had them even among gamers. They were a tiny niche. More mainstream graphics accelerators, like the Mach64 and the S3 ViRGE were even less capable.
In the first iterations, Direct3D was basically a toy. Very few games used it before DirectX 3, and even those mostly used the software pipeline - I could play most Direct3D games on my father's laptop, which had no 3D acceleration. The Microsoft OpenGL software implementation was a lot slower, and so no one used it for games that needed to run without hardware support. If you were willing to require a 3D card, OpenGL was a better choice, but that limited your market a lot. Most games that went this route wrote their own software pipeline, which typically performed better than the Direct3D HEL, and used OpenGL when there was compatible hardware available (and got better performance there than the Direct3D HAL). Direct3D was a complete bitch to program for until DirectX 5, when it started to look a bit more like OpenGL.
DirectX had one major advantage over OpenGL: it was not just a 3D API. Pretty much any Windows game used DirectX for window and display mode management, input, sound, and often networking and video decoding. Once you're using all of these things, Direct3D seemed like a natural fit to slot into the rest of the code.
ROI is very difficult to calculate for infrastructure like this. I used the channel tunnel as an example in an earlier post. It will probably be another 15-25 years before the investors make their money back on that, so by some metrics it's not a good investment. But that doesn't take into account the secondary benefits. How much extra profit was made by companies in the UK and France being able to send people and equipment to each other very quickly? That's much harder to calculate: every business passenger on the Eurostar is working for a company that thinks that sending them is more valuable than the cost of the ticket, so that gives you an absolute lower bound, but the upper bound is mucuh harder to find.
Is it? That's $100,000/rider, which sounds like a lot, but that's also including a lot of capital investment. In the UK, commuter rail tickets can cost over £5000 ($8000), so that's about 8% of the cost, but that cost only has to cover maintenance, not construction. For an infrastructure project on this scale, break even is typically meant to be somewhere in the 10-25 year mark. If they're still constructing infrastructure, then that's quite plausible.
For comparison, the channel tunnel cost £9.5bn to build, and finished in 1994. Eurostar made its first operating profit in 2007 and the only reason it is nominally in the black is that they effectively sold most of the company to the banks that loaned them the money. They're making something like £150m/year in operating profit (most of which goes towards financing their debt), and so it will take them a very long time to make back the initial investment. The banks are making around a 2.5-3% annual return on investment in terms of interest on the debt, but they also own the majority of a profitable company with a very valuable asset, so they have a very good long-term investment.
More importantly, a large piece of infrastructure was built and is getting regular use. Last year, around 17 million people used the channel tunnel (plus a load of freight), and that has a huge economic impact on Britain and France. It's now feasible for someone who works in London to go to Paris or Brussels for a meeting and be back the same day, for example. But if you'd done the same sums that you just did for its 1994 then you'd have seen a £9.5bn investment for 0.3 million passengers. That's £31,500/passenger, or around $50,000/passenger. In other words, about half the per-passenger cost of the Chinese high speed rail network. Clearly a waste of money...
BOSS RAIL
The disaster that exposed the underside of the boom.
BY EVAN OSNOS
OCTOBER 22, 2012
Wow, an article that was posted two days in the future! Slashdot has really come a long way from posting old news...
That's the point. You don't want hoarding for a functional currency, you want circulation. A small amount of inflation is a good thing, because it encourages people not to hoard money (they'll end up with less than they started with), but to invest it in real things instead. You want famers to be buying seed to plant and upgrading their equipment so that they can produce more next year, you don't want them to be hoarding gold coins that go up in value. In a healthy economy, the currency depreciates slowly, so that it works as a medium for interchange (people are willing to accept it in payment because it won't go down a noticeable amount before they spend it), but not as a store of wealth.
Yup, it really sucks to have beer that you can drink without having to chill it to a temperature that removes the sensation in your tastebuds...
If you talk to archeologists, you'll hear that this is a very common occurrence. Technology is always improving, and over time it becomes easier to non-destructively examine a site. This makes it very difficult to decide when it's the correct time to start a dig. If you wait a few years, you'll probably get more information out, but if you wait forever then you won't get any. It's quite common to excavate a small part of a site and leave the rest for future archeologists.
You misread. You are not imposing extra conditions on people who receive the code, you are accepting extra conditions imposed by the person to whom you give the code. This is permitted by the GPL, because copyright law does not make it possible to impose this restriction.