Systemd/systemd – shared: add minimal JSON tokenizer | Hacker News Reader

Systemd/systemd – shared: add minimal JSON tokenizer

cgit.freedesktop.org

11 pointslelf22 comments

For those who wonder, it's a dependency needed for the userspace parts that import docker images into "native" systemd-nspawn containers.

It's not actually used in pid 1, but in the userspace tooling.

As much as I dislike systemd, to use a standard format like JSON for config files looks like a really good idea.

I would however prefer if it used a lenient superset (allowing comments and trailing commas in lists, maybe also unquoted keys). Something like JSON5 ( http://json5.org/ ). The requirements for config files and for a wire-format are different (easily human-writable vs. strict standard).

Also, this is really, really something that would be better placed in a library. (If you don't want to avoid dynamic dependencies, then make it a source library or link staticly.)

I like toml files. https://github.com/toml-lang/toml

Looks good. I was just about to post how I think JSON is crappy as a config format and how I really liked INI. TOML seems to be very INI-like. Any software actually using it?

Anyone know any other config file targeted formats? I'm not keen on YAML for config. There's libconfig (and assoc. format), but, imho, it's a bit complex

Rust's package system, Cargo, uses it. See http://doc.crates.io/guide.html for an example.

Json. Seriously. In a replacement for init. And syslog. And ifconfig. Which already parses and understands XML. And other config files. And so on.

Why am I not surprised?

I give up.

Hmmm, just browsing the diff and spotted something odd to me : is that pretty typical code style to write: for (;;) ? Why not while (true)?

It is (for plain C). For while (true) you'd need <stdbool.h>. As for “for (;;)” vs “while (1)” I'd say the former is still more common.

diff --git a/src/shared/xml.h b/src/shared/xml.h to weed out the less than <C99 compilers? heh

And so it begins...

A system configuration tool needs to parse configuration files in a modern format? Shocking.

The Only True Unix way is to invent an ad hoc configuration format with arbitrary rules about line breaks, tabulators and separator characters, incomplete Unicode support and confusing issues around whitespace escaping.

Don't forget that the config format should also evolve until it is Turing complete, creating a crappy scripting language, instead of:

a) separating configuration values from code

b) embedding an established interpreter

The problem here is that Poettering ignored the numerous other small json libraries, like json-c, which is 69k compiled as a static library, and jansson, which is 89k as a static library, and built his own. Which means there's yet one more library out there to test against to make sure one's own stuff works without problem. This is developer bravado with no real benefit.

What are you talking about? JSON is a standard -- it doesn't matter which implementation you use as long as it conforms. (Indeed, that is the point of JSON.)

Of course being written in C, this implementation isn't likely to be able to handle arbitrary-precision numbers, but then neither do jansson nor json-c AFAIK.

He is very clear about Poettering's NIH syndrome. There are many established c libraries out there but he feels he needs to implement everything himself.

No, the systemd people probably just wanted to avoid an dependency that they don't control.

That is exactly nih syndrom told in another way.

No. There are many very valid reasons to want to avoid 3rd party dependencies.

(I am trying to be sincere here please don't take it any other way)

Could you please tell me few reasons against code reuse?

And as a bonus; a reasonable case for reimplementing everything in systemd ecosystem would be very appreciated.

Have you ever run a big C or C++ project? Dependencies in these languages are not a good thing -- especially if it's for such a trivial thing as JSON parsing. (If you want more, I'll be happy unless you're just being facetious. In which case, see below.)

> And as a bonus; a reasonable case for reimplementing everything in systemd ecosystem would be very appreciated.

Oh, fuck off.

EDIT: What I meant to say in that last sentence is: I realize that I could have been more upfront about what the tradeoffs are, but if you're just going to spew bullshit like "NIH!" over and over without anything to back it up, then I don't care to engage in a serious discussion with you. Indeed, I think it might not be possible to engage in a serious disccusion with you. Hence, "fuck off".

I did not run any big c/c++ projects but, I ran, big php/python web projects. Dependencies in these kinds of web projects are messier than desktop/system applications. And it is not unmaintable as you are implying. So reimplementing instead of depending on maintained projects with its own teams is getting that burden to yourself. Also you can put hard dependencies with version requirements.

We may look into big c/c++ projects like Firefox, blender, chrome and many others and we can see that dependencies are really managable and maintable.

But yet again you may argue that using reimplementation of a json parser in a code base is simpler. It's personal choice and I belive it is not a good engineering practice.

Still there is no good case for imlementation of any subsytem of linux in systemd.

Also systemd is very dependent on many other libraries (optional or mandatory). Adding json as an internal implementation instead of using an outer dependency is not justifiable with "dependency control reasons".

From the readme: glibc >= 2.14 libcap libmount >= 2.20 (from util-linux) libseccomp >= 1.0.0 (optional) libblkid >= 2.24 (from util-linux) (optional) libkmod >= 15 (optional) PAM >= 1.1.2 (optional) libcryptsetup (optional) libaudit (optional) libacl (optional) libselinux (optional) liblzma (optional) liblz4 >= 119 (optional) libgcrypt (optional) libqrencode (optional) libmicrohttpd (optional) libpython (optional) libidn (optional) gobject-introspection > 1.40.0 (optional) elfutils >= 158 (optional) make, gcc, and similar tools During runtime, you need the following additional dependencies:

        util-linux >= v2.25 required
        dbus >= 1.4.0 (strictly speaking optional, but recommended)
        dracut (optional)
        PolicyKit (optional)

        When building from git, you need the following additional
        dependencies:

        docbook-xsl
        xsltproc
        automake
        autoconf
        libtool
        intltool
        gperf
        gtkdocize (optional)
        python (optional)
        python-lxml (optional, but required to build the indices)
        sphinx (optional)

Reply on news.ycombinator.com