OpenZFS 2.3-rc3 Adds JSON Output For Commonly Used Commands

[mb_q]

Those claims are not true. If your data doesn't contain characters outside the ascii domain, json output can be pure 7-bit ascii. Also there are schema systems built on top of json. E.g. if you define the schema in high level typed language you can derive the serialization / deserialization process. Json serialization also doesn't require a full library. You can build a special purpose json serialization for a cmd line tool with just printf and some juggling.

If I understand correctly, you want to put invalid UTF-8 in JSON string by escaping it? But this is not going to be a valid JSON. Some parsers will eat it, some won't, and some will do strange things. I know there are schema systems for JSON, the problem is that they are useless without an ecosystem, i.e., one Linux or POSIX standard providing one schema in a particular schema system for all system utils for follow -- otherwise you have to adapt the parser to the tool anyway, so there is no gain from the fact that the output is JSON.

[mb_q]

There are some people who would argue that that is quite a radical position, given the history of Unix, and the general habit of piping the output of one program into another for further processing.

Sure, I use coreutils and pipes all the time, but this is ad hoc processing, where you just want the answer for a particular case. I have a problem with using tools created for ad hoc work in systems where side cases matter, like elaborate management or monitoring tools, because it ends badly; consider autotools, a simple framework for using built-in tools to just install stuff: zero functional C but dozens of "compile this to ensure that gcc is gcc".

IMHO JSON is not helpful in ad hoc work, but encourages those dubious integrations.

[mobadboy]

one step closer to deprecating btrfs