There's no hypocrisy if your distinction is one of scale. I regard censorship as only being bad when it has an impact on an individual's ability to speak freely. There is no problem with a single newspaper refusing to carry something, as long as there are other newspapers that are willing to run it or some other (relatively easy) mechanism for publication. There is a problem if a government or an industry body says 'no one may run this story'. There's a difference between saying 'you may not post this opinion on my blog' and saying 'you may not post this opinion on any blog'. The latter is dangerous censorship, the former is exercising free speech - the thing that rules about censorship are supposed to protect. It only becomes a problem when everyone with the infrastructure to host blogs says 'you may not post this on a blog that I run', at which point there should be government intervention.
There are lots of IP companies that no one has a problem with. There are basically two business models for IP companies:
File or buy a load of patents and then, the next time someone independently invents something you've patented, ask for royalties and sue them if you don't get them.
Design things of value and sell the rights to use the designs to companies that would end up paying more if they developed something in house.
There are a load of companies in the second category that are very profitable and usually respected. It's the ones in the first category that give them all a bad name.
That's a bit closer to what I was expecting. Last time I did these calculations, I came up with a figure of something like 100 years at my usage pattern. Seeing this drop to 5 years is somewhat alarming, but not too far off the trends we've seen with decreasing numbers of rewrites per cell in modern flash.
As for PCs you can program your decoder in CUDA or OpenCL so "hardware support" is not very important.
Mobile GPUs are also programmable, but without knowing the details of the algorithms involved it's hard to say what kind of speedup you'll get from a GPU. In general, later generations of video CODECs require inferring more from larger areas and so are less amenable to the kind of access that a GPU's memory controller is optimised for. Just doing something on the GPU isn't an automatic speedup, and until we see real implementations it's hard to say exactly how much better it will be.
Every time someone gives numbers like these, I look at my laptop's uptime and disk write counters and see what they say. Apparently I've written an average of about 13GB/day since my last reboot. This machine has a 256GB SSD, so if the write endurance scales linearly with the size as your numbers imply (assumes near-perfect wear levelling), this would give it a 24TB limit. I'd reach that limit in just over 5 years, which is a bit longer than the typical time that I use a laptop as my primary machine. It's probably adequate - I feel very nervous using hard disks that are over that age. I'd feel a lot happier with something a bit further away from the 5-year mark though...
Oracle is expensive, but if it were really overpriced then you'd see lots of cheaper alternatives. For a lot of workloads, something like PostgreSQL will get the job done for a fraction of the price. When you really need something at the high end, however, Oracle or a small handful of other companies will charge you similar amounts. The real problem for a company like Oracle is the same as the problem for SGI. In the '90s, a database with a few GBs of data was something you needed Oracle (or similar) and a lot of hardware for. Now, a cheap commodity machine can keep the whole thing in RAM for read-only queries and can write to an SSD (or a few in RAID-1) for a few thousand dollars, including the time it takes someone to set it up. The number of companies that have data of a size where an Oracle DB will work is increasingly small: at the very high end, you have companies like Google and Facebook that can't use any off-the-shelf solution, and at the other you have companies that can get away with cheap commodity hardware and an open source RDBMS.
This is why companies like IBM and Oracle are focussing heavily on business applications and vertical integration. They may be expensive, but there's a whole class of medium sized enterprises for whom it's a lot cheaper to periodically give a huge pile of money to Oracle periodically than it is to have a large in-house IT staff.
Companies have no incentive to invest in infrastructure if most of the benefits will be reaped by other companies. If one company owns an entire campus, town, or island, then they are generally good at improving the infrastructure. If such an area is owned by a diverse set of companies and individuals, then good infrastructure is rarely an emergent phenomenon, unless some organisation is responsible for collecting money to pay for it and for providing it. This organisation is traditionally referred to as a government...
Even for sequential reads, SSDs can be an improvement. My laptop's SSD can easily handle 200MB/s sequential reads, and you'd need more than one spinning disk to handle that. And a lot of things that seem like sequential reads at a high level turn out not to be. Netflix's streaming boxes, for example, sound like a poster child for sequential reads, but once you factor in the number of clients connected to each one, you end up with a large number of 1MB random reads, which means your IOPS numbers translate directly to throughput.
Spinning disks are still best where capacity is more important than access times. For example, hosting a lot of VMs where each one is typically accessing a small amount of live data (which can be cached in RAM or SSD) but has several GBs of inactive data.
SAS doesn't really get you anything useful with an SSD. The extra chaining isn't that important, because it's easy to get enough SATA sockets to put one in each drive bay. There's no mSATA equivalent for denser storage, and if you really need the extra speed then why not go all the way and get something like FusionIO cards that hang directly off the PCIe bus?
I compile large projects on a regular basis. We have one machine with 12 cores (24 threads) 256GB of RAM, so I tried running builds entirely to and from a RAM drive. The speed difference between that and using a mid-range SSD was too small to measure (-j12 up to -j64). The difference in performance between an SSD and a RAM drive is significantly greater than the difference between any two SSDs. In contrast, the difference between using a hard disk and an SSD is easily a factor of 2 in terms of build speed and often more.
Video editing is typically done in a nondestructive fashion, so you do a big copy to get the initial data on, but then it's comparatively small transactions. It's been almost 10 years since I did any, but I think the basic approach is still the same. You grab the data from the camera (easier now - back then FireWire was essential because you were getting DV footage from tape with no buffering in the camera, so you needed isochronous transfer. Now flash costs about as little as tapes did). DV footage was 10GB/hour, which was a bit painful to edit with 1GB of RAM, but a modern system with 32+GB of RAM it's nothing. HD footage for consumer editing is about the same data rate. For pro stuff, I believe about 40GB/hour is still common, but even that fits nicely in 64GB of RAM.
You're then going to be streaming it through some filters (typically on the GPU, but sometimes on the CPU) and writing the results out to cached render files. These are fairly small (order of 100MB or so) files containing short composited sequences. When you play, you're doing a lot of random seeks to get all of these and play them in sequence (or just cache them in RAM - with 64GB that's quite feasible, with 128GB it's easy).
Finally, you'll write out the whole rendered sequence. Your cached pre-renders might be at lower quality than this, so you might not use them for the final step, in which case you do have something like a simple copy with some processing in the middle.
Yes, but the best random number generator would return 0000000001 for exactly one phone in 10000000000, so if you sent 0000000001 to a single phone you'd have an insignificant chance of bricking it, and if you sent it to all phones you'd have a small chance of bricking one.
No, your plan isn't completely unworkable, but unless you are completely confident in your random number generator (possible, but hard), you have the potential for a really expensive recall when someone works it out. With 10 digits, you have about 33 bits of entropy. That's not a trivial search space, but it may be possible to brute force if it's something you can do over the local network. If you can do 1000/second, it will probably take about 1-2 months. 10,000/second, and you can do it in a week. Pretty obvious network traffic though. If, however, your random number generator is a lot less random than you think, then in this kind of thing you may end up with only 16 bits of entropy (random number generator errors in the past have resulted in a lot less than half the expected entropy). In that case, at 1000/second you could probably brute force it in about half a minute, and definitely do it in slightly over a minute.
And that's assuming the only flaw is in the random number generator. A more common error in implementing this kind of system would be a timing error in checking the code. If the time taken to process the key is related to the number of digits that you got right, then you can easily target a phone to disable, even with a strong random number generator.
Sure, it's possible to do it right. It's just a lot easier to do it wrong. There's only one way of doing it right and there are hundreds of ways of doing it wrong...
If the pin is 10 digits then "they" are wasting their time
Assuming that they are generated by a strong random number generator. Of course, there are no recent examples of random number generators having a lot less entropy than was believed (or required for the application). Well, except for that whole chip-and-pin thing. And the Debian OpenSSL packages. And...
Well, it's definitely for nerds, but the Tesselation paper was published in 2009, so hardly news. For those that don't have ACM DL access, the paper is interesting, but suffers from many of the same problems as LibOS / Exokernel approaches.
You seem to forget there's one more phone available, likely at a reduced price
But not in the same market. Its IMEI will be blacklisted, so it won't be useable in the country in which it is stolen and often not anywhere where the manufacturer cares about sales. You could argue that Apple (for example) gets the same benefit from thefts as Microsoft does from piracy in emerging markets: stolen phones get a generation of people accustomed to using Apple devices, priming demand so that when the economy has grown to the level where a significant number of people can afford new iPhones, Apple can just start selling them.
I'm not sure about the USA, but when you steal a phone in most of Europe its IMEI is blacklisted and it can no longer be used on any of the networks. Thieves get around this by exporting the phones (well, the small-time thieves sell to someone else who will export them) to countries with networks that don't participate in this scheme. The phones are then sold for a very small fraction of their retail cost. The people who buy them are not people who would be able to afford a new smartphone.
That sentence hurt my head, but even with what you mean it's irrelevant. In the USA, for example, 82% of the population lives in cities and suburbs and so could have most of their transportation needs met by mass transit and the gaps filled with taxis or schemes similar to ZipCar for occasional use.
I've only spent a few months in the USA, but I don't remember any restaurants I saw offering all-you-can-drink including alcoholic beverages along with a fixed price meal, and yet I recall this being fairly common in Tokyo. Or are you deliberately misreading the grandparent so that you can call him a retard?
There's nothing special about tablets, except for one thing: users don't expect backwards compatibility. You can make significant improvements if your customers don't expect to be able to use your product as a drop-in replacement for something else.
The hardware lock elision stuff is going to be more than just a little bit useful. It means that software that uses coarse-grained locking can get the same sort of performance as software using fine-grained locking and close to the performance of software written specifically to support transactional memory. It will be interesting to see if Intel's cross-licensing agreements with other chip makers includes the relevant patents. If it's something that is widely adopted, then it is likely to change how we write parallel software. If not, then it will just make certain categories of code significantly more scalable on Intel than other CPUs.
Non-Google Jabber accounts are less common than Google accounts
Not entirely representative, but on my Jabber roster about 30% are Google people, and about half of them are Google employees. I wonder how many Google Talk users have no non-Google people on their roster, and will be happy to learn that Google has just decided that they can no longer talk to them.
If the problem is wealth inequality, then you don't make it an explicit cap, you make it a ratio. Say, no person should be able to control more wealth than 100 times the median. That would mean, today, that a wealthy person would be in a position to live comfortably and never have to work again, which sounds like it's sufficient incentive for the people whose only motivation for doing things that benefit society is collecting personal wealth (I've never met any such people, but according to posts above they exist). And, if someone really wants more, then the incentives are set up so that they can get a lot more by increasing the median wealth a small amount...
Uh, no. An API is not subject to copyright, and so you can't sue someone for writing code to an API or reimplementing that API. That has absolutely nothing to do with whether you can use a specific service in a specific way. Google could not stop someone else implementing the YouTube APIs on a different media hosting site.
I think Microsoft has been quite clever here. They're now in the situations where they're giving their customers something that they want, and Google is telling them that they can't. They can't really lose: if they can keep offering the app in the same format, then they can provide a better experience than other platforms. If they can't, then they have some good material for their next round of anti-Google adverts.
Slashdot Mirror
There's no hypocrisy if your distinction is one of scale. I regard censorship as only being bad when it has an impact on an individual's ability to speak freely. There is no problem with a single newspaper refusing to carry something, as long as there are other newspapers that are willing to run it or some other (relatively easy) mechanism for publication. There is a problem if a government or an industry body says 'no one may run this story'. There's a difference between saying 'you may not post this opinion on my blog' and saying 'you may not post this opinion on any blog'. The latter is dangerous censorship, the former is exercising free speech - the thing that rules about censorship are supposed to protect. It only becomes a problem when everyone with the infrastructure to host blogs says 'you may not post this on a blog that I run', at which point there should be government intervention.
There are a load of companies in the second category that are very profitable and usually respected. It's the ones in the first category that give them all a bad name.
That's a bit closer to what I was expecting. Last time I did these calculations, I came up with a figure of something like 100 years at my usage pattern. Seeing this drop to 5 years is somewhat alarming, but not too far off the trends we've seen with decreasing numbers of rewrites per cell in modern flash.
As for PCs you can program your decoder in CUDA or OpenCL so "hardware support" is not very important.
Mobile GPUs are also programmable, but without knowing the details of the algorithms involved it's hard to say what kind of speedup you'll get from a GPU. In general, later generations of video CODECs require inferring more from larger areas and so are less amenable to the kind of access that a GPU's memory controller is optimised for. Just doing something on the GPU isn't an automatic speedup, and until we see real implementations it's hard to say exactly how much better it will be.
Every time someone gives numbers like these, I look at my laptop's uptime and disk write counters and see what they say. Apparently I've written an average of about 13GB/day since my last reboot. This machine has a 256GB SSD, so if the write endurance scales linearly with the size as your numbers imply (assumes near-perfect wear levelling), this would give it a 24TB limit. I'd reach that limit in just over 5 years, which is a bit longer than the typical time that I use a laptop as my primary machine. It's probably adequate - I feel very nervous using hard disks that are over that age. I'd feel a lot happier with something a bit further away from the 5-year mark though...
Oracle is expensive, but if it were really overpriced then you'd see lots of cheaper alternatives. For a lot of workloads, something like PostgreSQL will get the job done for a fraction of the price. When you really need something at the high end, however, Oracle or a small handful of other companies will charge you similar amounts. The real problem for a company like Oracle is the same as the problem for SGI. In the '90s, a database with a few GBs of data was something you needed Oracle (or similar) and a lot of hardware for. Now, a cheap commodity machine can keep the whole thing in RAM for read-only queries and can write to an SSD (or a few in RAID-1) for a few thousand dollars, including the time it takes someone to set it up. The number of companies that have data of a size where an Oracle DB will work is increasingly small: at the very high end, you have companies like Google and Facebook that can't use any off-the-shelf solution, and at the other you have companies that can get away with cheap commodity hardware and an open source RDBMS.
This is why companies like IBM and Oracle are focussing heavily on business applications and vertical integration. They may be expensive, but there's a whole class of medium sized enterprises for whom it's a lot cheaper to periodically give a huge pile of money to Oracle periodically than it is to have a large in-house IT staff.
Companies have no incentive to invest in infrastructure if most of the benefits will be reaped by other companies. If one company owns an entire campus, town, or island, then they are generally good at improving the infrastructure. If such an area is owned by a diverse set of companies and individuals, then good infrastructure is rarely an emergent phenomenon, unless some organisation is responsible for collecting money to pay for it and for providing it. This organisation is traditionally referred to as a government...
Even for sequential reads, SSDs can be an improvement. My laptop's SSD can easily handle 200MB/s sequential reads, and you'd need more than one spinning disk to handle that. And a lot of things that seem like sequential reads at a high level turn out not to be. Netflix's streaming boxes, for example, sound like a poster child for sequential reads, but once you factor in the number of clients connected to each one, you end up with a large number of 1MB random reads, which means your IOPS numbers translate directly to throughput.
Spinning disks are still best where capacity is more important than access times. For example, hosting a lot of VMs where each one is typically accessing a small amount of live data (which can be cached in RAM or SSD) but has several GBs of inactive data.
SAS doesn't really get you anything useful with an SSD. The extra chaining isn't that important, because it's easy to get enough SATA sockets to put one in each drive bay. There's no mSATA equivalent for denser storage, and if you really need the extra speed then why not go all the way and get something like FusionIO cards that hang directly off the PCIe bus?
I compile large projects on a regular basis. We have one machine with 12 cores (24 threads) 256GB of RAM, so I tried running builds entirely to and from a RAM drive. The speed difference between that and using a mid-range SSD was too small to measure (-j12 up to -j64). The difference in performance between an SSD and a RAM drive is significantly greater than the difference between any two SSDs. In contrast, the difference between using a hard disk and an SSD is easily a factor of 2 in terms of build speed and often more.
Video editing is typically done in a nondestructive fashion, so you do a big copy to get the initial data on, but then it's comparatively small transactions. It's been almost 10 years since I did any, but I think the basic approach is still the same. You grab the data from the camera (easier now - back then FireWire was essential because you were getting DV footage from tape with no buffering in the camera, so you needed isochronous transfer. Now flash costs about as little as tapes did). DV footage was 10GB/hour, which was a bit painful to edit with 1GB of RAM, but a modern system with 32+GB of RAM it's nothing. HD footage for consumer editing is about the same data rate. For pro stuff, I believe about 40GB/hour is still common, but even that fits nicely in 64GB of RAM.
You're then going to be streaming it through some filters (typically on the GPU, but sometimes on the CPU) and writing the results out to cached render files. These are fairly small (order of 100MB or so) files containing short composited sequences. When you play, you're doing a lot of random seeks to get all of these and play them in sequence (or just cache them in RAM - with 64GB that's quite feasible, with 128GB it's easy).
Finally, you'll write out the whole rendered sequence. Your cached pre-renders might be at lower quality than this, so you might not use them for the final step, in which case you do have something like a simple copy with some processing in the middle.
Yes, but the best random number generator would return 0000000001 for exactly one phone in 10000000000, so if you sent 0000000001 to a single phone you'd have an insignificant chance of bricking it, and if you sent it to all phones you'd have a small chance of bricking one.
Ah, starting with an ad hominem, good job.
No, your plan isn't completely unworkable, but unless you are completely confident in your random number generator (possible, but hard), you have the potential for a really expensive recall when someone works it out. With 10 digits, you have about 33 bits of entropy. That's not a trivial search space, but it may be possible to brute force if it's something you can do over the local network. If you can do 1000/second, it will probably take about 1-2 months. 10,000/second, and you can do it in a week. Pretty obvious network traffic though. If, however, your random number generator is a lot less random than you think, then in this kind of thing you may end up with only 16 bits of entropy (random number generator errors in the past have resulted in a lot less than half the expected entropy). In that case, at 1000/second you could probably brute force it in about half a minute, and definitely do it in slightly over a minute.
And that's assuming the only flaw is in the random number generator. A more common error in implementing this kind of system would be a timing error in checking the code. If the time taken to process the key is related to the number of digits that you got right, then you can easily target a phone to disable, even with a strong random number generator.
Sure, it's possible to do it right. It's just a lot easier to do it wrong. There's only one way of doing it right and there are hundreds of ways of doing it wrong...
If the pin is 10 digits then "they" are wasting their time
Assuming that they are generated by a strong random number generator. Of course, there are no recent examples of random number generators having a lot less entropy than was believed (or required for the application). Well, except for that whole chip-and-pin thing. And the Debian OpenSSL packages. And...
Well, it's definitely for nerds, but the Tesselation paper was published in 2009, so hardly news. For those that don't have ACM DL access, the paper is interesting, but suffers from many of the same problems as LibOS / Exokernel approaches.
You seem to forget there's one more phone available, likely at a reduced price
But not in the same market. Its IMEI will be blacklisted, so it won't be useable in the country in which it is stolen and often not anywhere where the manufacturer cares about sales. You could argue that Apple (for example) gets the same benefit from thefts as Microsoft does from piracy in emerging markets: stolen phones get a generation of people accustomed to using Apple devices, priming demand so that when the economy has grown to the level where a significant number of people can afford new iPhones, Apple can just start selling them.
I'm not sure about the USA, but when you steal a phone in most of Europe its IMEI is blacklisted and it can no longer be used on any of the networks. Thieves get around this by exporting the phones (well, the small-time thieves sell to someone else who will export them) to countries with networks that don't participate in this scheme. The phones are then sold for a very small fraction of their retail cost. The people who buy them are not people who would be able to afford a new smartphone.
That sentence hurt my head, but even with what you mean it's irrelevant. In the USA, for example, 82% of the population lives in cities and suburbs and so could have most of their transportation needs met by mass transit and the gaps filled with taxis or schemes similar to ZipCar for occasional use.
I've only spent a few months in the USA, but I don't remember any restaurants I saw offering all-you-can-drink including alcoholic beverages along with a fixed price meal, and yet I recall this being fairly common in Tokyo. Or are you deliberately misreading the grandparent so that you can call him a retard?
There's nothing special about tablets, except for one thing: users don't expect backwards compatibility. You can make significant improvements if your customers don't expect to be able to use your product as a drop-in replacement for something else.
The hardware lock elision stuff is going to be more than just a little bit useful. It means that software that uses coarse-grained locking can get the same sort of performance as software using fine-grained locking and close to the performance of software written specifically to support transactional memory. It will be interesting to see if Intel's cross-licensing agreements with other chip makers includes the relevant patents. If it's something that is widely adopted, then it is likely to change how we write parallel software. If not, then it will just make certain categories of code significantly more scalable on Intel than other CPUs.
Non-Google Jabber accounts are less common than Google accounts
Not entirely representative, but on my Jabber roster about 30% are Google people, and about half of them are Google employees. I wonder how many Google Talk users have no non-Google people on their roster, and will be happy to learn that Google has just decided that they can no longer talk to them.
Do you want to point out something that was wrong in my post, or are you just trolling?
If the problem is wealth inequality, then you don't make it an explicit cap, you make it a ratio. Say, no person should be able to control more wealth than 100 times the median. That would mean, today, that a wealthy person would be in a position to live comfortably and never have to work again, which sounds like it's sufficient incentive for the people whose only motivation for doing things that benefit society is collecting personal wealth (I've never met any such people, but according to posts above they exist). And, if someone really wants more, then the incentives are set up so that they can get a lot more by increasing the median wealth a small amount...
Uh, no. An API is not subject to copyright, and so you can't sue someone for writing code to an API or reimplementing that API. That has absolutely nothing to do with whether you can use a specific service in a specific way. Google could not stop someone else implementing the YouTube APIs on a different media hosting site.
I think Microsoft has been quite clever here. They're now in the situations where they're giving their customers something that they want, and Google is telling them that they can't. They can't really lose: if they can keep offering the app in the same format, then they can provide a better experience than other platforms. If they can't, then they have some good material for their next round of anti-Google adverts.