Not libc. The C++ runtime? Sure. Libssl, libz, or other libraries that didn't always care about ABI compatibility. Yep. They make universal binaries a pain. But libc only becomes an issue if you try to swap in certain versions that target embedded platforms.

You said Libc is the problem for portability. What are you seeing? The last glibc hiccup I recall was the 2.1 ABI break. (Fixed in 2.2 meaning another break but 2.0 code worked with 2.2.)

Now having to build using an old distro does suck. With windows, can I build with the latest and greatest tool chain and still expect it to run on something with a 5 year old runtime? (Without first installing that new runtime on the old system? I can do that on Linux too. It's just harder.)

A SQL DB? Yes. Some web scale keystore, maybe storing json or yaml "documents". I won't bet money on there being a "schema" or "types".

This is agile at web scale. It mostly works. The failure cases aren't life-or-death. It's "good enough" from the service provider's view point.

You "Whatabout"ed the TinkerPop case with your Google counter-example and a fictional case to try and case the TinkerPop example into more of a business setting. The followup demonstrated your example in fact played out in real life, but in a demonstrably one-sided, double-standard-ish way.

All of which is to illustrate that in real life, your Google & what-if examples are different in that they are much rarer and it involved an employee's actions that were at least in part directly work related (versus punishing a volunteer by kicking him out of his project for non-work related matters).

I would agree that GPL more than anything killed proprietary UNIX. In the 90s, the university I worked at had a large, heterogeneous UNIX environment. We had systemV-ish system, BSD-ish systems, systems with a SysV kernel & BSD userland, BSD kernel & SysV userland, we had odd ones out like OSF-1, NeXt, Irix, etc.

They were all UNIX, but all subtle incompatible in the littlest ways.
- Command line options on text tools like head & tail
- options and output on process listing with ps
- print queue management
- automount behavior
... and more.

They were all basically functionally equivalent, but incompatible. We managed to hide this from the users by building the GNU tools on every platform and present a consistent experience for the users. The GNU tools tried to be as compatible with any other standard that existed and often times tended to be the best-of-breed implementation due to compatibility and standards that discourage arbitrary limits like static buffer sizes. If some other version added a feature that was useful, the new feature would inevitably find it's way into the GNU version was well. UNIX was more flexible than any user needed and the GNU tools were more flexible than the regular UNIX tools.

Eventually the GNU tools became the standard that everyone had to comply with. UNIXes started bundling GNU tools instead of trying to make their stuff compatible. Proprietary compilers would try to implement the more common CLI options of the GNU compiler since all the common source packages targeted GCC, which then targeted every other UNIX & processor imaginable. Eventually, with Linux, there was no need to buy into a proprietary system (or UNIX) to get the best-of-breed UNIX experience.

Of course I now lament that the Open Source community no longer remembers the value of portability, compatibility or flexibility and I expect the heavy use of BSD-like licenses will help Open Core businesses to bring back the pains of "functionally equivalent, but incompatible".

Honest question. Which possessive pronoun (not noun) gets an apostrophe s?

Mine, yours, ours, theirs, his, hers, its? ... vs Bob's.

I'll admit it always felt like a stupid rule with its, but now that I think about it, there is a pattern.

As has been mention in another thread, there isn't a formal spec for rust. That makes writing and maintaining a third party implementation difficult.

But yes, rust becomes significantly more portable if someone makes a gcc front end for it. But for that to happen, rust needs a "spec" beyond the implementation.

Two questions. What is that cost? How will the tax actually but put to use?

This is true. It's meant to be another 'sin' tax, like the higher taxes on alcohol, smoking, fuel (in some places).

Likewise tax+subsidy has been used, for instance, when the there are higher taxes for highway, but part of that tax is "returned" to states as a subsidy (to cover highways for instance) for states that passes laws that the federal government does not have the authority to impose directly (like seat belt laws or drinking ages).

These are tools for social engineering in the US government.

Which ever you prefer.

True, but those are stupid rules. During the height of the (admittedly politicized) panic we had people saying you should never leave the house without a mask. Seeing city sidewalks where people are packed like cattle, I get it. That's necessary there. But in my town I could walk out on my front porch and not see another person in any directory most times of the day. I could walk to the store not come with in 100 meters another person on the sidewalk until I'm in front of the store. Wearing a mask wouldn't protect anyone until I'm about to enter the store.

I hate it when the population centers seem to think it makes sense to legislate one-size-fits-all mandates. It would be no different than if my state tried to force a law requiring that every one where mittens from December to February since frost bite is a problem here. Parts of the country that never see snow would consider it stupid. And they would be right.