4 ms·

I have a deep distrust of hierarchies, because they keep you trapped into a single model that keeps extending its authority, usuall without anyone explicitly de

I have a deep distrust of hierarchies, because they keep you trapped into a single model that keeps extending its authority, usuall without anyone explicitly deciding that it should do so. For example, the file system: once it was deemed hierarchy is the main metaphor for navigation, the structure persisted and was reused for organisation, ownership, access control and governance. And it became infrastructure we cannot easily remove before we could even question if it was right or not. And once it dominated, non-hierarchical things were retrofitted as glue, e.g.: symlinks, aliases, shortcuts... also, when's the last time you've used a tag? The webs are so much more malleable, but they're also not free. All the 'good enough's you were that a hierarchy that was taking care of implicitly are now your responsibility to model precisely and make sure they're performant as well. Look at ReBAC, for example. It gives you expressive power, but it also forces you to reason precisely about relationships, graph traversal, consistency, and cost. Strikingly similar is GraphQL. Interestingly, source code is hierarchical, but compiles almost immediately to a graph IR and most analysis and optimisations happen there. But almost nobody looks at a CFG/SSA graph directly. You author in a hierarchical manner, yet the operational substrate is a malleable graph.

speed_spread 5mo ago
IMO hard links are underused in filesystems. You can have the same file / dir appear in different places under different names. Once linked, app doesn't have to care and runtime cost is zero.
- PhilipRoman 5mo ago
  Hard links suffer from the general issue of there being two styles of writing to a file - open(2)/write(2) vs rename(2). Depending on the internals of each program you use to update the file, you will get very different results. This is one of the ugliest parts of POSIX design, making idioms like -o /dev/null and file attributes unpredictable (I've had a server run out of disk space because a root-owned process used rename-style writing on /dev/null)
  - lstodd 5mo ago
    That was breakdown on a different level: your server process had no business of renaming stuff and it still did that. POSIX had nothing to do with this.
    - jmalicki 5mo ago
      It's the fundamental idiom of how to do atomic file replacement. The sever process had better be doing that over editing a text file in a way that could leave it invalid if the process OOMs mid edit, or another process is reading it while it's being written.
    - PhilipRoman 5mo ago
      I'd agree if POSIX provided something like an open() flag which made the changes visible atomically, but as it stands, the rename() idiom is the mainstream way of durable file writing, so it is commonly used. Practical example using busybox sed: (GNU sed detects this case and refuses to overwrite) / # stat /dev/null File: /dev/null Size: 0 Blocks: 0 IO Block: 4096 character special file ... / # sed -i 's/foo/bar/' /dev/null / # stat /dev/null File: /dev/null Size: 0 Blocks: 0 IO Block: 4096 regular empty file ...
delusional 5mo ago
> before we could even question if it was right or not But we could. Early filesystems didn't have heirachy. They'd sometimes support a single level of organization by treating a prefix of the filename as directory, but nothing below that. We looked at that and considered heirarchy better. What you lament is that we stopped with heirarchy. You wish for something more general, and that you have received. With hardlinks and ACL the filesystem is freed from its shackles of heirarchy. Most people don't need that most of the the time. The strict heirarchy sits as the third step of a complexity ladder. The reason we stopped there, in most cases, is that it's enough complexity.
- gobdovan 5mo ago
  You're overfitting on the filesystem example. My point is model lock-in. Once a system commits to one hierarchy, it becomes very hard to introduce another authoritative model. Not only you cannot have alternative models with equal authority, you do not even get a clean parallel hierarchy later; you get the first hierarchy, now ossified, plus workarounds around it. On the other hand, webs are harder to reason about and more expensive to operate, but they can produce hierarchies 'on-demand' and you can get rid of them as easily as you've established them. Ergo, a ton of different programming languages just compile to LLVM IR.
fellowniusmonk 5mo ago
Here is my take using the city as a metaphor. All physical things have to be arranged in a linear fashion, this is pauli exclusion principle writ large. A type of mereological nihilism is true, so hierarchy is real but in a weak emergence sense. When I am standing on a street corner in a city, I can walk into a building and then navigate into a room inside that building and pick up a piece of paper inside. Or I can walk down the street and as I pass landmarks, I will pass things in order, this is also a perceived hierarchy, because my starting position and movement are bound by time, I will always have a fixed order of experiences from any x,y coordinate. So everything bounded by time and space acts as an emergent hierarchy via movement for a specific loci. The paper can be moved however, and that same piece of paper sitting in the drawer at an attorneys office means something very different than when its sitting in the approved licenses cabinet in an offical government building. Semantic meaning is first class but its an entirely different dimension than other types of meaning and due to pointers it isn't bound by pauli exclusion. When people start thinking about the semantics of objects in computer programs they often become confused, because the semantic representation of the object follows semantic ontology laws not physical object ontology. People can fuck this up in either direction and think physical laws apply to semantic meaning or physical meaning applies to semantics.
- gobdovan 5mo ago
  Yeah, that's part of it. But I'd argue that once you look at a city, you look at constructions administratively designed by men, with their preference for hierarchies. Try to hierarchically describe to someone instructions to pick a random leaf in a dense tree (ironically, we use them as a metaphor for hierarchical organisation) and see how far you could go in the same way you could point them out to pick a paper in the city. Not in a position to argue about physics, but I could think of quite a few things that are better described as web-like phenomena rather than hierarchical ones, electricity in a complex circuit comes to mind.

speed_spread 5mo ago

IMO hard links are underused in filesystems. You can have the same file / dir appear in different places under different names. Once linked, app doesn't have to care and runtime cost is zero.

PhilipRoman 5mo ago
Hard links suffer from the general issue of there being two styles of writing to a file - open(2)/write(2) vs rename(2). Depending on the internals of each program you use to update the file, you will get very different results. This is one of the ugliest parts of POSIX design, making idioms like -o /dev/null and file attributes unpredictable (I've had a server run out of disk space because a root-owned process used rename-style writing on /dev/null)
- lstodd 5mo ago
  That was breakdown on a different level: your server process had no business of renaming stuff and it still did that. POSIX had nothing to do with this.
  - jmalicki 5mo ago
    It's the fundamental idiom of how to do atomic file replacement. The sever process had better be doing that over editing a text file in a way that could leave it invalid if the process OOMs mid edit, or another process is reading it while it's being written.
  - PhilipRoman 5mo ago
    I'd agree if POSIX provided something like an open() flag which made the changes visible atomically, but as it stands, the rename() idiom is the mainstream way of durable file writing, so it is commonly used. Practical example using busybox sed: (GNU sed detects this case and refuses to overwrite) / # stat /dev/null File: /dev/null Size: 0 Blocks: 0 IO Block: 4096 character special file ... / # sed -i 's/foo/bar/' /dev/null / # stat /dev/null File: /dev/null Size: 0 Blocks: 0 IO Block: 4096 regular empty file ...

delusional 5mo ago

> before we could even question if it was right or not But we could. Early filesystems didn't have heirachy. They'd sometimes support a single level of organization by treating a prefix of the filename as directory, but nothing below that. We looked at that and considered heirarchy better. What you lament is that we stopped with heirarchy. You wish for something more general, and that you have received. With hardlinks and ACL the filesystem is freed from its shackles of heirarchy. Most people don't need that most of the the time. The strict heirarchy sits as the third step of a complexity ladder. The reason we stopped there, in most cases, is that it's enough complexity.

gobdovan 5mo ago
You're overfitting on the filesystem example. My point is model lock-in. Once a system commits to one hierarchy, it becomes very hard to introduce another authoritative model. Not only you cannot have alternative models with equal authority, you do not even get a clean parallel hierarchy later; you get the first hierarchy, now ossified, plus workarounds around it. On the other hand, webs are harder to reason about and more expensive to operate, but they can produce hierarchies 'on-demand' and you can get rid of them as easily as you've established them. Ergo, a ton of different programming languages just compile to LLVM IR.

fellowniusmonk 5mo ago

Here is my take using the city as a metaphor. All physical things have to be arranged in a linear fashion, this is pauli exclusion principle writ large. A type of mereological nihilism is true, so hierarchy is real but in a weak emergence sense. When I am standing on a street corner in a city, I can walk into a building and then navigate into a room inside that building and pick up a piece of paper inside. Or I can walk down the street and as I pass landmarks, I will pass things in order, this is also a perceived hierarchy, because my starting position and movement are bound by time, I will always have a fixed order of experiences from any x,y coordinate. So everything bounded by time and space acts as an emergent hierarchy via movement for a specific loci. The paper can be moved however, and that same piece of paper sitting in the drawer at an attorneys office means something very different than when its sitting in the approved licenses cabinet in an offical government building. Semantic meaning is first class but its an entirely different dimension than other types of meaning and due to pointers it isn't bound by pauli exclusion. When people start thinking about the semantics of objects in computer programs they often become confused, because the semantic representation of the object follows semantic ontology laws not physical object ontology. People can fuck this up in either direction and think physical laws apply to semantic meaning or physical meaning applies to semantics.

gobdovan 5mo ago
Yeah, that's part of it. But I'd argue that once you look at a city, you look at constructions administratively designed by men, with their preference for hierarchies. Try to hierarchically describe to someone instructions to pick a random leaf in a dense tree (ironically, we use them as a metaphor for hierarchical organisation) and see how far you could go in the same way you could point them out to pick a paper in the city. Not in a position to argue about physics, but I could think of quite a few things that are better described as web-like phenomena rather than hierarchical ones, electricity in a complex circuit comes to mind.