Where this approach might shine right now is .o/.obj files for assemblers/compilers/linkers. Instead of using COFF/ELF/whatever binary voodoo, a relational DB container makes most of the previously hard things trivial, including optional vendor extensions.
This would be a super pragmatic approach for a modern compiler suite. This is the brilliant part of the whole idea.
Don't pay too much attention to the inner-circle feedback. Some people subconsciously use the tone of reception to control you, especially peers/colleagues are prone to this. They see someone having a bright idea, and they genuinely don't like it just because it makes them feel small in comparison. The thing they do next - they try to extinguish the spark by creating an illusion of worthlessness in your mind. By doing so, they are getting rid of a potential competitor on their own way to success. According to psychology, they start feeling normal again by reducing you, this is a natural compensatory mechanism ingrained in human archetypes.
The key thing here is to be able to discern between real and manipulated input information. For this, gut feeling usually works best: it spots that whiny, attention-insisting, importance-seeking, fear-inducing tone of a manipulator, but oftentimes the higher-level nervous system of the brain suppresses that signal (e.g. "How can a well-educated and charismatic person feel a bit off and responsibility-lacking sometimes? It cannot be right, so it must be something with my interpretation of reality. I bet they have the best intentions.")
An even better approach may be not to search for feedback at all, unless it's shared naturally without any strings attached.
The copied vs. mapped memory situation is the only deal breaker in this experiment. Otherwise, file format unification would be a big step forward. The PE/COFF executable file format used by Windows (and some older Unix systems) is a relational database as well. The same goes to .NET assembly format - it's a relational database too. The wheel gets reinvented over and over again.
I was thinking that one could just write a loader that goes from SELF->ELF on load. You then pay the cost on startup. Probably not worth it for one-shot programs like ls/cat/etc, but for long running programs and daemons it might be workable.
Of course there are many options, but the benefit of the SQLite approach is the existing tooling, support, etc. Like others have said, one could just write a SQL interface over a set of virtual tables derived from the actual elf (if one just wanted a CRUD-like interface to a binary).
All of the benefits of SQLite disappear once one diverges from the format in any way. At which point it would be better to ask: "what is the best first-principles implementation of this idea?", instead of "what is the minimal change to SQLite to achieve this specific narrow goal?"
I didn't understand the core issue, is it that due to non-alignment of the on-disk data you have to do a copy at load time, but if you could guarantee alignment of the actual blob content then you could use it directly?
On a brief background read it looks like another issue is that blobs are not necessarily stored in contiguous regions of the file. Maybe there's some clever way to combine a VFS shim and virtual tables to store page aligned blobs in a region of the same file as the main database.
In real life, an imaginary "leadership" quickly evaporates upon the first hurdle of any kind until proven otherwise by real actions. If I was in your shoes, I would be very careful with blanket statements like these.
This would be the "proven otherwise by real actions" part. They've been around since 2017 and have had plenty of time to hit various hurdles. Past performance is no guarantee of future performance and it is within the realm of possibility for them to go of change course like Elon did. But who are you? Are your Internet comments some proenoucement of truth that can never ever be taken back? So you said something that, years later, turns out to be wrong. So what?
I do not see any value proposition in this - if I need a sandbox, I make one with Dockerfile, Bubblewrap or virtualization. What I am missing? An enforced required login is a net negative value - it means rug pulls in the future.
On Linux I am using https://github.com/wrr/drop which configures bubblewrap based on a simple yaml config specific for the project path and it is enough for me.
I know a guy who founded an AI-based startup well before ChatGPT, and recently I saw some of his public messages where he stands as an ultimate anti-AI proponent.
Meanwhile, his startup that received multi-million dollar funding and developed proprietary specialized LLMs, continues to exist being somewhat profitable.
Universal AI, however, poses an existential risk to his company. So he turns into a typical gaslighter: he tries to convince everyone that AI is a dead-end, not worth it, a total disaster. By doing so, he hopes to prolong the stream of existing profits maybe just for one extra day, but internally he already knowns that his company is toast.
This is a psychological phenomenon going on right now in the world around AI: gaslight your competitors into doubt and disbelief, then win.
I presume that there were similar movements during 1950-1980s who tried to gaslight the publics against using computers while using the computers to gain a competitive advantage over them.
LLM writes a better ASM then a C compiler? From running the demo in the browser, it seems so performance-wise and size-wise, but the ultimate test should be performed on a real hardware that I have no direct access to.
Anyone can validate the performance on a real PC of the era? If it's confirmed, LLMs may be one of the ways of creating highly optimizing compilers in the future.
I was curious about this and had a look. The code doesn't look much better than what a good C compiler might produce, and I found quite a few opportunities to optimize. It doesn't look much at all like the 8088 code I wrote when I was a teen. Among other things, so much pushing and popping.
Take the irow loop in vga12.inc[1] (of course I'm going to look at the graphics code). Each iteration does push di; rep stosb; pop di; add di, ROW_BYTES (and some other stuff). Why not save the push/pop and add (ROW_BYTES - count), which could be stored in a register (dx is free here)? Just the push+pop is 15+12 cycles.
True, that piece can be optimized better, but quality of the assembly code in general is not far away from what I had been writing in 1993-96. Back then, push/pops in function prologues/epilogues were a sign of experienced assembly programmer who avoided register clobbering by using standard calling conventions.
I've built custom exotic architectures in Verilog with their own bespoke ISAs and weird assembler and found LLMs entirely competent at writing for them, and even building compilers to target it.
Yes, just like early optimising compilers eventually got their heuristics.
Many still haven't understood that dynamic compilers, and machine learning based optimisations are equally not deterministic, which is why benchmarks are hard to implement properly.
Hell, the internal complexities of scheduling/branch-prediction etc inside the processor may strictly be defined as "deterministic" but in reality cannot be fully kept in the head of a software engineer at this point, too.
It's been a long time since I've worked on a machine I could describe as "understandable."
Aside: One of the niceties of using agentic LLMs to do optimization work is letting them do the drudgery of creating a pile of microbenchmarks for different scenarios (scalar popcount on a this-shaped vector, or SIMD on another? which wins? sometimes the answer is surprising!). I've built all sorts of bespoke tools / harnesses for forcing them to evaluate their findings empirically, and it's amazing what can be done that would take me weeks by hand.
While she has some experience, she well may be a total outsider for the assigned role. This is often the case in Satya's Microsoft. Spontaneous program managers from that special village somewhere in the world (nepotism) who have near zero prior participation in the industry (incompetency).
This would be a super pragmatic approach for a modern compiler suite. This is the brilliant part of the whole idea.