NB: This is a workaround only for the "drive freezes on FLUSH_CACHE_EXT" bug in SD17, SD18, SD19 firmware drives. It seems this article is about/two/ different bugs (the other being the bricking bug in SD15).
Never mind - in another thread someone pointed out to me there are 2 different bugs. One of which, at least, is affecting 1TB drives (the bricking bug).
Ok.. Clearly I'm blind - at least one of the links is about a bricking issue:). So there's two different bugs affecting various revisions of recent firmware - one slightly less serious than the other.
Wow, didn't know about that one - that sounds bad.
That said, my point still stands: this article seems to be about the bug in the SD17, SD18 and SD19 (possibly more?) firmware revisions on FLUSH_CACHE_EXT. Which doesn't brick the drive.
My understanding (so far) is that it only affects the 1.5TB drive, not the 1TB ones. (I have a 1.5TB drive, the flash procedure doesn't suit me and the retailer are offering to replace it with a 1TB - which Seagate were saying aren't affected - this was a week or two though).
Not die, become unresponsive for short periods of time after it receives a "FLUSH CACHE EXT" command (used by journalling filesystems and RAID layers).
At least, if you're talking about the firmware bug this article is about...
It doesn't brick itself, it just becomes unresponsive for a while when sent a "FLUSH CACHE EXT" command. Not sure how long, but long enough to cause problems obviously (e.g. get kicked out of RAID arrays).
I have an SD17 firmware 1.5TB which I'm trying to return to the retailer for this reason..
That link is specifically about commercial photography/filming. (Non-commercial photography is allowed just fine, provided no flash/tripod/obstruction - see commentator a good bit above).
It destroys the "BBC must have been contractually obliged to use DRM" apologisms made by many. Admittedly your version of it was the weaker "to convince" rather than "contractually obliged", but still..
I don't know why you're marked informative. I suspect you're telling us about what you think is the case for US law, completely oblivious to the fact that this article is about the UK. (You know, different country, different laws?).
Police in the UK have *far* broader powers to stop and search people on the streets and public roads. IANAL, so I won't go further.
Apologies (honest) for the sarcasm, but do really think that if the CPU vendors had any useful room left to increase sequential processing performance that they wouldn't use it? Are 3D layouts out of the research labs yet? Are production fabs for 3D chips feasible?
I.e. what basis is there to think CPU designers have any choice (for the mid-term) but to spend the transistor income from Moore's Law on parallel processing?
Your pedantry is hilarious because you're so oblivious to the locale-specifity of it. "Daylight savings time" would probably be the more common usage in British-english following locales (though "summer time" would be even more common).
Works fine on large-ish collections (240MB total and 70MB RSS here with a ~100GB collection). Supports DAAP (so iTunes users on your network can play your stuff) as well as another MS sharing protocol (?). Album art lookup, lyrics lookups, tag editing, Last.fm plugin, smart playlists. etc.
That's not really true. E.g. notice the overlap between Ireland, Norway and Denmark, due to some degree to Viking tribes pillaging and then settling in Ireland, in the 600s to 800s (I think - going out on a limb by not checking wikipaedia first). You could go and on in similar fashion.
You can go back further in time and find evidence of trade stretching across Europe and even beyond. Even as far as back as *neo-lithic* (ie late stone age, circa 4k years ago) times, there is evidence of trade routes as stone axe heads known to have been quarried in Northern Ireland have been found in the UK and even the continent.
I'm picking a bit of a nit, cause you're right that travel was less common, but it wasn't confined to rich people and there was still plenty of it thanks to trade and war (e.g. we havn't even mentioned the Romans).
Slashdot Mirror
I was completely unaware my buggy 1.5TB drive might also have /another/ bug. Thanks! :)
NB: This is a workaround only for the "drive freezes on FLUSH_CACHE_EXT" bug in SD17, SD18, SD19 firmware drives. It seems this article is about /two/ different bugs (the other being the bricking bug in SD15).
Never mind - in another thread someone pointed out to me there are 2 different bugs. One of which, at least, is affecting 1TB drives (the bricking bug).
Ok.. Clearly I'm blind - at least one of the links is about a bricking issue :). So there's two different bugs affecting various revisions of recent firmware - one slightly less serious than the other.
Wow, didn't know about that one - that sounds bad.
That said, my point still stands: this article seems to be about the bug in the SD17, SD18 and SD19 (possibly more?) firmware revisions on FLUSH_CACHE_EXT. Which doesn't brick the drive.
My understanding (so far) is that it only affects the 1.5TB drive, not the 1TB ones. (I have a 1.5TB drive, the flash procedure doesn't suit me and the retailer are offering to replace it with a 1TB - which Seagate were saying aren't affected - this was a week or two though).
Not die, become unresponsive for short periods of time after it receives a "FLUSH CACHE EXT" command (used by journalling filesystems and RAID layers).
At least, if you're talking about the firmware bug this article is about...
Turning off write-caching ("hdparm -W0" on linux) appears to work around this firmware bug, till you can get the drive flashed/replaced.
It doesn't brick itself, it just becomes unresponsive for a while when sent a "FLUSH
CACHE EXT" command. Not sure how long, but long enough to cause problems obviously (e.g. get kicked out of RAID arrays).
I have an SD17 firmware 1.5TB which I'm trying to return to the retailer for this reason..
That link is specifically about commercial photography/filming. (Non-commercial photography is allowed just fine, provided no flash/tripod/obstruction - see commentator a good bit above).
[citation needed]
It destroys the "BBC must have been contractually obliged to use DRM" apologisms made by many. Admittedly your version of it was the weaker "to convince" rather than "contractually obliged", but still..
you're missing the point...
When the iPhone came out the BBC made un-DRMed content available for it...
Your argument holds no water.
I don't know why you're marked informative. I suspect you're telling us about what you think is the case for US law, completely oblivious to the fact that this article is about the UK. (You know, different country, different laws?).
Police in the UK have *far* broader powers to stop and search people on the streets and public roads. IANAL, so I won't go further.
Apologies (honest) for the sarcasm, but do really think that if the CPU vendors had any useful room left to increase sequential processing performance that they wouldn't use it? Are 3D layouts out of the research labs yet? Are production fabs for 3D chips feasible?
I.e. what basis is there to think CPU designers have any choice (for the mid-term) but to spend the transistor income from Moore's Law on parallel processing?
Your pedantry is hilarious because you're so oblivious to the locale-specifity of it. "Daylight savings time" would probably be the more common usage in British-english following locales (though "summer time" would be even more common).
Rhythmbox..
Works fine on large-ish collections (240MB total and 70MB RSS here with a ~100GB collection). Supports DAAP (so iTunes users on your network can play your stuff) as well as another MS sharing protocol (?). Album art lookup, lyrics lookups, tag editing, Last.fm plugin, smart playlists. etc.
Great.
"spacious reasoning"? :) Reasoning that has lots of room for expansion? :)
I think you meant specious.
Who modded this crap up?
Someone with more experience than you perhaps? :) (joke).
I challenge you to find one enterprise level SAN storage device that doesn't have battery backed storage.
Googles' GFS clusters...
(Presuming we're talking about "close to the storage" batteries, and not data-centre level UPS).
crap.. misclicked and wrong-modded. Posting to undo.
So why not a height restriction rather than an age restriction?
There's a 14 year old competing for Great Britain in the synchronised high-diving event. So the age restriction must be specific to gymnastics.
So it seems pretty arbitrary, or not?
Inter-domain multicast is far from a solved problem - at least, judging by operational deployment.
Stoutlimb meet scope and funding, and likewise..
That's not really true. E.g. notice the overlap between Ireland, Norway and Denmark, due to some degree to Viking tribes pillaging and then settling in Ireland, in the 600s to 800s (I think - going out on a limb by not checking wikipaedia first). You could go and on in similar fashion.
You can go back further in time and find evidence of trade stretching across Europe and even beyond. Even as far as back as *neo-lithic* (ie late stone age, circa 4k years ago) times, there is evidence of trade routes as stone axe heads known to have been quarried in Northern Ireland have been found in the UK and even the continent.
I'm picking a bit of a nit, cause you're right that travel was less common, but it wasn't confined to rich people and there was still plenty of it thanks to trade and war (e.g. we havn't even mentioned the Romans).