Yes, those. The open source drivers perform badly, and don't have fixes/workarounds for broken games. The proprietary drivers do, but often break against kernel and userland software versions. Neither is particularly pleasant with weird display setups (niche resolutions or refresh rates.)

That's ignoring that driver support often lags, there's tons of hardware out there that's either not supported yet, not supported well, or never will be supported.

If you need to resort to "instructibles" [sic], you've already lost. Locked audio devices, 30 layers of abstraction with their own quirks (and latency, lol latency), and on and on.

I should never have to run xrandr myself. Or add a modeline. X can't even manage a locking screensaver.

That's hardly the only problem. High DPI displays look like shit, default rendering settings (often) look like shit, and there's the mayhem of trying to get Qt, GTK, and misc window toolkit apps using the same widgets, fonts, font sizes, etc. Some distros do an *okay* job of that, but none comes anywhere close to OSX or Windows. There's a long way to go.

No, I suspect the community is pretty aware of this one. It comes up on Slashdot literally all the time. For example I could theoretically save a file to a remote site over SSH in Konqueror by saving it to a fish:// url. For Firefox (if this is even possible) I guess it would be smb:// because kioslaves and gnome-vfs are completely separate and incompatible. Or the completely different print/open dialogs between Qt apps and GTK ones. Or how I need basically two full desktop environments at all times, because neither ecosystem has a monopoly on good apps.

Hey, you're right: nobody cares.

Every one of these points is addressed (with links to bugs and sources) in TFA.

first I have to manage to get an SSL certificate (costs serious effort and money)

No, it costs ~$7/yr and takes a few minutes. Maybe 15 if you need to look up how to generate the signing request.

This is a dumb idea. A very dumb idea.

Since we're assuming MITM, what happens when I inject javascript into the page? Even assuming the browser prevents me from leaking the PROT header, I can still have it make arbitrary requests using your session.

What happens when I just block the original response, pretend your session died, and serve up a bogus login page that gives me your credentials?

We wouldn't have to slash school budgets if these employers paid taxes.

How's that for critical thinking?

The paper explains it.

It is to support old servers (ancient Cisco gear comes to mind) that can't properly negotiate newer TLS versions. Unfortunately those failed negotations don't fail, er, gracefully -- it just kills the connection. Browsers (Chrome, Firefox, probably others) retry using SSLv3. Why? There's a lot of old gear out there.

From agl:

We used to have an entry in the preferences for that but people thought that “SSL 3.0” was a higher version than “TLS 1.0” and would mistakenly disable the latter.

"Chrome Users Dumbed Down" might have been a more apt title.

though it might be as simple as including a Micro-USB-to-Type-C adapter with every new smartphone

This is genius.

"This new connector, whose only value is that it's reversible, doesn't work on the billions of existing devices. Why don't we include a non-reversible adapter?"

Hell, for extra convenience, just leave the adapter on the cable all the time.

You're externalizing blame.

If you have a problem with 'hoppers' have you looked into why you're failing to retain people?

Small companies are especially bad for that: fewer employees means fewer paths for personal/professional advancement: there's nowhere 'up' to move, and wearing a half-dozen hats might seem like variety at first, but you'll be wearing those same hats forever. It's too bad that they have less room to take the hits from people leaving and new people coming up to speed, but it's also unreasonable to expect people to stick around past the point they gain anything from the exchange. People *should* be moving on when they feel they're stagnating.

I have an x230 that I put a Corsair SSD in. It's running Ubuntu 13.10, so I guess it's running a 3.11.something kernel. On resume I can see the kernel block for 10+s (by the timestamps in dmesg) waiting for my SSD to get its act together. Screen is on, lockscreen is displayed ... but I can't enter a password because the entire system is waiting on the disk.

It sounds like I will benefit from this.

Your theory has one fatal flaw.