one thing that i really dislike about Unix is the zealous adherence to semi-accidental design elements that ends up interfering with the utility of the underlying useful principle

for example:

  • early Unix could not run too complex a program due to hardware restrictions, so programs were composed using text streams
  • useful underlying principle: designing your applications for composition
  • zealous interpretation: your OS should have a toolkit of single-purpose programs communicating over text streams
  • design we could have had, but never will: applications that communicate using structured data, simplifying life for both programmers and end users

there is also much to be said about splitting your application into many different pieces, but keeping a unified approach to application design so that the pieces may be understood via a unified mental model

i think some Unices (that i haven't really used enough to comment) do approach userspace design like this, but the GNU-plus-random-tools userspace you're much more likely to encounter definitely doesn't

why the actual fuck does Linux not have a syscall for /proc/self/maps

it is beyond ridiculous that the 2026 solution to "find out what my memory mappings are" is fucking fscanf

@whitequark I wonder what is the use case?
I can imagine only security-related stuff like anti-cheats.
@iurii debuggers, JITs, crash reporters, allocators, and similar low-level users could all benefit from VirtualQuery-like API

@whitequark Interesting. While working with JITs and allocators, I never looked beyond virtual memory, hence the question.

I'm not saying have the mapping is not useful, just pointing out that mileage may vary, so that may be the reason nobody has done it.

@iurii what do you mean "beyond virtual memory"?
@whitequark I never cared about virtual vs physical memory relation.
Basically my process' address space is what it is.
@iurii that is not what /proc/self/maps gives you
@whitequark my bad. Off to read.