I think at this point what the Netherlands, and any other country that wants a good model in their language should do, is gather up every piece of text ever written in that language and license it to the big AI labs/companies for training. I'm sure there are vast libraries of books and other text that haven't been digitized and aren't a priority for the big labs.
Oh I didn’t mean at all charging them. I mean licensing in the sense of granting rights for the purpose of training. Probably most labs would be fine adding the language to the training for free as long as the dataset quality is high and it improves the results. But yes, pay them if that’s what it takes for them to use it.
I was just looking at Unicorn last week because it's used by unipacker to do automated unpacking of binaries. I built a "toolbox" for gpt-5.5 to do semi-automated malware and exploit reverse engineering and unipacker is sometimes useful for that purpose.
Mini Micro seems to be built on Unity. The MiniScript portion of it is open source https://github.com/JoeStrout/miniscript but the version packaged for use by Unity costs some money. I can't tell if the people behind MiniScript are the same people behind the Mini Micro.
Every C program I've had codex write ended up costing me more time than had I just done it from the start myself. Whereas almost every Python program it's written for me saved me time, even including the time I spent cleaning it up.
I chalk this up to primary two reasons. First, I cared a lot more about the implementation details of the C program than I did the Python one, and second, it's just better at simple stand-alone python programs than it is at C programs.
The criteria I know use is "do I care about the implementation details of this?". If I do (because for example it's going to be long-term code that I need to maintain) then the agent likely isn't worth it. But if I don't, there are huge efficiency gains to be had using the agent.
Ah I was a few years later on the TI-86. Around 1999.
Between this, and SNES emulation (searching memory for values and adjusting things to see how they'd affect the game), I was destined for computer science.
> The article doesn’t really tell us what is gained by rejecting infinity.
Decidability. The issues around undecidability all involve the lack of an upper bound. In a finite deterministic space, everything is decidable, although some things may be too costly computationally to decide.
There are several ways to go for decidability. The brute force way is computer arithmetic - there is no number larger than 2^64-1. That's how we get things done on computers, but proofs about numbers with finite upper bounds need lots of special cases. Mathematicians hate that.
I used to work on this sort of thing, using Boyer-Moore theory. That's a lot like the Peano axioms. There is (ZERO), and (ADD1 (ZERO)), and (ADD1 (ADD1 (ZERO))), etc. Everything is constructive and has an unambiguous representation in a LISP-like form.
You can have recursive functions. But they must be proven to terminate, by having a nonnegative value which decreases on each recursive call. There is a distinction between "infinite" and "arbitrarily large". You can talk about arbitrarily large numbers, but you cannot get to 1/2 + 1/4 + 1/8 ... = 1. You can have integers and rational numbers of arbitrary size, but not reals.
Set theory was interesting. Rather than axiomatic set theory, I was using lists as sets, with the constraints that no value could be duplicated and the list must be ordered. Equality is strict - two things are equal only if the elements are all equal, compared element by element. It's possible to prove the usual axioms of set theory via this route. The ordered criterion requires proving things about ordered list insertion to get there. It's ugly and needs machine proofs.
I was doing this back in the early 1980s, when machine proofs were frowned upon. Mathematicians were still upset about the four-color theorem proof. It's all case analysis, with thousands of cases. That's more acceptable today.
Looked at in this light, infinity is a labor-saving device to eliminate special cases, at a potential cost in soundness.
> Looked at in this light, infinity is a labor-saving device to eliminate special cases, at a potential cost in soundness.
Or it is something that clearly conceptually exists, and makes simplistic reductionist viewpoints impossible to prove, which frustrates those who attempt to extend them into twisted metaphysical conjectures.
All indications seem to be that things are only lost, not gained. But that doesn't mean it doesn't hew closer to how things actually are. But if that's how reality actually is, then developing a rigorous understanding of it can only be a good thing, right?
Rejecting infinity is a purely philosophical stance that doesn’t teach us anything about reality.
There is a big difference between “infinity doesn’t exist” and “infinity doesn’t exist physically”.
I should also add that the resolution of zeno’s paradox in the form of calculus where and infinite set of steps can occur in a finite time (or infinite set of distance can span a finite total distance) is conceptually very simple and useful. Rejecting it as unphysical, or saying it must imply time or space come in discrete chunks, is not contributing to an understanding of reality unless the rejection also comes with a set of testable (in principle) predictions.
EDIT: you could even probably claim "nothing exists which isn't physically measureable" which may or may not be a stronger claim depending on your point of view.
EDIT AGAIN: rate limited by this dogshit website :D but I'll respond to this comment here:
> Which is exactly why I mentioned rejection of zero, negative numbers, etc. You can reject them, but doing so just throws away useful tools without gaining anything in return.
Yeah! I fully agree. I can see no obvious benefit to rejecting these powerful tools. However, important discoveries often happen in non-obvious directions, and exploring unexplored territory is generally worthwhile. So the fact that it doesn't seem immediately useful doesn't mean it's not worth trying!
No, the gains here aren't very dramatic when compared properly (against fsync), and have nothing to do with AI help. The gains come down to Linux kernel support for certain synchronization primitives like the Mutex on Windows, such that there is a more direct mapping of what a Windows binary expects to what the Linux kernel provides. See https://docs.kernel.org/userspace-api/ntsync.html for the kernel support that makes this possible.
Those benchmark numbers are slightly misleading, as they are a comparison of Wine+ntsync against Wine+nothing. There has been a somewhat fast "fsync" library built around Linux's futex and the gains over Wine+fsync are modest (just a few % in most cases).
That said, Wine+ntsync is still a win, just not a 8x improvement like the Dirt 3 benchmark suggests.
(And it case it's not clear, ntsync is https://docs.kernel.org/userspace-api/ntsync.html, which is a driver for Linux that offers syncronization primitives (mutex, semaphore, events) that more closely match the semantics of the Windows primitives. It's easier to do a direct implementation in Wine to support code compiled for Windows that expects to be talking to an NT kernel.)
Ironically, SQL Server AFAIK in order to run on Linux uses what basically amounts to a Microsoft reimplementation of Wine. Which always makes me wonder if they'll ever get rid of Windows altogether someday in favour of using Linux + a Win32 shim. I think there are still somewhat strong incentives nowadays to keep NT around, but I wouldn't be that surprised it this happened sometime down the line.
AFAIK it's more like a reimplementation of NT APIs in userspace - aka basically Wine with extra steps, or Linux UM. There was a slide deck going around about Project Drawbridge, here: https://threedots.ovh/slides/Drawbridge.pdf
reply