punnerud

https://github.com/punnerud/mpedb is not there yet, focused on sync between sqlite3, Postgresql and Oracle. Shown that concurrent writes to sqlite3 is possible at the speed of Postgresql (My own project)

Replacing Tesla Cybertruck as the primary emergency escape vehicle for astronauts?

Yes

"""One of their better releases that seemingly focused more on quality and refinements than new-features.""" - Compared to a lot of others, this one have introduced more bugs than I have ever experienced in more than 10 years.

I have stopped submitting bugs because of the tedious bug reporting app, only submit really bad ones. Can't they give some helping functions to finding the correct categories based on problem description?

The program this fits into was not started by us nor was it proposed by a Large Language Model. (…) We took their work as a starting point, using Large Language Models to push their program to completion.

Thats how most people use LLMs? If I was back in my student days working in Navier-Stokes, I guess I would also punch at blow ups. The number of students doing this at the same time, posting open efforts to GitHub then retraining of the models. If there is solutions to the problem, it’s a real possibility that it was not a result of this effort?

Using a large amount of tokens is not a good augment that it’s not likely others have done the same. Good questions is the difference between $10 and $10M in token usage to solve a problem.

The demo use WASM/browser when available, but also supports running only on ESP32. Figured out I could offload and give the users a better experience when available.

Thanks for noticing the Tailscale demo. Created a Tailscale-Rust client that supports NAT-traversial, encryption etc. and manage to run on ESP32 (together with the local LLM). Just the Tailscale part can be found here: https://github.com/punnerud/tailscale-mpe-rust

A trick to fit language models of this size it to remove the word to embeddings from the NN, and have a database to look up a dictionary of words and their embeddings. This way the LLL only need the "core" and you do the reverse for loopup again (kind of Text->RAG->LLM->RAG->Text). Have an example here: https://punnerud.github.io/pyspell/

The example have a limited language of around 1000 words, but make it possible to do Python (like) programming with LLM on an ESP32.

My prediction is that HuggingFace will take up the challenge with OpenRouter (now Stripe) and ollama.com (Facebook)

Already using it as the primary DB in multiple off my apps and dev pipelines. I don't trust my own "slop", but the all the tests from SQLite, Python, PHP etc agains the DB

You can think further, you can build a no-server server; Example let Nginx be running, then forward requests to the database, running the code, query data and responding then shutting down again. Need the service to do something regularly, just trigger that part of the database through crontab.

And yes you can let authorized users add custom code, make it run in the database like a micro-micro-vm and do stuff on triggers etc in the database as well.

This makes it even more powerful, because users can switch code during runtime and you can have multiple users "programming" against the same database at the same time working against the same data.

I build a SQLite clone in Rust with this analogy in mind, and unlike SQLite it support multiple writers by giving them separate segment in a file. Calles the programming "language" PySpell, it converts Python into AST then into RUST with a lot of cool features you can enable when the database and programming language is living in the same place.

http://github.com/punnerud/mpedb

“I start to see what’s really slowing people down and what my team or I can do about it.”

I often tell engineers that employees will never go to an “innovation center” in a company to say that their job could be made obsolete. And by definition the workplace is not 100% effective as long as there is employees. Still there is most likely always more that can be done, so think that the existing people can be automated away and be used in new positions.

A good way to find problem from top-down is to look for similar jobs done. Often a department with a lot of employees. 10% more efficient for 100 is better than 100% for two, unless those two indirectly slow the rest of the company down.

And I like to think that when companies expand rapidly it’s easy to spot problems, the contrary is slow growth, then problems is often someone’s job and they will not complain if it’s not stressful. The last part is often solved over time with even more people.

Added, thanks

Checked and this 100% compatible SQLite3 database (also C-API) did not contain the bug: https://github.com/punnerud/mpedb (Disclaimer: My own project)

And this statement is wrong in the article: “ Because SQLite is a single-writer database with serialisable transactions, our transaction history was completely linear and deterministic. (This wouldn’t be true in a multi-writer database like Postgres or MySQL.)”

Actually possible in mpedb to replay multi-writer, and actually better than SQLite3. Try to reply now() in a statement, that is not deterministic in SQLite but is in MPEdb.

Wow, had to check some of his other repos; his the one behind dump1090

What’s in that “Search tool”, could actually be the same solution presented in a different way

What a great idea! Anyone that want to join up in Oslo / Norway?

I can use the work office, have more then enough coffee, tea etc. with space to around 150 people.

https://forms.gle/2pDEkQTYihQ4txK29

(Copy pasted the form. Why change a winning team)

Sorry, that’s correct. The other one is an internal one not released yet that also have a full Tailscale server written in Rust.