
Systemd/systemd – shared: add minimal JSON tokenizer - lelf
http://cgit.freedesktop.org/systemd/systemd/commit/?id=e7eebcfc42f00aa481ef31abc8e7e243c16f5b2c
======
Spidler
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.

------
captainmuon
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/](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.)

------
Flow
I like toml files. [https://github.com/toml-
lang/toml](https://github.com/toml-lang/toml)

~~~
nly
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

~~~
Flow
Rust's package system, Cargo, uses it. See
[http://doc.crates.io/guide.html](http://doc.crates.io/guide.html) for an
example.

------
mondoshawan
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.

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

~~~
lelf
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.

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

------
unmole
And so it begins...

------
pavlov
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.

~~~
Sanddancer
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.

~~~
lomnakkus
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.

~~~
fsniper
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.

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

~~~
fsniper
That is exactly nih syndrom told in another way.

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

~~~
fsniper
(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.

~~~
lomnakkus
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".

~~~
fsniper
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.

~~~
fsniper
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)

