✧✦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 threadDavid Chisnall (*Now with 50% more sarcasm!*)

@whitequark

This one of the things that keeps me on FreeBSD. Linux decided to put most of the things that the BSDs put in sysctls in filesystems and make them human readable. The equivalents on the BSDs are usually structured data from a sysctl.

About 20 years ago, I wrote some code for showing machine info in a desktop environment’s about box. On FreeBSD, NetBSD, OpenBSD, and Solaris, the information was exposed as sysctls. They had different names, but it was trivial to write a little wrapper where each platform told you the sysctls to use.

On Linux, the info was in /proc/cpuinfo. The structure of this changed between releases and also between architectures on the same kernel version. The code for Linux was more than all of the other three platforms, combined, and that code was just to interface with a 300 KiB library that included a parser that worked on all of the different versions.

It makes me sad that so many people’s first experience with a F/OSS kernel is with a design that bad.

Feb 1 at 12:07pmWeb
Show threadRichard BarrellFeb 1
@david_chisnall am I remembering this correctly please? As far as I remember one of the other nice things about bsd sysctls is that you can use a lot of them from shell scripts and a sh prompt too because the sysctl userland program can convert them all to and from text too?
Show threadDavid Chisnall (*Now with 50% more sarcasm!*)Feb 1

@0x2ba22e11

Yes, they advertise the type, so the sysctl program can provide the value, the type, and a human-readable description. Some of the structured ones can”t (yet) be exposed nicely as structures (it would be nice if the sysctl tool could emit them as JSON or something).

Show threadLisPiFeb 3
@david_chisnall @whitequark Linux really should've just made them sysctls and then added a virtual filesystem interface to do the Plan9 thing (for those who care to have it).
Show threadAdrian Chadd <verified.png>Feb 7

@david_chisnall @whitequark right, but it should all be behind a library at this point so i don't have to care about the sysctl details.

also, just as a side note - parsing /proc/cpuinfo vs sysctl dev.cpu is an interesting example of "which scales poorly with increasing number of CPUs", and it . turns out /proc/cpuinfo ends up being pretty good in that respect :(

So, I do prefer the structured data way, but honest to god i wish we had libraries for this stuff and people didn't hand roll it all

Show threadDavid Chisnall (*Now with 50% more sarcasm!*)Feb 7

@erikarn @whitequark

At least for my use case, the code required to call the library was more than the code required to read the sysctls directly. And the sysctl code was shared across four platforms (only the names of the sysctls differed). I don’t see a value in an abstraction layer if the abstraction layer is more complex than the thing it abstracts over needs to be.

Show threadAdrian Chadd <verified.png>Feb 7

@david_chisnall @whitequark because then the sysctl interface across four operating systems - that isn't defined in any standard - is the thing that you're hoping doesn't change.

in your case, for a simple tool, yeah. I'm porting another tool that implements /proc/cpuinfo parsing and i really wish we just had a library that abstracted this stuff out for all OSes and actually /that/ was standardised.

Note - one of my systems has 160 CPUs. sysctl iteration takes TIME there.