No, that's a zeroth approximation. To a first approximation, 65Mhz of spectrum gets you capacity linearly proportional to the frequency.

Of course, in reality there's a few more nasty surprises -- higher frequencies can carry more capacity but have much worse penetration through obstacles. Lower frequencies give better coverage at the cost of capacity. That's why shoving T-Mobile and Sprint up in the 1800+ nosebleeds means they will never get the coverage range of VZ and ATT down in the 700-800 range.

I'm no Windows fanboy, but this is just factually incorrect.

(1) All those operations require elevation, so unless the user has lowered UAC from the default, they will require authentication. I suppose a malicious installer could do that, but it is emphatically incorrect that any running code can effect that change.

(2) Since 7, when Windows elevates it completely suspends the old 'Desktop' and creates a brand new one for the elevation prompt. If you look closely, you'll realize that all the other 'windows' are actually just a static screenshot of what happened on the unprivileged desktop at the point where the elevation prompt was created.

So "from a security point of view", on Windows you have a specific privilege required to change the SS that is mediated through a privileged interface where it cannot be snooped/intercepted by unprivileged processes.

[ Of course, this comparison is also patently unfair -- Windows 7 was written in the 2000s, X11 was written in the 1980s. Expecting them to be comparable in terms of security is pretty ridiculous. ]

Reading posts in context is pretty key. For instance, I was replying to a post with the claim:

When now (taking your info) it should specify that you check a box and pay more for registration and your insurance costs more.

So you are right, and the guy to which I was responding was wrong. Doubly wrong for using "simply" for something that wasn't simply that.

Mostly (a). For instance, most registration can be done online but comercial still requires an in-person trip to the DMV. The fees are also higher for no perceptible reason, but (c) is off the mark since we are talking about commercial vehicle registration, not commercial driver licensing.

As to the last question, I don't think it matters. If the State wants to impose a uniform insurance requirement (details tbd) on all taxis and similar ride services, they can go ahead and do that directly and clearly. There's no need to tie it to registration or any other thing -- just go ahead and plainly say that you need such-and-such insurance if you give rides in exchange for money.

[ Of course, that would increase the cost of traditional taxis just as much as Uber, which is (IMHO) a feature of a fair set of regulations. They are supposed to protect the customers by providing insurance/inspection/training requirements, not pick favorites among competitors. ]

If it was just a matter of ticking off a different check box, why wouldn't every Uber drive just go ahead and do that when registering? In fact, if checking an additional box gave you more privileges, why wouldn't everyone do it all the time?

In practice, of course, it's not at all "just checking the box" but rather a red-tape nightmare of confusing and contradictory regulations. The process needs to be cleaned up and the regulations (which I'm sure the content of which are mostly fine) need to be stated clearly and applied uniformly. That's not too much to ask.

Maybe the DMV should streamline the process instead of lowering the requirements? In fact, living in CA I can say that the DMV has pretty reasonable objective requirements/policies even when they have godawful process/implementation.

They should make it trivially easy for anyone that meets a set of clearly-defined objective requirements -- training, insurance, inspection, whatever else -- to get a commercial license. I don't even particularly care what the content of those requirements is -- so long as they are non-arbitrary and enforced even-handedly.

[ In fact, they ought to do the same for cabs -- write up the requirements, then implement them. Most of the reason for Uber is that cities had these absurd fixed-number-of-medallions systems anyway. By doing that they ultimately authored their own destruction. ]

In addition to selling your credit card and social security numbers, they can now offer to sell your vote for 10 cents apiece. Just harvest the private keys and it's a race to see which botnet can sign with the stolen key first! Sell them on TOR or I2P, I'm pretty sure Koch and Soros will bid big money to literally buy the election -- you can auction them against each other.

And if you say "we'll put the private key on a dedicated USB stick only for voting" then not only have you killed a lot of the convenience (for instance, you cannot do it from a phone but need a PC that can act as a USB host) but you've just moved the point of pwnage up a little bit to having to steal it right as you vote (or present a bogus voting interface!).

Really what you need is a set of physically separate machines that people can go to and plug their USB drive into a known secure environment. You could even put them in convenient nearby locations like schools and churches ...

Easier solution: if you are drunk, do not consent to the breathalyzer/blood test. They can still try to convict you, but it's a lot harder without the forensic evidence. That can also try to phone a judge and get a warrant, but that takes time and judges don't like being woken up -- if they have a warrant, you have to comply. And don't let them try any of this "implied consent" nonsense, the US Supreme Court has recently affirmed that a motorist can withdraw/refuse consent to any test at any point, see Missouri v. McNeely explicitly holding that neither implied consent nor exigency allows the police to compel a DUI test without first obtaining a warrant.

Of course, you can have your license suspended for refusing the test (i.e. the right to refuse consent to the test does not confer immunity from the consequences) but that's all civil. You'll have a much better chance at avoiding the criminal conviction and subsequent stint in jail.

Penalizing those of us that walk/cab/transit home from a night out (after leaving the car at home like a responsible human being) is really the best you can think of?

That's 43% of discretionary spending, which is itself about 30% of total spending. Spending Social Security and Medicare/Medicaid are both individually 1.5x as large as medical spending.

Here's that in pie chart form and in infographic form. All numbers from the Congressional OMB.

OP said: "I'm a felon with several prior misdemeanor convictions".

Don't you mean a felon with prior felony convictions? As far as I understand (please do correct me if I'm wrong) you cannot be treated as a felon for misdemeanor offenses, no matter how numerous.

Also, I'm going to give the benefit of the doubt that the statement was just clumsily phrased but even so, the wording ought to be fixed to be crystal clear.

The problem with taxing at a fixed percentage of volume is that it penalizes high-volume low-margin businesses relative to the high-margin ones. That introduces serious inefficiency by artificially lowering the relative cost of expensive good relative to cheaper ones (which is also regressive*).

In practice, States try to soften the regressive nature of fixed-percentage taxes by devising a classification scheme wherein essential goods like food are taxed at a different rate (sometimes zero). That leads to a separate inefficiency where now people start to game and dispute the classification, leading to high-stakes court battles about wether Jaffa cakes are a cake or biscuit.

* Most commodities like gas* and groceries fall into the "high volume low margin" category, so this will harder hit the lower class that spends a large percentage on its income on commodities. In the US, gas stations average 3c on each dollar spent on gas, less than half the average margin for a private business in the US. YMMV in other countries.

I don't think anyone claims that Uber should not have insured drivers or should permit their drivers to discriminated by race.

What they do claim, is that it's ridiculous for the city to have a fixed number of medallions for drivers, instead of letting anyone that meets the (insurance,inspection,background,...) checks compete under the same set of rule. The sad fact in a number of cities is that possession of an arbitrary token is more important that substantive comliance with an objective set of requirements.

With a dozen or so lines of code you can convert any services that listens on a socket (UNIX, INET, NETLINK or POSIX) to have systemd create the socket and pass it in -- and that includes code to fall back to socket creation if it's not launched by systemd. This has a few benefits:

• Startup: Services don't need to signal back init systems that a service is ready to receive requests (or, worse: I've seen colleagues either put in a sleep, or having dependent processes poll, shudder). As soon as the socket is created, requests can be received. When the process is ready to read/select, it gets everything in the buffer.

  In fact, while a ton of people are focused on the way systemd manages dependencies between startup processes, they overlook that socket-passing actually removes dependencies between them. In other words, even if you have some horribly complex web of socket-based services, you can treat them as entirely independent.

• On-demand-services: Got a socket service that doesn't have tight startup latency requirements and is launched infrequently like sshd or ntpd? Why does it have to stick around all the time consuming resources? Let systemd hold the socket and launch it whenever a client connects and just exit() when your last client goes away. Apple has been doing this for years -- aggressively reclaiming memory from daemons that don't need to be immediately available. This also improves startup times because non-essential services aren't launching at the same time as essential ones, decreasing CPU/IO thrash -- I've seen admins create init-groups that launch 5 minutes after startup for this purpose actually, this solves the issue more sensibly.
• Crashes: Services that crash obviously lose all session state, but having the socket persist means that requests never get rejected -- they just wait a bit longer. For a concrete example, if Apache relies on SQL and then SQL crashes, obviously any in-flight queries are going to return errors. But new queries launched by different Apache worker threads will just sit in the socket buffer until SQL comes back to life. This is a pretty big win for mitigating client impact.
• In-place-updates: Services that need to be updated/patched are just a different manifestation of the "Crash" bullet above. Need to patch your services without killing all its clients? Stop processing new requests, fulfill everything in the queue, restart, pick up where you left off. Unless the client is closely monitoring the latency of requests, they won't even know that the service was patched underneath them.

So that's at least one thing that systemd brings that other init systems don't, that solves a few real problems and enables some new features that other init systems can't.

Actually systemd doesn't care if it's actually running yet or not, because it already created a socket listening on port 80/443 (or whatever) and passed it to Apache. If anyone tries to send something to 80, it will be queued in the socket's buffer, and once Apache finishes its startup goo, it will process the backlog.

In other words, there's a third state in between "Not Ready" and "Fully Ready" which is "I'm ready enough to receive and enqueue requests without dropping them but I can't fulfill them immediately". Once a service hits that state, no one should care any further.

[ Bonus round: if Apache crashes, that's fine too because systemd keeps the socket around and passes it to the relaunched instance with all the pending requests intact. Which actually means that it never goes to "Not even ready to receive requests" even on crash and all requests are seamlessly processed. ]