Rethinking fsinfo()

The worst thing about the text formats is that they are brittle. They're prone to failure when some unexpected character sneaks in, to ad-hoc implementations that are based on a programmer looking at 'cat /proc/whatever' and writing whatever comes to mind ("oh, so this is a list with one entry per line, with elements separated by spaces") and to being inflexible for expansion (can you add anything to /proc/partitions and not break a lot of stuff?)

The second worst is that different philosophies are being followed.

/proc/swaps might as well be the output of a command like 'df'

/proc/meminfo is half-written for human consumption, with amounts in kB and aligned columns, and half written for machine consumption with obscure labels like "Committed_AS".

/proc/mounts is very machine oriented.

Some files explicitly tell you the units (and it can be unclear whether another unit could ever be used). Some files have column names. Some like /proc/ioports have meaningful identation.

Many are uncomfortable for machine parsing. Eg, in /proc/cpuinfo you get "address sizes : 39 bits physical, 48 bits virtual". -- you have to parse that comma, and it's unclear whether a third thing could ever be there. Many files are lacking in unique identifiers, eg, my /proc/ioports has 3 levels of "0000-0000 : pnp 00:00", one under another.

I'm amazed that the computing industry is pretty old by now, we have plentiful RAM, storage and CPU power, and the issues of escaping data, representing arrays and trees, and allowing for adding extra info without breaking existing software are still with us, despite there being things like JSON that solve the vast majority of them.