Back in the late 80s, when I was working on that decade's failed project to replace the 360/90-based systems, my coworker and I were in DC for a meeting on some phase of the project (or one of the related projects), and we had half a day spare, so we went to the Smithsonian Air&Space Museum to do "research". They didn't have examples of the system we were working on, but they did have some other air traffic control systems (Tracon, I think), and other cool stuff like astronaut ice cream. After that we went to the National Gallery, because Van Gogh.
That's not even counting the huge amount of code that's designed to make sure all the other parts of the code are working, and to do something appropriate if they're not, and the code that's designed to make sure that code is also working. That stuff's a lot harder than the basic code, and getting it right is the difference between a system with double- or triple-redundant hardware that gets you the 8 9s of reliability the FAA naively thought was possible with 1980s hardware and a air-traffic control system that had triple-redundant hardware running an operating system that crashed weekly (that one was in Singapore, but I don't know if it was actually deployed; I assume they killed it long before it hit the field.)
The 1980s attempt at developing this was only going to be deployed at the ~25 En-Route control centers (with simpler components at the several hundred radar sites feeding each one); it's not intended to be at every airport tower, which was a bunch of different systems.
It's interesting to see how much this thing has grown into, beyond the initial "get radar signals onto the board and replace paper flight-strips and never ever ever crash" goals.
Most of it on the part of the people who started the original project, who thought it would be done in 3-4 years, made way too many incorrect decisions for the wrong reasons, specified lots of requirements without understanding how impossible they were to meet, picked multiple sets of pie from multiple sets of skies, and didn't start with the ability to get kinds of budget they would have needed to do the job right (if they'd picked a definition of "right" that could have been implemented in the 1980s, when they were trying to replace a 1960s system that had much lower ambitions when it was built, but was still a big upgrade over the 1950s predecessor), but the one thing everybody knew was that if airplanes fall out of the sky or crash into each other, the FAA gets blamed, and if the system's late, the FAA gets blamed, and if it's over budget, the FAA gets blamed, and if the budget had been bigger to start with, the FAA would have been blamed, and if the FAA's going to get blamed, then you can be the contractors trying to design the system are going to get blamed a lot, even just for asking questions when they're working on the thing.
Projects with a scope of tens of millions of dollars are much much different than projects with a scope of a few billions or a few tens of billions. A couple of years after I worked on my part of that fiasco, one of the directors for information systems for one of the National Labs was telling us that he was trying to restructure things to be done in small manageable projects, because he'd never seen the government do a billion-dollar computer project that didn't fail. And all that ancient "Mythical Man-Month" stuff said things you probably already knew about projects in the $10m range sometimes being too large; I remember one much less critical project that had 30 people working on it, so it had to grow to 150 people before it totally failed; if it had started with 5 people instead of 30 and had a budget limiting it to a max of 10, it might have worked. But projects that know they're legitimately in the billion-dollar scale are really really hard.
It's designed for object-oriented use, with lots of type specification and such upfront, to push decisions into upfront design time rather than coding time, and it's not as terse as C or APL, but it's nowhere near as verbose as COBOL. I wouldn't use it today (mostly because its main uses are for military stuff I won't do, and for antique maintenance, and it doesn't have all the friendly libraries that I'm used to and probably doesn't easily link to non-Ada systems), but it's a fairly cromulent language.
You did get the bit about how this system was decades behind schedule and tens or hundreds of billions over budget, with a couple of major iterations thrown away in the process? 2MLOC sounds nice, clean, compact, and surprisingly low.
The article you're pointing to was about how one of the ERAM systems crashed trying to cope with a bizarre flight plan for a U-2 spy plane.
When I was working on AAS in the late 80s, one thing I was mildly concerned about was that the planned "upgrade" our project was trying to design wouldn't really be able to cope with super-sonic aircraft over the continental US. The requirements for how much area had to show on a controller's screen and how fast the radar sweeps were meant that anything at Concorde speeds would kind of blip onto the screen, maybe bounce once or twice more, and then be gone by the next refresh, either to somebody else's screen or another regional center. Economics and politics (sonic booms, restrictions on what nations' airlines could compete for US markets, etc.) meant that it wasn't a likely prospect anyway, but U-2 spy planes operate under different economics and politics.
Back in the 1980s, the FAA's shiny new Advanced Automation System project (AAS) was being designed to replace the 1960s-vintage En-Route system, which used IBM 360/90 and 360/50 computers that were getting to be old, unmaintainable, and unreplaceable. (It was getting hard to even get cable connectors for components - imagine coming up with new SCSI-1 terminators these days.)
As with many military aircraft system contracts, they ran a design competition, which had funneled down from 4 bidders to two by the time I was there. I worked for a subcontractor on one of the teams bidding on AAS. We were the lucky ones who lost; IBM were the poor suckers who won the deal. We learned many lessons about how not to do large software projects. The requirements weren't very well-defined, but the one thing that was certain was that if yet another airplane crash happened, the FAA would take lots of political heat, so everything had to be totally bullet-proof, and every bureaucratic ass had to be covered in triplicate. The phase we were working on was already behind schedule and over budget, and once IBM won it got much farther behind, way farther over budget, and it kind of slunk into the 90s, the 2000s, and the articles referenced above make it sound like Lockheed-Martin bought the IBM Federal division that was working on this debacle.
Originally, the requirements were for 8 9s of reliability (so 99.999999%), but what was worse was that there was no definition of what a failure event was. If a failure meant "each individual radar needed to meet 8 9s", that was hard enough, but if a failure meant "ANY radar's connection was down", that meant the system had to meet 10 9s, not just 8, since there were O(100) radars. Everything had to be triple-redundant to meet those numbers, because taking down any component of a dual-redundant system for maintenance for 5 minutes would blow your reliability for the year. We later found out that the existing 1960s-vintage system that AAS was supposed to replace was shut down for 4 hours per night, replaced by EDARC (a ~1970s upgrade to the ~1950s DARC radar controllers), to make sure that the EDARC system was available as a working backup and that personnel stayed trained in using and maintaining it. (And of course the radars only had dual access lines, with a typical reliability of 3-4 9s each, so 8 9s per radar was already overkill. Phone company equipment with the famous 5 9s of uptime got that by using lots of dual redundancy in appropriate places.)
AAS was originally required to use DOD-STD-2167 software development methodology, a 1985 standard that the DOD replaced in 1988 with 2167A because 2167 was unusable. (You're having trouble dealing with Agile? This is way way far out the other direction.) Both were cumbersome waterfall processes, 2167 requiring something like 180 documents over the predicted 3-year development period, so every week, there'd be one or more new documents, hundreds of pages long, that were all ironclad requirements for all remaining development; developers wouldn't have the time to read and analyze each document and still get their work done, and if they determined down the road that a previous decision had undesirable consequences, there was no way to go back and change it. For example, a decision about whether a given calculation should be done out at the remote radar site, or on one of several central processing computers, or on the computer that drove a given operator console, might turn out to make several hundred milliseconds difference in processing time, but any given radar signal had to get from the remote radar to the console in under 1 second. The subcontractor designing the display consoles knew they wouldn't have the horsepower to do it in time, so they bounced it to the central processors early in the requirement process; those didn't even have an architecture that met the redundancy specs yet, so we didn't know if they'd have the resources to do it in time either. (We later offered to move a bit more of their processing into the central system, because we could do the combined calculations faster than having to split them.)
(And no, we didn't have to walk uphill both ways through the snow to work on it, but I did have to fly to Chicago for a weekend kickoff meeting in the winter, there was snow there and I had a bad cold, and stuff that looked really good and feasible on a sales VP's slide-show presentation didn't actually look so good when you tried to map it to reality. And we had to fly out to California weekly for months, back when you could listen to the Air Traffic channel on the plane's sound system and get an idea of what you were working on, which we decided was intended to make us take this stuff seriously. One reason we'd gotten picked, besides having lots of other Air Traffic Control and system integration experience, was because we had a floating-point chip that calculated trig functions really fast. It turned out that all the "floating-point" data was coming from 12-bit ADCs, and it's much faster to use a lookup table than wedge in a floating-point chip
I was eight years old when Neil Armstrong stepped off the LEM onto the Moon. It was an overcast day but the thing I remember vividly was how quiet the city was; aside from a few trucks in the distance and the wind blowing between the buildings there was simply nothing to be heard. The street was utterly deserted, more deserted than it would have been in the middle of the night. I'd gone out to find someone to play with, but gave it up for a bad job. I came in just in time to watch Armstrong step off the LEM. Cronkite couldn't make out what Armstrong said -- later it turned out Armstrong had bungled his line.
The only thing since then that has come close for shared amazement was 9/11.
The thing is there will never be another moment like that, not for manned space exploration. For those of us too young to remember WW2, the Apollo program was the biggest, most exciting thing that had happened in our lifetime. Older people had grown up with the Moon as the very symbol of something that was impossible to obtain. Every human being who'd ever lived and who wasn't blind had looked up in the sky and seen that big fat Moon hanging up there looking so close you could touch it.
Mars isn't like that. For most people it's just a name. More people have seen fake Mars in movies than have seen the real thing. So I'm guessing that few people will interrupt their lives to watch the first step on Mars. Maybe some of us will, but there won't be the same amazement, that sense of witnessing a once-in-a-species event.
Speaking of movies, one of the things that happened after 1970 is that production values on sci-fi movies went way, way up. Most people today have grown up watching representations of humans traveling to the stars; that's the new milestone for the human imagination. So I don't think there will ever be the kind of adulation for real astronauts that we had in the 60s. Actors are more photogenic than real astronauts and they don't spend their time doing tedious and inexplicable things.
But I don't think it's impossible to get people interested in space exploration; only that it's folly to put men up there and expect the public to automatically get excited. Henceforth space exploration is only going to matter to people who've been educated enough to find science interesting. That in itself is a worthwhile goal.
A week or so ago, my wife's Lenovo let some magic smoke out of the charger connection, and yesterday we heard back from the repair folks who are saying that the motherboard is shorted, not just the jack, so depending on how much they want to charge, it's probably new laptop time. What would be really nice would be an Apple magnetic power cord connector on the replacement, but of course patents mean that's not going to happen.
Meanwhile, what I really want for my work laptop is a description of exactly which ports are which; it's an HP ZBook of some sort, but doesn't seem to exactly match any of the diagrams only (G1, G2, etc.) One port is definitely USB3, and talks at high speeds to my external backup drive, and it's likely that one of the other two USB ports can do higher-current charging, but I can't tell which one, or how much higher (500mA instead of 100??) There's some kind of HDMI, and something I don't recognize that's probably a DisplayPort. And there's an SDHC slot, which has turned out to be really useful, because it can hold a 128GB card that lets me keep music, experimental virtual machines, and other space hogs online (the laptop has a 256GB SSD, while its predecessor had a 320GB spinning disk.) And yes, there's an Ethernet port, and a docking-station port, so I've got reliable high-speed alternatives to WiFi.
Half the thing I want to do with USB would probably work fine with MicroUSB (and maybe a USB-to-Go cable) if it were short on space. Mice and keyboards don't really need a lot of power. OTOH, I've started to like the fact that Lightning cables work either way up.
I've been a Democrat since 1979. I'd vote for Bernie Sanders if he weren't an abrasive, self-righteous prig who'd inevitably do more damage to his allies than to his enemies. But despite that I'm almost 100% in agreement with the man. And I haven't seen any rampant Republican agenda here. More like rampant laziness, if there were such a thing.
If the editors spent a whole minute between the moment they opened the story and the moment they hit "post" I'd be flabbergasted.
When hardline socialist parties gain power they tend to become more pragmatic. Such parties usually still consider themselves socialist and think of themselves as working toward eventual socialism.
The Socialist Party in France is a good illustration of this. Go back and look at the history of the Mitterrand presidency. In 1984 he abandoned nationalization of industry so that France would qualify for the European Monetary System. The subsequent collapse of the leftist coalition forced him to "cohabit" with Chirac's conservative RPR. Since then it'd be fair to characterize PS as a center-left party.
Technically a "socialist" is anyone who believes in "social ownership" of the means of production. A "communist" is someone who believes in the common ownership of the means of production. This may sound like a distinction without a difference, but "social ownership" is a broader concept than common ownership. Common ownership is just one form of "social ownership". Worker cooperatives are another form of social ownership.
Logically then, all communists are socialists, and not all socialists are communists. Some communists see non-communist socialism as a desirable intermediate step toward communism, others do not. Some communist and socialist ideologies fit within the umbrella of "social democracy", others do not.
Socialists and especially communists tend to be idea-fetishists, and so often display a peculiar mania for mutual ideological excommunication.
Most "democratic socialist" parties are socialist (like the DSP in the US), or have at some point in their history been socialist, or at least see socialism as a desirable long-term goal. But I'm sure there are exceptions. What you really have to do is ask what someone *believes*, not what they call themselves.
Sanders has never run away from the word "socialist", but what he seems to believe in is a strong welfare safety net, labor unions operating in a market economy which allows private profit but with regulatory restrictions on the ability of private entities to externalize costs like pollution. There are plenty of people who would call that "socialist", but most people who just plain call themselves "socialist" wouldn't. What he wants is for the US to be more like "Nordic model" country such as Sweden or Denmark. Maybe that's not your personal idea of political paradise, but it's a hell of a long way from North Korea.
As to why Sanders would call himself a socialist, it may be that's what he calls "socialism", but I think it's because he's a contrarian and gadfly who likes to rile people up but excels at retail politics in a tiny, tiny state. I'm all for his preferred policies, but personally I think he'd be terrible president because he's a self-righteous political prig who'd alienate and undermine any of his allies that didn't toe the line.
Except that the latest UAH and RSS data sets (still in beta, so unofficial) show no warming for the last 18 years - something your link even acknowledges. (In 2009 he mentions "I have to say I find this all very puzzling.")