4,380 karma · joined June 8, 2010
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.)
(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.
(and AMD is still serious challenging Intel in x86 and GPUs today)