Throttling Netflix to a number that's well over any rate they actually stream at doesn't really make sense. Netflix says 25mbit/sec for 4K and 5mbit/sec for 1080p, so if it's actually being throttled the only way that would ever affect me is if I tried to stream two 4K movies at the same time. I'm not even sure if that's allowed by Netflix on a normal plan, I'm pretty sure I pay extra to be able to stream two things at once even in 1080p.

My connection is nominally 250/25.

Speedtest.net gives me 238/28 to another ISP across the state from me (http://www.speedtest.net/result/5335405259.png). Amusingly I actually get a bit worse, 220/28, to my ISP's own Speedtest server (http://www.speedtest.net/result/5335408660.png)

My usenet and Steam downloads agree, I can easily max out my connection with either.

Fast.com gets me between 35 and 45 Mbit/sec down.

Don't use channel 13.

Look here: https://en.wikipedia.org/wiki/...

1, 6, 11, and 14 where available are the only channels anyone should use. They allow the most non-overlapping use of the available spectrum. If you use anything else, you've now limited the choices of everyone around who wants to avoid interference.

IMO AP vendors should really lock down the channel selection. The legitimate reasons to use any other channels are so rare and specialized that it at least shouldn't be easy to do.

Because cell phones work in frequencies a WiFi router would be capable of transmitting in? Or consumer WiFi hardware has enough power to jam a cell phone?

You might, and I stress *might* be able to push a 2.4GHz WiFi device far enough out of spec to affect the SNR on a Sprint 4G signal using the 2.5GHz band, but I still don't think it'd be powerful enough to actually jam unless you were at the fringe (though having used Sprint 2.5GHz back when they ran WiMax on it, there were a lot of fringes...)

A valid point, but I have automation already set up to handle things for me. Sonarr handles my TV library, Couch Potato does the same for movies. As long as I don't lose their databases (which are small and easy to back up) I can restore my TV and movie collections basically at the push of a button. Those programs will then go out and light up my internet connection for a few days and the missing parts will (mostly) reappear. My music collection is synced to Google. The majority of the rest is cached Steam data, which will reload the next time someone downloads that game.

Honestly I said rip more out of habit than anything. I used to rip all my DVDs myself even if I had access to a pirate release because in the DVD>Xvid era the "scene" standards had a lot of bits that were only relevant to compatibility with obscure hardware playback devices. Since I was only watching things on my computer or using an Xbox running XBMC to put it on my TV playing off a network share I could do basically anything. Increase the bitrate, change the container, change the codec entirely, keep only the audio and subtitle tracks I care about, etc. I did put a lot of time in to that and if I still bothered with it I'd probably care a lot more about my movie folder.

The thing is with DVD I was able to build a workflow and find nice open source tools I liked for every step of the process, and with that I knew I could rip any DVD I got my hands on. With Blu-Ray at least the last time I looked it was still an ongoing battle between the rippers and the DRM vendors where you had to actively keep up to be able to rip new releases. That's just not worth the time to me. Instead of ripping my Blu-Rays now I usually queue up the download from my phone while I'm in the checkout line. There are quite a few cases in my shelf that have never once been opened.

Blu-Ray's DRM definitely hasn't stopped pirates, but it's made it a real pain in the ass to casually rip your own legally obtained content. It's easier for me to pirate a copy of something I own than to rip it myself so I can use it with my nice convenient HTPC setup instead of having to deal with physical media.

I'm with you on this one. My home server has around 8TB of data on it and out of that probably 7.5TB is videos/music/games that I can redownload or rerip as necessary if I lose them.

I use a manual system, personally. /home is on a RAID1. /mnt/media is a JBOD pool. Everything easily replaced goes in /mnt/media, everything important goes in /home/$user which is also backed up. /mnt/media just gets a file listing taken every night so if it blows up I know what I lost.

As I type this there are 11 million users logged in to Steam, the primary source for PC games. There are nearly 2 million players actually in-game right now between the top 10 titles alone.

A market of millions is nothing to sneeze at. I personally would love external graphics to become a proper supportable thing rather than the occasional one-off proprietary setup I can't expect to use with the next model. I have a desktop for gaming and a laptop for portability, but with a proper external GPU option I could just have the laptop and pair it with a GPU-equipped dock for when I'm at home.

I'm not making an argument, just stating a fact.

That said, what this basically comes down to is the age-old practicality vs. idealism problem. A cryptographically verified boot process, as a basic concept, is beneficial to everyone. Bootkits are a real thing and this is a barrier against them.

If we're going to do this, we run very quickly in to the same usability problem as SSL. Most users don't have any interest in verifying and installing certificates, they just want to use the software they've bought. Even the mjg59 public shim that prompts you to install the cert off the boot media if you trust it is too much for the general market. To appease this majority you have to have a certain later of base trusted certificates which can then sign further content. Unfortunately unlike SSL where there's a massive market of domain owners who want to be able to prove they are who they say they are, there's a very small market interested in paying for signed bootloaders. Apple and all the proprietary hardware vendors don't care, they can make their EFI implementations trust whoever they want. As far as generic PC type hardware goes Microsoft is the 800 pound gorilla, with the Linux distros that care about commercial users as a very distant second class and the end-users who actually want to compile kernels somewhere out near Pluto as far as the certificate vendors are concerned.

There just isn't the market to get the certificate vendors to care, which means none of them work with the OEMs to have their certificates trusted, which ends up where we are now with Microsoft's certificate being the only one you can guarantee to be on Secure Boot capable hardware. Without a mandate from some legal authority (unlikely) or from some licensing body in control of something important to PC hardware (more unlikely) I just don't see how the situation ends up any different at this point in time. Any of the big CAs could theoretically get in this game, but why would they care to?

So, do you:

1. Throw out the entire concept, even though it has definite benefits when implemented in a fashion that respects the rights of the owner of the hardware.
2. Figure out some way to mandate that all hardware allow user management of keys.
3. Form some organization that will somehow get enough influence to get their signing key added to the default trust lists of enough major vendors to matter, then operate a signing service of your own.
4. Use the system that exists, that effectively achieves its goals, that generally supports custom keys, and that in the event custom keys are not available the one vendor who's all but guaranteed to be preinstalled offers an open signing service for...

---

To me the current situation is of course not ideal, but I can't see any practical way it could have ended up any better. Expecting every motherboard manufacturer to include keys for all the major distros is absurd. I don't expect major x86 vendors, especially those targeting businesses or the DIY market, to disable key management because it opens them up to nerd rage without any real benefits. Even if they do I don't expect Microsoft to shut down their signing service, nor do I expect them to change keys in such a way that the existing solutions stop working on new hardware because that would also break all existing UEFI Secure Boot compatible Windows install media. It's theoretically possible that all these things combine, but I consider it unlikely enough to not be worth worrying about.

Yeah, that's what my last paragraph is about. You can do that or sign any other EFI bootloader you prefer with any OS you prefer if your hardware allows changing your keys and you know how to do it.

Depends on how your distro of choice has implemented Secure Boot.

All of the distros with official support are using a shim derived from Red Hat's. That shim is a very simple bootloader which maintains compliance with Secure Boot by only chaining on to verified binaries, but it allows the use of an additional public key which has been compiled in to the binary. Anyone who finds it worth the $99 can have their build signed by Microsoft and will then be able to boot anything signed with the associated private key on top of anything signed with the Microsoft keys the system has built in. It also provides a method to pass the public key down the chain so the next stage bootloader, kernel, and beyond can verify with it as well.

Fedora and Ubuntu stop here. Fedora signs GRUB2 with their key which then verifies the kernel, which then verifies the modules. ( http://mjg59.dreamwidth.org/12... ) Ubuntu jumped on a loophole in the wording of the Secure Boot spec to just use their key to sign a bootloader which will then happily launch an unsigned kernel. ( https://lists.ubuntu.com/archi... )

Suse took things a step further and expanded the shim to support a local key list in the UEFI configuration area. ( https://www.suse.com/communiti... ). Now even a system that lacks the ability to add keys to the firmware's verification process can run a fully signed boot process with custom keys.

Finally one of the main original developers on the shim who has since left Red Hat took Suse's key management code, mixed it with his own continued tinkering, and added a user interface that comes up if you attempt to boot a signed binary that doesn't match an approved key, allowing the user to browse for a key on any accessible storage and add it to the system. ( http://mjg59.dreamwidth.org/20... )

---

So the answer depends on your distro. If you're running Ubuntu, you just compile your new kernel and go have fun because Ubuntu's not yet verifying the kernel (this is apparently becoming optional in 16.04). If you're running Suse, you use whatever tool they offer to add a key to their shim's list. If you're running Fedora, you replace their shim with one of the other variants and either add a key of your own or just go Ubuntu-style and drop it at the kernel.

Of course this is all assuming your system doesn't allow you to change the keys, which I know is a valid theoretical possibility but I still haven't encountered in the real world.

There's actually a lawsuit going on right now about this very tactic. https://sfconservancy.org/copy... (article source is funding the suit, so apply grains of salt as appropriate)

IANAL, but the position I've always heard (and seemingly the one this lawsuit is taking) is that the "GPL shim" is only legitimate in cases where the proprietary side it's interfacing with is the same on other platforms. In that case instead of just being an obvious attempt to run around copyleft it becomes a mere adapter to a vendor's standard interface. Supposedly this is how the nVidia driver has worked for a long time now, the binary blob is the same on all supported operating systems and only the shim that adapts it to each kernel differs. VMware's attempt on the other hand appears to be pretty much the opposite side of the spectrum, with heavy integration with one specific kernel under the guise of a "shim".

Personally I think that's a legitimate workaround, since in the end most drivers exist to connect the kernel with some proprietary black-box hardware over an interface that's standard to the hardware but may or may not be documented. That the public standard interface is implemented in software rather than hardware doesn't seem like it should be meaningful to me.

I guess if that suit runs to completion we'll at least see some line drawn in the sand legally which obviously wouldn't directly apply to anywhere not under German law but would probably influence future cases.

Koenigsegg (you know, the supercar company) has had a running four-cylinder prototype car built from a Saab 9-5 for years under their Freevalve (formerly Cargine) division.

http://jalopnik.com/what-its-l...

That article's two years old and they were working on their sixth generation design at the time.

The bill is literally linked in the summary. I'll link it again here: https://assets.documentcloud.o...

It's a page and a half of actual content, even with the narrow columns and oversized font they use for whatever reason.

This is actually part of a standard practice in traffic engineering called traffic calming.

It's well known that without strict enforcement people will drive whatever speed they feel comfortable on a road regardless of the posted speed limit. This is why for example when you have a four-lane divided highway with a speed limit of 55-60 MPH (common in most major metro areas) the average speed of free-flowing traffic is still likely 65+.

The same applies in areas where you really do want people driving slower. If you put a nice wide four lanes plus suicide lane down the middle of a neighborhood it doesn't matter if you put a 25 MPH limit on it, people will still tend to drive it at the same speed they would any other road of that size. Traffic calming is the practice of intentionally doing things that make it less comfortable for drivers to travel at speed, thus reducing the average speed naturally. Narrowing lanes, removing markings, the funky markings some countries use, center islands, chicanes, etc.

This is the sort of thing that should be encouraged, because they're doing it right rather than just tossing up unrealistic speed limits and going hardcore on enforcement.

Of course that is all on the assumption that these are areas where reducing speeds is legitimately desirable, as opposed to places where some idiots suddenly decided a road that's been there for years is a dangerous menace around the time their kid started walking or some old bastard whose reaction times aren

Killing the motherboard is a lot worse than just losing what's on the hard drive. When a hard drive dies (effectively the same result as 'rm -rf /' in a traditional environment in one of my clients' machines I can replace it with a random one from stock and reinstall the OS from a USB stick within an hour. Restore from backup takes whatever time it takes for how much data that machine had over gigabit ethernet.

If an otherwise good motherboard gets nuked, now I have to get parts that may be in a proprietary formfactor, I have to completely pull apart the machine, etc.

For your gun analogy it'd be more like if it brought the whole building down rather than just putting a hole in the wall.