This is what a 5MB hard drives looked like in 1956 (note: required a forklift)(thenextweb.com)
thenextweb.com
This is what a 5MB hard drives looked like in 1956 (note: required a forklift)
http://thenextweb.com/shareables/2011/12/26/this-is-what-a-5mb-hard-drive-looked-like-is-1956-required-a-forklift/
3 comments
not sure what's happening but we're looking into it. We definitely haven't got extraordinarily high traffic atm.
Are you running preforked/threaded Apache? That's usually the culprit on WP-powered sites. I'd check the Server header but recv() is failing now. ;)
Can you explain how running any other httpd that runs PHP via FastCGI or CGI would be any better? The problem is that they're dynamic pages. The solution is to statically cache the page in question. Since WP has this block in the default .htaccess:
RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L]
if you just SSH in to the server, cd over to the HTML root, wget the page in question and save the file as the name of the path, it'll statically cache it and instantly alleviate ~95% of the work needed to serve the page.
Dynamic pages are the culprit in /any/ dynamic CMS, and caching is the solution. You could use Varnish, or write/find a memcached plugin, or use redis or whatever other key/value store is trendy at the moment...it's all caching and it's the best way to make dynamic sites fast (besides Cloudflare, which is just "magical" black-box caching)
Edit: TL;DR using nginx or lighttpd or cherokee or webrick or whatever other httpd happens to be trendy this week won't help that much. Properly configuring a caching system will help an order of magnitude more.
RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L]
if you just SSH in to the server, cd over to the HTML root, wget the page in question and save the file as the name of the path, it'll statically cache it and instantly alleviate ~95% of the work needed to serve the page.
Dynamic pages are the culprit in /any/ dynamic CMS, and caching is the solution. You could use Varnish, or write/find a memcached plugin, or use redis or whatever other key/value store is trendy at the moment...it's all caching and it's the best way to make dynamic sites fast (besides Cloudflare, which is just "magical" black-box caching)
Edit: TL;DR using nginx or lighttpd or cherokee or webrick or whatever other httpd happens to be trendy this week won't help that much. Properly configuring a caching system will help an order of magnitude more.
There is a WordPress plugin entitled 'W3 Total Cache' which is a drop-in solution for this problem. No wgetting required.
W3 Total Cache with memcached and/or Cloudflare, yo.
I like reading stories about how careful programmers had to be when writing code so the use of every bit was maximized. Unfortunately, this also lead to the Y2K debacle.
Which wasn't really much of a debacle after all...
When in 2050 people will see how big a 1TB HDD is now they'll smile at it. I love progress.
I'm not so sure about that. The 3.5 inch form factor has been around for more than 30 years, and I don't see it going away anytime soon because it's a "human" size (about the size of a hand). People are not getting smaller.
We'll fit a lot of more data onto them, sure. But the physical size of the largest/most common hard disk available at that time is unlikely to change much.
We'll fit a lot of more data onto them, sure. But the physical size of the largest/most common hard disk available at that time is unlikely to change much.
Interesting theory on things only shrinking until they reach a "human size".
Many things have shrunk: cell phones, thumb drives, wall warts, personal routers/access points, flash lights, inkjet printers…
Some things can not successfully shrink: keyboards, displays…
But there are very few things that have artificially resisted shrinking: Household telephones and credit cards come to mind.
I think hard drives are a component. 3.5" will yield to 2.5" as each drive stores enough data. Smaller platters start to have diminishing returns. Before you know it the whole product will be over run by something solid state and no one will care what the last size of buggy whip was.
Many things have shrunk: cell phones, thumb drives, wall warts, personal routers/access points, flash lights, inkjet printers…
Some things can not successfully shrink: keyboards, displays…
But there are very few things that have artificially resisted shrinking: Household telephones and credit cards come to mind.
I think hard drives are a component. 3.5" will yield to 2.5" as each drive stores enough data. Smaller platters start to have diminishing returns. Before you know it the whole product will be over run by something solid state and no one will care what the last size of buggy whip was.
"We'll fit a lot of more data onto them, sure. But the physical size of a hard disk is unlikely to change much."
There's 32gb of storage on my phone, held in an area roughly the size of a dime. It's not a hard disk, but it shows where hard disks are going.
There's 32gb of storage on my phone, held in an area roughly the size of a dime. It's not a hard disk, but it shows where hard disks are going.
It's possible (likely?) that 1 TB storage will also be available in much smaller form factors - to fit inside a watch or a keychain, if not smaller.
Even if that happens, a page of uncompressed plain-text data will still be small -- that's another "human size" that won't go away any time soon, so this makes me question how much storage we'll really need in the future. Sure, we'll come up with all kinds of interesting ways to use more of it, but with devices becoming more and more "cloud-centric"...will a phone ever needs /terrabytes/ of storage?
I hope they'll be doing that towards backblazes myself. Would be far more comparable and I'd love that amount of storage to be "quaint".
"In September 1956 IBM launched the 305 RAMAC, the first ‘SUPER’ computer with a hard disk drive (HDD). The HDD weighed over a ton and stored 5 MB of data."