More like robbers rob a bank and take hostages. They threaten to kill a hostage, but still don't get any money. So they threaten to report the bank for not being up to code with an expired fire extinguisher if they don't get some money.
They know the bank doesn't give a shit about hostages being killed. But a few pennies for a minor fine is a threat the bankers really understand.
No he does actually mention in the middle of that that while code must be free, art is different because art is not software. I guess he's imagining a situation where a game would have multiple licences (one licence for the code, a different one for the art assets).
Is it entitlement to expect to get what was advertised from a service you pay for? If they advertise $x/month for 4k and you pay them $x/month and get 720p, that seems like a very legitimate complaint to me.
For anyone not wanting to read through that article, here's the tl;dr:
Apache requires you to note what changes (if they're "substantial") you made to the code. Otherwise it's identical to MIT.
BSD is effectively identical to MIT.
At a minimum they've got to design a wider issue. Current high-performance superscalar chips like the XuanTie 910 (what this laptop's SoC are built around) are only triple-issue (3-wide superscalar), which gives a theoretical maximum of 3 ipc per core. (And even by RISC standards, RISC-V has pretty "small" instructions, so 3 ipc isn't much compared to 3 ipc even on ARM. E.g., RISC-V does not have any comparison instructions, so comparisons need to be composed of at least a few more elementary instructions). As you widen the issue, that complicates the pipelining (and detecting pipeline hazards).
There's also some speculation that people are going to have to move to macro-op fusion, instead of implementing the ISA directly. I don't think anyone's actually done that in production yet (the macro-op fusion paper everyone links to was just one research project at a university and I haven't seen it done for real yet). If that happens, that's going to complicate the core design quite a lot.
None of these things are insurmountable. They just take people and time.
I suspect manufacturing is probably a big obstacle, too, but I know quite a bit less about that side of things. I mean a lot of companies are already fabbing RISC-V using modern transistor technologies.
I think it's the "temporary" part of the licence where the trouble comes. Yes, you're allowed to do whatever you want privately...until you're not. I mean Louis Rossman is (in my view) a very trustworthy individual, so "trust me bro" legitimately does carry a lot of weight when he's involved on the project, but "we can take away your licence at any time for no reason at all" is not something seen in the open source world.
Seriously, I don't get distro hoppers. "I want my desktop wallpaper to be green. Can you tell me how to install an entirely new operating system with a green background?"
Does it do PGF/TiKZ or have something comparable?
You definitely have to ~~go to the Arch wiki~~Google in some cases. Knowing what the problem is and knowing how to fix it are sometimes seemingly unrelated. E.g., "Could not open foo.yaml: File not found" could actually mean "Some non-obvious file in the tarball was not set executable, which screwed up this one script that ran another script but couldn't run some other script which didn't give an error message, which made another script think the file had already been copied". If you can find someone out there who ran into exactly the same problem, you can find a solution to it, but if none of the words in your error message are completely unique, it can be very hard to find someone with the same problem.
Those instructions are from the official docs, and install.sh comes from the source repo. It's an annoying script (it basically runs apt, npm, make, on your behalf...thanks, I can do that myself), but if you're trusting the repo source to begin with, I don't think it's any less secure.