Hacker News new | past | comments | ask | show | jobs | submit
BoppreH | on: AI is forcing us to pay off 40 years of technical debt
Another thing that has bothered me for a long time: we have far too many data isolation mechanisms, each with their own idiosyncrasies and trying to cover up for each other's gaps. Very very roughly, from source code up:

- Variable naming conventions (_field in Python).

- Lexical scopes.

- Visibility annotations (public, private, protected).

- Coroutines, threads.

- Packages/modules.

- Sandboxes.

- Processes.

- OS capabilities (pledge/unveil, SELinux, etc).

- Local user accounts.

- File permissions.

- Containers/chroot.

- User mode vs kernel (Ring 0 vs ring 3).

- Virtual machines.

- Cryptographic measures (secureboot, attestation, memory encryption, etc).

On the other hand we have few mechanisms to share data: the filesystem, clipboard, sockets, maybe dbus. Shared memory if you're feeling brave.

If a script wants to know what file is currently open on my editor or what email attachments I recently uploaded, the editor or email client has to explicitly implement this feature via one of those limited mechanisms. Almost nobody does this, so we're stuck with black box applications that are hostile to customization.

cjfd | parent
You have a point that there are a lot of separation mechanisms and that, if things were designed better, fewer would be needed but by the same argument it also seems unwise to increase the number of mechanisms to share data. Sockets by themselves are quite big enough on their own to quite literally drive the whole internet through.
BoppreH | root | parent
A socket is just a raw byte stream. It's a solid base layer, but you'll have to implement your own communication protocol on top, and it'll require copying the data from one process to another. A "stream" is the wrong metaphor for local data sharing.

The data is already in memory and the source program knows its "shape"; there should be an easy mechanism to provide access to that by default, like /proc or gdb but for arbitrary data structures and with better UI.

cjfd | root | parent | next
One idea would be that the data structures that a program uses declare if and how they want to be protected/accessed. E.g., access levels could be: only accessible in a local code block, only accessible in one thread, accessible by a limited number of threads, persistent or not between program runs, accessible over the network by certain machines/people, accessible to the whole world. A tree of all data in a program/computer could be exposed subjected to such access control. I would think that this does not even need to cost performance because 'only accessible in one thread' would not have to be implemented in a way that is different from current local/global variables.
| root | parent
{"deleted":true,"id":50367592,"parent":50366766,"time":1793808452,"type":"comment"}