Also for sterilizing stuff. Cheap autoclave.

Of course it's all pre-sterilized disposables these days. Can you even buy glass Petri dishes ^H^H^H^H^H^H^H^H^H^H^H^H baby bottles any more?

I kept wondering what geologic processes could produce such an even change in elevation.

It (along with eastern Colorado and much of the other great plains states/provinces) is an old sea bed, the floor of the central inland waterway in the mid/late Cretaceous. Flat from millions of years of sediments, tilted slightly from being pushed up as the continent drifts westward. (Dramatically so at the Rockies). The foothills of the Colorado Rockies do not "end just short of the border" at least not anywhere near I-70; it's pretty much flat east of Limon.

Florida probably is flatter, but the trees hide it. Kansas is mostly grassland (well, where it's not farms), so you have longer sight lines.

Telenet was a dial-up access packet-switched network (think X.25) back before internet access was a common thing, similar to rival company Tymnet. I spent many, many hours on Telenet back in the day, logged into BIX.

You probably meant telnet, the *nix app which has been around even longer. When internet access became publicly available, I'd telnet into BIX (while it lasted, sigh).

I guess it's time we forbid anyone under 25 to drive a car,

Car rental companies do exactly that.

Just because you were lucky enough to have hyperdeveloped frontal lobes at age 10 doesn't mean that most, or even on average, people do. Apparently you haven't quite reached the stage of not overgeneralizing from personal anecdote.

Heck, if IFR (I Follow Roads) is good enough for me, it should be good enough for anyone, right?

(One thing that struck me about several of the old Soviet Aeroflot planes I saw -- and flew on -- in Russia was the bomber-like downward looking windows in the cockpit. I don't know if that reflected the aircraft's original bomber roots or the fact that sometimes they did follow roads. My flight to Krasnoyarsk was diverted because of fog, for example. What, no autoland?)

Over and above all that, there are plenty of other components which relate to Air Traffic Control system, such as various navaids (VORs and such, although they're slowly losing favor to GPS), ATIS and D-ATIS info updates, ACARS messaging, METAR info, etc. Again, these may not be under the control of the current new system, but they should certainly be considered in any design for the future.

First, it has to get the data -- which covers everything from radar skin-paints if the aircraft transponder isn't operating, to unpacking the data that that transponder is sending (which could include anything from a simple 4-digit number to altitude, airspeed, heading, etc, etc.). Oh, and it has to raise appropriate alerts if that 4-digit number happens to be one of several special codes (indicating anything from voice-radio outage to a hijacking). There are plenty of other sources these days of location data too, (aircraft position/speed info relayed via satellite, for example) I don't know how many are integrated into this new system.

It has to present subsets of that data to particular controllers' displays, not every controller sees everything, even in a given range. That would be crazy-making. And controllers have to be able to hand off flights from one to another, so there's the whole UI, authentication, confirmation, etc, etc, there.

Naturally everything has to be recorded and logged, and queryable.

It has to project flight paths, and then analyze all that for possible intersections and raise appropriate warnings.

It also needs to be aware of airspace limitations -- which are frequently updated -- so that information can be displayed to controllers too. So there's another UI, to input those changes, along with the authorization, authentication, etc for that. Ditto with severe weather -- so it needs input from weather radars, etc.

It has to be able to cope with sudden changes to the system, like if an airport or ATC center suddenly drops out for some reason. (Weather, power failure, earthquake, terrorist, whatever.)

The distributed nodes in the system (airports and flight control centers) have to be able to communicate with each other with minimal latency and despite node failures, cable cuts, microwave tower outages, etc, etc.

The finished system has to be deployed across hundreds (thousands?) of flight centers and airports big and small (basically, almost anyplace with a tower) across the country in a way that it all works with the in-place systems everywhere else. There has to be room in those airports and flight control centers (most flight control centers are not in airports, BTW, there's no need for them to be. The controllers aren't looking out the windows. Airport ground control (the guys controlling aircraft taxiing) and approach/departure control is.)

No, this is not just a souped-up iPhone track-your-flight app. It's something responsible for the lives of millions of air travellers (not to mention air cargo flights) a year.

This is actually a little-known third experiment that's part of the launches. They're perfecting the material to make Elon Musk's super-villain lair out of.

All the engines on the Falcon 9 (and just about every other multiengine* rocket stage) are fed from the same propellant and oxidizer tanks. Giving them separate tankage just adds weight and plumbing complexity.

In the Falcon Heavy, there is a cross-feed mechanism from the outrigger 9s to the core so that the core can keep burning when the outriggers jettison (saving weight).

*(except multiengine solids, where the engine is the fuel tank.)

DC-X also did it, several times -- but then DC-X wasn't trying to make even a fraction of orbit, it was proving the vertical takeoff and landing principle. Its engines (modified Pratt & Whitney RL-10s) could be more deeply throttled than the Falcon's Merlin, and it (the DC-X) was built fairly heavy to start with, since was designed as a test vehicle rather than a launcher (fully-fueled the legs couldn't hold its weight, it needed a support structure for takeoff -- and in an abort (happened once) it had to hover until it had burned off enough fuel to land).

Since then a number of small-company-built test vehicles have done the same, although not (afaik) to the tens of thousands of feet altitudes that the latter DC-X flights made.

One would think that if they didn't know that the shuttle's boosters are made of inch-or-more-thick steel, while the Falcon's tanks are millimeter thick aluminum-lithium. And that the booster splashdown still tended to leave the boosters slightly out of round (which contributed to the problem Challenger had).

The extra fuel almost certainly weighs less than the necessary parachutes would.

Kind of a dumb question on the face of it. If they're your peers, then you're all about equal. Call it a five-point-five with a very tiny variation, unless they're talking about peers with respect to something else.

"Bad smell" is a (silly, I'd agree) term of art. You know it when you look at code, wrinkle up your nose and go "eww".

I just call it ugly code.

Hence the title of Wirth's book, Algorithms + Data Structures = Programs. I think it was my second semester CS text (nigh on nearly forty years ago).

"Memory architecture" -- you mean data structures?

As the title of my old intro CS text put it, "Algorithms + Data Structures = Programs". Yep, one is clearly going to influence the other, and sometimes a minor tweak in one will vastly simplify (or complicate, if you do it wrong) the other.

Refactoring isn't merely reformatting -- a prettyprinter can do that -- but it can help give you insight into the code. After getting the code right I like to refactor to see how much code or useless variables I can get rid of, but that's partly a hangover from my old APL one-liner days. (grin)