✧✦Catherine✦✧Feb 1

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
Show thread✧✦Catherine✦✧Feb 1

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

Show thread✧✦Catherine✦✧Feb 1

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

Show threadYurii / Юра 🇺🇦Feb 1
@whitequark I wonder what is the use case?
I can imagine only security-related stuff like anti-cheats.
Show thread✧✦Catherine✦✧Feb 1
@iurii debuggers, JITs, crash reporters, allocators, and similar low-level users could all benefit from VirtualQuery-like API
Show threadYurii / Юра 🇺🇦Feb 1

@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.

Show thread✧✦Catherine✦✧Feb 1
@iurii what do you mean "beyond virtual memory"?
Show threadYurii / Юра 🇺🇦Feb 1
@whitequark I never cared about virtual vs physical memory relation.
Basically my process' address space is what it is.
Show thread✧✦Catherine✦✧
@iurii that is not what /proc/self/maps gives you
Feb 1 at 1:44pmWeb
Show threadYurii / Юра 🇺🇦Feb 1
@whitequark my bad. Off to read.
Show threadYurii / Юра 🇺🇦Feb 1

@whitequark I see now. But again, never had to encounter those.

It’s fascinating to watch Linux evolve.

On one hand, one may expect /proc/self just for coherency. On the other, in corporate development, I’m a proponent of not writing code until it’s actually required. If someone implements a linked list with `insert_before`, I’ll ask them to delete `insert_after` if it’s unused.

Linux seems to handle this naturally, by the absence of certain patches.

Show thread✧✦Catherine✦✧Feb 1

@iurii you still fail to understand the core of my complaint. it is not about the specifics of /proc/self/maps. it is rather about how little care and thought was put into the design of the system as a whole.

moreover, the Linux development process actively filters out people with better taste who could improve the design, both by exhaustion of having to deal with assholes (gregkh isn't much better than linus) and by virtue of "if everything around you is a pile of crap, there is little point in building something great"

Show threadrobrykFeb 1
@whitequark @iurii See also the ` (deleted)` suffix in iirc maps and in symlink targets in /proc/PID/fd/ (what if I actually have a file that a name that ends like that?)
Show thread✧✦Catherine✦✧Feb 1
@robryk @iurii you can also put a newline into it to completely fake entries! (they might have fixed that specific one, but it is absurd that it is a problem in first place)
Show threadrobrykFeb 1
@whitequark @iurii Relatedly, a thing that surprised me a lot once is that symlinks in /proc are fake: if you open through them you can get totally different things than if you resolve the path they expand to (e.g. `root` or `exe` if that process is in a different mount namespace might be accessible, but its target path might be nonsensical).
Show threaduisFeb 5
@robryk @iurii @whitequark for Plan 9, which Linux took procfs from, it was sensible and probably even worked.
Show threadYurii / Юра 🇺🇦Feb 1

@whitequark I understand the complaint, I was just cautious to frame it that way.

if you view Linux not as a coherent system but as a set of related patches, it makes more sense, but yeah... When I was trying to understand how TCP/IP stack is implemented in Linux, I was reading BSD code, because "look we apply this flag just to make socket handler look like a file's one because unrelated code crashes"

I'm still fascinated by the lengths that Linux has made always being like this.

Show threadYurii / Юра 🇺🇦Feb 1

@whitequark to me, it is a mystery why BSD is decaying, and Linux is thriving.

Judging by the readability of code only, it should be vise versa. Knowing a bit about maintaining OSS project makes me think sometimes that being an asshole is a hard requirement, I don't know.