3 ms·

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.

by fsniper 12y ago

lomnakkus 12y ago
No, the systemd people probably just wanted to avoid an dependency that they don't control.
- fsniper 12y ago
  That is exactly nih syndrom told in another way.
  - lomnakkus 12y ago
    No. There are many very valid reasons to want to avoid 3rd party dependencies.
    - fsniper 12y ago
      (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 12y ago
        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 12y ago
        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 12y ago
        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)

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.

by fsniper 12y ago

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 12y ago

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

fsniper 12y ago
That is exactly nih syndrom told in another way.
- lomnakkus 12y ago
  No. There are many very valid reasons to want to avoid 3rd party dependencies.
  - fsniper 12y ago
    (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 12y ago
      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 12y ago
        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 12y ago
        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)