What's the minimum altitude requirement for flying a non-military aircraft over a residential area in the USA?

If we all went vegetarian and killed off the domesticated cattle, then we'd make a huge difference! Kill a cow today!

I found that above about 10Mb/s you start to hit diminishing returns. The jump from 10 to 30 was barely noticeable. The jump from 30 to 100 is noticeable with large downloads, but nothing else. From 100 to 1000, the main thing that you notice is if you accidentally download a large file to a spinning-rust disk and see how quickly your fill up your RAM with buffer cache...

Over the last 10 years, I've gone from buying the fastest connection my ISP offered to buying the slowest. The jump from 512Kb/s to 1Mb/s was really amazing (though not as good as moving to 512Kb/s from a modem that rarely managed even 33Kb/s), but each subsequent upgrade has been less exciting.

Well, maybe. Back then home computers were already a growth area and so it was obvious that one computer per household would eventually become the norm. If you wanted to put these all on IPv4, then it would be cramped. The growth in mobile devices and multi-computer households might have been a bit surprising to someone in 1981, but you'd have wanted to add some headroom.

With IPv6, you can have 4 billion networks for every IPv4 address. Doublings are much easier to think about in base 2: one bit per doubling. We've used all of the IPv4 addresses. Many of those are for NAT'd networks, so let's assume that they all are and that we're going to want one IPv6 subnet for each IPv4 address currently assigned during the transition. That's 32 bits gone. Assuming that we're using a /48 for every subnet, then that gives us 16 more doublings (160 years by your calculations). If we're using /64s, then that's 32 doublings (320 years). I hope that's within my lifetime, but I suspect that it won't be.

In practice, I suspect that the growth will be a bit different. Most of the current growth is multiple devices per household, which doesn't affect the number of subnets: that /64 will happily keep a house happy with a nice sparse network, even if every single physical object that you own gets a microcontroller and participates in IoT things using a globally routable address.

This isn't really a workable idea. Routing tables need to be fast, which means that the hardware needs to be simple. For IPv4, you basically have a fast RAM block with 2^24 entries and switch on the first three bytes to determine where to send the packet. With IPv6, subnets are intended to be arranged hierarchically, so you end up with a simpler decision. With variable-length fields, you'd need something complex to parse them and that would send you into the software slow path. This is a problem, because you'd then have a very simple DoS attack on backbone routers (just send them packets with large length headers that chew up CPU before they're dropped). You'd also have the same deployment headaches that IPv6 has: no one would buy routers that had fast paths for very large addresses now, just because in 100 years we might need them, so no one would test that path at a large scale: you'd avoid the DoS by just dropping all packets that used an address size other than 4 or 16. In 100 years (i.e. well over 50 backbone router upgrades), people might start caring and buy routers that could handle 16 or 32 byte address fields, but that upgrade path is already possible: the field that you're looking for is called the version field in the IP header.

It depends on the ISP. Some managed to get a lot more assigned to them than they're actually using, some were requesting the assignments as they needed them. If your ISP has a lot of spare ones, then they might start advertising non-NAT'd service as a selling point. If they've just been handing out all of the ones that they had, then you might find that they go down to one per customer unless you pay more.

The dock was there, but the shelf wasn't added until 4.1. 4.1 and 4.2 contained quite a number of UI changes.

Sites that are distributing malware are not exactly legitimate porn sites though - if it were technically feasible to shut them down then we already have sufficient legal justification for doing so from the Computer Misuse Act.

Except those of us who use a terminal, who find control-C and control-Z (and, on FreeBSD, control-T) indispensable.

The problem with shell scripts for this kind of thing is that they're a Turing-complete language. This makes it very hard to present to the user what they actually do. .BAT files on DOS / Windows provided that functionality too, but unless you aggressively restrict yourself to a subset of the shell language it's very hard to check a .sh / .bat file and see exactly what command is going to be invoked.

This requires the program to be explicitly written that way. Gcc and clang also do this, to detect whether they're invoked as C or C++ compilers, and clang will detect a target triple if it's the compiler invocation name prefix. This just goes in argv[0] though - you can't modify the other arguments from a shortcut. It would be really useful to be able to add things like --sysroot=/some/path and -msoft-float to a symlink so that you had a single cc that you could invoke as a cross compiler, but currently the only way to do this is with a tiny shell script that execs the compiler with the correct flags.

Except that the $300 cable isn't grounded on either end, and shows a high level of crosstalk. So the arrows on this cable are just to make people think it's worth the $300.

This cable is better than a $2 cable: It's well built, and meets the specs - barely. But you can get $10-$20 cables that are as well built, and meet the specs with less margin for error (these literally tested as 'within the specs' by less than the margin of error on the testing device) easily.

Has anyone ever clicked on a random link and been taken to a commercial porn site? To shock sites and stuff hosted in random places, sure, but these are not the ones being threatened with shutdown.

Nonsense. It is true, however, that Windows and Linux use different (overlapping) subsets of the SATA (and SCSI) command sets and, in particular, use very different sequences of commands in common use. If you test heavily with Windows and not with Linux, then you may find that there are code paths in your firmware that Linux uses a lot but which are mostly untested.

The 'tray' that Raymond describes in his second article looks very much like the Shelf from OPENSTEP 4.1, which was released just after Windows 95. I wonder if some of the NeXT people were playing with early betas of Windows 95 and, as their company CEO later quipped, started their photocopiers...

Win32s was released for Windows 3.1, but it just added some win32 APIs, not the UI. The UI was first introduced in the Chicago betas, which were eventually released as Windows 95. NT4 was released shortly afterwards and wasn't a bad OS, but hampered by the lack of plug-and-play support and perpetually having old versions of DirectX.