Should it?

Not true. https://developers.google.com/speed/public-dns/faq#cdn. Most site's nameservers that serve geo-sensitive results (including Youtube's) respect the edns-client-subnet information that most public DNS resolvers send, including Google's Public DNS. That means that regardless of where the public nameserver is located, it'll fetch the appropriate results from the authority as if it was on your network.

If other sites work at full speed, it's possible that your ISP's peering with Google is the bottleneck, not the last mile. It would be tricky to get much visibility into that though.

I agree because people are dumb, but it's ironic because the original autopilots, the ones in planes, are nowhere near this sophisticated despite recent improvements. It's only relatively recently that they're smart enough to avoid stalling the plane by giving up trying to maintain altitude, or will refuse to fly into a mountain. Lane-keeping is actually a much harder challenge.

Simple autopilots take a few inputs:
- Aircraft roll from the gyroscope, or an internal gyroscope
- Heading and selected heading
- Navigation error
- Altitude from an altimeter, or more commonly an outside-air-pressure input with their own altimeter inside

They have usually 2 outputs: servos on the control yoke to control roll, and a servo on the trim tab to control pitch. A bigger plane will have a yaw control on the rudder (to make turns more comfortable), and an even bigger plane will have auto-throttles. Without auto-throttle you have to manually adjust the power setting for the climb/descent you're commanding - and yes sometimes people forget and die.

They basically live their lives trying to make some of their inputs match other inputs, or match some selected value, with no concepts beyond that. One common autopilot in small planes (KAP140) can be put in roll, heading, or 'nav' mode in the roll axis, and vertical-speed or altitude-hold mode in the pitch axis. Roll mode just means "wings level" and drives towards level if it's not. Heading compares the current heading to the selected heading (via the "heading bug") and tries to line them up, turning until they are. Nav mode takes an input from the "CDI" (position error from desired course) display and tries to make that 0 by turning opposite the error direction. The pitch-axis modes are pretty obvious. You can "arm" a particular mode to "capture" it when it the error gets close enough to 0, for instance flying a particular heading until on the desired course, then maintaining that course - or perhaps holding a particular vertical speed until reaching the desired altitude, then leveling off there. There's no inputs for "don't hit other airplanes" or "don't hit the ground" or "don't stall by trying to climb without enough power" - they just try to keep the analog error signal at 0 and correct if it's not.

So "autopilot" is pretty apt for Tesla's thing, which you can tell to hold speed and lane and set it off. What people get wrong is they figure that pilots are sipping mimosas or something for most of the flight since the autopilot is doing everything - actually you assume the autopilot's going to try to kill you and are constantly monitoring its performance, ready to take over at any second, and you get extensive training in this. The autopilot just frees up some mental space to do all the *other* work you need to do to fly the plane - briefing departure and approach procedures, communicating with ATC, watching out for other airplanes, evaluating performance, monitoring weather, etc etc.

Despite specific training in the use of the autopilot for workload management, but also to keep a close eye on it, there's *still* a problem with pilots losing their flying skills due to (some argue) overuse, and being unable to assess a problem and hand-fly the airplane correctly after an A/P disconnect. Sound familiar? If professionals with extensive, specific training and procedures can't get this automation stuff right, what hope does the average driver have?

Using unsigned for an extra bit is dumb. Unsigned values should only be used for data, not numbers, or if that extra bit is really really important and you can prove it If you want to prove an invariant that the thing is always non-negative, that's what asserts are for. If you think your data type might ever have more than a million of something, automatically reach for 64-bit values. Don't play games about the difference between 2 and 4 billion.

Using signed values for non-negative numbers have the nice property that overflows are immediately recognizable and generally cause crashes or "entry not found" rather than corruption. For loop counters they prevent infinite loops. And memory (even on phones) is too cheap to worry about the extra 32 bits. Besides how sure are you that you're not wasting those 32 bits anyway inside the allocator's fixed-size buckets or packing issues with your struct? Those yield bigger gains than using a smaller data type.

I lol'd.

Ah got it - I misinterpreted your comment.

The whole plan is pretty unfortunate, but if a non-profit became the regulator that would be extremely alarming. I haven't read the plan but AFAIK most of these proposals - and implementations in other countries - leave the government proper with the regulatory aspects and turn over only the ATC system itself to the private organization.

The FAA does about the best job in the world at air traffic control. IAAPilot (private, of small planes for fun and personal travel) and I'm sympathetic to basically being a special interest group. However the US has the strongest general aviation (GA) sector of any country in the world, and part of that is due to the government treating everyone equally. The reason the big airlines like privatization is because it would let them effectively design routes and airspace that save them money, at the expense of smaller operators - anything from crop-dusters to news helicopters to medivac flights to guys like me.

There's a safety aspect as well, though it's a bit technical. Countries with privatized ATC pay for it with "user fees" - which to be clear the US already has, and it's a fuel tax, but other countries send you a bill for any services you use. Services are things like talking to an airport control tower or regional area controller, instrument flight clearances or instrument approaches, etc. Our (GA's) interaction with the ATC system is a small fraction of their workload, but it pays disproportionate mutual benefits because airlines are pretty much all flying the same routes but we all have to get along.

Let me explain: most GA flying doesn't require talking to anybody at all, even most flights near busy urban centers, but it's very beneficial to do so. There's a service called "flight following" where you don't need a flight plan but you show up no the controller's screen and they know how to reach you if they'd like you to turn, climb, or descend to avoid another airplane - especially a passenger jet on a fixed routing, which would otherwise have to be turned to avoid you. In exchange they help you find other airplanes, so you can keep away from them visually (as is your responsibility in visual conditions), and if you have an emergency they already know exactly where you are. It's super useful and dramatically improves safety and efficiency for everyone. But it's not remotely required, so if it costs money most pilots would simply ignore it - and now they have to turn jets out of the way of some guy bumbling around (as is his right) in a Cessna on a nice day.

Furthermore the US is about the only country where non-career pilots can practically fly by reference to instruments (in the clouds). Having an instrument rating and an instrument-certified small airplane lets you fly in worse weather, but the biggest benefit is that it makes your flights in marginal weather much, much safer. Dangerous "scud-running" with low-to-the-ground clouds and low visibility might be possible, and legal to do visually, but it's far safer to do the flight on instruments instead. A buddy was doing some flying in Finland with an instructor, and the weather started to get worse, so he suggested simply getting an instrument clearance and doing an instrument approach to land - but it would have cost about 200 euros so the instructor wouldn't do it unless he paid.

tl;dr ATC services should not be pay-per-usage as it degrades safety for everyone. Existing mechanisms like fuel taxes are sufficient to cover the cost and encourage all pilots to eagerly use the services, which keeps everyone safer.

Sorry, what's wrong with the regulator operating the infrastructure? The regulators *and* the infrastructure serve the public interest here. The FAA has plenty of faults, but they're not generally of the power-hungry variety.

One of the things the FAA is doing is coordinating the development of unleaded 100-octane avgas. There's been a number of promising developments and some are already on the market. Once the FAA finishes its tests and (as expected) is able to give blanket approval to use the new fuels in every plane where 100LL is currently certified, everyone'll switch over pretty quickly.

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

Are you OK with getting Al Capone for tax evasion?

That's not remotely the case. There are many circumstances in which someone can be compelled to testify - in fact, the only time you *can't* be compelled to testify is if it's against yourself. The lawsuit is against Uber. Uber can be compelled to produce documents, and so can the people around them if a court can be convinced. Levandowski isn't Uber. And even if it is against yourself, you can absolutely be compelled to hand over documents and other evidence, even if it proves your guilt.

Even in a criminal trial, you can be compelled to testify against yourself - you just have to be granted immunity by the grand jury in exchange. This is common in e.g. drug trials, they'll arrest the user and charge him with a felony, then offer him immunity in exchange for (compelled) testimony against the dealer. You have to be careful though, because if you compel testimony about a murder and the guy says "yes I know who killed him, it was me" - you're SOL.

It's a common argument, but why does x86 continue to dominate, in performance and performance-per-dollar and performance-per-watt? (If not absolute-low-watts.)

Is it just because they have the best fabs or designers or the most experience? Those are probably true, but you seem like you know what you're talking about so I'd like to float a different theory:

- x86 has a pretty expressive instruction set which improves code density enough that more code can fit in cache than RISC-y architectures
- Modern processors are so fast and have so many cores that the RAM is often the bottleneck, especially with NUMA. Managing the cache is more and more important, so code density pays increasing dividends
- The standard argument is that the compiler can make better optimization decisions, but is that really true? Intel's engineers are really really good and the optimization they're able to do in generating the microinstructions (and potentially different microinstructions for identical instructions!) that's informed by their intimate knowledge of that specific die are just too powerful to beat the compilers, which don't know the chip as well as the designer.

It's a bit like the native code vs JIT VM debate - the VM folks argue that the VM knows more about the program since it's at a higher level and can make smarter choices. I wonder if CISC is analogous to VM bytecode here.

I should also note the irony of essentially saying "the compiler makers will figure out how to make the dumb chip fast" on an article about Itanium - that's a large part of why it failed, even Intel couldn't figure out how to make a compiler good enough to really make use of the chip. Of course Itanium wasn't RISC, but still.

Likewise; I first booted it in a VM probably 10+ years ago. It's a nifty idea but it's far, far behind Wine. It's probably great if you're the sort of person who gets excited about the NT kernel and know about subsystems other than Win32 (though I don't actually know how NT-style the kernel of ReactOS is).

It turns out making a Windows compatibility layer as well as the kernel, sound, print, network, graphics, etc stacks is kind of a lot of work and there's a good reason for taking an existing fully-featured OS and adding just the compatibility layer. If you like Windows, you might be better off working on a Windows-style desktop environment for Linux.

Good thing his show runs at 23:30 then.

Code review isn't supposed to be about rejecting code, it's supposed to be about improving code and providing another set of eyes with a different perspective. In several years doing code reviews for men and women, and having my code reviewed by men and women (for >1000 overall), I can count on maybe two hands the number of changes that I'd count as rejected - either because the change was unneeded and I was misunderstanding, or because it was needed but I wasn't the person to do it because I wasn't experienced enough with the code I was changing. Many changes go through substantial rework, though as you gain experience you can write better code that needs fewer fixes - so if on average females are more junior (which is true across a wide range of industries and largely responsible for the gender pay gap) then they will on average face greater rework - though on an individual basis they will face less and less as they become more experienced just like everyone else.

But thinking of - or practicing - code review as adversarial or something where changes can be "rejected" (other than for mundane reasons like trying to change another team's code in ways that don't fit their model of how their code works) is an antipattern. The most senior people, people who literally have invented entire disciplines, still have their code reviewed and change it in response to feedback. My tech lead likes to say that "confusion is a signal" - if your code is so brilliant or clever that it leaves a brand new engineer going "wha?" then it means you have to fix it, regardless of how senior you are, since the code should be understandable by the average employee. And when I review code I don't expect to pass down edicts, and probably 10-15% of my comments receive pushback from the author. It has to be a real problem for me to actually refuse to accept a change - maybe that's happened twice for reasons of code quality and not the mundane stuff I mentioned earlier like "I planned to rewrite how that test worked anyway, let's hold off on this hacky fix since I'll fix it properly". I prefer to chat informally with the author (and, and as an author, vice-versa) to come to something mutually agreeable, which lets me understand their concerns and vice-versa - and we both learn something.

Er, I'm using RSS in Firefox right now (it's how I found this article). 52.0.2.