Not everything is perfect.

One big problem of many big open source projects is that they are contributed to by separate selfish organizations, that have private information. Then what happens is that:

Another common difficulty is that open source maintainers may simply not care enough about their own project (maybe they did in the past but lost interest) to review external patches by people they don't know.

This is understandable: a new patch, is a new risk of things breaking.

Therefore, if you ever submit patches and they get ignore, don't be too sad. It just comes down to a question of maintenance cost, and means that you will waste some extra time on the next rebase. You just have to decide your goals and be cold about it:

Writing documentation in an open source project in which you don't have immediate push rights is another major pain due to code reviews. Code code reviews tend to be much less subjective, because if you do something wrong, stuff crashes, runs slower, or you need more lines of code to reach the same goal. There are tradeoffs, but in a limited number. Documentation code reviews on the other hand, are an open invitation to infinite bike-shedding, since you can't "run" documentation through a standardized brain model. Much better is for one good documenter person to just make one cohesive Stack Overflow post, and ping others with more knowledge to review details or add any missing pieces :-)

Open source development model in which developers develop in private, and only release code to the public during releases.

Notable example project: Android Open Source Project.

This development model basically makes reporting bugs and sending patches a waste of time, because many of them will already have been solved, which is why this development model is evil.

Ciro Santilli can accept closed source on server products more easily than offline, because the servers have to be paid for somehow (by stealing your private data).

Closed source on offline products used by millions of people is evil, when you could just have those for free with open source software! Thus Ciro's hatred for Microsoft Windows and MacOS (at least userland, maybe).

The opposite of open source software.

ISO is the main culprit of this bullshit, some notable examples related to open source software:

The only low level thing that escaped this was OpenGL via Khronos, what heroes those people are.

How the hell are you supposed to develop an open source implementation of something that has a closed standard?

Not to mention open source test suites, that would be way too much to ask for, those always end up being made by some shady small companies that go bankrupt from time to time, see e.g. .

If you are going to do closed source, at least do it like this.

Basically the opposite of need to know for software.

The approach many courses take to physics, specially "modern Physics" is really bad, this is how it should be taught:

This is likely because at some point, experiments get more and more complicated, and so people are tempted to say "this is the truth" instead of "this is why we think this is the truth", which is much harder.

But we can't be lazy, there is no replacement to the why.

Related:

These people are heroes. There's nothing else to say.

This is the only way to truly understand and appreciate the subject.

Understanding the experiments gets intimately entangled with basically learning the history of physics, which is extremely beneficial as also highlighted by Ron Maimon, related: there is value in tutorials written by early pioneers of the field.

"How we know" is a basically more fundamental point than "what we know" in the natural sciences.

In the Surely You're Joking, Mr. Feynman chapter O Americano, Outra Vez! Richard Feynman describes his experience teaching in Brazil in the early 1950s, and how everything was memorized, without any explanation of the experiments or that the theory has some relationship to the real world!

Although things have improved considerably since in Brazil, Ciro still feels that some areas of physics are still taught without enough experiments described upfront. Notably, ironically, quantum field theory, which is where Feynman himself worked.

Feynman gave huge importance to understanding and explaining experiments, as can also be seen on Richard Feynman Quantum Electrodynamics Lecture at University of Auckland (1979).

Videos should be found/made for all of those: videos of all key physics experiments

The key thing in a good system of units is to define units in a way that depends only on physical properties of nature.

Ideally (or basically necessarily?) the starting point generally has to be discrete phenomena, e.g.

What we don't want is to have macroscopic measurement artifacts, (or even worse, the size of body parts! Inset dick joke) as you can always make a bar slightly more or less wide. And even metals evaporate over time! Though the mad people of the Avogadro project still attempted otherwise well into the 2010s!

Standards of measure that don't depend on artifacts are known as intrinsic standards.

A language that allows you to talk to and command a computer.

There is only space for two languages at most in the world: the compiled one, and the interpreted one.

For 2020 now, when you have a choice, you must go for:

Those two are languages not by any means perfect from a language design point of view, and there are likely already better alternatives, they are only chosen due to a pragmatic tradeoff between ecosystem and familiarity.

Ciro predicts that Python will become like Fortran in the future: a legacy hated by most who have moved to JavaScript long ago (which is slightly inferior, but too similar, and with too much web dominance to be replaced), but with too much dominance in certain applications like machine learning to be worth replacing, like Fortran dominates certain HPC applications. We'll see. Maybe non performance critical scripting languages are easier to replace.

C++ however is decent, and is evolving in very good directions in the 2010's, and will remain relevant in the foreseeable future.

Bash can also be used when you're lazy. But if the project goes on, you will sooner or later regret that choice.

The language syntax in itself does not matter. All that matters is how many useful libraries and tooling it has.

This is how other languages compare: