Correct. Backwards compatibility is both its biggest asset and its bigger problem.
In syntax alone, you can check what Herb Sutter is doing with cppfront. Specifically, the wiki page on the postfix operators is quite enlightening. It shows some interesting examples of how by making everything a postfix operator you drop the need of -> and the duality of pre/post increment and decrement operators.
Meanwhile, this was a feature on KDE-land since Klipper, which goes back (as far as I know and if I remember well) to KDE 3 or sooner.
I've been compiling apps depending on newer Qt and/or kdelibs versions for ages (back when the repository was literally called "kdelibs", about 20 years ago).
This has never been an issue for me. Even with autoconf/automake, I just compiled everything to its own prefix, so it doesn't interfere with the system at all. You don't even need to fix the build system in the cases where it's broken/lacks features, if you leverage all the "path" variables (CPATH, LIBRARY_PATH, LD_LIBRARY_PATH, PKG_CONFIG_PATH, etc.). But autotools, cmake, qmake, and every build system I've used so far supports this out of the box.
Not claiming it's a skill issue, but I have to say I'm very surprised by reading any of this.
Specifically, for Debian, I was told 20 years ago by a very wise person "you never do make install on Debian, specially not for the kernel", and taught me how to use make-kpkg (or something like that, I don't remember the name of the tool), which was a way to make a debian package of a self built kernel, which is obviously something that can't be installed to its own prefix.
Related: There is an article on LWN called Lua and Python, which is mostly about the approach of the two languages WRT being "batteries included" or not.
I think Lua being a bit barebones is 100% fine... if you just pair it with a good helper library, or set of libraries with a coherent API, that allows it to thrive. Then you can either use the framework library or not, depending on whether your project requires the extras, or can do without.
As a parallel, I've been doing C++ development for almost two decades, and I cannot imagine doing anything non-trivial without Qt. For example, Qt has a debug framework that pretty prints automatically most containers, and adds the newline also automatically. Also, QString is an actual string type, whereas std::string is more like QByteArray. It's functionality that it's essential for me (and it's just the minimal examples... then Qt has all the GUI functionality, of course, but I use Qt even in console-only programs!).
This is surely opinionated on my side, and most C++ devs don't see it this way, but my point is that a language with a "core experience" that it's lackluster to you should not be a bad thing if the language is capable enough to provide an ecosystem with a good 3rd party library that adds exactly what you want. In the Lua ecosystem that maybe it's Penlight.
But I totally get your point. Penlight doesn't even seem to have a math library, so I found no round implementation there. This can be not a problem for some, but deal breaking for others.
The github project page is for developers, and Github already gives you tons of ways to make a user website. Don't ask your users to visit github.com/group/project, make them visit group.github.io/project, like any sane person.
Same with Gitlab, BTW.
And if you don't like the full static site, use the wiki, or guide your users in the first paragraphs of the README so they find the user information if they must.
The very first moment that I had to use JSON as a configuration format, and I was desperate to find a way to make a long string into a JSON field. JSON is great for many things, but it's not good at all for a configuration format where you need users to make it pretty, and need features like comments or multi-line strings (because you don't want to fix a merge conflict in a 400 character-wide line).
Doesn't YAML have a (seldom used) feature of a start and end of document marker? The "YAML frontmatter" that a few markdown documents have, uses this.
The problem is not that the US is sparse, is that cities are. You are probably misunderstanding the problem, and if not, you are not explaining correctly. Check out The Dumbest Excuse for Bad Cities from Not Just Bikes for a breakdown of the issue.
No one is blaming you individually, or even the US citizens individually. The problems are multiple for sure, but you won't start to fix it unless you understand the issue properly. Maybe it's not your case, but many US citizens are surely not seeing the point at all.
Sorry, could you clarify what you mean? I don't see the difference. Isn't the author complaining about Canonical for the policy enforcement?
"Theft" is never a technically accurate word when dealing with the so called "intellectual property", because the digital content being copied without authorization is legal in tons of cases, and because, come on, property is very explicitly exclusive. I cannot copy my house or my car, but I can make copies of my works for virtually 0 cost.
Using data for training ML models is even explicitly allowed in some jurisdictions (e.g. Japan), and is likely to be fair use everywhere else. LLMs are very transformative, and while they often can produce verbatim copies of fragments of copyrighted works, they don't store the whole works or significant pieces of them.
Don't get me wrong, I don't like big companies making big money. I would not mind a law that would force models to be open sourced. But restricting them to train their models on public data by restricting fair use, it would harm them very little (they could pay something if they are making some profit), while small researchers or companies would never be able to compete, because they would not have the upfront costs, nor the economic engineering to disguise profits and pay less.