You're making a lot of assumptions about the wear leveling algorithm that while generally correct, aren't guaranteed. As for me, I find myself very uncomfortable knowing that the reliability of my data depends on a smart controller that uses tricks to extend the life of the parts by many orders of magnitude and that without such tricks, I'd start losing data in hours.
That said, you're right that under a typical workload, it should last years, assuming the wear leveling algorithm is good.
Now let's come back to reality. A million write cycles is not typical of most flash parts that are commonly used in devices these days. The ones that last that long are relatively expensive. If your OS uses the same block every time and if the wear leveling is on a per-flash-part rather than per-device basis, a more typical MLC flash write cycle limit of 10,000 writes can be exhausted in days if you're unlucky.
Start by writing a file, then write the file after it. The OS sends the writes. The drive interprets them. If the second set of writes isn't close enough to get grouped with the first, you've now erased and rewritten the flash block that contains those two files twice. If the wear leveling is done with a fairly lightweight scheme---say maintaining a 10% pool of extra flash blocks and cycling them in when the write count exceeds a threshold, and if the wear leveling is per part, and if each part is 64 megabytes with a 512KB flash block size and you have 10% extra (6 megs) then you only have 13 times as many writes as if you had no wear leveling at all. 10,000 writes * 13 = 130,000 writes before you experience a failure on average. At 20 times per day times two erasures per CVS operation, that's a mere 9 years, and you're describing a fairly light load. If instead of two files, you have 50 files that all end up in the same flash block, you're potentially down to a little over four months.
So the answer to the question of whether a SSD would be suitable or not is pretty complex and depends highly on how well the wear leveling is implemented and on the write count of the flash parts in question. If we were seeing 1,000,000 write count MLC parts being used in most SSDs, the answer would be a lot clearer, though I'd rather see more on the order of 10,000,000 write cycles. Either way, that's not what SSDs typically use, and basing decisions on that could easily lead to very wrong assessments of usability.
You're right that magnetic drives don't have infinite life. They are more likely to fail due to a limited number of park cycles, but point taken. In the medium term, I suspect flash parts will replace hard drives (and particularly in laptops, where HDs have such poor life expectancy). I'm not quite ready to give them my complete trust yet, though.
The whole "millions" thing may be true for SLC parts. MLC parts (which are much cheaper) have much lower write counts. The best MLC flash I'm aware of is only rated for a million write cycles. Thousands or tens of thousands is more typical for MLC flash parts. Write amplification makes this even more fun, since it means that a write of one disk block can require rewriting many, many blocks that otherwise would not have been written. If the wear leveling algorithm is optimal, then it's a moot point. If the wear leveling is nowhere near optimal, you can create artificial workloads that will burn out a few cells on the flash part in hours, which is a bit problematic. There is no clear-cut answer for this sort of question, unfortunately, at least not with the current crop of MLC tech.
You're kidding, right? Mandatory binding arbitration clauses are struck down frequently. If both parties have comparable negotiating power, they are generally upheld, but that's the exception, not the rule, from what I've seen. The 9th circuit has been striking them down left and right. Even in the 6th circuit, for disagreements not stemming out of the terms of the contract itself, such clauses have been thrown out recently.
I'm not saying you can blow your nose on the binding arbitration clause, but it is a lot closer to the way a waiver of liability doesn't necessarily protect against claims of gross negligence, but rather tries to convince the injured party that they don't have a case so that they don't contact a lawyer in the first place. In other words, it's mostly a smoke screen more often than not, at least in the 9th Circuit. Your circuit may vary.
The problem is that these extensions aren't just used for long file names. IIRC, extra directory records in the FAT filesystem are also overloaded for other purposes like permissions, without which Linux et al would be unbootable off of FAT. I'd imagine that many of those uses would run afoul of the patent, but I could be wrong.
More to the point, if it only applies to its use for naming purposes and not to the concept of storing additional data about a file in additional directory entries with reserved type codes that older OSes ignore, then the invention should have been unpatentable anyway, as there's nothing particularly original about taking the Rock Ridge extension set from ISO-9660 and applying the exact same concept to FAT except insofar as it uses additional directory entries. That's literally all they did here. Instead of an additional entry in the system use area of the variable-length directory record, they use additional directory entries with a different type code, but that's basically caused by differences in how the filesystem describes a file....
Actually, there are plenty of patents on UDF, or at least patents on ways of implementing UDF whose performance is even slightly usable.... In other words, just making sure the UDF implementation in Linux is clear of patent issues would be a major headache. There's really no good solution for storing user data that can't potentially run afoul of patents short of convincing the courts to ban data format patents and void all existing patents in this area. It's yet another clear example of how patents are stifling innovation in the field of computing for anyone without a multi-billion-dollar patent portfolio.
And would make updating the thing nearly impossible. They do firmware updates by mounting it as a USB mass storage device. Without a hardware redesign to emulate FAT (which would probably also violate M$'s patents), they're pretty much stuck here.
This is why I've been arguing for nearly a decade that file and volume formats should not be patentable, nor the means used to read and write those formats. Free and open access to data formats is fundamentally crucial to the interoperability of all hardware and software, and as such, statutes should very clearly define those as part of a class explicitly excluded from patent protection. As soon as the courts allow even one patent like this to stand, they are pretty much saying "f**k you" to the entire computing industry and depriving consumers of their fundamental right to have access to data of their own creation. That data isn't Microsoft's. It belongs to the users, and it is a violation of the most fundamental rights of the users to deny them access to content that they create merely because they choose to not use a particular software product, regardless of whether that product is made by Microsoft, AutoCAD, or anybody else.
Locking down user content is fundamentally wrong and unjust, and any laws that allow a company to do so are also fundamentally wrong and unjust. Therefore, it is our right, nay, our duty to users everywhere to violate those bits of intellectual property at every possible opportunity until it becomes such a legal nightmare for these companies that they are forced to back down. Anything less would be uncivilized. I know this is no Rosa Parks moment, but it still very much necessary for the long-term viability of computing as we know it. Just say no to data format patents.
Nothing in my suggested wording prevents a patent from existing in a provisional state prior to the release of the product. Something like this would merely prevent patent litigation until the person or company who filed for the patent actually makes a product. If somebody steals a company's design, that company can still collect damages for any product their competitor produced without a patent license all the way back to the original provisional filing date. They just can't file the suit until they actually ship a product and the patent becomes extant.
Besides, given the current state of the USPTO, most patents don't actually get approved until years after the product was first made available for sale anyway.
In that patents are intended to protect actual inventions, no patent shall be granted on any hypothetical product or service, nor on any portion thereof, until such time as that product or service is rendered in a form suitable for use by others and is made openly available to the public in the form of sales of the product or use of the service. Should the product or service be removed from the market, the patent shall expire two years after the date that the product or service ceases to be generally available unless the patent is employed in a new product or service within that time period.
You're right that liquid lenses improve resolving power over cheap plastic lenses. The resolving power of liquid lenses, according to Varioptic, is about the same as that of glass lenses. Therefore, their real-world resolution will probably max out short of 10 MP, assuming a traditional cell phone lens diameter. They certainly can't go beyond that level, as 10 MP was right up against the resolving limit for a theoretically ideal lens; no lens, no matter how amazing, can change the laws of physics.
If you're above the real-world resolving power of the lens, it's not going to make any difference in terms of digital zoom, either. The resolving power of the lens defines the maximum useful resolution of the resulting image. Using an image sensor with greater resolution than the resolving power of the lens is a bit like taking Photoshop and having it scale up an image to a larger size by interpolation. You aren't getting any additional picture information that way because the information isn't there to get.
Could somebody explain what the point of a 10 MP CCD is with a typical cell phone lens being only 1.25 mm in diameter with a 3.5 mm focal length? That's like putting a Ferrari engine in a Pinto, but slightly less useful.
By my math, the resolving power of the lens provides for a horizontal resolution (at the red end of the spectrum) of just shy of 4,000 pixels in the long direction on a cell-phone-sized CCD, and that's if the lens is ground perfectly and if the alignment between lens and CCD is also perfect. Chances are, at 3600 pixels, a 10 MP photo is probably significantly exceeding the real-world resolving power of any real-world cell camera lens unless the lens costs $10,000 to grind and is glued to the sensor....
Not to mention that the light gathering capabilities of such a small lens are terrible and that the low light SNR of a CCD is inversely proportional to the number of pixels. Can a 10 MP cell phone camera take pictures of usable quality in anything less than the light of the sun going nova?
Seriously, I just don't get it. It's like they're adding pixel count because they can without stopping to consider whether they should.... Above about 3 MP, a cell camera makes no sense given the lens size, quality, and mounting tolerances. Maybe 5 MP. Maybe.
Here's what I don't get: why didn't the border patrol agent immediately instruct the guy to step away from the computer and walk across the room, then photograph the evidence? Also, how could somebody be so dumb as to show a border patrol agent child pornography in the first place? I mean, maybe I could see it if the person opens the computer and that's what's on the screen, maybe, but explicitly going through and showing off your stash of illegal videos to a border patrol agent has to be the dumbest thing any human being could possibly do short of showing off your collection of illegal narcotics in your suitcase at the same time.
Everything about this screams "The border patrol agent is lying" to me. I just have a really hard time believing that two people could both behave so unbelievably cluelessly in the same place over such a short period of time. Doesn't that normally cause some kind of tear in spacetime or something?:-D
More importantly, they can ask you to take that unencrypted data and prove that it encrypts to the output in evidence.
Actually, no, that's not going to work unless you encrypt each file individually using the exact same key. The order in which files are written or deleted on a disk causes the blocks of those files to occur in different blocks on disk. Therefore, putting together a new encrypted disk image will never (or at least should never) result in the same encrypted data beyond perhaps the first few bytes to account for the initial filesystem metadata, and only then if you create an image of the exact same size with the exact same name, etc. In short, you'd have to go through billions of possible permutations to get the same data back even if you used the same encryption key.
Also, the assumption that the same underlying encryption key is used for encrypting the new volume is almost certainly going to be wrong. In most crypto schemes, your password is merely used to protect the actual crypto key, which is different for each new encrypted volume. Bottom line is that if the crypto software doesn't suck, the number of permutations you'd have to try before you got the original encrypted volume back should be orders of magnitude greater than the effort needed to crack the key.
What he explicitly said is that the kindle creates extra value for the work. In return the people who created the material should share in that extra value.
Ah, but they do share in that extra value. You see, those people who have a hard time seeing would not have bought the text version of the book because they could not have read it. Therefore, either way, the vast, vast majority of people would be buying either the audio book or the printed book, not both. Therefore, a device that reads the text merely reduces the overhead for the book manufacturer by reducing the necessity of having two separate versions for these almost completely disjoint audiences. If anything, the publishers benefit from this sort of arrangement, were it sufficiently ubiquitous.
And lest you criticize this argument by saying that some people would buy the audio book for "reading" parts of the book in the car, then picking up where they left off in print, for everyone person who does this, far more than one person merely doesn't read the book while in the car. Those people now have the opportunity to do so at no cost, and many of them will. As a result, they will finish the book sooner, and will---yup, you guessed it---buy another book. Over a lifetime, this equates to many, many additional books that those people would not have had time to read otherwise. The result is a net increase in total sales, thus completely nullifying that argument, too.
The whole greedy "you should pay me for everything" mentality almost never works in favor of content creators, nor indeed even in favor of content publishers/distributors. When content creators and distributors act this way, everybody loses, not just the consumers who are harmed by having to pay twice for a single copy of the content. The usual consumer reaction would be "You mean I have to pay an extra fee to have this content read to me? Heck, no, I won't do that." And that would be the end of the Kindle.
Not to mention that what they want is basically impossible. Computers already have screen readers, and if you explicitly go out of your way to block screen readers, you're likely to get sued on ADA compliance grounds. In effect, they're asking eBook reader software vendors to put their backsides on the line and risk a lawsuit without giving them any support to back them up. When eBook software vendors start dropping like flies, that would be the beginning of the end for commercial eBooks in general.
Faced with a downturn in print readership, snubbing new markets is not a particularly bright idea. Thus, I tend to agree with the comment in the summary---the author's guild needs someone in charge who has a better grasp of new media and how best to make money off their content through those means rather than somebody who barely understands it and is blindly grasping at straws trying to find ways to grab a bigger piece of the new media pie. If this guy remains in charge, this story can't possibly have a happy ending.
What it could not do is play back the content through a software decoder. It doesn't have the storage to be a good Myth back end, and doesn't have the display hardware to be a good front end, though with an external USB display adapter, you could sort of make it work if the CPU could decode the video quickly enough. I'm not sure it could, though, once you add in the extra overhead of pushing the video stream over USB to a framebuffer.
No, to get the comparison right, you have to be irritatingly quoting Shakespeare at the presumed guilty party. Oh, and they have to lock up the presumed guilty person in a prison of no escape in the middle of an ice moon. Siberia, perhaps?
Agreed. Either it needs BPL or it needs Wi-Fi. Most people don't put an ethernet jack wherever they have a power connection, making this somewhat less than ideal for home automation purposes. I'd also like to see it have a relay to switch on and off a power outlet, but maybe that's just me.
Either way, it's a cool little piece of hardware. I'm just not quite sure what I could use it for. It's too underpowered for video encoding/decoding, has no power switching capabilities needed for it to control lights, doesn't have the CPU power to replace my web server (a C2D takes several seconds to render an image with dcraw; this would take several minutes), etc. Maybe coupled with some outboard piece of USB gear, it might serve some obscure purpose like controlling a motor to open and close window shades/awnings for solar heating purposes, but it would still have to be enclosed in some sort of box to safely mount it outdoors....
Do you work for Rambus or something? That's the exact opposite of what Wikipedia has to say. Basically, if I read it correctly, they say that Rambus listened in on a bunch of the JEDEC meetings and secretly started writing up patents on what was discussed, presumably including other people's ideas.
Either way, it's a moot point. Fully 19 standards organizations supported the request for certiorari on this. I think it's safe to say that standards bodies are busy writing rules to ensure that this can never happen again, but I also think that no standards body in their right mind is going to let Rambus participate again after this little stunt. As soon as JEDEC et al have finished working around the Rambus patents and the royalties dry up, Rambus is likely to shrivel up and die. They screwed a lot of companies with their actions, and that will not soon be forgotten. Scratch my back, and I scratch yours. Kick me until I bleed, and I lock you out of the playground.
Actually, assuming you're talking about an unmonitored repeater, you aren't knowingly doing anything, and thus, you should, at least in theory, be protected under the same sorts of DMCA exemptions as any other internet service provider that passes pirated/illegal content during the normal course of IP-based routing.
That said, if you do pass something inappropriate, IP number alone is almost certainly sufficient probable cause to obtain a search warrant. Having the same protection as an ISP doesn't mean they can't charge you with a crime or sue you for copyright violation, doesn't mean they can't confiscate your equipment, and doesn't mean the charges won't stick if they find evidence of the crime or copyright violation on your computer.
In short, if you are an innocent repeater, you are probably protected (though you may incur significant difficulty getting your confiscated equipment back), but if you are abusing your status as a repeater to mask the fact that you are doing something wrong, chances are they'll find you through some other means outside the scope of the protocol itself---possibly even outside the scope of the Internet entirely.
Slashdot Mirror
You're making a lot of assumptions about the wear leveling algorithm that while generally correct, aren't guaranteed. As for me, I find myself very uncomfortable knowing that the reliability of my data depends on a smart controller that uses tricks to extend the life of the parts by many orders of magnitude and that without such tricks, I'd start losing data in hours.
That said, you're right that under a typical workload, it should last years, assuming the wear leveling algorithm is good.
Now let's come back to reality. A million write cycles is not typical of most flash parts that are commonly used in devices these days. The ones that last that long are relatively expensive. If your OS uses the same block every time and if the wear leveling is on a per-flash-part rather than per-device basis, a more typical MLC flash write cycle limit of 10,000 writes can be exhausted in days if you're unlucky.
Start by writing a file, then write the file after it. The OS sends the writes. The drive interprets them. If the second set of writes isn't close enough to get grouped with the first, you've now erased and rewritten the flash block that contains those two files twice. If the wear leveling is done with a fairly lightweight scheme---say maintaining a 10% pool of extra flash blocks and cycling them in when the write count exceeds a threshold, and if the wear leveling is per part, and if each part is 64 megabytes with a 512KB flash block size and you have 10% extra (6 megs) then you only have 13 times as many writes as if you had no wear leveling at all. 10,000 writes * 13 = 130,000 writes before you experience a failure on average. At 20 times per day times two erasures per CVS operation, that's a mere 9 years, and you're describing a fairly light load. If instead of two files, you have 50 files that all end up in the same flash block, you're potentially down to a little over four months.
So the answer to the question of whether a SSD would be suitable or not is pretty complex and depends highly on how well the wear leveling is implemented and on the write count of the flash parts in question. If we were seeing 1,000,000 write count MLC parts being used in most SSDs, the answer would be a lot clearer, though I'd rather see more on the order of 10,000,000 write cycles. Either way, that's not what SSDs typically use, and basing decisions on that could easily lead to very wrong assessments of usability.
You're right that magnetic drives don't have infinite life. They are more likely to fail due to a limited number of park cycles, but point taken. In the medium term, I suspect flash parts will replace hard drives (and particularly in laptops, where HDs have such poor life expectancy). I'm not quite ready to give them my complete trust yet, though.
The 9th Circuit is legal precedent, at least for cases within the 9th Circuit.... But here you go.
Some links, many of which are not from the 9th:
http://www.iphonereal.com/iphone_news/200808/08-11492.html
http://www.uslaw.com/library/Legal_Research/Oregon_9th_Circ_Mandatory_Arbitration_Unconscionable.php?item=221171
http://www.thisistech.com/2008/01/25/class-actions-t-mobiles-mandatory-arbitration-clause-ruled-unconscionable-lawsuits/
http://www.constructionweblinks.com/Resources/Industry_Reports__Newsletters/Apr_02_2007/cour.html
http://www.metnews.com/articles/2007/omel051507.htm
http://www.calbizlit.com/cal_biz_lit/2007/09/how-to-get-out-.html
http://findarticles.com/p/articles/mi_qa3898/is_200103/ai_n8951872
http://www.allbusiness.com/legal/trial-procedure-appellate-decisions/8133987-1.html
http://www.stephenmmurphy.com/pdfs/Hancock_article.pdf
http://finance.yahoo.com/news/3rd-Circuit-Deals-Blow-to-law-14460950.html
http://kruismediation.com/cgi-bin/adrcases.cgi?case=ADR20071031.htm
http://www.justanswer.com/questions/16oig-wisconsin-courts-interpret-term
http://www.prweb.com/releases/2008/11/prweb1556074.htm
http://www.chicagobusinesslitigationlawyerblog.com/2008/10/chicago_federal_district_court_1.html
http://www.rtoonline.com/Content/Article/Aug_06/NewJerseyBindingArbitration081106.asp
The whole "millions" thing may be true for SLC parts. MLC parts (which are much cheaper) have much lower write counts. The best MLC flash I'm aware of is only rated for a million write cycles. Thousands or tens of thousands is more typical for MLC flash parts. Write amplification makes this even more fun, since it means that a write of one disk block can require rewriting many, many blocks that otherwise would not have been written. If the wear leveling algorithm is optimal, then it's a moot point. If the wear leveling is nowhere near optimal, you can create artificial workloads that will burn out a few cells on the flash part in hours, which is a bit problematic. There is no clear-cut answer for this sort of question, unfortunately, at least not with the current crop of MLC tech.
Consider a log-structured filesystem, perhaps....
Perl is hard. Let's use brainf*ck.
You're kidding, right? Mandatory binding arbitration clauses are struck down frequently. If both parties have comparable negotiating power, they are generally upheld, but that's the exception, not the rule, from what I've seen. The 9th circuit has been striking them down left and right. Even in the 6th circuit, for disagreements not stemming out of the terms of the contract itself, such clauses have been thrown out recently.
I'm not saying you can blow your nose on the binding arbitration clause, but it is a lot closer to the way a waiver of liability doesn't necessarily protect against claims of gross negligence, but rather tries to convince the injured party that they don't have a case so that they don't contact a lawyer in the first place. In other words, it's mostly a smoke screen more often than not, at least in the 9th Circuit. Your circuit may vary.
The problem is that these extensions aren't just used for long file names. IIRC, extra directory records in the FAT filesystem are also overloaded for other purposes like permissions, without which Linux et al would be unbootable off of FAT. I'd imagine that many of those uses would run afoul of the patent, but I could be wrong.
More to the point, if it only applies to its use for naming purposes and not to the concept of storing additional data about a file in additional directory entries with reserved type codes that older OSes ignore, then the invention should have been unpatentable anyway, as there's nothing particularly original about taking the Rock Ridge extension set from ISO-9660 and applying the exact same concept to FAT except insofar as it uses additional directory entries. That's literally all they did here. Instead of an additional entry in the system use area of the variable-length directory record, they use additional directory entries with a different type code, but that's basically caused by differences in how the filesystem describes a file....
Actually, there are plenty of patents on UDF, or at least patents on ways of implementing UDF whose performance is even slightly usable.... In other words, just making sure the UDF implementation in Linux is clear of patent issues would be a major headache. There's really no good solution for storing user data that can't potentially run afoul of patents short of convincing the courts to ban data format patents and void all existing patents in this area. It's yet another clear example of how patents are stifling innovation in the field of computing for anyone without a multi-billion-dollar patent portfolio.
And would make updating the thing nearly impossible. They do firmware updates by mounting it as a USB mass storage device. Without a hardware redesign to emulate FAT (which would probably also violate M$'s patents), they're pretty much stuck here.
This is why I've been arguing for nearly a decade that file and volume formats should not be patentable, nor the means used to read and write those formats. Free and open access to data formats is fundamentally crucial to the interoperability of all hardware and software, and as such, statutes should very clearly define those as part of a class explicitly excluded from patent protection. As soon as the courts allow even one patent like this to stand, they are pretty much saying "f**k you" to the entire computing industry and depriving consumers of their fundamental right to have access to data of their own creation. That data isn't Microsoft's. It belongs to the users, and it is a violation of the most fundamental rights of the users to deny them access to content that they create merely because they choose to not use a particular software product, regardless of whether that product is made by Microsoft, AutoCAD, or anybody else.
Locking down user content is fundamentally wrong and unjust, and any laws that allow a company to do so are also fundamentally wrong and unjust. Therefore, it is our right, nay, our duty to users everywhere to violate those bits of intellectual property at every possible opportunity until it becomes such a legal nightmare for these companies that they are forced to back down. Anything less would be uncivilized. I know this is no Rosa Parks moment, but it still very much necessary for the long-term viability of computing as we know it. Just say no to data format patents.
Nothing in my suggested wording prevents a patent from existing in a provisional state prior to the release of the product. Something like this would merely prevent patent litigation until the person or company who filed for the patent actually makes a product. If somebody steals a company's design, that company can still collect damages for any product their competitor produced without a patent license all the way back to the original provisional filing date. They just can't file the suit until they actually ship a product and the patent becomes extant.
Besides, given the current state of the USPTO, most patents don't actually get approved until years after the product was first made available for sale anyway.
In other words, the law should read:
In that patents are intended to protect actual inventions, no patent shall be granted on any hypothetical product or service, nor on any portion thereof, until such time as that product or service is rendered in a form suitable for use by others and is made openly available to the public in the form of sales of the product or use of the service. Should the product or service be removed from the market, the patent shall expire two years after the date that the product or service ceases to be generally available unless the patent is employed in a new product or service within that time period.
Or some such.
You're right that liquid lenses improve resolving power over cheap plastic lenses. The resolving power of liquid lenses, according to Varioptic, is about the same as that of glass lenses. Therefore, their real-world resolution will probably max out short of 10 MP, assuming a traditional cell phone lens diameter. They certainly can't go beyond that level, as 10 MP was right up against the resolving limit for a theoretically ideal lens; no lens, no matter how amazing, can change the laws of physics.
If you're above the real-world resolving power of the lens, it's not going to make any difference in terms of digital zoom, either. The resolving power of the lens defines the maximum useful resolution of the resulting image. Using an image sensor with greater resolution than the resolving power of the lens is a bit like taking Photoshop and having it scale up an image to a larger size by interpolation. You aren't getting any additional picture information that way because the information isn't there to get.
Could somebody explain what the point of a 10 MP CCD is with a typical cell phone lens being only 1.25 mm in diameter with a 3.5 mm focal length? That's like putting a Ferrari engine in a Pinto, but slightly less useful.
By my math, the resolving power of the lens provides for a horizontal resolution (at the red end of the spectrum) of just shy of 4,000 pixels in the long direction on a cell-phone-sized CCD, and that's if the lens is ground perfectly and if the alignment between lens and CCD is also perfect. Chances are, at 3600 pixels, a 10 MP photo is probably significantly exceeding the real-world resolving power of any real-world cell camera lens unless the lens costs $10,000 to grind and is glued to the sensor....
Not to mention that the light gathering capabilities of such a small lens are terrible and that the low light SNR of a CCD is inversely proportional to the number of pixels. Can a 10 MP cell phone camera take pictures of usable quality in anything less than the light of the sun going nova?
Seriously, I just don't get it. It's like they're adding pixel count because they can without stopping to consider whether they should.... Above about 3 MP, a cell camera makes no sense given the lens size, quality, and mounting tolerances. Maybe 5 MP. Maybe.
Here's what I don't get: why didn't the border patrol agent immediately instruct the guy to step away from the computer and walk across the room, then photograph the evidence? Also, how could somebody be so dumb as to show a border patrol agent child pornography in the first place? I mean, maybe I could see it if the person opens the computer and that's what's on the screen, maybe, but explicitly going through and showing off your stash of illegal videos to a border patrol agent has to be the dumbest thing any human being could possibly do short of showing off your collection of illegal narcotics in your suitcase at the same time.
Everything about this screams "The border patrol agent is lying" to me. I just have a really hard time believing that two people could both behave so unbelievably cluelessly in the same place over such a short period of time. Doesn't that normally cause some kind of tear in spacetime or something? :-D
Actually, no, that's not going to work unless you encrypt each file individually using the exact same key. The order in which files are written or deleted on a disk causes the blocks of those files to occur in different blocks on disk. Therefore, putting together a new encrypted disk image will never (or at least should never) result in the same encrypted data beyond perhaps the first few bytes to account for the initial filesystem metadata, and only then if you create an image of the exact same size with the exact same name, etc. In short, you'd have to go through billions of possible permutations to get the same data back even if you used the same encryption key.
Also, the assumption that the same underlying encryption key is used for encrypting the new volume is almost certainly going to be wrong. In most crypto schemes, your password is merely used to protect the actual crypto key, which is different for each new encrypted volume. Bottom line is that if the crypto software doesn't suck, the number of permutations you'd have to try before you got the original encrypted volume back should be orders of magnitude greater than the effort needed to crack the key.
Exactly. Am I the only one who first read this as "Jobs, 54, passed on Tuesday"? Yikes!
I think you mean iGore, a member of Apple's board.
Ah, but they do share in that extra value. You see, those people who have a hard time seeing would not have bought the text version of the book because they could not have read it. Therefore, either way, the vast, vast majority of people would be buying either the audio book or the printed book, not both. Therefore, a device that reads the text merely reduces the overhead for the book manufacturer by reducing the necessity of having two separate versions for these almost completely disjoint audiences. If anything, the publishers benefit from this sort of arrangement, were it sufficiently ubiquitous.
And lest you criticize this argument by saying that some people would buy the audio book for "reading" parts of the book in the car, then picking up where they left off in print, for everyone person who does this, far more than one person merely doesn't read the book while in the car. Those people now have the opportunity to do so at no cost, and many of them will. As a result, they will finish the book sooner, and will---yup, you guessed it---buy another book. Over a lifetime, this equates to many, many additional books that those people would not have had time to read otherwise. The result is a net increase in total sales, thus completely nullifying that argument, too.
The whole greedy "you should pay me for everything" mentality almost never works in favor of content creators, nor indeed even in favor of content publishers/distributors. When content creators and distributors act this way, everybody loses, not just the consumers who are harmed by having to pay twice for a single copy of the content. The usual consumer reaction would be "You mean I have to pay an extra fee to have this content read to me? Heck, no, I won't do that." And that would be the end of the Kindle.
Not to mention that what they want is basically impossible. Computers already have screen readers, and if you explicitly go out of your way to block screen readers, you're likely to get sued on ADA compliance grounds. In effect, they're asking eBook reader software vendors to put their backsides on the line and risk a lawsuit without giving them any support to back them up. When eBook software vendors start dropping like flies, that would be the beginning of the end for commercial eBooks in general.
Faced with a downturn in print readership, snubbing new markets is not a particularly bright idea. Thus, I tend to agree with the comment in the summary---the author's guild needs someone in charge who has a better grasp of new media and how best to make money off their content through those means rather than somebody who barely understands it and is blindly grasping at straws trying to find ways to grab a bigger piece of the new media pie. If this guy remains in charge, this story can't possibly have a happy ending.
What it could not do is play back the content through a software decoder. It doesn't have the storage to be a good Myth back end, and doesn't have the display hardware to be a good front end, though with an external USB display adapter, you could sort of make it work if the CPU could decode the video quickly enough. I'm not sure it could, though, once you add in the extra overhead of pushing the video stream over USB to a framebuffer.
No, to get the comparison right, you have to be irritatingly quoting Shakespeare at the presumed guilty party. Oh, and they have to lock up the presumed guilty person in a prison of no escape in the middle of an ice moon. Siberia, perhaps?
Agreed. Either it needs BPL or it needs Wi-Fi. Most people don't put an ethernet jack wherever they have a power connection, making this somewhat less than ideal for home automation purposes. I'd also like to see it have a relay to switch on and off a power outlet, but maybe that's just me.
Either way, it's a cool little piece of hardware. I'm just not quite sure what I could use it for. It's too underpowered for video encoding/decoding, has no power switching capabilities needed for it to control lights, doesn't have the CPU power to replace my web server (a C2D takes several seconds to render an image with dcraw; this would take several minutes), etc. Maybe coupled with some outboard piece of USB gear, it might serve some obscure purpose like controlling a motor to open and close window shades/awnings for solar heating purposes, but it would still have to be enclosed in some sort of box to safely mount it outdoors....
I'll keep thinking. :-)
Do you work for Rambus or something? That's the exact opposite of what Wikipedia has to say. Basically, if I read it correctly, they say that Rambus listened in on a bunch of the JEDEC meetings and secretly started writing up patents on what was discussed, presumably including other people's ideas.
Either way, it's a moot point. Fully 19 standards organizations supported the request for certiorari on this. I think it's safe to say that standards bodies are busy writing rules to ensure that this can never happen again, but I also think that no standards body in their right mind is going to let Rambus participate again after this little stunt. As soon as JEDEC et al have finished working around the Rambus patents and the royalties dry up, Rambus is likely to shrivel up and die. They screwed a lot of companies with their actions, and that will not soon be forgotten. Scratch my back, and I scratch yours. Kick me until I bleed, and I lock you out of the playground.
Actually, assuming you're talking about an unmonitored repeater, you aren't knowingly doing anything, and thus, you should, at least in theory, be protected under the same sorts of DMCA exemptions as any other internet service provider that passes pirated/illegal content during the normal course of IP-based routing.
That said, if you do pass something inappropriate, IP number alone is almost certainly sufficient probable cause to obtain a search warrant. Having the same protection as an ISP doesn't mean they can't charge you with a crime or sue you for copyright violation, doesn't mean they can't confiscate your equipment, and doesn't mean the charges won't stick if they find evidence of the crime or copyright violation on your computer.
In short, if you are an innocent repeater, you are probably protected (though you may incur significant difficulty getting your confiscated equipment back), but if you are abusing your status as a repeater to mask the fact that you are doing something wrong, chances are they'll find you through some other means outside the scope of the protocol itself---possibly even outside the scope of the Internet entirely.
Then what the heck is rubbing against my leg? Aaaaaaaaaaaah!