It seems very hard for OpenAI to prove that independence. Since they seem unable to exclude the possibility that their model was trained on transcripts by the two mathematicians.
It’s extra hard on Linux because the amount of ways you can reconfigure a linux machine to work around boot- or root-kits, the ways you can modify a running process, and hide what is happening from an existing process.
Really, linux is meant to give you control over the software that runs in your computer. Anti-cheat is inherently about limiting what you can run on your computer. Windows is much more aimed at allowing you opt in to hard limitations.
Trumps short term actions will have long term consequences on the alliance. Specifically on how the alliance views reliance on the US. Trump has shown how unreliable an ally the US can be. Putting that cat bag in the bag doesn’t reverse the realisation that there’s a cat in that bag.
This will likely strengthen NATO in the long term. But only if it doesn’t get tested by Russia in the short term.
It's probably for the better over the long term, I Agree. We might be getting into complicated times, with AI and robotics, so it's much better if Europe would be more self-sufficient, militarily, technologicaly and economicaly.
The worry is not that Nvidia isn’t open about their models.
The worry is that Nvidia is trying to control the way you run those models. Trying to bake CUDA assumptions into model design, and pushing the software ecosystem to be as Nvidia first as they can.
Your looking at this from a legal perspective. Consider a diplomatic one instead.
Model training is expensive. Model distillation is cheaper. If you train models, and that lets your adversary distill them for much cheaper, that gives your adversary an advantage. Giving your adversary an advantage is bad, so you address it.
It doesn’t matter whether the advantage was gained legally, not even if it was fair. The advantage in and of itself is bad, and sufficient reason to act. You couch it in less nakedly power hungry terms, but this is the reasoning.
If they are an adversary, then you could inject broken information for them to distil with. Then have an alternative, private model for government and military purposes that doesn't have the broken information.
It’s more like eating your own fiber supplement in public, and then shitting your pants and telling everyone about it. Sure, it’s embarrassing. But it shows how potent your product is.
I especially wonder about the quality of N big models in a delegation harness against M smaller models in a delegation harness with N and M tuned to use the same amount of total compute. (So a few agents of big models against a lot of big models). I wouldn't be surprised if the advantages of delegation and the corresponding compression of context outweighs the lower quality of the smaller models.
Or put differently a wide exploration of long chains of obvious insights might be more valuable than a more narrow exploration of shorter chains of deeper insights. But perhaps that is a wrong sense of the difference between a small model and a large model.
It states regarding a visa:
"A visa allows a foreign citizen to travel to a U.S. port-of-entry (generally an airport) and request permission to enter the United States. A visa does not guarantee entry into the United States.
The Department of Homeland Security (DHS), U.S. Customs and Border Protection (CBP) officials at the port-of-entry have authority to permit or deny admission to the United States. "
Under the assumption that this framework is somewhat sane and only shares biometric data of those people who actually request an ESTA, I don't see the issue.
This data already leaks whenever you travel legally to the US, because they take it from you as a requirement of entry. All this does is let them check the data they take on entry against the provided data. Which seems fair. The fact this data is already in passports is a very different matter, but that is something the EU has done voluntarily.
I order to know who actually requested it, information needs to be shared that previously was not.
(I can think of technical schemes to limit this to less scary recipients and data, but however you do it, some necessary side-effect remains: Citizens of the EU who do not make such request cannot remain entirely unaffected.)
It seems to me you hooked onto the wrong part of proofs vs software compared to what OP meant.
The difference OP cares about isn’t how much one cares about style. Instead the important difference lies in validation. A proof can be validated as either correct or wrong. That type of hard feedback really helps combat the optimism and desire for shortcuts of modern models.
Now, that still doesn’t help an LLM distinguish between good and bad correct proofs. But it still really helps a lot. On top of that, taste in proofs is a lot more uniform than taste in coding. That helps LLMs be better at judging the quality of a proof, because there’s less disagreement in the wider world.
The standards of proof are different from the fundamental operation of "OK, cool, you solved this problem. Why does this problem matter? Isn't it useless? Senseless? Meaningless?" You have this same question whether or not you're in an a priori discipline (mathematics), scientific fields proper, or engineering. "Absolute certainty" has nothing to do with it. I can assure you, people on the job are not looking for The Absolute Truth when doing their jobs, yet they still can question at a solution by asking: are we solving the right problem?
(Although in general, there's no true difference between "I answered the question correctly, but the question was mapped to this thing we call 'reality' wrong", and "I answered the question incorrectly", because you can (try) adding the constraints that you really wanted targeted in case A, to case B, and boom, suddenly a question/answer pair that was "Answered correctly, but question doesn't map to reality" now becomes, "You answered this question wrong". However, individuals generally tend to have some breakpoint to differentiate between the two).
That's a valuable extra distinction between Mathematics and Software.
In Mathematics there is much more clarity on what question you want to answer. It's much less likely you get an answer to a question, and then realize that the question was useless. Whereas in software its almost guaranteed that your first implementation, correct or otherwise, will solve the wrong problem.
If you're saying that math has a consolidating network effect, sure. There are a lot of people who think similar problems are important. I guarantee you that when math was small, that is not the case, and when coming up with new math, that's not the case, and when coming up with sub problems to tackle large problems, that is not the case.
No, what I'm saying is that I don't agree that taste in mathematics is more uniform than taste in coding! Mathematicians argue about taste all the time. Just as you might look at a piece of code and agree that it compiles and doesn't have any fatal bugs but still think it's badly written, hard to follow, hard to modify, or whatever else, mathematicians judge mathematical work using very similar criteria.
reply