> Why JSON?

> JSON is nicely extensible and widely used. In particular it’s easy to synthesize and process with numerous programming languages. It’s particularly popular in the web communities, which hopefully should make it easy to link user credential data from the web and from local systems more closely together.

Was this written by a CSI or NCIS screenwriter?

Is a closer coupling between ‘the Web’ and local systems (especially concerning login and personal id) really what anyone needs?

I don’t even think it’s what anyone really wants, but sure, let’s find a way to make some random server located somewhere run by some SaaS be responsible for negotiating rights to access our own hardware.

It may not be the only way to access things, and I don't think the systemd maintainers will argue with you over the importance of single-box authentication robustness, only that compatibility is worthwhile and among the arbitrary formats there is a clear winner.

Why would anyone want to do such a thing? This sounds like an anti-feature (non-goal?) to me.

JSON and YAML do not belong in *nix config files.

What else will systemd do next? Audio? Kernel functions? Send mail? Read news? Become a web browser?

So I figure it will no later then 2023 before RedHat becomes IBM...

It gives you lots of niceties when you editing a file by hand and then you can just output a JSON object if you're generating the config with code.

It's my favorite thing ever to do something like:

    - name: Configure $service.
      copy:
        dest: /path/to/config.yml
        content: >-
        ---
        {{ config_obj | to_nice_json }}

[1] https://www.arp242.net/yaml-config.html

YAML's super clever upgrading of strings into other types is irritating ("foo: yes" is type {foo boolean}). Indentation-based semantics are not for everyone, and I think most of us would not mind the "noise" of braces. Other than that it's pretty OK. It's easy to write code that reads and writes it. It's very easy to read. It's above average but not prefect for writing (again, braces are pretty okay, not sure why they went the indentation route).

I agree with the article you linked that a lot of YAML implementations in scripting languages do dumb things like letting you put code in the file, and they all parse their special features differently. A config format does not need to be portable; while all these implementations do different things, they follow a format that continues to allow something to parse the entire file. So you can write an auto-formatter in Javascript (prettier) even though a Go program (kubectl) is going to actually read the file, and it all works.

I have used many other formats for config files. They all suffer from their fair share of problems. TOML/INI handles nesting very poorly (making you retype the names of all parent keys). JSON doesn't let you write comments or trailing commas, so it's hard to work on in your editor (running prettier on save fixes the trailing commas though). Text protobuffers are great but people look at you weird when you use them.

XML is a travesty. It is hard to write and hard to parse. It does all sorts of confusing things that humans do not expect, so it's really more of a binary format for computers to use than a text format for humans to write. (Remember, the XML spec says:

    <foo>
       bar
    </foo>

XPath querying is great, I love it. But we have "jq" now that works on JSON and YAML.

Anyway, I think YAML is basically a fine format for config files. Perfect? Nope. OK? Yup. I will happily read or write a YAML file in a computer program or by hand. It's pretty OK.

This is because JSON is not a configuration format but a machine-to-machine data exchange format. Using it for configurations is using it for something it was not designed to do.

And comments were left out of JSON on purpose:

> Comments were purposefully excluded from JSON. In 2012, Douglas Crockford described his design decision thus: "I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability." [27]

* https://en.wikipedia.org/wiki/JSON#Data_portability_issues

This is where you lose me. AFAICT, no two YAML parsers agree on what YAML is, so it's actually very hard to write code that reads and writes YAML because it has to be carefully tailored to work with whatever other YAML parsers are in your toolchain.

    {
        ...
        "comment": "this is a comment",
        ...
    }

Surely "#__comment__!11!!1#" would reduce the confusion !

  grep -Pv '^\s*#'

Good thing JSON doesn't permit literal newlines in strings. Any valid JSON should be able to go through that comment filter without getting modified.

Sure. I wouldn't even try.

> And if you don't have that, you have a config file which can only be read, not written.

Just like most config files.

> And if you accept that, then what was the point of using JSON in the first place?

To not define your own format and be able to use ready-made parsers.

It's not like I'm advocating for the use of JSON over other choices like YAML. I'm just replying to a comment about how to add comments to a JSON with a better alternative. If someone wants to use JSON over other choices for whatever reason and the only thing holding them back is the lack of comments, then this is a valid way to add comments, I believe.

If you use a string property, you can't split your comment among multiple lines. You could perhaps do an array of strings or something, but I think adding a simple commenting syntax like this is neater.

EDIT: Fixed double negative in penultimate paragraph.