jdub
Getting an LLM to use reverse compilation tools to interpret and map machine code (which is inefficient to process as language) into to something higher level (typically very ugly C code), then frobbing the bytes in the binary to alter a constant, change a condition, etc...? Yes, lots of people are doing this.
A larger model may be more capable at processing/interpreting neural network weights. A smaller model may be easier to process/interpret.
That doesn't preclude a smaller model having the resources to process/interpret a larger model (or subset thereof).
It's worth reflecting on the original domain jargon for selecting the next token: completion.
What the fuck do you think the DevOps movement was about?
You absolutely can, and we absolutely have. You believe this because anti-trust action was derided as anti-growth in the latter quarter of the 20th century, by people who knew exactly what they were doing (see also: banking deregulation).
It's one of the major reasons we're stuck with such horrendous corporate and individual wealth inequality today.
Google should never have been allowed to buy DoubleClick, ship a browser, or ship general-purpose client operating systems.
steady on, youngster
Complex topics are built on history, on those who came before us, on attempts and failures and successes. Ignoring it is garden variety stupid.
Perhaps a good thing to come out of these big companies over-indexing on "AI" is the liberation of creative minds. So many fantastic open source contributors have disappeared into corporate black holes...
Only a relatively small subset of tech enthusiasts want to tweak everything, and there are PLENTY of options for those people.
Heh. In the future I imagine, this would be embarrassingly redundant. "Thou shalt not make a machine in the likeness of a human mind."
To clarify "cognition outside of language" and "unable to convey"... did it purely affect external communication? Were you able to think "in language"? Do you tend to rely on thinking "in language" (whether inner monologue, describing problems like drafting prose, or otherwise)?
Then, when your senior developer is working on a new feature that requires some changes to adapt to a dependency upgrade, some refactoring, some forwards-and-backwards compatible database migrations, you'll appreciate a stack of discrete, clean, working, individually reviewable commits.
The SELF upgrade (heh, self upgrade) and rollback processes could benefit from some... fancier... footwork.
Your example has a new binary copying old data into it, but then you have to move the new binary to the deployed location. Which means an outage through stop service, data migration, replace file, start service.
What if the upgrade process was more like... write the new SELF data into the old binary, send SIGHUP, and then the service fork+execs itself, while doing haproxy-like zero downtime FD handover?
Replacing the SELF data in the existing file is safe right now, because you can't mmap segments into memory. But if you do end up figuring out some clever BLOB alignment mmap stuff, you could do the SELF upgrade like a data migration! INSERT segments/symbols, fork+exec, and the data migration cleans out the old code. :-D
Updating the SELF schema to allow multiple sets of segments and symbols would allow for this upgrade trick, but could do other fancy things... thin multi-arch binaries where only the code segments differ.
BLOB alignment should also mean more efficient static asset serving and a bunch of other niceties... definitely worthy of investigation.
However -- very strong however -- as fun as this is, I would never, ever, ever allow an internet-facing service binary to be self-writable. :-)
Like an autonomous helicopter. Flight control? Very important. A bunch of hardware drivers and services for imaging, navigation, comms... not so much, and not worth the (long term ongoing) effort of replatforming.
(Even with ELF, a kernel can have a relatively simple parser and loader and leave more challenging work to user space... like relocations, dynamic libraries, etc.)
- by a plain reading it's clearly singular; seeing beyond that requires at least some effort (e.g. curiosity, education... but also authority, responsibility, time)
- there are lots of people dealing with complex system failures that haven't been exposed to any of the relevant theory... tech folk, but also mgmt, comms (which can be more problematic)
- concluding with a single cause is frequently less work
- concluding with a single cause is frequently convenient (e.g. pinning the blame on a single vendor, component, person)
That's why it's helpful to introduce terminology that points everyone's brains in the right direction from the very start, e.g. contributing factors.
(also common sense isn't real)
(One could add a Hypervisor.framework backend to Firecracker, though I'd be surprised if AWS accepted it.)
So you get a Cambrian explosion of weird little projects. Ultimately, one of them will probably become the "market" leader... or at least the market default.
Right now there's a lot of agent harnesses and sandbox projects floating about.
Fun examples from the past: text editors, window managers, IRC clients, blogging engines (first static, then dynamic, then static again), Twitter clients... every programming language community has weird clusters of library/framework duplication in their history...
Sometimes these projects take on a rite of passage flavour... like, as every Jedi builds their own lightsaber, every developer builds their own... blog? That used to be the obvious one. Less so these days.