How long exactly do you suppose that phones are expected to last? I had a RAZR ten years ago and it's insane to demand that Motorola should still be supporting it in any meaningful way. More recently, the first iPhone shipped with 128MB of RAM and as little as 4GB of flash - not to mention a non-replaceable battery that is probably universally dead by now. You know, there are legitimate reasons why things improving as quickly as portable consumer electronics have short expected lifetimes. It's not so much that the hardware should die quickly as that almost everything will be functionally obsolete after a couple of years.

Should Apple be supporting a 7-generation-old iPhone 1? Should Motorola be supporting a class of device that for practical purposes no longer exists? Both of those are unreasonable expectations.

That seems to be the case. Is there an Android vendor that makes upgrading as seamless as it is for Apple devices? If so, I'd like to see what their adoption rates are like.

Joking aside Lollipop went from 0% to 0.1% in two months. iOS 8 went from 0% to 56% in two months (released in September; at 56% in November). As of now, the latest iOS 8 has 68% share, the previous iOS 7 has 29%, and older releases have about 4%.

According to Google, 46% are using two-generations-old Jelly Bean and 15% are using versions at least three generations old.

I think there are more reasons for Android users not upgrading than "they got busy over Christmas".

In which we are once again reminded how much the Slashdot demographic differs from the rest of the populace.

Which isn't a good idea anyway.

Ignore. HTTP vs HTTPS, yes. I'm still waiting for my coffee to kick in.

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.

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.

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.

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.