jcarrano

You are missing the most important part: a culture in which these kinds od overreach are not tolerated. For sure resistance has waned over time, but it is still strong. The constitution is merely a piece of paper if people are not willing to defend their rights.

I can't even describe how much frustration this caused me when I worked at the RIOT project. macOS was by far the most problematic development platform to support. Even Windows was far friendlier since it has WSL which is officially supported.

The manual has everything and is not long. It is actually very concise, but with the caveat that within each page you have to read everything. Every sentence of the manual has important information.

There are roughly two ways to learn programming: top down (start with abstract concept and go down to actual implementation, e.g. SICP) and bottom up (start with the concrete low-level code and let the abstractions naturally emerge).

I studied electronics, so naturally we began with assembly (Motorola HC11). By the end of the course everyone had independently developed their macros to do things like for-loops, so it was a natural progression from there to C. By the end of the C course "C-style OOP" had also emerged naturally, which led to the next course in C++.

The downside of this approach is that it there is no gradual route from there to functional paradigms (or non-imperative in general). Also, one develops the habit of always thinking of how the language works under the hood, which can be counter, productive. E.g. when I was trying to learn Haskell, my mind was trying to understand how the interpreter worked.

Learning assembler is not just about the language, but understanding how the machine works (buses, memory-mapped peripherals, etc). In older platforms this is much simpler, so while ARM instructions can be easier to learn than the CISC instructions of the HC11, everything else is much friendlier for the beginner in the HC11.

Also, the power density of the sun is extremely low. A rotting orange produces more power per unit mass.

If it is really an AGI it will have its own set of opinions. It would be quite ironic if the AGI ends up believing that humans are in the image of God, against its own "believers".

Exactly. Mises explains, in the first part of Human Action, that the ultimate limiting factor of production is human labor. AI does not change this, or any other thesis of praxeology.

That book, and the follow up "Pentagon of Power" blew my mind when I read them years ago. I can't even enumerate how many topics it discusses. 100% recommended reading.

I once read that the collapse of the Roman empire set back technological progress a few centuries. Maybe it was a good thing. Could you imagine having atomic bombs with a XV century mentality? I'm not saying that the 500 years ago the mentality was worse, but maybe we weren't prepared yet.

At some point "the rubber meets the road", i.e., you have to bridge the digital world and the physical one. Increase the probability that thugs are caught and increase the severity of the consequences.

In the real world the ultimate countermeasure is bullets. All the rest is to avoid reaching this last resort.

I don't know if it would be a good or a terrible idea to have, as a last resort, a law entitling researchers to a reward for vulnerabilities, similar to laws that give someone who finds a lost item a right to a reward. Hopefully, in most cases it would not need to be invoked and the issue would be settled privately.

We are talking about a sci-fi style force-field here! I'd be surprised if the military didn't secretly experiment with this.

The general philosophy of these CI systems is flawed. Instead of CI running your code, your code should run the CI. In other words, the CI should present an API such that one can have arbitrary code which informs the system of what is going on. E.g. "I'm starting jobs A,B,C", "Job A done successfully", "This file is an artifact for job B".

Information should only from from the user scripts to the CI, and communication should be done by creating files in a specific format and location. This way the system can run and produce the same results anywhere provided it has the right environment/container.

That is true for most cases, which nowadays is web and backend software. As you get into embedded or anything involving hardware things get slower and you need to optimize.

For example, tests involving read hardware can only run at 1x speed, so you will want to avoid running those if you can. If you are building a custom compiler toolchain, that is slow and you will want to skip it if the changes cannot possibly affect the toolchain.

100% agree and that has been my experience too. It also makes testing the logic locally much easier, just run the script in the appropriate container.

The pipeline DSLs, because they are not full programming languages have to include lots of specific features and options and if you want something slightly outside of what they are designed for, you are out of luck. In a way it feels like how graphics were in the age of fixed-pipeline, when there had to be a complex API to cover all use cases yet it was not flexible enough.

One of my biggest headaches is that the pipeline cache never seemed to work predictably (e.g. not pulling cached data that was available, it uses zip so the permissions are messed up, etc), so I ended up writing my own caching system. It was important for my use case because full runs could take 2 to 3 hours.

Then there is the YAML config which is too convoluted. It took me several attempts to get things right.

What works better, IMO, is to have each CI step as a script or a Make target that can run anywhere (CI or dev PC) and in the CI configuration have a single line in each step that invokes the script.

For me GitLab CI is a reason to move _away_ from it.

Copyleft licenses are supposed to prevent to an extent this sort of free riding, but they are no longer "fashionable".

I don't see the point of refusing to add additional (copyleft) terms to a license, only to end up hoping companies act as if the terms existed out of good will.

Companies like Google love the permissive licenses, and go as far as to sponsor MIT/BSD-licensed replacements to common building blocks like toybox.

EDIT: I see that Forgejo v9+ is indeed GPL-licensed.

In Germany, all storage products (e.g. USB sticks) have to pay a canon "because you could use it to pirate media". Now, if I pre-paid the canon for pirating, does it mean I'm authorized to?

It took way less than 100 years to eradicate illiteracy, and further improvement followed. However, as soon as a system is established, the forces that corrupt that system start acting, finding ways to exploit it to their own advantage. Then, as special interests (politics, unions) take over, the quality stagnates and then decays.

I find it appalling that parent who can afford a private school, even with much sacrifice, would instead send their children to a a public school.

It is the equivalent of eating soup at a homeless shelter when you can go to the store and buy something better, made worse by the fact that you are making the decision for someone else that cannot decide on their own.

For most of history, homeschooling was the norm for those who could afford private tutors. We know how our current mass-production type education appeared, but what needs to be explained is how it surviving into the 21st century.

It is. We can argue under which conditions it is legitimate, which is long debate. At some point, it seems that the TOS does make a distinction between legitimate and illegitimate violence, however imperfect it may be.

For example, nobody in their right mind would consider a policeman being distinguished for stopping a shooter as "glorifying violence" even if the officer had to use violence to him down.

Maybe they should be banned too? It doesn't subtract from my point. Still, there is a world of difference between killing people because you don't like their companies and killing combatants of a terrorist organization.

Yes, "political statements are violent or are calls to violence" is true in the sense that state power is ultimately based on the threat of violence. At the deepest level of analysis this violence is illegitimate too. The thing is, we are sadly not yet at the point where we can do away with the state.

The rules are reasonable as far as they prohibit glorifying illegitimate violence. Whether the platforms applies the rules in this way for other cases or not is irrelevant for this particular case, even if we know the TOS are applied pretty arbitrarily.

It would make for an interesting plot twist if her ex was behind the scam.

I usually agree with EFF, but this clearly crosses a limit of promoting and glorifying violence. In this case the user is clearly in violation platform TOS.

Just add a "$comment" key. The only problem will be if the parser is too strict and rejects the unrecognized key.

Essentially a stripped-down ini where you have to code any additional functionality and you will never have any tooling because basic things (like comments) are not standardized.

For the use cases mentioned in the article, I have used JSON with schemas and JSON-merge and JSON-patch quite effectively. VScode supports schemas so it will help you edit the file without making mistakes. You can use JSON merge to combine global and local configs and you could even use custom fields in the schema to indicate metadata, for example, that a key represents an upper limit so the lowest value should be considered when merging.

I am that someone else because I seldom edit the makefiles and I forget things. That's why I try to trim unused targets and recipes and I try to keep it documented.

In the end it is no different from any code that's suffered from 10 years of tuning and it can get ugly. Maybe Make is even somewhat worse in this respect, but then again it does not need to be changed often.