So in other words you bought some cheap crap from a fly-by-night called "OCZ" and installed it in your servers, and were surprised when it didn't work. Do you also buy hard drives from no-name Taiwanese, or do you stick to Seagate, Western Digital, and Hitachi?
Crap is crap, whether HDD or SSD. And for that matter, memory. You can buy some janky erroneous DRAM from OCZ as well, but I don't recommend it.
This is completely backwards. It is hard drives which fail without warning. See Google's recent paper on the futility of S.M.A.R.T. And when an HDD fails, your data is _gone_. The best you can hope for is spending huge amounts of money to put the platters into another drive and reading the data back. The predominant failure mode for flash is erase cycle endurance exhaustion, upon which time the flash reverts to being read-only. Compared to a HDD the flash failure mode is hugely desirable. You can also monitor an SSD and replace it when it reaches the 100,000 erase cycle limit (or 10,000 for MLC). HDD has no such mechanism.
The AI cheats in all Civ4 difficulties above Noble. In the higher difficulty levels the AI gets free technologies, builds faster and cheaper, has lower maintenance and inflation, etc. For instance on the Monarch difficulty the AI starts (starts!) with Archery.
Exactly! I have a major "WTF?" moment every time I see people opening PDFs in their web browser. Drives me nuts. And Mac people are all up in arms because Chrome on Mac doesn't (or didn't -- it may be implemented now) open PDFs in a plug-in. To me, that's a feature, not a bug.
Why shouldn't you use XHTML? By the way, SVG made its way into HTML5 and it's much more useful than canvas so I think the reports of SVG's death are greatly exaggerated.
I would say that the main thing holding it back is the total lack of a high-performance way to address bytes in JavaScript. The state-of-the-art for decoding binary protocols in JS is to use charAt and charCode to grab a character at a certain offset in a string, which throws off a phenomenal amount of garbage to be collected and is tremendously slow as well.
The language needs better ways of manipulating bits and bytes.
I suspect that, given this was a geographic mission, the resolution is specified in arc-seconds, which does not equate exactly to an integral number of yards or meters, and varies in size from the equator to the poles.
I guess all I'm really saying is that in the debate about vaccination -- and I don't even think there's enough evidence to support a reasonable anti-vaccination position -- a discussion between Bill Maher and Bill Frist adds nothing. You might as well have Cheech and Chong talking about it.
But you think people should pay attention to Bill Frist, noted video diagnostic specialist and cat torturer, the guy who thought it would be OK to interfere with the Terry Shiavo case without 1) examining the patient or 2) even being a neurologist? In my view anybody who listens to either of these idiots on matters of medicine is a fool.
Yes, it certainly would be a nice opportunity for someone to provide a framework or library for nice looking UI elements. There is also a business opportunity to make a library or possibly a service that takes the pain -- and it is a great deal of pain -- out of implementing BlackBerry's highly touted "push" network feature.
It seems more likely to me in the long run that RIM will simply buy Palm. One of them has good hardware and a solid operating system foundation, and the other has a spiffy user interface and a consumer market strategy that passes the laugh test.
He's certainly right about one thing: his app has an ass UI. It's RIM's fault, of course. On the Palm, Android, or iPhone platforms even "hello, world!" looks great. On BlackBerry it's impossible to get even a simple app to look good. All apps on BlackBerry that do, in fact, look good are using full-custom drawing engines. See Bloomberg, Facebook, etc. For the small developer, doing your own custom drawing is a huge undertaking assuming you have any visual design talent to speak of.
No, it's just because Linux sucks at scheduling i/o during a heavy writeout load. It always prefers to starve readers while serving writers, so if you need to save your file, and therefore you need to read a temporary file or directory, you're waiting. The SSD mitigates this problem by being 1000x faster at random i/o.
If you build is really IOPS-bound, then an SSD will utterly smoke a single disk. Even a whopping great expensive disk can only muster 300 iops under the best possible circumstances, and typically 100 iops under real conditions. A cheapo SSD can deliver 1000 mixed iops, and a good SSD can deliver 100,000 mixed iops. Ever since switching to an SSD on my dev machine I no longer have to suffer through things like a:wq in vim taking 5-10 seconds, or loading a file taking several seconds, etc. One of the benchmarks I did was starting Firefox during a build. On the machine with a disk, it actually took more than ONE MINUTE to start Firefox under a build load. With the SSD, there is no measurable difference between the Firefox startup on an idle machine and a machine with a build happening. The difference is massive.
The SSD doesn't know about the free space. There is an proposed specification in one of the committees (SCSI or ATA or somebody) to inform a storage device that blocks have been freed, thereby giving them back to the wear leveling pool. SSDs today do not care about used vs. free space. If the operating system calls for write to offset 123, the disk writes to logical offset 123, and rearranges the underlying translation layer so it knows the physical location of logical offset 123. SSDs typically have 10-20% extra physical space above and beyond their advertised logical capacity, so they never truly "run out of space".
Yes, you're right, but only because the article submitter is ignorant of how SSDs work. Writes to the same offset (from the operating system's perspective) never or rarely go to the same erase block on the flash device itself. Even static data is moved around to prevent hot spots. For MLC you can write 10,000 times the capacity of the disk before you would expect the disk to fail. With SLC you can write the capacity times 100,000. That's 12PB of writing for a 120GB SLC.
More to the point, when an SSD fails it becomes read-only, which is a VERY desirable failure mode. When a disk fails it's just trash. SSDs are clearly superior to disks for anyone who cares about keeping their data.
This is not "informative" it's "crap" and also "wrong". Modern SSDs move data even when it isn't written. Therefore there is no static data from the flash controller's point of view.
This doesn't seem right. The early 90's S3 card were some of the easiest to get working in XFree86. The Trio32, Trio64, 968, etc were all extremely common in those days. They were marketed under popular brands like Diamond, Number Nine, Hercules, and STB.
Interesting, but i have a rabbit ears with no loop and I pick up numerous digital channels. Moving and turning the ears makes channels cut in and out. Therefore I doubt your assertion.
Slashdot Mirror
Good luck. Depending on what state you live in, you are either well and truly fucked, or deeply, seriously fucked.
The best thing you can do is start a trivial corporation, hire on some fake employees, and then get a group plan.
So in other words you bought some cheap crap from a fly-by-night called "OCZ" and installed it in your servers, and were surprised when it didn't work. Do you also buy hard drives from no-name Taiwanese, or do you stick to Seagate, Western Digital, and Hitachi?
Crap is crap, whether HDD or SSD. And for that matter, memory. You can buy some janky erroneous DRAM from OCZ as well, but I don't recommend it.
This is completely backwards. It is hard drives which fail without warning. See Google's recent paper on the futility of S.M.A.R.T. And when an HDD fails, your data is _gone_. The best you can hope for is spending huge amounts of money to put the platters into another drive and reading the data back. The predominant failure mode for flash is erase cycle endurance exhaustion, upon which time the flash reverts to being read-only. Compared to a HDD the flash failure mode is hugely desirable. You can also monitor an SSD and replace it when it reaches the 100,000 erase cycle limit (or 10,000 for MLC). HDD has no such mechanism.
The AI cheats in all Civ4 difficulties above Noble. In the higher difficulty levels the AI gets free technologies, builds faster and cheaper, has lower maintenance and inflation, etc. For instance on the Monarch difficulty the AI starts (starts!) with Archery.
Which inclues an XML syntax. Any browser which supports HTML5 will also have XHTML5.
HTML5 includes XHTML5, so although it is true that XHTML2 is dead, it is also irrelevant.
http://www.whatwg.org/specs/web-apps/current-work/#the-xhtml-syntax
Exactly! I have a major "WTF?" moment every time I see people opening PDFs in their web browser. Drives me nuts. And Mac people are all up in arms because Chrome on Mac doesn't (or didn't -- it may be implemented now) open PDFs in a plug-in. To me, that's a feature, not a bug.
Tons of shit doesn't work in IE.
Why shouldn't you use XHTML? By the way, SVG made its way into HTML5 and it's much more useful than canvas so I think the reports of SVG's death are greatly exaggerated.
I would say that the main thing holding it back is the total lack of a high-performance way to address bytes in JavaScript. The state-of-the-art for decoding binary protocols in JS is to use charAt and charCode to grab a character at a certain offset in a string, which throws off a phenomenal amount of garbage to be collected and is tremendously slow as well.
The language needs better ways of manipulating bits and bytes.
I don't have a droid so I can't confirm, but this flickr user seems to have replicated the test on the Droid with far different results:
http://www.flickr.com/photos/42580856@N08/4264037413/
Yes! The Ion/MyTouch has terrible response at the edges. Hitting "P" or "Del" is very difficult.
I suspect that, given this was a geographic mission, the resolution is specified in arc-seconds, which does not equate exactly to an integral number of yards or meters, and varies in size from the equator to the poles.
I guess all I'm really saying is that in the debate about vaccination -- and I don't even think there's enough evidence to support a reasonable anti-vaccination position -- a discussion between Bill Maher and Bill Frist adds nothing. You might as well have Cheech and Chong talking about it.
But you think people should pay attention to Bill Frist, noted video diagnostic specialist and cat torturer, the guy who thought it would be OK to interfere with the Terry Shiavo case without 1) examining the patient or 2) even being a neurologist? In my view anybody who listens to either of these idiots on matters of medicine is a fool.
Yes, it certainly would be a nice opportunity for someone to provide a framework or library for nice looking UI elements. There is also a business opportunity to make a library or possibly a service that takes the pain -- and it is a great deal of pain -- out of implementing BlackBerry's highly touted "push" network feature.
It seems more likely to me in the long run that RIM will simply buy Palm. One of them has good hardware and a solid operating system foundation, and the other has a spiffy user interface and a consumer market strategy that passes the laugh test.
He's certainly right about one thing: his app has an ass UI. It's RIM's fault, of course. On the Palm, Android, or iPhone platforms even "hello, world!" looks great. On BlackBerry it's impossible to get even a simple app to look good. All apps on BlackBerry that do, in fact, look good are using full-custom drawing engines. See Bloomberg, Facebook, etc. For the small developer, doing your own custom drawing is a huge undertaking assuming you have any visual design talent to speak of.
Fail.
No, it's just because Linux sucks at scheduling i/o during a heavy writeout load. It always prefers to starve readers while serving writers, so if you need to save your file, and therefore you need to read a temporary file or directory, you're waiting. The SSD mitigates this problem by being 1000x faster at random i/o.
If you build is really IOPS-bound, then an SSD will utterly smoke a single disk. Even a whopping great expensive disk can only muster 300 iops under the best possible circumstances, and typically 100 iops under real conditions. A cheapo SSD can deliver 1000 mixed iops, and a good SSD can deliver 100,000 mixed iops. Ever since switching to an SSD on my dev machine I no longer have to suffer through things like a :wq in vim taking 5-10 seconds, or loading a file taking several seconds, etc. One of the benchmarks I did was starting Firefox during a build. On the machine with a disk, it actually took more than ONE MINUTE to start Firefox under a build load. With the SSD, there is no measurable difference between the Firefox startup on an idle machine and a machine with a build happening. The difference is massive.
The SSD doesn't know about the free space. There is an proposed specification in one of the committees (SCSI or ATA or somebody) to inform a storage device that blocks have been freed, thereby giving them back to the wear leveling pool. SSDs today do not care about used vs. free space. If the operating system calls for write to offset 123, the disk writes to logical offset 123, and rearranges the underlying translation layer so it knows the physical location of logical offset 123. SSDs typically have 10-20% extra physical space above and beyond their advertised logical capacity, so they never truly "run out of space".
Yes, you're right, but only because the article submitter is ignorant of how SSDs work. Writes to the same offset (from the operating system's perspective) never or rarely go to the same erase block on the flash device itself. Even static data is moved around to prevent hot spots. For MLC you can write 10,000 times the capacity of the disk before you would expect the disk to fail. With SLC you can write the capacity times 100,000. That's 12PB of writing for a 120GB SLC.
More to the point, when an SSD fails it becomes read-only, which is a VERY desirable failure mode. When a disk fails it's just trash. SSDs are clearly superior to disks for anyone who cares about keeping their data.
This is not "informative" it's "crap" and also "wrong". Modern SSDs move data even when it isn't written. Therefore there is no static data from the flash controller's point of view.
This doesn't seem right. The early 90's S3 card were some of the easiest to get working in XFree86. The Trio32, Trio64, 968, etc were all extremely common in those days. They were marketed under popular brands like Diamond, Number Nine, Hercules, and STB.
Interesting, but i have a rabbit ears with no loop and I pick up numerous digital channels. Moving and turning the ears makes channels cut in and out. Therefore I doubt your assertion.