> If not, I would guess these models would be getting stuck in a local maxima
It sounds like you're referring to something like simulated annealing. Using that as an example, the fundamental requirement is to introduce arbitrary, uncorrelated steps -- there's no requirement that the steps be random, and the only potential advantage of using a random source is that it provides independence (lack of correlation) inherently; but in exchange, it makes testing and reproduction much harder. Basically every use of simulated annealing or similar I've run into uses pseudorandom numbers for this reason.
In the Ollama API, you use the "tools" parameter to describe the available tools to the model, then use the "tool_calls" from the response to call the functions and send the results back to the model using "role": "tool".
Most of this is handled very easily by the ollama-python library, so you can integrate tool calling very simply in any script.
That said, this specific model was unable to call the functions and use the results in my "hello world" tests, so it seems it expects a few very specialized tools to be provided, which are defined by that platform they're advertising.
Right now the best tool calling model I've used is still qwen3, it works very reliably, and I can give it any ability I want and it'll use it when expected, even in /no_think mode.
I did a very simple tool calling test and it was simply unable to call the tool and use the result.
Maybe it's specialized to use just a few very specific tools? Is there some documentation on how to actually set it up without requiring some weird external platform?
Drivers are precisely the reason we only have Windows, Macos and Linux as viable options.
Hardware manufacturers write Windows drivers, Linux community write drivers for basically all consumer hardware, and apple develops both the hardware and the OS with their own drivers.
>Drivers are precisely the reason we only have Windows, Macos and Linux as viable options
That is one big issue and another one is software.
Writing drivers and porting software means both time and money.
How ever if a new OS would bring lots of benefits to both users and companies, it might tip the scale and make the time and money investment worthwhile.
Of course, by a new OS I don't mean just another platform that ebables us to run software and use hardware, as existing OSes do that just fine.
By a new operating system, I mean one that enables us to use new computing paradigm, enable new types of software to software and software to hardware interactions and would make a big disruption to the market. Something with the same kind of impact as AI or the introduction of smartphones.
GNU has a helpful chart where they clearly show that there is a sliver of "nonfree open source" licenses that are available [0].
> The term “open source” software is used by some people to mean more or less the same category as free software. It is not exactly the same class of software: they accept some licenses that we consider too restrictive, and there are free software licenses they have not accepted. However, the differences in extension of the category are small: we know of only a few cases of source code that is open source but not free.
I was able to find one example, the NASA Open Source Agreement, which is accepted by the OSI [1] but rejected by the FSF [2]:
> The NASA Open Source Agreement, version 1.3, is not a free software license because it includes a provision requiring changes to be your “original creation”. Free software development depends on combining code from third parties, and the NASA license doesn't permit this.
Guarantee that all "nonfree open source" is different readings. Take the NASA case. If youu read it as strictly as Stallman does then it violates the OSD also. The people at OSI at the time it was submitted read it more like a lawyer and decided it was compliant. Possibly today's OSI would disagree. Possibly tomorrow's FSF would agree. It's not a difference between free software and open source but a difference between how two sets of humans interpreted the text of the license.
Eh, OSD 3 just says that derived works must be possible, it doesn't say that you must be able to incorporate third party source code into the derived work. Meanwhile the FSF's definition explicitly calls out this freedom as an essential component of Freedom 1:
> One important way to modify a program is by merging in available free subroutines and modules. If the program's license says that you cannot merge in a suitably licensed existing module—for instance, if it requires you to be the copyright holder of any code you add—then the license is too restrictive to qualify as free.
Training is reproducible only if, besides the pipeline and data, you also start from the same random weights.