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)?
My internal dialog was impacted, not just external.
To get retrospectively nerdy, it felt like switching from a raw text based lookup system to a knowledge graph / vector search.
Instead of accessing memories / concepts at a raw text level, I was pulling up lots of metadata and making links to these fusiform concepts that it was invoking. I would then try to find the words to describe what the links were conveying.
That’s fascinating. I know there are a few different kinds of “thinkers” out there. Conceptual, visual, language. I wonder if temporarily devolving language center capability would change someone’s thinking model
1998! Almost 30 years later, we're living in a Third Culture world. Look at Tesla door handles, addictive consumption apps, Flock cameras, LLMs... the consequences of elevating the incurious, impatient, and output-obsessed.
Yes. We can decide not to do bad things. Globally. Occasionally, it takes some time to figure out if something is bad. Especially when there's money to be made. But when we do, we can and have stopped doing them.
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.
Instead of post-processing the binary to add the application (non-SELF) schema, you could run database migrations before servicing requests. Thus, every time you start the process, the app creates and/or upgrades its own schema.
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. :-)
It's frequently done in research and industry when there's a component that has strict timing and separation requirements, and a bunch of supporting software that doesn't.
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.
I think a scheme as simple as running two Linux VMs, where you have isolated the services that have real-time guarantees into their own VM, lets you benefit from seL4.
This is tangential to your comment, but it's worth mentioning that you can often begin securing a (Linux) system with seL4 by putting the entire system into a VM. Then, you iteratively port components to run "natively" over seL4 -- a process called "cyber retrofit" [0, 1].
BTW, it was probably just a typo but I believe "se" in seL4 is not a shortening of "secure", but an initialism for "secure embedded". Which is why it's not "secL4".
A system with two seL4 tasks, (1) a flight control system, and (2) a VMM running Linux, uses seL4's formally proven safety properties to meet the timing and separation requirements of the critical flight control system... and run a bunch of less critical stuff on Linux that no one wants to rewrite.
(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.)
It's not just a matter of people taking the phrase literally:
- 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.
Heh. In the future I imagine, this would be embarrassingly redundant. "Thou shalt not make a machine in the likeness of a human mind."
reply