The reason the LaserJet II is still working is that the guts were built by Canon. There are plenty of LaserWriter printers that still work, too. It was a good engine.
To be fair, HP's bigger laser printers are pretty solid (e.g. the 81xx series) unless you actually need them to conform to their specs. Then they fail miserably.
For example, we have two 81xx series printers where I work. I tried to use them to print 11x17 pages double-sided. Shouldn't be a problem, right? Wrong. The printers are so brain damaged that they feed the pages too close together. Thus, if you send multiple pages at once, you never get a single page out of the printer before it is jammed (at a total loss of all pages in flight). You have to send every 11x17 double-sided page individually (e.g. print pages 1-2, wait, print pages 3-4, wait, etc.). If you do that, it works and never jams, but that's pretty painful when you have to print... say a hundred pages in this fashion. I mean seriously, how hard is it to not start one page until the previous page is clear? Both our 8100 and our 8150 do exactly the same thing (with up-to-date firmware in both). Apparently testing is optional at HP.
Oh, and did I mention that it takes three minutes for the d**n things to warm up from powersave mode? Sure, it's great that they can crank out 32 pages per minute, but until you hit 32 pages, my 8ppm low-end Brother consumer printer is faster (startup time measured in low double-digit seconds). The vast majority of the time, I wish I had my personal printer from home instead of these beasts.
And don't get me started on their dithering/halftoning algorithm. I've never once seen any HP printer reproduce any photographic content (even in black-and-white) without objectionable banding problems. That includes both laser and inkjet printers. The print quality on gradients is absolutely awful from what I've seen. It's even noticeable in the sample printouts that you get from their printers in stores. To say that I'm unimpressed would be generous. Don't get me wrong, they're by no means the worst out there---I still swear more at Epson, Lexmark, and a couple of others---but HP is way up on my list.
Speaking as someone who implemented the text file handling part of an ebook reader that never shipped, I can tell you that "simple" ASCII is anything but. First, you have to guess the encoding. Good luck with that. Then, you get to guess whether a newline is a paragraph break or a line break. If you decide it's a line break, then you get to decide if a paragraph is indicated by a blank line or a leading tab or spaces. Then, you get to decide whether multiple indented lines in a row are paragraphs or a block indent. Then you get to emit the HTML markup that they should have used to begin with and render the result.
Plain text is about the worst format you could choose for an ebook. And don't get me started on text files that use overstrike for bold/underline. Been there, parsed that. Not fun.
Yes, I read the reviews on one of those sites. The ones I read were reporting that the flash parts just plain stopped working entirely, though I suppose it's remotely possible that:
The flash part's firmware could get corrupted in such a way that at least one of the three access modes (but not all three) is nonfunctional.
The flash reader uses a working access mode at USB 1.0 speeds and a nonworking mode at USB 2.0 speeds.
That last one seems somewhat unlikely to me (since I'd expect flash readers to try to be as simple as possible, which means only implementing the fastest mode), but I guess anything's possible. That would certainly be an odd failure mode if that's the problem. It just seems more likely that there's some bizarre interaction in the way the flash reader implements the spec that happens to interact badly with that flash card....
If it is a failure of the flash card, my guess would be something really bizarre like a thermal failure caused by a failing solder joint where the card glitches when some part of the silicon reaches a certain temperature (which might not occur at lower access speeds). That's a stretch, but then again, it is the sort of design flaw that could also explain the more common sudden death failure. Has anybody tried throwing one of these flash cards in an oven... no, wait... plastic case... bad idea. *shrugs*
Either way, I made sure not to buy that model at Fry's when I bought an SDHC card last night....:-)
And it's probably not the fault of the flash part anyway. I'm assuming by "hang", the original poster meant that accesses to the device stall indefinitely. Since the device stalls only when accessed at USB 2.0 speeds, that almost completely rules out the flash part as the culprit. Although flash drives do support multiple protocols, there's really no good reason for a flash controller to implement support for more than one protocol, as flash parts have to support all of them. Thus, they're going to pick the fastest protocol and use it every time, without regard to what speed the USB side of the bridge is using for communication. Therefore, the only way the USB speed should realistically trigger a failure in the flash part is if the flash part can't handle high throughput.
It's important to understand that actual cameras write data to flash parts as quickly as the flash part can take it. Thus, a failure caused by high throughput (in the absence of specific workarounds in the camera) would cause the card to be completely and totally nonfunctional in basically any real-world camera hardware. Therefore, the fact that this card is even on the market is a pretty strong indication that the problem is on the other side of the USB bridge---either the USB bridge silicon itself, the USB cable, the host silicon, or drivers.
Yes, lots of people are having trouble with those cards, but in every report, the failure was an outright controller failure, with all data lost, not problems accessing it at certain speeds. I'd be very surprised if that sort of failure were anything other than a junk flash reader.
Now I know what you're thinking. USB card readers "just work". No, they don't. I was rather miserable using dd to manually work around bugs in a USB flash reader just a few years ago. In that particular case, throwing large requests at the thing over a high speed connection caused the device to randomly return a copy of block zero instead of the expected data. Did I mention that this particular controller silicon was used for dozens of products by at least half a dozen major manufacturers for a couple of years before the flaw was discovered? Or that the bug was never fixed in firmware or silicon?:-) So yeah, a thoroughly broken flash reader would not be at all surprising.
First thing I'd do is grab yourself a new flash reader and make sure it doesn't use the same chipset as the one you have. If that doesn't help, *then* you can blame the flash part, and there probably isn't anything you can do about it other than ripping it open and making cufflinks out of it.
If you have access to the flash reader firmware, you might try using a different access mode. I'm guessing that's not an option, though.
Worst comes to worst, if it worked okay with a camera, you could try using the camera's flash controller to read/write the flash part. It will probably be dog slow, but at least you can copy the data off the card before you toss it out.
Actually, it doesn't provide any evidence at all that it was premeditated. It merely provides evidence that going to that particular location was premeditated, not that the person intended to commit a crime while there.
A dirtbag uses Google Maps to find a club because there's a party there. While at the party, he notices that they have a bunch of expensive electronics and have no security system. He waits until everyone has gone home, breaks in, steals stuff, and leaves
A dirtbag is in town visiting for the week. He uses Google Maps to locate the home of an old friend, who turns out not to be home. He breaks into the house and steals stuff.
A dirtbag uses Google Maps to find an electronics store. While there, he notices that they have only one sales associate and that their back door has no security cameras near it. He calls a friend to distract the salesperson while he walks out the back door carrying a pile of Blu-Ray players.
Notice that none of these crimes were premeditated. They are all crimes of opportunity. Yet in every case, the criminal found the place using Google Maps. It's harder to come up with good excuses if we're talking about the address of a residence, but even that might be possible if we're talking about a residence where there's a party, an open house, a recital, etc., assuming that the crime was committed on the same day.
You're right that this doesn't provide any useful data about real-world drives at all because the technology is completely different (the EEPROM probably uses SLC NOR flash judging by the write cycle count in its specs, while as you said, most SSDs use MLC NAND flash parts).
However, the GP post did not say or imply that SSDs used SLC parts. The post said that this was roughly a best case for SSDs that used the same flash tech as the part being tested (with SLC being an example), meaning a test against SLC parts is valid against other SLCs. That's not entirely correct, of course, because of the presence of spare parts and significant differences in the longevity of flash parts from one manufacturer to another, variation between parts, etc., but it is still interesting.
Also, the question of wear leveling is completely irrelevant. This still provides a close approximation of the best case for that particular flash part, and you can multiply by the number of flash parts to get the best case for any device that uses such a part. The very definition of an erase cycle count for the entire drive, by its very nature, takes into account perfect wear leveling. A drive with an erase cycle count of 1,000 means that on average, every cell has seen 1,000 write/erase cycles. In perfect wear leveling, that means you've written and erased 1,000 times the capacity of the drive. In less than ideal wear leveling, it is less than that. And, of course, for writes that only change bits in a single direction (the direction being different for NOR vs. NAND), you might get a few extra write cycles once in a while, but that's likely to be so rare in real-world use that it's almost not worth mentioning. Thus, this does, in fact, as the GP indicated, provide a fairly good best case bound for the reliability of the particular device in question, were it used in any sort of SSD.
I'd love to see this test repeated with MLC NAND flash parts. I think the results would be eye-opening.
Didn't I just buy a tank from you? "I mean sure, any car is a car, but a tank is a tank!" I'm ready for the disaster. Shoot depleted uranium shells first and ask questions later, tank you very much.
Oh, wait, data disaster? Seriously? No, we're not ready, and we never will be. Danger pretty much demonstrated what will likely happen in a real world data disaster. Thousands of people who couldn't be bothered to synchronize their data and make backups suddenly found themselves screwed.
The takeaway is simple: if your data is valuable, don't trust anyone else with the only copy, and that includes the manufacturer of your hard drive. The only safe data is the fifth backup copy stored on mag tape in a storage vault buried half a mile beneath NORAD.
Even with the ID of the teenager, you're assuming that the teenager will be able to accurately describe somebody who he/she only met once, possibly years earlier. What, you don't really think criminals would ask their *friends* to do such favors, do you?
This is unconstitutional because it destroys a major venue for anonymous speech. Centuries of history have proven that such venues are necessary to carry out legal acts of political dissent that otherwise result in all sorts of abuses.
I'm okay with $10 per gallon gasoline under two conditions:
every PENNY of those $7 in taxes must be given out in the form of research grants to companies and universities working on developing alternative energy technologies.
every single patent resulting out of those grants must belong to the U.S. government and must be freely licensed to any U.S. company that wants to produce such a product under the condition that the products be manufactured in the U.S.
As long as that money actually goes towards developing technology to bring the cost of renewable energy down, then great. But that's not what will happen. It will be used to penalize people who use energy and to give huge grants to megacorps that then use our hard-earned dollars to develop technology that only benefits themselves. And that's not cool.
My laptop is my test environment. As the sole developer, given that everything is checked into version control, there's no benefit to maintaining a third test box.
Further, I periodically write Mac software. Thus, it is advantageous to have my home directory and/Library on a case-sensitive volume to ensure that the apps I write will work correctly for other people who do. Were that not a real risk, we wouldn't be having this conversation because Steam would have worked on my system....
So no, I'm not making a problem where none exists. I'm not saying I'm likely to make a case sensitivity issue (given that I'm aware of them), but why take the chance? It was a trivial thing to change when I reinstalled by system after a hard drive crash, and the breakage rate for apps has been in the single digits. Also, by being a guinea pig and running with a case-sensitive volume, I'm able to find problems when they do occur and point them out to the software developer so that other people with less programming knowledge don't have to try to figure it out for themselves.
You were speaking from the developer level when you were talking about case insensitivity.
And developers using file access APIs in Windows can get case sensitive behavior. It's just a single FILE_FLAG_POSIX_SEMANTICS flag to CreateFile and friends. It's actually easier to do that in Windows because it doesn't require a reformat and reinstall.
I cannot see how you can honestly say that case insensitivity is the exception and not the rule when 99% of people in the world use a filesystem that is case insensitive for all practical purposes.
Case-insensitive volume formats are only common if you're talking about hard-drive-based filesystems for consumer use. As soon as you move beyond that market into anything remotely enterprise-y (e.g. home directories on any NFS server, some SMB servers, some AFP servers, etc.), there's a very real chance that you're getting into case sensitivity territory. As soon as you talk about the world of servers, it's almost a given.
Further, every CD-ROM (except the base ISO-9660, which is almost useless), every DVD, every Blu-Ray disc, a sizable percentage of cell phones, and lots of embedded systems use a case-sensitive filesystem. Want that game to work when run from optical media? You'd better work with case-sensitive volumes. Want to port it to iPhone? It had better work with case-sensitive volumes. Want to be able to fetch files over the Internet? Yup. Case usually matters. And so on.
The average home has one hard drive, thirty or forty DVDs. When viewed in a broader sense (not limited to local hard-drive filesystems), case sensitivity is the norm, and case insensitivity is the exception. Case-sensitive volumes likely outnumber case-insensitive volumes by several orders of magnitude.
That said, I wasn't talking about the number of instances of any given filesystem when I referred to case insensitivity being in the minority but rather that *recent* filesystems are almost *universally* case sensitive. That's a pretty strong indication that technology is moving towards case sensitivity, not away from it. Thus, designing software that doesn't take this into account is very shortsighted, and is likely to be costly in the long run.
Put another way, if you want to talk about total number of instances of a filesystem, ignoring DVDs and CDs, the most popular filesystem that a home user will encounter (by a large margin) is non-long-filename FAT16 on flash cards. That doesn't mean it's acceptable for a photo viewer application to barf when it sees a filename that's more than eight characters long, even though 99.999% of them won't be.
What, like that obscure filesystem, what's it's name, that no one uses? Oh, right, NTFS.
NTFS, which dates back to the early 1990s, is hardly a modern filesystem. It is also a case-sensitive filesystem under the hood. This is masked by a case-insensitivity shim for applications accessing it through the Win32 API, but applications that use lower-level APIs get case-sensitive behavior. So I'll see your NTFS and raise you basically every single filesystem created in the past two decades.
Case-sensitivity in a filesystem is not something a developer should have to care about, any more than they should have to care about, oh, I don't know, a lack of protected memory. Sure, it would be nice if people used correct cases, but really, it's 2010.
Exactly. It's 2010. If twenty years of every single new filesystem being case-sensitive hasn't gotten people to realize that this is the direction technology is moving, I don't know what will....
(I thought that it had been deprecated, but can't find any evidence of this)
Nope. HFSX is fully supported and is most certainly not deprecated. You're thinking of the ancient UFS format that has been deprecated for a while. UFS is not only deprecated, but was actually demoted to read-only in Snow Leopard.
The reason UFS is deprecated has nothing to do with case sensitivity, though. It's deprecated because A. it's very, very slow compared with HFS+, B. it doesn't support extended attributes or POSIX filesystem ACLs or any of the other dozen things that have been added to the VFS layer in Mac OS X over the last several years (so using it would break a LOT of things), and C. case-sensitive HFS+ made it largely unnecessary.
What are you doing that makes this problematic?
It's not that it's problematic. It's that I want to be certain that when I check in changes to the tree, they're not going to break my server when the update goes live.
Show me where any Apple web page says that. It most certainly is not discouraged in any way, shape, or form.
It's amusing that you dismiss those of us who run OS X in its default config (HFS+) as "toy" when you're trying to get a game to run.
I can think of quite a few security bugs over the years in Apache that have been specific to case-insensitive filesystems, plus *countless* other bugs in web applications, etc. So my server is case-sensitive, and my laptop is also case-sensitive so that I never have to worry about creating case-sensitivity bugs when I create content to upload to my web server. And if I were writing iPhone software, it would be case sensitive for that reason, too (as iPhone OS uses a case-sensitive volume format exclusively).
Sure, I could parcel out the content that has to be case sensitive into a disk image. I can also parcel off broken applications into a case-insensitive disk image, to some extent. It's still an unnecessary hassle that could be fixed by the app developer spending about an hour to run a few scripts, fix the problems that it reports, and then reconfigure at least one of their test machines to be case-sensitive.
ROTFL. I used to run UFS on all my machines back then, but eventually stopped because performance was so incredibly bad. The moment case-sensitive HFS+ came around, I started moving to it, and the experience has been much better.
Lots of apps didn't work eight or ten years ago on case-sensitive (UFS) volumes. The good news is that about 98% of those developers paid attention to those bug reports and actually fixed their software, and the only three apps I've run into over the past two years of case-sensitive HFS+ are:
Adobe Photoshop CS3 (and CS4 and CS5, which is why I'm still running CS3)
MakeMusic Finale
Steam
That's my list. Even other Adobe products work quite well (Lightroom, for example), as do Photoshop alternatives (Pixelmator), and as far as I know, Finale alternatives (Sibelius). Even random open source tools like Hugin work fine. The rarity of problems I've had with it recently is why it was so surprising to see a major software manufacturer get it wrong in this day and age. They're sure going to be unhappy if they ever try to port their games to iPhone (which is case sensitive by design).
HFSX is an extension to HFS Plus to allow additional features that are incompatible with HFS Plus.
You are completely misunderstanding that sentence. HFSX is incompatible with HFS+ because a filesystem B-tree sorts its keys in different ways depending on whether it is using case-sensitive or case-insensitive matching. As a result, at a volume format level, HFSX includes low-level changes that are incompatible with ancient tools that work with HFS+ volumes. If we were talking about a disk utility like DiskWarrior (which, incidentally, has supported HFSX since way back before it even became a GUI-selectable formatting option in the non-server version of Mac OS X)---an application that mucks around in the raw volume B-trees by accessing disk blocks directly, then yes, it would break when it encountered these volumes, and break massively. As a general rule, 99.99999% of application developers should not be anywhere near the low-level bits that the technote you referenced refers to.
We're not talking about software that works with the volume format directly here. We're talking about software that opens files by passing hard-coded path names with incorrect case. Such apps also don't work when your home directory is:
On an NFS mount
On an AFP volume backed by a UNIX box
On an HFSX volume
On a UFS volume (in an older Mac OS X version where this was still supported for writing)
And so on. That incompatibility list is only going to get longer as time moves forward. These days, case insensitive filesystems like HFS+ are the exception, not the rule.
Moreover, Apple has never in any way even HINTED that not working on case-sensitive volumes is an acceptable practive, and even published Technote 2096 that basically says the precise opposite of what you're implying. Because the filesystem underlying iPhone OS is case sensitive, iPhone developers are strongly discouraged from building iPhone applications on case-insensitive HFS+ volumes. On case-insensitive volumes, the simulator can't catch bugs caused by case sensitivity mistakes, so when you finally get the app on an actual device and it fails miserably, you'll be scratching your head.
In short, if your app doesn't work on case-sensitive volumes, now would be a good time to fix it, particularly if you want iPhone developers, web developers, etc. to use your software.
This is like complaining about KDE not compiling properly with a "perfectly sane" configuration of Hurd running on ARM.
No, this is like complaining about KDE running fine on an EXT3 volume, but crashing in bizarre, inexplicable ways when you migrate your system to EXT4. It's a sign that the developer couldn't be bothered to use correct capitalization in hard-coded filenames within their code. The ONLY relevant difference between case-sensitive and non-case-sensitive filesystems in Mac OS X is that if you write code that tries to load "~/Library/application support/whatever" instead of "~/Library/Application Support/Whatever", it will fail on the case-sensitive filesystem. The ONLY bugs it causes are entirely due to sloppy, bad coding on the part of the developer. Thus, software that won't work on HFSX volumes are like a giant shining beacon that screams "We don't know how to write software."
No, it doesn't. There is no warning whatsoever in Disk Utility (at least in Snow Leopard). It's a fully first-class filesystem in Mac OS X.
And I can count the apps that it breaks on one hand. This is only the third I've encountered, and I've been using case-sensitive HFS+ exclusively for a couple of years now.
Because I build and maintain web sites, and the servers I deploy on are case-sensitive. And because I like to actually test my software so that it works everywhere, not just on a subset of installations.
Simple. Because open like a Mac means "lots of configurations to have to support". So far, in trying in vain to play Portal on my Mac, I found that:
It doesn't support case-sensitive HFS+, so for those of us who use a non-toy configuration, you have to throw it into a disk image and create dozens of symlinks all over your ~/Library folder just to make Steam launch.
The Portal game itself crashes on launch if you try to run it on anything other than the most recent GPUs.
So I'm just glad it was free, since at least I got exactly what I paid for.
No, automation is generally much cheaper. However, Commodore had economies of scale in its favor. The money you get from sales also must pay for your R&D costs. If you're selling a million units per year to cover a quarter billion in annual R&D spending, you need to make $250 per unit above and beyond the manufacturing costs just to break even. If you're only selling 100,000 units, you need to make $2,500 per unit.
I think there's a good possibility that Microsoft will drop support for Windows 7 before NASA drops support for Opportunity. I doubt, however, that Opportunity will still be functioning when Microsoft declares bankruptcy in 2148....
Slashdot Mirror
The reason the LaserJet II is still working is that the guts were built by Canon. There are plenty of LaserWriter printers that still work, too. It was a good engine.
To be fair, HP's bigger laser printers are pretty solid (e.g. the 81xx series) unless you actually need them to conform to their specs. Then they fail miserably.
For example, we have two 81xx series printers where I work. I tried to use them to print 11x17 pages double-sided. Shouldn't be a problem, right? Wrong. The printers are so brain damaged that they feed the pages too close together. Thus, if you send multiple pages at once, you never get a single page out of the printer before it is jammed (at a total loss of all pages in flight). You have to send every 11x17 double-sided page individually (e.g. print pages 1-2, wait, print pages 3-4, wait, etc.). If you do that, it works and never jams, but that's pretty painful when you have to print... say a hundred pages in this fashion. I mean seriously, how hard is it to not start one page until the previous page is clear? Both our 8100 and our 8150 do exactly the same thing (with up-to-date firmware in both). Apparently testing is optional at HP.
Oh, and did I mention that it takes three minutes for the d**n things to warm up from powersave mode? Sure, it's great that they can crank out 32 pages per minute, but until you hit 32 pages, my 8ppm low-end Brother consumer printer is faster (startup time measured in low double-digit seconds). The vast majority of the time, I wish I had my personal printer from home instead of these beasts.
And don't get me started on their dithering/halftoning algorithm. I've never once seen any HP printer reproduce any photographic content (even in black-and-white) without objectionable banding problems. That includes both laser and inkjet printers. The print quality on gradients is absolutely awful from what I've seen. It's even noticeable in the sample printouts that you get from their printers in stores. To say that I'm unimpressed would be generous. Don't get me wrong, they're by no means the worst out there---I still swear more at Epson, Lexmark, and a couple of others---but HP is way up on my list.
Speaking as someone who implemented the text file handling part of an ebook reader that never shipped, I can tell you that "simple" ASCII is anything but. First, you have to guess the encoding. Good luck with that. Then, you get to guess whether a newline is a paragraph break or a line break. If you decide it's a line break, then you get to decide if a paragraph is indicated by a blank line or a leading tab or spaces. Then, you get to decide whether multiple indented lines in a row are paragraphs or a block indent. Then you get to emit the HTML markup that they should have used to begin with and render the result.
Plain text is about the worst format you could choose for an ebook. And don't get me started on text files that use overstrike for bold/underline. Been there, parsed that. Not fun.
Yes, I read the reviews on one of those sites. The ones I read were reporting that the flash parts just plain stopped working entirely, though I suppose it's remotely possible that:
That last one seems somewhat unlikely to me (since I'd expect flash readers to try to be as simple as possible, which means only implementing the fastest mode), but I guess anything's possible. That would certainly be an odd failure mode if that's the problem. It just seems more likely that there's some bizarre interaction in the way the flash reader implements the spec that happens to interact badly with that flash card....
If it is a failure of the flash card, my guess would be something really bizarre like a thermal failure caused by a failing solder joint where the card glitches when some part of the silicon reaches a certain temperature (which might not occur at lower access speeds). That's a stretch, but then again, it is the sort of design flaw that could also explain the more common sudden death failure. Has anybody tried throwing one of these flash cards in an oven... no, wait... plastic case... bad idea. *shrugs*
Either way, I made sure not to buy that model at Fry's when I bought an SDHC card last night.... :-)
And it's probably not the fault of the flash part anyway. I'm assuming by "hang", the original poster meant that accesses to the device stall indefinitely. Since the device stalls only when accessed at USB 2.0 speeds, that almost completely rules out the flash part as the culprit. Although flash drives do support multiple protocols, there's really no good reason for a flash controller to implement support for more than one protocol, as flash parts have to support all of them. Thus, they're going to pick the fastest protocol and use it every time, without regard to what speed the USB side of the bridge is using for communication. Therefore, the only way the USB speed should realistically trigger a failure in the flash part is if the flash part can't handle high throughput.
It's important to understand that actual cameras write data to flash parts as quickly as the flash part can take it. Thus, a failure caused by high throughput (in the absence of specific workarounds in the camera) would cause the card to be completely and totally nonfunctional in basically any real-world camera hardware. Therefore, the fact that this card is even on the market is a pretty strong indication that the problem is on the other side of the USB bridge---either the USB bridge silicon itself, the USB cable, the host silicon, or drivers.
Yes, lots of people are having trouble with those cards, but in every report, the failure was an outright controller failure, with all data lost, not problems accessing it at certain speeds. I'd be very surprised if that sort of failure were anything other than a junk flash reader.
Now I know what you're thinking. USB card readers "just work". No, they don't. I was rather miserable using dd to manually work around bugs in a USB flash reader just a few years ago. In that particular case, throwing large requests at the thing over a high speed connection caused the device to randomly return a copy of block zero instead of the expected data. Did I mention that this particular controller silicon was used for dozens of products by at least half a dozen major manufacturers for a couple of years before the flaw was discovered? Or that the bug was never fixed in firmware or silicon? :-) So yeah, a thoroughly broken flash reader would not be at all surprising.
First thing I'd do is grab yourself a new flash reader and make sure it doesn't use the same chipset as the one you have. If that doesn't help, *then* you can blame the flash part, and there probably isn't anything you can do about it other than ripping it open and making cufflinks out of it.
If you have access to the flash reader firmware, you might try using a different access mode. I'm guessing that's not an option, though.
Worst comes to worst, if it worked okay with a camera, you could try using the camera's flash controller to read/write the flash part. It will probably be dog slow, but at least you can copy the data off the card before you toss it out.
Actually, it doesn't provide any evidence at all that it was premeditated. It merely provides evidence that going to that particular location was premeditated, not that the person intended to commit a crime while there.
Notice that none of these crimes were premeditated. They are all crimes of opportunity. Yet in every case, the criminal found the place using Google Maps. It's harder to come up with good excuses if we're talking about the address of a residence, but even that might be possible if we're talking about a residence where there's a party, an open house, a recital, etc., assuming that the crime was committed on the same day.
You're right that this doesn't provide any useful data about real-world drives at all because the technology is completely different (the EEPROM probably uses SLC NOR flash judging by the write cycle count in its specs, while as you said, most SSDs use MLC NAND flash parts).
However, the GP post did not say or imply that SSDs used SLC parts. The post said that this was roughly a best case for SSDs that used the same flash tech as the part being tested (with SLC being an example), meaning a test against SLC parts is valid against other SLCs. That's not entirely correct, of course, because of the presence of spare parts and significant differences in the longevity of flash parts from one manufacturer to another, variation between parts, etc., but it is still interesting.
Also, the question of wear leveling is completely irrelevant. This still provides a close approximation of the best case for that particular flash part, and you can multiply by the number of flash parts to get the best case for any device that uses such a part. The very definition of an erase cycle count for the entire drive, by its very nature, takes into account perfect wear leveling. A drive with an erase cycle count of 1,000 means that on average, every cell has seen 1,000 write/erase cycles. In perfect wear leveling, that means you've written and erased 1,000 times the capacity of the drive. In less than ideal wear leveling, it is less than that. And, of course, for writes that only change bits in a single direction (the direction being different for NOR vs. NAND), you might get a few extra write cycles once in a while, but that's likely to be so rare in real-world use that it's almost not worth mentioning. Thus, this does, in fact, as the GP indicated, provide a fairly good best case bound for the reliability of the particular device in question, were it used in any sort of SSD.
I'd love to see this test repeated with MLC NAND flash parts. I think the results would be eye-opening.
Didn't I just buy a tank from you? "I mean sure, any car is a car, but a tank is a tank!" I'm ready for the disaster. Shoot depleted uranium shells first and ask questions later, tank you very much.
Oh, wait, data disaster? Seriously? No, we're not ready, and we never will be. Danger pretty much demonstrated what will likely happen in a real world data disaster. Thousands of people who couldn't be bothered to synchronize their data and make backups suddenly found themselves screwed.
The takeaway is simple: if your data is valuable, don't trust anyone else with the only copy, and that includes the manufacturer of your hard drive. The only safe data is the fifth backup copy stored on mag tape in a storage vault buried half a mile beneath NORAD.
Even with the ID of the teenager, you're assuming that the teenager will be able to accurately describe somebody who he/she only met once, possibly years earlier. What, you don't really think criminals would ask their *friends* to do such favors, do you?
This is unconstitutional because it destroys a major venue for anonymous speech. Centuries of history have proven that such venues are necessary to carry out legal acts of political dissent that otherwise result in all sorts of abuses.
Humorously, I actually thought the game was silent when I first viewed it. Once again, ClickToFlash delivers an improved user experience.
I'm okay with $10 per gallon gasoline under two conditions:
As long as that money actually goes towards developing technology to bring the cost of renewable energy down, then great. But that's not what will happen. It will be used to penalize people who use energy and to give huge grants to megacorps that then use our hard-earned dollars to develop technology that only benefits themselves. And that's not cool.
Only on Slashdot would my previous comment be modded "interesting" instead of "funny".... :-)
I drank a sonic screwdriver once. They don't taste nearly as good as you might think.
My laptop is my test environment. As the sole developer, given that everything is checked into version control, there's no benefit to maintaining a third test box.
Further, I periodically write Mac software. Thus, it is advantageous to have my home directory and /Library on a case-sensitive volume to ensure that the apps I write will work correctly for other people who do. Were that not a real risk, we wouldn't be having this conversation because Steam would have worked on my system....
So no, I'm not making a problem where none exists. I'm not saying I'm likely to make a case sensitivity issue (given that I'm aware of them), but why take the chance? It was a trivial thing to change when I reinstalled by system after a hard drive crash, and the breakage rate for apps has been in the single digits. Also, by being a guinea pig and running with a case-sensitive volume, I'm able to find problems when they do occur and point them out to the software developer so that other people with less programming knowledge don't have to try to figure it out for themselves.
Thanks for the correction. I'm not exactly a Windows programmer (though I could qualify as a recovering DOS assembly language programmer).
And developers using file access APIs in Windows can get case sensitive behavior. It's just a single FILE_FLAG_POSIX_SEMANTICS flag to CreateFile and friends. It's actually easier to do that in Windows because it doesn't require a reformat and reinstall.
Case-insensitive volume formats are only common if you're talking about hard-drive-based filesystems for consumer use. As soon as you move beyond that market into anything remotely enterprise-y (e.g. home directories on any NFS server, some SMB servers, some AFP servers, etc.), there's a very real chance that you're getting into case sensitivity territory. As soon as you talk about the world of servers, it's almost a given.
Further, every CD-ROM (except the base ISO-9660, which is almost useless), every DVD, every Blu-Ray disc, a sizable percentage of cell phones, and lots of embedded systems use a case-sensitive filesystem. Want that game to work when run from optical media? You'd better work with case-sensitive volumes. Want to port it to iPhone? It had better work with case-sensitive volumes. Want to be able to fetch files over the Internet? Yup. Case usually matters. And so on.
The average home has one hard drive, thirty or forty DVDs. When viewed in a broader sense (not limited to local hard-drive filesystems), case sensitivity is the norm, and case insensitivity is the exception. Case-sensitive volumes likely outnumber case-insensitive volumes by several orders of magnitude.
That said, I wasn't talking about the number of instances of any given filesystem when I referred to case insensitivity being in the minority but rather that *recent* filesystems are almost *universally* case sensitive. That's a pretty strong indication that technology is moving towards case sensitivity, not away from it. Thus, designing software that doesn't take this into account is very shortsighted, and is likely to be costly in the long run.
Put another way, if you want to talk about total number of instances of a filesystem, ignoring DVDs and CDs, the most popular filesystem that a home user will encounter (by a large margin) is non-long-filename FAT16 on flash cards. That doesn't mean it's acceptable for a photo viewer application to barf when it sees a filename that's more than eight characters long, even though 99.999% of them won't be.
NTFS, which dates back to the early 1990s, is hardly a modern filesystem. It is also a case-sensitive filesystem under the hood. This is masked by a case-insensitivity shim for applications accessing it through the Win32 API, but applications that use lower-level APIs get case-sensitive behavior. So I'll see your NTFS and raise you basically every single filesystem created in the past two decades.
Exactly. It's 2010. If twenty years of every single new filesystem being case-sensitive hasn't gotten people to realize that this is the direction technology is moving, I don't know what will....
Nope. HFSX is fully supported and is most certainly not deprecated. You're thinking of the ancient UFS format that has been deprecated for a while. UFS is not only deprecated, but was actually demoted to read-only in Snow Leopard.
The reason UFS is deprecated has nothing to do with case sensitivity, though. It's deprecated because A. it's very, very slow compared with HFS+, B. it doesn't support extended attributes or POSIX filesystem ACLs or any of the other dozen things that have been added to the VFS layer in Mac OS X over the last several years (so using it would break a LOT of things), and C. case-sensitive HFS+ made it largely unnecessary.
It's not that it's problematic. It's that I want to be certain that when I check in changes to the tree, they're not going to break my server when the update goes live.
Show me where any Apple web page says that. It most certainly is not discouraged in any way, shape, or form.
I can think of quite a few security bugs over the years in Apache that have been specific to case-insensitive filesystems, plus *countless* other bugs in web applications, etc. So my server is case-sensitive, and my laptop is also case-sensitive so that I never have to worry about creating case-sensitivity bugs when I create content to upload to my web server. And if I were writing iPhone software, it would be case sensitive for that reason, too (as iPhone OS uses a case-sensitive volume format exclusively).
Sure, I could parcel out the content that has to be case sensitive into a disk image. I can also parcel off broken applications into a case-insensitive disk image, to some extent. It's still an unnecessary hassle that could be fixed by the app developer spending about an hour to run a few scripts, fix the problems that it reports, and then reconfigure at least one of their test machines to be case-sensitive.
ROTFL. I used to run UFS on all my machines back then, but eventually stopped because performance was so incredibly bad. The moment case-sensitive HFS+ came around, I started moving to it, and the experience has been much better.
Lots of apps didn't work eight or ten years ago on case-sensitive (UFS) volumes. The good news is that about 98% of those developers paid attention to those bug reports and actually fixed their software, and the only three apps I've run into over the past two years of case-sensitive HFS+ are:
That's my list. Even other Adobe products work quite well (Lightroom, for example), as do Photoshop alternatives (Pixelmator), and as far as I know, Finale alternatives (Sibelius). Even random open source tools like Hugin work fine. The rarity of problems I've had with it recently is why it was so surprising to see a major software manufacturer get it wrong in this day and age. They're sure going to be unhappy if they ever try to port their games to iPhone (which is case sensitive by design).
You are completely misunderstanding that sentence. HFSX is incompatible with HFS+ because a filesystem B-tree sorts its keys in different ways depending on whether it is using case-sensitive or case-insensitive matching. As a result, at a volume format level, HFSX includes low-level changes that are incompatible with ancient tools that work with HFS+ volumes. If we were talking about a disk utility like DiskWarrior (which, incidentally, has supported HFSX since way back before it even became a GUI-selectable formatting option in the non-server version of Mac OS X)---an application that mucks around in the raw volume B-trees by accessing disk blocks directly, then yes, it would break when it encountered these volumes, and break massively. As a general rule, 99.99999% of application developers should not be anywhere near the low-level bits that the technote you referenced refers to.
We're not talking about software that works with the volume format directly here. We're talking about software that opens files by passing hard-coded path names with incorrect case. Such apps also don't work when your home directory is:
And so on. That incompatibility list is only going to get longer as time moves forward. These days, case insensitive filesystems like HFS+ are the exception, not the rule.
Moreover, Apple has never in any way even HINTED that not working on case-sensitive volumes is an acceptable practive, and even published Technote 2096 that basically says the precise opposite of what you're implying. Because the filesystem underlying iPhone OS is case sensitive, iPhone developers are strongly discouraged from building iPhone applications on case-insensitive HFS+ volumes. On case-insensitive volumes, the simulator can't catch bugs caused by case sensitivity mistakes, so when you finally get the app on an actual device and it fails miserably, you'll be scratching your head.
In short, if your app doesn't work on case-sensitive volumes, now would be a good time to fix it, particularly if you want iPhone developers, web developers, etc. to use your software.
No, this is like complaining about KDE running fine on an EXT3 volume, but crashing in bizarre, inexplicable ways when you migrate your system to EXT4. It's a sign that the developer couldn't be bothered to use correct capitalization in hard-coded filenames within their code. The ONLY relevant difference between case-sensitive and non-case-sensitive filesystems in Mac OS X is that if you write code that tries to load "~/Library/application support/whatever" instead of "~/Library/Application Support/Whatever", it will fail on the case-sensitive filesystem. The ONLY bugs it causes are entirely due to sloppy, bad coding on the part of the developer. Thus, software that won't work on HFSX volumes are like a giant shining beacon that screams "We don't know how to write software."
No, it doesn't. There is no warning whatsoever in Disk Utility (at least in Snow Leopard). It's a fully first-class filesystem in Mac OS X.
And I can count the apps that it breaks on one hand. This is only the third I've encountered, and I've been using case-sensitive HFS+ exclusively for a couple of years now.
Because I build and maintain web sites, and the servers I deploy on are case-sensitive. And because I like to actually test my software so that it works everywhere, not just on a subset of installations.
Simple. Because open like a Mac means "lots of configurations to have to support". So far, in trying in vain to play Portal on my Mac, I found that:
So I'm just glad it was free, since at least I got exactly what I paid for.
No, automation is generally much cheaper. However, Commodore had economies of scale in its favor. The money you get from sales also must pay for your R&D costs. If you're selling a million units per year to cover a quarter billion in annual R&D spending, you need to make $250 per unit above and beyond the manufacturing costs just to break even. If you're only selling 100,000 units, you need to make $2,500 per unit.
I think there's a good possibility that Microsoft will drop support for Windows 7 before NASA drops support for Opportunity. I doubt, however, that Opportunity will still be functioning when Microsoft declares bankruptcy in 2148....