Everything was available everywhere. Napster delivered MP3s, which worked on every device, including the dirt-cheap Chinese players. Netflix works on devices blessed by Netflix. I have a few friends who work there (in the OpenConnect group) and they say that there are about 80 types of devices (all with special streaming requirements) that they have to support. The Napster equivalent would just let me download H.264 video files with no DRM. I could play them on any device, including my old WebOS tablet (which is never going to be worth any company's time to support, but can happily play back H.264) or the FreeBSD box connected to my projector (similarly, far too small a nice to be worthwhile for Netflix to support). If a company wanted to create a Netflix-compatible appliance, they wouldn't have to talk to Netflix, they'd just use published APIs for getting the video files, and as long as the person using the device entered some valid login credentials it would work.
The arguments against this model?
People could copy the files? Newsflash: anything more than 2 people want to watch is already available for illegal download. DRM on Netflix doesn't prevent this.
People could just download things and stop paying? Most people don't subscribe to a service like Netflix to watch a specific set of things, they subscribe because the catalogue is constantly growing - they get to see new things every month. Plus, you could impose download limits (10, 20, 30, etc. hours of video per month at different tiers).
The problem is that the studios are still seeing the world as a rent / buy dichotomy. For digital goods, the concept of renting doesn't make much sense. I don't want to pay to rent a movie, I want to pay to have on-demand access to an ever-growing catalogue of things that I might want to watch. Currently, the closest I get to that is with a DVD rental service, and that's a long way from ideal.
The problem is that we're trying to monetise the wrong thing. Creating a movie is a difficult and expensive endeavour. At the very least, you need some sets and actors, writers, and so on quite like to be paid. If you need to film on location or need special effects, the costs go up.
Copying a film is easy. Peer to peer distribution is also easy, but even in a client-server environment the cost of streaming / copying a movie across the Internet is pretty tiny.
So what does copyright do? It encourages a business model where you do the difficult and expensive bit for free and then try to recoup your loss (and, ideally, make a profit) by charging a lot for the easy bit. This worked when copying a painting meant hiring an artist or when copying a book meant paying a monk or even hiring a team of people to do the typesetting for your (very expensive) printing press. The only way that these business models can survive long term is by imposing limitations on technology to try to make copying hard again and they will always be lagging behind innovation if they do.
They are popular with FadCoin mining because they are good at GPGPU work. This also makes them attractive to people doing useful and productive work with them, which is (thankfully) a much larger market. Lots of clusters now have AMD GPUs for number crunching.
I bought an AMD E-350 motherboard and a Chenbro case with 4 removable drive bays. It takes a slimline optical drive (which actually has a BD-RE drive, because they weren't much more expensive than DVD drives, although in the 3 years since I bought it I've yet to burn a single BD).
It's running FreeBSD, booting from a RAID-Z array (so cheap snapshots, block-level checksums, single drive failure recovery, and all of that good stuff). The GPU is now supported and so it runs XBMC connected to my projector for video playback too.
There's also an e-SATA port that I should be using for external backups, but am not currently...
That doesn't really make sense. The architectures of the three main GPU vendors are sufficiently different that it's highly unlikely that the can benefit much from tricks in the drivers (which are basically compiler optimisations these days, since the performance-critical part of the driver is the shader compiler). nVidia uses something that looks more or less like a scalar CPU (with some SIMD) but with SIMT so that if you run threads in lockstep they just do one decode but execute several steps at once. AMD is a VLIW-inspired design. Intel is a more classical SIMD architecture, but with the tweak that their vector register set is 2D and each operand encodes a start and a stripe size, so you can do vertical or diagonal stripes through the register set and don't have to do vector permutes. Intel and AMD put more of the parallelisation into the compiler (drivers) than nVidia, but the transforms that they do are quite different.
There's more of a chance that AMD drivers would help Broadcom than anyone else, but AMD and Broadcom aren't really in the same markets, especially since AMD sold Qualcomm their mobile GPUs (Radeon became Adreno)
I chose AMD because Intel is very aggressive about market segmentation. I wanted a MiniITX board with a low-power CPU and (at least) 4 SATA ports (so I could have RAID-Z and an optical drive). Intel Atom boards all restricted the number of SATA ports (a quick look now seems to show that they all come with 2 ports). If I wanted Intel and 4 SATA ports, I was pushed to the more expensive i3 range.
I don't think I, the grandparent, or anyone else was talking about lowering the pixel density, we were all talking about larger screens with the same pixel density.
Flat panel screens have the same yield issues as ICs (the process for creating them is vaguely similar). If you go from a 4" screen to a 8" screen, you quadruple the area, which quadruples the chance that there'll be a manufacturing error that will result in a dead / stuck pixel. This means that your yield drops by a factor of four.
Eventually, some one will figure out a way of creating really big panels and then cutting them to size, and then we'll have a large variety of screen sizes depending on where the defects happen to lie in a particular run.
I'd love to see Thunderbolt connections on phones. The connector is just about small enough for a phone and provides DisplayPort and enough PCIe bandwidth for a disk controller and a USB hub. Perhaps someone could come up with a connector that was slightly thinner (and wider) and contained Thunderbolt and power.
300dpi for print is actually a lot lower than 300ppi for displays. Each dot for print is, depending on your technology, either black, cyan, magenta or yellow, or one of a very small (typically 4-16) shades of these colours. For a display, you have at least 2^16 shades of colour for each pixel. This is why the output from a 300dpi inkjet looks a lot worse than a 70dpi monitor. For print, you typically use 2400dpi, which comes close to approximating 300ppi.
Personally, I find you hit diminishing returns after about 200ppi. It's easy to tell 70-100ppi apart from 200ppi, but 400ppi is only better if you look really carefully. 600ppi is a marketing gimmick (and will need more frame buffer memory and more CPU power to use, so is likely to drain the battery faster). On the plus side, hopefully this will mean that the 225ppi panels will become cheaper and I'll be able to get a cheap phone with a nice screen...
That doesn't quite make sense as you've described it, because you can still only push one operations in to the ALU or get them out on cycle boundaries relative to the rest of the pipeline. It may run in a different clock domain (modern Intel CPUs have several clock domains for various things) for internally pipelined operations, but that still gives you a best case of starting an operation one cycle and getting the result back the next (and, more plausibly, two later). For multi-cycle operations, like divide or multiply, it would give a noticeable speedup, because the throughput would double (although the latency would remain one cycle), but for single-cycle operations there'd be no detectable difference.
This is why Ben Laurie and others at Google (and elsewhere) are pushing certificate transparency. This is basically a mechanism to see that the certificate that you see for server X is the same as the certificate everyone else sees. It means that the NSA has to either steal the certificate that Google uses, or MITM all connections to Google to be able to compromise the connection without detection. Or just ask Google to do it on their server...
The Core 2 and later were entirely new 64-bit microarchitectures. The Core 1 was the last that began life as a 32-bit design. That said, the integer data paths had been 64 bit since the Pentium. I don't really understand what the grandparent is claiming (you don't do things in half a clock cycle - it's the discrete unit of time within a CPU). I suspect that he's confusing it with the Atom's implementation of SSE, which dispatched one 64-bit operation per cycle, so if you had two SSE operations back to back in the instruction stream there'd be an extra cycle of latency, but you still got the same performance improvement from denser instructions and only got one extra cycle of latency before the result was available. I had a student implement something similar last year, and found that this approach gave a very good ratio of performance to die area used (although on a more modern x86 chip you have a lot of spare transistors to play with, so now it doesn't make much sense to do the saving, and it doesn't help much with power consumption as it means the SSE execution units need to be powered for longer and you need a more complex micro-op path).
Exactly. Unless it's an experiment to see how well peer review works, putting it in Nature is pretty stupid. You're pretty much guaranteeing that people will try to reproduce your work and you'll be exposed. You can probably get away with it if you put it in a less prestigious journal, but if people start citing it then there's a good chance that someone will try to reproduce it, especially when the novelty of the article is that it's an easy way of doing a thing that loads of people want to do. And if it isn't read and cited enough that people want to reproduce it, it's pretty worthless (from a research career perspective) as a publication...
If you don't think Lamport has made a real difference already, then either you have no idea who he is, or you don't think computers are very important.
Finally, people who go to Microsoft Research tend to disappear and never be heard of again. No one knows why.
That's only true if you never go to any computer science conferences: if you do, you'll find a lot of good papers written by MSR people. They do, however, have an appalling track record of turning them into products. This has improved a bit over the past few years, but until then MS and MSR were effectively run as two different companies and ideas from MSR were unlikely to be exploited in MS products.
The cynical explanation is that MSR exists to provide talented people with a well-funded sandbox where they will play and not create companies that compete with MS. The more likely explanation is that MSR has a budget of around $5bn annually, has separate premises, and does not provide any incentive to its employees to get their work into products.
Facebook is only able to buy them because they can raise insane amounts of money selling shares (or buy partly with shares), and guess who is buying those shares...
I should try it again. I found it frustrating on my 400MHz machine that gameplay became really slow when the map became complex (2-3 minutes for all of the AI turns to run really breaks immersion), but on a modern machine it's probably quite a lot faster.
Actually, thinking about how long I spent playing it, maybe I shouldn't...
Don't start playing FTL unless you have a lot of spare time. It's about as addictive as Civilisation was back in the day - one of those games where you think you'll just explore a couple more systems and then realise that two more hours have elapsed. It's periodically on sale on GOG: I got it for $2.50, and it's been $5 a few times. I probably wouldn't have paid full price for it based on the screenshots, but based on the gameplay I'd say it would definitely be worth it. I think they priced it a bit too high though - at $2.50 it was an impulse purchase and I didn't care if I only played it a couple of times, and I suspect a lot more than four times as many people would have bought it on the same principle than would pay $10 for it. At $10, you most likely won't buy it unless you're pretty sure you'll enjoy it.
Amazon launched their app store long before they launched the Kindle Fire. It's not tightly integrated with the Kindle line, and you can download it as an apk. There's nothing stopping other manufacturers from building their own custom Android version and shipping the Amazon store by default. There's also F-Droid, which maintains a large repository of open source Android apps, and also makes available the infrastructure that they use to build it, so creating a vendor-specific app store with a moderate set of applications as a bootstrap would be quite easy.
I was quite impressed with the Kindle Fire. My stepfather got one for Christmas, and is now using it as his primary computer. It was very easy to set up and use. I did find the pervasive adverts somewhat annoying, but from a UI perspective Amazon has done a pretty good job at implementing something that is easy for non-technical users to set up and run. The walled garden aspect is quite troubling though, and more so given that it's quite an appealing garden: no one would care about walled gardens if they didn't contain things people wanted.
I had a look, and all of the proprietary Android apps that I'm currently running are available on the Amazon store, which you can download as an apk. I'd love to have a phone with the Amazon store and F-Droid installed by default, but without any of the Google things. If the device manufacturer would guarantee OTA security updates for 4-5 years, I'd buy one today.
The bold part looks like something that is almost certainly illegal, as it indicates that Google is controlling a cartel. If they put that in a public license agreement, then they need to fire their entire corporate legal team.
The big advantage that the tablet has over an eInk device of the same size is that you can scroll quickly. I found having an eBook reader that could only display half of an A4 page quite annoying, but on a tablet it's far less of a problem because you can slide the page up as you read it.
JavaScript is quite different in its use from most languages that live in VMs. Java or.NET applications, for example, tend to be quite long-lived and often CPU dependent, so spending a couple of seconds at the start optimising them can be a big win. The VM will then build some profiling data and recompile things based on that, and may do some other tricks.
With JavaScript, in most cases, the thing that users care the most about is load time. It's often better to use a simple AST interpreter for JavaScript than a clever compiler, because you can start executing the interpreter as soon as you've got the text. If you spend more than a few ms getting the JS ready to run, users notice even if the resulting code is faster.
The 'often' is the important bit here, because some pages use JavaScript extensively for animations, games, and so on. In this case, users will notice if it's slow. They'll also notice if it's eating all of the CPU on their mobile device and flattening the battery. It's better in this case to switch to an optimised compiled representation as soon as possible, because you can get away with running the game slowly for a few second (while it's typically loading assets and displaying splash screens anyway), but after that people notice.
In both cases, after a while you've got some useful profiling data and so you want to recompile and generate more optimised code (unless it's just doing menu animations and the JavaScript is using 1% of your CPU, in which case the compiler is likely to consume more CPU time than the compiled code will save). Ideally, you want to do this in the background, on another core (or, at least, on a lower-priority thread on the same core), because otherwise you're interrupting the thing that the user cares about to run the compiler.
Slashdot Mirror
Everything was available everywhere. Napster delivered MP3s, which worked on every device, including the dirt-cheap Chinese players. Netflix works on devices blessed by Netflix. I have a few friends who work there (in the OpenConnect group) and they say that there are about 80 types of devices (all with special streaming requirements) that they have to support. The Napster equivalent would just let me download H.264 video files with no DRM. I could play them on any device, including my old WebOS tablet (which is never going to be worth any company's time to support, but can happily play back H.264) or the FreeBSD box connected to my projector (similarly, far too small a nice to be worthwhile for Netflix to support). If a company wanted to create a Netflix-compatible appliance, they wouldn't have to talk to Netflix, they'd just use published APIs for getting the video files, and as long as the person using the device entered some valid login credentials it would work.
The arguments against this model?
The problem is that the studios are still seeing the world as a rent / buy dichotomy. For digital goods, the concept of renting doesn't make much sense. I don't want to pay to rent a movie, I want to pay to have on-demand access to an ever-growing catalogue of things that I might want to watch. Currently, the closest I get to that is with a DVD rental service, and that's a long way from ideal.
The problem is that we're trying to monetise the wrong thing. Creating a movie is a difficult and expensive endeavour. At the very least, you need some sets and actors, writers, and so on quite like to be paid. If you need to film on location or need special effects, the costs go up.
Copying a film is easy. Peer to peer distribution is also easy, but even in a client-server environment the cost of streaming / copying a movie across the Internet is pretty tiny.
So what does copyright do? It encourages a business model where you do the difficult and expensive bit for free and then try to recoup your loss (and, ideally, make a profit) by charging a lot for the easy bit. This worked when copying a painting meant hiring an artist or when copying a book meant paying a monk or even hiring a team of people to do the typesetting for your (very expensive) printing press. The only way that these business models can survive long term is by imposing limitations on technology to try to make copying hard again and they will always be lagging behind innovation if they do.
They are popular with FadCoin mining because they are good at GPGPU work. This also makes them attractive to people doing useful and productive work with them, which is (thankfully) a much larger market. Lots of clusters now have AMD GPUs for number crunching.
I bought an AMD E-350 motherboard and a Chenbro case with 4 removable drive bays. It takes a slimline optical drive (which actually has a BD-RE drive, because they weren't much more expensive than DVD drives, although in the 3 years since I bought it I've yet to burn a single BD).
It's running FreeBSD, booting from a RAID-Z array (so cheap snapshots, block-level checksums, single drive failure recovery, and all of that good stuff). The GPU is now supported and so it runs XBMC connected to my projector for video playback too.
There's also an e-SATA port that I should be using for external backups, but am not currently...
That doesn't really make sense. The architectures of the three main GPU vendors are sufficiently different that it's highly unlikely that the can benefit much from tricks in the drivers (which are basically compiler optimisations these days, since the performance-critical part of the driver is the shader compiler). nVidia uses something that looks more or less like a scalar CPU (with some SIMD) but with SIMT so that if you run threads in lockstep they just do one decode but execute several steps at once. AMD is a VLIW-inspired design. Intel is a more classical SIMD architecture, but with the tweak that their vector register set is 2D and each operand encodes a start and a stripe size, so you can do vertical or diagonal stripes through the register set and don't have to do vector permutes. Intel and AMD put more of the parallelisation into the compiler (drivers) than nVidia, but the transforms that they do are quite different.
There's more of a chance that AMD drivers would help Broadcom than anyone else, but AMD and Broadcom aren't really in the same markets, especially since AMD sold Qualcomm their mobile GPUs (Radeon became Adreno)
I chose AMD because Intel is very aggressive about market segmentation. I wanted a MiniITX board with a low-power CPU and (at least) 4 SATA ports (so I could have RAID-Z and an optical drive). Intel Atom boards all restricted the number of SATA ports (a quick look now seems to show that they all come with 2 ports). If I wanted Intel and 4 SATA ports, I was pushed to the more expensive i3 range.
I don't think I, the grandparent, or anyone else was talking about lowering the pixel density, we were all talking about larger screens with the same pixel density.
Flat panel screens have the same yield issues as ICs (the process for creating them is vaguely similar). If you go from a 4" screen to a 8" screen, you quadruple the area, which quadruples the chance that there'll be a manufacturing error that will result in a dead / stuck pixel. This means that your yield drops by a factor of four.
Eventually, some one will figure out a way of creating really big panels and then cutting them to size, and then we'll have a large variety of screen sizes depending on where the defects happen to lie in a particular run.
I'd love to see Thunderbolt connections on phones. The connector is just about small enough for a phone and provides DisplayPort and enough PCIe bandwidth for a disk controller and a USB hub. Perhaps someone could come up with a connector that was slightly thinner (and wider) and contained Thunderbolt and power.
300dpi for print is actually a lot lower than 300ppi for displays. Each dot for print is, depending on your technology, either black, cyan, magenta or yellow, or one of a very small (typically 4-16) shades of these colours. For a display, you have at least 2^16 shades of colour for each pixel. This is why the output from a 300dpi inkjet looks a lot worse than a 70dpi monitor. For print, you typically use 2400dpi, which comes close to approximating 300ppi.
Personally, I find you hit diminishing returns after about 200ppi. It's easy to tell 70-100ppi apart from 200ppi, but 400ppi is only better if you look really carefully. 600ppi is a marketing gimmick (and will need more frame buffer memory and more CPU power to use, so is likely to drain the battery faster). On the plus side, hopefully this will mean that the 225ppi panels will become cheaper and I'll be able to get a cheap phone with a nice screen...
That doesn't quite make sense as you've described it, because you can still only push one operations in to the ALU or get them out on cycle boundaries relative to the rest of the pipeline. It may run in a different clock domain (modern Intel CPUs have several clock domains for various things) for internally pipelined operations, but that still gives you a best case of starting an operation one cycle and getting the result back the next (and, more plausibly, two later). For multi-cycle operations, like divide or multiply, it would give a noticeable speedup, because the throughput would double (although the latency would remain one cycle), but for single-cycle operations there'd be no detectable difference.
This is why Ben Laurie and others at Google (and elsewhere) are pushing certificate transparency. This is basically a mechanism to see that the certificate that you see for server X is the same as the certificate everyone else sees. It means that the NSA has to either steal the certificate that Google uses, or MITM all connections to Google to be able to compromise the connection without detection. Or just ask Google to do it on their server...
The Core 2 and later were entirely new 64-bit microarchitectures. The Core 1 was the last that began life as a 32-bit design. That said, the integer data paths had been 64 bit since the Pentium. I don't really understand what the grandparent is claiming (you don't do things in half a clock cycle - it's the discrete unit of time within a CPU). I suspect that he's confusing it with the Atom's implementation of SSE, which dispatched one 64-bit operation per cycle, so if you had two SSE operations back to back in the instruction stream there'd be an extra cycle of latency, but you still got the same performance improvement from denser instructions and only got one extra cycle of latency before the result was available. I had a student implement something similar last year, and found that this approach gave a very good ratio of performance to die area used (although on a more modern x86 chip you have a lot of spare transistors to play with, so now it doesn't make much sense to do the saving, and it doesn't help much with power consumption as it means the SSE execution units need to be powered for longer and you need a more complex micro-op path).
Exactly. Unless it's an experiment to see how well peer review works, putting it in Nature is pretty stupid. You're pretty much guaranteeing that people will try to reproduce your work and you'll be exposed. You can probably get away with it if you put it in a less prestigious journal, but if people start citing it then there's a good chance that someone will try to reproduce it, especially when the novelty of the article is that it's an easy way of doing a thing that loads of people want to do. And if it isn't read and cited enough that people want to reproduce it, it's pretty worthless (from a research career perspective) as a publication...
If you don't think Lamport has made a real difference already, then either you have no idea who he is, or you don't think computers are very important.
Finally, people who go to Microsoft Research tend to disappear and never be heard of again. No one knows why.
That's only true if you never go to any computer science conferences: if you do, you'll find a lot of good papers written by MSR people. They do, however, have an appalling track record of turning them into products. This has improved a bit over the past few years, but until then MS and MSR were effectively run as two different companies and ideas from MSR were unlikely to be exploited in MS products.
The cynical explanation is that MSR exists to provide talented people with a well-funded sandbox where they will play and not create companies that compete with MS. The more likely explanation is that MSR has a budget of around $5bn annually, has separate premises, and does not provide any incentive to its employees to get their work into products.
Facebook is only able to buy them because they can raise insane amounts of money selling shares (or buy partly with shares), and guess who is buying those shares...
I should try it again. I found it frustrating on my 400MHz machine that gameplay became really slow when the map became complex (2-3 minutes for all of the AI turns to run really breaks immersion), but on a modern machine it's probably quite a lot faster.
Actually, thinking about how long I spent playing it, maybe I shouldn't...
Don't start playing FTL unless you have a lot of spare time. It's about as addictive as Civilisation was back in the day - one of those games where you think you'll just explore a couple more systems and then realise that two more hours have elapsed. It's periodically on sale on GOG: I got it for $2.50, and it's been $5 a few times. I probably wouldn't have paid full price for it based on the screenshots, but based on the gameplay I'd say it would definitely be worth it. I think they priced it a bit too high though - at $2.50 it was an impulse purchase and I didn't care if I only played it a couple of times, and I suspect a lot more than four times as many people would have bought it on the same principle than would pay $10 for it. At $10, you most likely won't buy it unless you're pretty sure you'll enjoy it.
Amazon launched their app store long before they launched the Kindle Fire. It's not tightly integrated with the Kindle line, and you can download it as an apk. There's nothing stopping other manufacturers from building their own custom Android version and shipping the Amazon store by default. There's also F-Droid, which maintains a large repository of open source Android apps, and also makes available the infrastructure that they use to build it, so creating a vendor-specific app store with a moderate set of applications as a bootstrap would be quite easy.
I was quite impressed with the Kindle Fire. My stepfather got one for Christmas, and is now using it as his primary computer. It was very easy to set up and use. I did find the pervasive adverts somewhat annoying, but from a UI perspective Amazon has done a pretty good job at implementing something that is easy for non-technical users to set up and run. The walled garden aspect is quite troubling though, and more so given that it's quite an appealing garden: no one would care about walled gardens if they didn't contain things people wanted.
I had a look, and all of the proprietary Android apps that I'm currently running are available on the Amazon store, which you can download as an apk. I'd love to have a phone with the Amazon store and F-Droid installed by default, but without any of the Google things. If the device manufacturer would guarantee OTA security updates for 4-5 years, I'd buy one today.
The bold part looks like something that is almost certainly illegal, as it indicates that Google is controlling a cartel. If they put that in a public license agreement, then they need to fire their entire corporate legal team.
The big advantage that the tablet has over an eInk device of the same size is that you can scroll quickly. I found having an eBook reader that could only display half of an A4 page quite annoying, but on a tablet it's far less of a problem because you can slide the page up as you read it.
With JavaScript, in most cases, the thing that users care the most about is load time. It's often better to use a simple AST interpreter for JavaScript than a clever compiler, because you can start executing the interpreter as soon as you've got the text. If you spend more than a few ms getting the JS ready to run, users notice even if the resulting code is faster.
The 'often' is the important bit here, because some pages use JavaScript extensively for animations, games, and so on. In this case, users will notice if it's slow. They'll also notice if it's eating all of the CPU on their mobile device and flattening the battery. It's better in this case to switch to an optimised compiled representation as soon as possible, because you can get away with running the game slowly for a few second (while it's typically loading assets and displaying splash screens anyway), but after that people notice.
In both cases, after a while you've got some useful profiling data and so you want to recompile and generate more optimised code (unless it's just doing menu animations and the JavaScript is using 1% of your CPU, in which case the compiler is likely to consume more CPU time than the compiled code will save). Ideally, you want to do this in the background, on another core (or, at least, on a lower-priority thread on the same core), because otherwise you're interrupting the thing that the user cares about to run the compiler.