5,314 karma · joined February 16, 2015
Blog: https://gavinhoward.com/
Contact: https://gavinhoward.com/contact/
I know it isn't mainstream, but companies try to avoid those licenses as much as possible.
Tinfoil hat: sometimes I wonder if companies astroturfed support for permissive licenses. Getting the entire Rust ecosystem to avoid copyleft was a huge win, for example.
And now that copyleft Gnu tools are being replaced with permissive uutils in Ubuntu, it seems they won, whether or not they were the ones to push it.
> Companies don't care about it. We carry on as is...
If required by law, companies would care.
> This is a classic over-engineered solution that nobody wants to a problem that barely exists.
The sorry state of our industry means the opposite: the problem is big, but lack of teeth means companies can ignore it and externalize the costs.
> Just add burocracy, what could possibly go wrong...??
I'd prefer to create our own bureaucracy, not have governments push one on us, like the Cyber Resilience Act does in the EU.
Copyright laws (in the US) added fair use, which has four tests. Not all of the tests need to fail for fair use to disappear. Usually two are enough.
The one courts love the most is if the copy is used to create something commercial that competes with the original work.
From near the top of the article:
> I agree that the dynamic of corporations making for-profit tools using previously published material to directly compete with the original authors, especially when that work was published freely, is “bad.”
So essentially, the author admits that AI fails this test.
Thus, if authors can show the AI fails another test (and AI usually fails the substantive difference test), AI is copyright infringement. Period.
The fact that the article gives up that point so early makes me feel I would be wasting time reading more, but I will still do it.
Edit: still reading, but the author talks about enumerated rights. Most lawsuits target the distribution of model outputs because that is reproduction, an enumerated right.
Edit 2: the author talks about sunstantive differences, admits they happen aboit 2% of the time, but then seems to argue that means they are not infringing at all. No, they are infringing in those instances.
Edit 3: the author claims that model users are the infringing ones, but at least one AI company (Microsoft?) had agreed to indemnify users, so plaintiffs have full right to go after the company instead.
Is your company hiring?
I hate AI.
C and C++ programmers complain about UB, but they don't really care.
TCC is probably the closest thing we have to that, and for me personally, I made all of my stuff build on it. I even did extra work to add a C99 (instead of C11) mode to make TCC work.
[1]: https://gavinhoward.com/2023/02/why-i-use-c-when-i-believe-i...
I don't know which one I will actually implement, though.
And it doesn't even have to be that much cheaper. Maybe 15% or so.
That said, a lot of people want it, so I hold no grudge that they do it. It certainly is reasonable use of AI compared to others.
I just use Windows to build and test my FOSS on it.
With this change, I have decided to accept the insecurity of not updating and stick with 10. The only thing I do on Windows is ensure my FOSS is cross-platform.
Edit: wait, that is actually how many points I got. Eh, I am still on the list.
A violin is most expressive because it is the one that uses friction (rubbing a bow on strings).
Also, moving the bow just right is harder than slamming keys.
Anyway, as someone with a blog, people actually have conplimented me for not using images unless they support the point in the post. I see plenty of negative comments about blog posts with header images.
Friction with growth is good friction, so long as the friction is minimized for the amount of growth.
And by "growth," I mean anything that helps people to "level up," such as learning, gaining a skill, becoming more Christ-like, whatever.
Growth cannot happen without friction. Your use of AI is stunting whatever growth you could have gained from those processes.
"So what?" you may say. However, someone who applies friction to growth consistently in their blog/code/whatever will find that growth compounds like interest, and though they may be less "productive," their productivity will be better in the long run because they will have the skills to go beyond anything you could ever dream of doing.
I agree that too much friction is terrible.
But what I was saying, and the article seems to be implying, is that too little friction is terrible too.
Using Stable Diffusion is lower friction than sketching or painting. But the latter two are better.
The difference is that there is friction that leads to a good outcome, and friction that does not. Mixers with bread hooks are eliminating bad friction, whereas Stable Diffusion is removing good friction.
And in fact, there's actually more friction when using Stable Diffusion if you have an end in mind; trying to get it to output what you want is high in bad friction.
Yes, flat design is too flat, and AI chat is too devoid of friction.
But mobile and tablets are better at certain things [1], and we shouldn't get rid of that either.
I saw somewhere (Bret Victor?) that tools have two parts: the part that fits the problem, and the part that fits the human. The example was a hammer; the head fit the problem (the nail), and the handle fit the human (the hand).
Notably, the two parts must fit their respective things, but they also have to work together.
That is what we should be doing: creating harmonious tools that fit the problem and the human. What that looks like will be different for every tool.
Our interfaces currently have two problems:
* Because they can have any appearance, appearance gets more attention than being a good tool. Example: flat design (good appearance) overriding skeuomorphic design (human fit).
* No one wants to redesign everything, so we all reuse the same base stuff (Electron, Qt, etc.) even if the result won't fit (one or both ends) or harmonize.
I would love to fix both of those problems, but because people are lazy, it essentially means creating a GUI framework that is flexible enough to fit almost any problem and any human (accessibility included) while making sure that flexibility does not destroy harmony.
While I am working on that, it is a tall order, and I am almost certain I will not succeed.
My guess is that bitslicing only gets you so far.
I am working on designing a bug tracker, and this post completely clarified that I am going down the wrong road.
Back to the drawing board.
Sorry, I was AFK for several hours.
Thank you for the offer, but I don't think Yao should be featured yet.
Edit: I guess I'll answer your questions anyway.
> So Yao has a delineation between safe and unsafe code, correct?
Correct. However, Yao's "unsafe" will actually be separate files, written directly in an LLVM-like assembly (Yvm in the repo). That's how it will be harder to use.
> Does "safe" in Yao have the same (or stronger) set of guarantees as Rust (i.e. no memory safety if all necessary invariants are upheld by unsafe code, and boundary of safe-unsafe code)?
Stronger.
First, Yvm (Yao's assembly/unsafe) is made specifically for structured languages, and it will still do bounds checks by default. Yes, there will be ways of not doing bounds checks, of course, but even in "unsafe," bounds checks will exist.
Second, Yao and Yvm are both explicitly designed for better formal verification. [1] This includes user-defined formal properties.
> Does Yao guarantee memory safety in the absence of unsafe blocks?
Yes.
> does the condition+restart system in Yao fall under the safe subset of the language?
It's still being implemented (hence why Yao should not be featured), but it will be a part of the safe subset. That is a guarantee; I will completely redesign Yao if I cannot fit conditions and restarts in the safe subset. But I am confident that they will work as-is because I implemented a prototype in C that is safer than C itself.
> 1. Are the types of restart functions passed down to functions that are called?
Not directly. My C code uses, and Yao will use, what I call "context stacks," an idea that comes from Jonathan Blow's Jai.
These are more useful than just restart functions, but there is explicitly one context stack for restart functions, per thread. Registering a restart function means pushing it onto the context stack.
Then, when an error happens, the context stack is walked backwards until a restart function handles the error. If no function handles it, the context stack for the parent thread is walked (starting at the point where the child thread was created), and so on until some function handles it.
I push a default restart function at the root, so errors will always be handled.
> 2. If the type information is not passed, and conditions+restarts are part of the safe subset of Yao, then how is resumption logic checked for type safety and lifetime safety? Can resumptions cause run-time type errors and/or memory unsafety, e.g. by escaping a value beyond its intended lifetime?
This is one of the craziest parts of Yao: it will have the capability to be generic over types at runtime. In addition, Yao has something like Go interfaces or Rust traits. What it has is more powerful, though.
The end result is that errors will actually be interfaces, and everything will be type checked at comptime, but be memory safe.
I hope this answers your questions.
[1]: https://gavinhoward.com/2024/05/what-rust-got-wrong-on-forma...