HN Explorer

22 comments

[ 3.8 ms ] story [ 58.1 ms ] thread
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.

oblio
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

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)
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.
Flow
I like toml files. 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

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/ ). 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.)

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.

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.

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