The TREZOR is close to what the GP requested, or would be if 7-11s sold bitcoins. It requires a PIN to spend the funds, which protects against theft, and if it's lost or stolen or simply stops working you can recover your funds with the backup seed and any of several compatible wallet programs. Aside from the backup, which you keep in a secure place, the key never leaves the device, so you don't have to trust the USB host.

I just checked with my AT&T mobile phone and found an "x-acr" header which seems to serve much the same purpose, so switching away from Verizon might not help. (The header is not present when accessing the site through a VPN, so it wasn't sent by the browser.)

The content seems to be based on the Anonymous Customer Reference concept promoted by the GSM Alliance.

The number may have been assigned by the USB WG, but it was the manufacturer who decided to check for it in the drivers. Either way, the use of that number is a necessary part of creating drop-in-compatible hardware.

Of course, they can't advertise their product with the USB logo if they're not following the USB specifications, including the use of assigned ID numbers, but that's a separate matter. There is no requirement for non-members to adhere to the ID numbers assigned by the USB WG so long as they don't claim to be fully compliant.

It is a textbook trademark case, but you're referring to the wrong part of the textbook. Consider the case of the game consoles which wouldn't operate without a bit-for-bit copy of the manufacturer's logo in the ROM, a trick intended to shut out unlicensed game developers. The court ruled that third-party developers could include the logo image without a license despite the fact that it was both copyrighted and trademarked, because the manufacturer had chosen to make it necessary for compatibility.

Only to the computer, which doesn't really count. These IDs could reasonably be considered part of the interface to the hardware; exceptions have been granted for both copyright and trademarks in the past when the infringement was required for the sake of compatibility. The real question is whether the buyer was misled to believe that these chips were manufactured by FTDI. It seems that this was indeed the case, but that's a separate issue from the USB VID/PID.

I stand corrected. It appears that while there are plenty of humans with four cones, this has only been identified (in 2012) to lead to enhanced color differentiation in one subject after 20 years of research. The vast majority are "non-functional tetrachromats". So perhaps not entirely discredited, but close enough as makes little difference.

This is separate from the ability for trichromats to distinguish more colors by taking into account both the cones and the rods, which is well-established, though generally limited to the low-light conditions where the rods are more sensitive.

The cybermen aren't that different—despite the suppressed emotions, they're not purely mechanical. They have living brains inside their mechanical bodies. The difference is that the cybermen are set on "upgrading" people; they think of it as a service. They consider themselves advanced life-forms and want others to have the same experience. Failure to comprehend the benefits of what they're offering is taken as further evidence that you're in need of an "upgrade". They're constantly looking for ways to incorporate improvements into their design—the ultimate "progressives", in a sense.

The Daleks, on the other hand, are all about "racial purity"; their driving interest is the elimination of any form of life other than their own. They aren't interested in turning anyone into a Dalek. In contrast to the cybermen's drive for constant improvement, the Daleks are striving to restore an idealized version of themselves from their past—the ultimate "conservatives".

And while I'd rather avoid both if possible, if it came to a choice then I'd also prefer to deal with the Daleks. At least they'll acknowledge that they're out to kill you, as opposed to claiming that they're acting for your own good.

Of course not. Thanks to the Private Express Statutes, FedEx can't legally deliver ordinary letters unless USPS postage is paid on top of its own delivery rate. The system is deliberately set up such that no one can compete effectively with the USPS.

It's not quite that simple. Putting aside the rare few tetrachromats with four kinds of cone cells, there are also the rods, which can sense a broad spectrum of light overlapping the ranges of the cone cells—some more than others. The color isn't going to look quite right if the overall brightness reported by the rods doesn't match the per-component brightnesses reported by the cones.

That said, three well-chosen primary colors can get us most of the way there, perhaps enough so that these minor differences won't matter—unless you happen to be tetrachromatic.

That isn't what I said. You can run systemd without running all of the other components. I use systemd for init but networkd or firewalld, for example. The reverse may or may not be possible for any particular component within the systemd "brand", and I don't see any problem with that. These programs are add-ons designed to work with systemd. If they happen to work without it as standalone daemons, that's a nice coincidence, but by no means essential. Anyone using sysvinit already had their own cobbled-together shell scripts for managing these things.

Anyway, why would I want to? Systemd works just fine for me as it is. I have no need nor desire to split up the package. Don't fix what isn't broken. (And yes, sysvinit was well and truly broken. Linux was one of the last Unix-based operating systems to cling to it; everyone else had already moved on.)

Having looked over the source for systemd-networkd, I see no particular reason why it couldn't be used outside of systemd provided dbus was up and running. I'll grant that systemd depends on systemd-journald, or at least something implementing the same interface. That's one of the few "hard" dependencies; most of the remaining services (like networkd, hostnamed, localed, and timedated) are optional. I assume you were exaggerating, but just to be clear: it is not necessary to run all of the programs which make up the systemd "brand". With the exception of a few core dependencies like journald, you are free to pick the components you wish to run.

That assumption is the problem. Congress can pass whatever it wants, and if the Supreme Court doesn't deign to overturn it, it's presumed constitutional—anyone who disagrees is referred back to the Court. That attitude effectively makes the Court the final arbiter of constitutionality, when it is in fact the responsibility of every individual involved to judge the constitutionality of the law and refuse to enforce those which Congress had no authority to pass.

That may not technically be called "judicial review", but it's what the OP was complaining about—not the practice of overturning unconstitutional laws, but that of upholding ones of dubious constitutionality which the Supreme Court, for whatever reason, has not chosen to strike down.

Exactly. It's not a single application, it's a brand. Separate applications developed in a common repository and intended to work well together. One might as well complain about all the basic utilities under the GNU project umbrella. Or consider the various BSDs, where the entire userspace (including the init system) is developed in the same repository as the kernel.

It's perfectly reasonable for the Supreme Court to have the power to review laws and strike them down as unconstitutional. The problem enters when they presume to declare a law constitutional, or when failure to strike down a law is taken as affirmation of the same. An unconstitutional law is void whether or not the Supreme Court rules against it. It is not within Congress's authority to pass such a law, nor does the Executive have the authority to enforce it.

No, I'd say that's closer to what I was describing. The UI is a separate component which is hosted on the server but runs entirely in the browser, on the client side. The UI makes remote API calls at the UI/backend interface level back to retrieve data or perform actions. With the more modern web applications, interaction with UI elements results in running local Javascript code in the browser rather than communicating low-level UI events like button pushes back to the server.