The original Linux shared library system was the toxic waste dump, being basically impossible to use if you weren't a distribution maker (every shared library had to have its own unique address in memory because code was just mmap()ed in without relocation). What we've got now is better, with just the problems of ensuring that versioning across effectively-independent software products works (and that's just plain hard for everyone).

Memory and disk have only recently become effectively too cheap for anyone (excluding embedded) to worry about the size of code; that's a new phenomenon.

At that time there was 386BSD but they were tearing themselves apart for some reason which I never bothered to get to the bottom of (I think the corpse of that became FreeBSD, but I could be wrong). Linux was not as polished at all, but did a few things reasonably. In particular, it had shared libraries, greatly reducing the memory requirements at a time when memory was expensive, and it had built in floating-point coprocessor emulation. (This was back when programming on DOS/Windows still meant using a segmented memory model or futzing around with a DOSExtender. Linux's flat model — heck, all Unixes' flat model — was much nicer, with far fewer contortions in the code to deal with squeezing things into 64kB blocks.)

Good memories...

Those are only mid-tier carriers really. The major carriers are the people who build national fibre backbones, trans-oceanic links, etc. The end-customer doesn't normally see them (unless they use traceroute) but they're there and they're important.

You need to think more in terms of how to monetize! Media rights. Merchandise. Special access opportunities for other super-fans. Franchise-themed credit card. If being a super-fan is the only thing you can think of, you're wasting that asset...

I think that's going to be close to 100% of all users...

Really? I think I'll define "give dkf lots of money for doing nothing much, so he can spend it on beer and pizza and the other good things in life" as a cause and see how effective that is! Contact me for detailed instructions on how to remit payments.

(I know, it probably won't bring in much, but it also takes so little effort I might as well try.)

But then most of the employees and contractors of the NSA won't be able to attend!!!

That's not a bug in your plan, of course...

And lots of good companies also don't last. Their products might be good, but their upstream suppliers too often stiff them and their downstream customers fail to pay promptly, causing a critical cashflow problem and making them go bankrupt despite being theoretically just fine. "Theoretically just fine" doesn't count for much in reality.

The flip side is with large companies that do a few things well enough to generate a large stream of money, but which are otherwise massively inefficient. The parts which generate a lot of money support the rest (and at least some of that rest is actually necessary for making the profitable parts work, so simply divesting everything that doesn't turn an instant profit is a surefire way to kill the company). Plus there's no guarantee that a company will be run solely to maximise the amount of profit produced each quarter; that's formally a matter for the board and the shareholders, and nobody else.

Large companies tolerate quite a bit of inefficiency, but are capable of doing things that small companies cannot do because of a key fact: they can borrow much more cheaply and in much larger amounts. That's the part that really runs counter to your preferred story about nimble small firms beating lumbering large ones; the reality is that small firms are much riskier investments than large ones, so most people are much more reluctant to lend them anything.

No, it isn't. A bunch of incompetently integrated systems that require lots of effort to put into a state suitable for students and to keep in that state? Speaking as someone who has actually written a course on cloud computing, no thanks. The students can get free time on one of the big providers instead and learn everything they need, and those providers actually try really hard to make things work. (The free allocations tend to be fairly small, but they're enough for learning basic principles.)

I've also seen what tends to happen when someone tries to operate a cloud without sufficient spend on QoS or integration: paying for AWS or Azure is an easy decision by comparison. (Losing access for a week because someone pushed a wrong configuration to a router and then went on holiday? Of course nobody else on the cloud operations side could fix it either. Aaargh...)

Well duh! How do you think normal domestic and lab thermometers work? They've got a liquid in them that expands as temperature rises, and that's been calibrated. Yes, they usually use alcohol or mercury (depending on the intended temperature range) but water's not really that much different. (Except between 0C and about 4C, when it is weird!)

OK, so there's other ways that are used too, but liquid-based temperature measurements are still very common.

How would a court even begin to believe that sort of thing might be conscionable?

As long as all the chairs are underneath the eroding tank of toxic radioactive sludge, we'll be OK anyway. Or we'll have a legion of mutant superpowered bureaucrats poised to take over the world...

Hmm, maybe I need to think about this a bit more.

Their leaders also hate that most of the people taking the decisions on these things didn't go to the same school and aren't members of the same clubs, so that it's rather more difficult for them to influence what happens by a quiet word outside of view of any public scrutiny. (Unfortunately the British press are singularly useless at actually correctly reporting what happens at European level, but the decision-making there a heck of a lot more open to actual scrutiny than at national level...)

The problem with that approach is that you end up with devs being told to produce iPhone apps using just Microsoft Word "because that's what the company provides for all their employees; no program may be present that has not been vetted by central operations". It's going from one extreme to the other...

Most of those are actually due to constraint violations. Too many people in this industry think that they can implement half an interface and ignore the difficult bits. I've even had someone seriously tell me that doing the whole semantics would break things. That facepalm hurt my nose.

There are worse. Security problems with multiple components all in different security contexts on different hosts... that's hard (no debuggers, no unified logging, lovely...) However, in general there are always deeper problems possible; the ultimate problems tend to relate helping the customer understand what the program can and should do in the first place.