LOLWAT? Given the ubiquity of JSON-over-REST as a common API for just about everything, HTTP is the exact opposite of on the way out. If anything, it's absorbing and replacing many other protocols (even when it shouldn't).
Medium's just another blogging platform. Why does it matter whether it's explicitly pointed out, any more than Wordpress or Tumblr or other blog hosts?
SSH connections take For. Eh. Ver. relatively speaking:
% time ssh localserver exit ssh localserver exit 0.02s user 0.02s system 2% cpu 2.061 total
Subsequent requests using the same connection are quick enough:
% time ssh localserver exit
ssh localserver exit 0.00s user 0.00s system 20% cpu 0.039 total
But compare to an HTTPS connection to a remote host:
% cat curlcfg verbose trace-time
url = "https://www.google.com/" output = "/dev/null" head
url = "https://www.google.com/" output = "/dev/null" head
% curl -K curlcfg ...
A brand new request to a remote server takes just 263ms, and a second request only 81ms. Considering that the server is 25ms away, that makes it a bit faster than a cached SSH connection to a local machine.
But even more than that, SSH in this context is a transport, not a protocol. It allows you to build and manage secure connections, but you still have to write a protocol on top of it ("I'll send this command, and you reply with..."). Even if you "cheat" and use SFTP, you're still missing out on fixes to the thousands of little issues people have worked out with HTTP over the years. What's the SFTP equivalent of If-Modified-Since? How will redirects to remote servers work? What's your cross-domain scripting policy? How are you going to handle anonymous connections?
Use SSH for SSH. Use HTTP for HTTP. They're separate things for good reasons.
Because without HTTPS, anyone who owns a router between me and their hosting site can see everything I'm reading, every comment I make as AC, every session cookie I pass over the wire, everything. More importantly, there's no good reason whatsoever not to secure it. Encryption is incredibly cheap, so Just Do It.
And how many of these drives protect against bit rot?
All of them. Sometime when you feel overly happy and secure, throw on some emo music and read about how all modern hard drives use statistical analysis to figure out how the waveform they pull off the platters most likely maps into a pattern of ones and zeros. You won't sleep well that night.
The startup overhead is higher, but I think a nice RAID is cheaper in the long run. For one, it's no longer suicidal to wait for a drive to die before replacing it. (Not saying that's a great idea, just not utterly insane. It also means that most home users can make their back schedule less frequent and still have a decent expectation of not losing data. (Yes, RAID isn't backup - but it gives you a fighting chance of keeping your data alive long enough to get it backed up.)
You (and I) care more about throughput than IOPS. I most frequently access my data over Wi-Fi, so I'm only using a tiny portion of my NAS's potential R/W bandwidth. The SSD cache would be awesome if you're hosting a bunch of VMs over iSCSI or something like that where you're getting lots of random writes. You (and I) don't do that, so an SSD would be a waste of money - and in my case, an otherwise usable drive bay.
Apparently Seagate meant 2400h per year, i.e. typical office usage, in contrast to 24x7.
I'm a little confused, because that PDF sounds like they expect 2,400 hours when used 40 hours per week, or about 60 weeks. That's "slightly" less than the two year warranty, so I'm wondering how they reconcile those numbers.
I'm not sure what "power-on hours" mean. It's obviously not MTBF. Is it max lifetime?
It's just that: how many hours it's designed to be turned on for. Compare to a lightbulb labeled to last for 1,000 hours but marketed as lasting for two years, with the fine print explaining "* when used for an hour per day". The expectation is that this particular drive will last for 24 calendar months, but that it won't be powered up and spinning the whole time. Imagine an office computer that gets turned off at night and weekends, and puts itself to sleep regularly throughout the day.
Given that this is a desktop-grade hard drive, that light duty cycle is probably not unreasonable. In any event, I'm sure Seagate has done their homework and 2,400 is the line between "we can reject warranty claims with 'you overworked it' as the reason" and "if we say our drive only lasts 2,000 hours, no one will buy it".
My biggest complaint with it is that there's no way that can responsibly listed as a NAS drive, but that's what their data sheet says it's good for. If you dropped that in a NAS, either it'd be spun up the whole time and burn through its specced lifetime in three months, or it'd be spinning up and down constantly and cause terrible performance with huge latencies on first reads after the drive falls asleep.
Look at the AFR on the data sheet. It's less than 1%. So, obviously the MTBF is not 2400 hours. It's >875,000 hours.
There's a difference between powered hours and total expected lifetime. These drives have a two year warranty, so they're betting that it will last for at least 1,200 powered up hours per year, or about 3 hours a day. Also, MTBF does not mean that a single drive will last 875,000 hours (or 100 years), just that only one in hundred drives is expected to die per year.
In the same data sheet, they claim the drive is ideal for:
- Desktop or all-in-one PCs
- Home servers
- PC-based gaming systems
- Desktop RAID
- Direct-attached external storage devices (DAS)
- Network-attached storage devices (NAS)
Maybe that's why they bumped the load/unload cycles to 300,000 when they went from 500GB to 750GB: so the drive can spin up and down constantly so that it's only spinning the bare minimum of time necessary. Never mind that almost no NAS will have this set up by default, because that'd be a horrible user experience and everyone would complain to support that it takes 10 seconds to start retrieving a file each time they go to access it.
I'm buying 6TB drives now because two years from now I'll really wish I would've. They're not much more in absolute dollars than 4TB drives, and WD Reds had a small margin over Greens the week I bought them. As of today:
At those prices, to me the Red drives are definitely worth the narrow price difference, and 6TB is reasonably priced. The Seagate is an expensive travesty.
I started way back when with a Drobo and a 1TB WD Black. When I wanted to grow that, 2TB drives were the sweet spot so I added a 2TB WD Green. Same for a year or so later, when I added a Seagate 3TB Barracuda. When I upgraded the Drobo to the DS412+, I threw in a WD Green 4TB.
Six months ago, the Seagate died. Tech support was decent and they replaced it under warranty with a refurb that had a 90 day warranty. At day 95, the replacement died. That's when I upped the ante and replaced it with a 6TB WD Red.
I keep watching SMART stats on that WD Black 1TB with 25,434 hours on it but it seems to be holding steady. The WD Greens aren't NAS drives but they're chugging away with nary a scary SMART data point. Seagate can go screw themselves.
...which is the only reason I'd care to read such an article. I have a Synology 4-bay NAS filled with drives for home stuff. Although it's not critical data and I have the most important folders backed up to Amazon Glacier, several TB of data is tied up in rips of our CD and DVD collection. While I could re-rip everything, the first effort took weeks and I'd strongly prefer not to have to again.
So for my specific application, I don't care a lot about raw performance because everything's going through a 1Gb switch anyway. However, this thing runs 24/7 and I'd like a reasonably warm fuzzy feeling that I'm not likely to have two drives fail simultaneously. NAS drives (I've bought WD Red most recently) are specced for exactly that environment and have things like anti-vibration mechanisms to make them less likely to spontaneously explode. For the exact opposite, check out the Seagate Barracuda Data Sheet. Scroll down to where they're rated for 2,400 power-on hours. In other words, they're built to survive a whopping 3 months in a NAS.
If you're buying something to stick in your gaming computer, read the performance specs. If you actually care about the data you're writing, the reliability numbers are way more interesting.
Also, video games tend to have no depth of field. How could they? The whole screen needs to be in focus so that you can look at any part of it. Movies have the luxury of deciding what you should pay attention to and focusing (literally) on that.
Copyright infringement is theft because it denies a copyright owner the ability to sell the product for which they have the copyright and thus they lose money.
Thanks for the nostalgia! I remember when people tried to claim that with a straight face back in the 80s, but no one believed it even then. Can you imagine that someone actually said that ridiculous crap in seriousness once? I'm glad we've moved past those ludicrously mind-bending contortions and can laugh about them now, knowing full well that no one actually thinks that way anymore.
Whatever the environment, there are jobs that require someone just to be there waiting for something unusual to happen. Even in the nuclear missile bunkers, I bet they spend about 95% of their time sitting around waiting for an alarm they hope never comes. You can only clean so much before it's time to lean. So what if OP works in a clean room? I bet there are plenty of "I'm paid to sit here" jobs in there, too.
Why not? Why should the creator not be able to impose any restrictions they damn please?
Largely because of the first-sale doctrine, which codifies property rights sanity: if you sell me something, it is now mine, not yours. I can do whatever I want with it. Use my spatula as a screwdriver? Use a thermos bottle for a hammer? Watch scenes in a movie out of order? It's none of your business. I bought it. It is now my property, and I'm free to do with it as I please.
(Averting pedantry: of course that doesn't involve violating copyright. Straw men will be ignored.)
Hell yeah, I'll admit that I am King of the Geeks. Talk nerdy to me.
OK, OK. I'll double-check with a calculator that's not "bc" before publishing. I've done enough physics work, though, to trust that 1) calculations showing explicit conversions are almost always correct, and 2) calculations that don't almost never are.
Like when Bell Labs developed C to write Unix? There's a long tradition of major companies coming up with new languages to scratch an itch. Thank God is hasn't died. How boring to live in a time when we'd decided that there was nothing left to innovate?
Slashdot Mirror
In which we are once again reminded how much the Slashdot demographic differs from the rest of the populace.
* compression. You mean like this, "SSLCompression On".
Which isn't a good idea anyway.
Ignore. HTTP vs HTTPS, yes. I'm still waiting for my coffee to kick in.
http is on the way out
LOLWAT? Given the ubiquity of JSON-over-REST as a common API for just about everything, HTTP is the exact opposite of on the way out. If anything, it's absorbing and replacing many other protocols (even when it shouldn't).
Medium's just another blogging platform. Why does it matter whether it's explicitly pointed out, any more than Wordpress or Tumblr or other blog hosts?
SSH connections take For. Eh. Ver. relatively speaking:
Subsequent requests using the same connection are quick enough:
% time ssh localserver exit ssh localserver exit 0.00s user 0.00s system 20% cpu 0.039 total
But compare to an HTTPS connection to a remote host:
A brand new request to a remote server takes just 263ms, and a second request only 81ms. Considering that the server is 25ms away, that makes it a bit faster than a cached SSH connection to a local machine.
But even more than that, SSH in this context is a transport, not a protocol. It allows you to build and manage secure connections, but you still have to write a protocol on top of it ("I'll send this command, and you reply with..."). Even if you "cheat" and use SFTP, you're still missing out on fixes to the thousands of little issues people have worked out with HTTP over the years. What's the SFTP equivalent of If-Modified-Since? How will redirects to remote servers work? What's your cross-domain scripting policy? How are you going to handle anonymous connections?
Use SSH for SSH. Use HTTP for HTTP. They're separate things for good reasons.
To what end should slashdot secure itself?
Because without HTTPS, anyone who owns a router between me and their hosting site can see everything I'm reading, every comment I make as AC, every session cookie I pass over the wire, everything. More importantly, there's no good reason whatsoever not to secure it. Encryption is incredibly cheap, so Just Do It.
And how many of these drives protect against bit rot?
All of them. Sometime when you feel overly happy and secure, throw on some emo music and read about how all modern hard drives use statistical analysis to figure out how the waveform they pull off the platters most likely maps into a pattern of ones and zeros. You won't sleep well that night.
The startup overhead is higher, but I think a nice RAID is cheaper in the long run. For one, it's no longer suicidal to wait for a drive to die before replacing it. (Not saying that's a great idea, just not utterly insane. It also means that most home users can make their back schedule less frequent and still have a decent expectation of not losing data. (Yes, RAID isn't backup - but it gives you a fighting chance of keeping your data alive long enough to get it backed up.)
You (and I) care more about throughput than IOPS. I most frequently access my data over Wi-Fi, so I'm only using a tiny portion of my NAS's potential R/W bandwidth. The SSD cache would be awesome if you're hosting a bunch of VMs over iSCSI or something like that where you're getting lots of random writes. You (and I) don't do that, so an SSD would be a waste of money - and in my case, an otherwise usable drive bay.
Apparently Seagate meant 2400h per year, i.e. typical office usage, in contrast to 24x7.
I'm a little confused, because that PDF sounds like they expect 2,400 hours when used 40 hours per week, or about 60 weeks. That's "slightly" less than the two year warranty, so I'm wondering how they reconcile those numbers.
I'm not sure what "power-on hours" mean. It's obviously not MTBF. Is it max lifetime?
It's just that: how many hours it's designed to be turned on for. Compare to a lightbulb labeled to last for 1,000 hours but marketed as lasting for two years, with the fine print explaining "* when used for an hour per day". The expectation is that this particular drive will last for 24 calendar months, but that it won't be powered up and spinning the whole time. Imagine an office computer that gets turned off at night and weekends, and puts itself to sleep regularly throughout the day.
Given that this is a desktop-grade hard drive, that light duty cycle is probably not unreasonable. In any event, I'm sure Seagate has done their homework and 2,400 is the line between "we can reject warranty claims with 'you overworked it' as the reason" and "if we say our drive only lasts 2,000 hours, no one will buy it".
My biggest complaint with it is that there's no way that can responsibly listed as a NAS drive, but that's what their data sheet says it's good for. If you dropped that in a NAS, either it'd be spun up the whole time and burn through its specced lifetime in three months, or it'd be spinning up and down constantly and cause terrible performance with huge latencies on first reads after the drive falls asleep.
Look at the AFR on the data sheet. It's less than 1%. So, obviously the MTBF is not 2400 hours. It's >875,000 hours.
There's a difference between powered hours and total expected lifetime. These drives have a two year warranty, so they're betting that it will last for at least 1,200 powered up hours per year, or about 3 hours a day. Also, MTBF does not mean that a single drive will last 875,000 hours (or 100 years), just that only one in hundred drives is expected to die per year.
In the same data sheet, they claim the drive is ideal for:
- Desktop or all-in-one PCs
- Home servers
- PC-based gaming systems
- Desktop RAID
- Direct-attached external storage devices (DAS)
- Network-attached storage devices (NAS)
Maybe that's why they bumped the load/unload cycles to 300,000 when they went from 500GB to 750GB: so the drive can spin up and down constantly so that it's only spinning the bare minimum of time necessary. Never mind that almost no NAS will have this set up by default, because that'd be a horrible user experience and everyone would complain to support that it takes 10 seconds to start retrieving a file each time they go to access it.
That's an attractive offer, but there's zero chance I'm going to be the first to try a new technology that Seagate's just now rolling out.
I'm buying 6TB drives now because two years from now I'll really wish I would've. They're not much more in absolute dollars than 4TB drives, and WD Reds had a small margin over Greens the week I bought them. As of today:
At those prices, to me the Red drives are definitely worth the narrow price difference, and 6TB is reasonably priced. The Seagate is an expensive travesty.
I started way back when with a Drobo and a 1TB WD Black. When I wanted to grow that, 2TB drives were the sweet spot so I added a 2TB WD Green. Same for a year or so later, when I added a Seagate 3TB Barracuda. When I upgraded the Drobo to the DS412+, I threw in a WD Green 4TB.
Six months ago, the Seagate died. Tech support was decent and they replaced it under warranty with a refurb that had a 90 day warranty. At day 95, the replacement died. That's when I upped the ante and replaced it with a 6TB WD Red.
I keep watching SMART stats on that WD Black 1TB with 25,434 hours on it but it seems to be holding steady. The WD Greens aren't NAS drives but they're chugging away with nary a scary SMART data point. Seagate can go screw themselves.
There were no mentions of reliability metrics
...which is the only reason I'd care to read such an article. I have a Synology 4-bay NAS filled with drives for home stuff. Although it's not critical data and I have the most important folders backed up to Amazon Glacier, several TB of data is tied up in rips of our CD and DVD collection. While I could re-rip everything, the first effort took weeks and I'd strongly prefer not to have to again.
So for my specific application, I don't care a lot about raw performance because everything's going through a 1Gb switch anyway. However, this thing runs 24/7 and I'd like a reasonably warm fuzzy feeling that I'm not likely to have two drives fail simultaneously. NAS drives (I've bought WD Red most recently) are specced for exactly that environment and have things like anti-vibration mechanisms to make them less likely to spontaneously explode. For the exact opposite, check out the Seagate Barracuda Data Sheet. Scroll down to where they're rated for 2,400 power-on hours. In other words, they're built to survive a whopping 3 months in a NAS.
If you're buying something to stick in your gaming computer, read the performance specs. If you actually care about the data you're writing, the reliability numbers are way more interesting.
Also, video games tend to have no depth of field. How could they? The whole screen needs to be in focus so that you can look at any part of it. Movies have the luxury of deciding what you should pay attention to and focusing (literally) on that.
Copyright infringement is theft because it denies a copyright owner the ability to sell the product for which they have the copyright and thus they lose money.
Thanks for the nostalgia! I remember when people tried to claim that with a straight face back in the 80s, but no one believed it even then. Can you imagine that someone actually said that ridiculous crap in seriousness once? I'm glad we've moved past those ludicrously mind-bending contortions and can laugh about them now, knowing full well that no one actually thinks that way anymore.
Sharing: Willingly giving a portion of your possessions
Bzzt. I can share hugs, music, friendship, laughter, pain, and joy with others, but I wouldn't call any of those "possessions".
to another, denying you use or benefit thereof.
That presumes scarcity. If I share your post on Twitter, you are not deprived of it. Neither would I be.
Whatever the environment, there are jobs that require someone just to be there waiting for something unusual to happen. Even in the nuclear missile bunkers, I bet they spend about 95% of their time sitting around waiting for an alarm they hope never comes. You can only clean so much before it's time to lean. So what if OP works in a clean room? I bet there are plenty of "I'm paid to sit here" jobs in there, too.
Why not? Why should the creator not be able to impose any restrictions they damn please?
Largely because of the first-sale doctrine, which codifies property rights sanity: if you sell me something, it is now mine, not yours. I can do whatever I want with it. Use my spatula as a screwdriver? Use a thermos bottle for a hammer? Watch scenes in a movie out of order? It's none of your business. I bought it. It is now my property, and I'm free to do with it as I please.
(Averting pedantry: of course that doesn't involve violating copyright. Straw men will be ignored.)
Burma Shave.
Hell yeah, I'll admit that I am King of the Geeks. Talk nerdy to me.
OK, OK. I'll double-check with a calculator that's not "bc" before publishing. I've done enough physics work, though, to trust that 1) calculations showing explicit conversions are almost always correct, and 2) calculations that don't almost never are.
Like when Bell Labs developed C to write Unix? There's a long tradition of major companies coming up with new languages to scratch an itch. Thank God is hasn't died. How boring to live in a time when we'd decided that there was nothing left to innovate?