✧✦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 threadMyrrh PeriwinkleFeb 2
@whitequark It does now: https://docs.kernel.org/filesystems/proc.html
"Starting with 6.11 kernel, /proc/PID/maps provides an alternative ioctl()-based API that gives ability to flexibly and efficiently query and filter individual VMAs. This interface is binary and is meant for more efficient and easy programmatic use. struct procmap_query, defined in linux/fs.h UAPI header, serves as an input/output argument to the PROCMAP_QUERY ioctl() command."
The /proc Filesystem — The Linux Kernel documentation

Show threadschuelermineFeb 3
@myrrhperiwinkle @whitequark you still need to actually have a /proc fs mounted for this unfortunately
Show threaduis
@anselmschueler @myrrhperiwinkle @whitequark So?
Feb 5 at 2:03amWeb
Show threadschuelermineFeb 5
@uis @myrrhperiwinkle @whitequark That's obviously still a very silly requirement for an API. You need to rely on something other than the kernel for this basic property of your process. Unless you make your own mount, which I'm not sure whether you can in some way without effective root. Even if you make your own mount, it's a hideously complicated sequence compared to just having a syscall for this, especially if you rigorously use O_PATH etc. to avoid TOCTOU. The path is effectively a magic number (a magic string) which is just inelegant.
Show threaduisFeb 5
@anselmschueler @myrrhperiwinkle @whitequark > You need to rely on something other than the kernel for this basic property of your process.
Then I have good news for you: procfs is a pseudo-filesystem implemented in your kernel.
> Unless you make your own mount, which I'm not sure whether you can in some way without effective root.
Namespaces, but in case of procfs requiring root is a good idea(see mount options, that give more isolation).
> Even if you make your own mount, it's a hideously complicated sequence compared to just having a syscall for this, especially if you rigorously use O_PATH etc. to avoid TOCTOU. The path is effectively a magic number (a magic string) which is just inelegant.
System call numbers are also magic numbers in that sense. If syscall numbers could be rebound, we would be in exactly same situation regardless of mapping in VFS.