1. 6
  1.  

  2. 6

    Among the items being explored by systemd-homed are JSON-based user records

    oh god no

    1. 5

      I’m looking forward to the discussions of whether systemd represents a use of JSON for good, or evil.

      1. 8

        Evil, obviously. Fortunately (?), they’re not going to use json.org’s parser; they’ll implement their own, with a bunch of brand-new never-before-seen security vulnerabilities.

        1. 1

          For good.

        2. 4

          You like the GECOS field?

          1. 9

            Surely we can agree there is design space worth exploring between “the first thing the Unix devs originally hacked together in ’69” and “arbitrarily-structured unschema-ed generic serialization format with poor human readability and writability which is difficult to manipulate with plain-text tools and has few affordances for streaming reads”.

            1. 3

              How often are you editing /etc/passwd and friends “raw”? I just checked my VPS, there’s 35 lines, of which one is my user (that was added when I set up this instance). The rest have been added programmatically by apt and friends.

              When I actually did have to add stuff (on *BSD) I used vipw to prevent me from messing up a field.

              I suspect most files for user directories etc are generated programmatically (via puppet etc) anyway. Why does the file have to be easy to handle in a text editor?

              1. 3

                Well, if it doesn’t need to be human editable, why use JSON? It’s purest madness.

                1. 2

                  Because, in contrast to a binary format, you can fix it with vi in case it is really necessary.

                  JSON is not my favorite text-based data format, but switching to something that is more structured that is still human readable, but also machine-modifiable sounds like a great idea. If it really needs to be JSON, I can live with it.

                  Anyway, this borders on bike shedding, we are discussing JSON vs. TOML vs. GECOS, rather than the main ideas proposed in the presentation: decoupling user information from /etc, making home directories portable, better per-user home directory encryption, etc.

                  1. 1

                    It’s purest madness.

                    I don’t agree, but I’m open for suggestions for other formats.

                    The entire idea is so much more than just “JSON for config” - there’s all sorts of stuff to make using a Linux computer better for (mostly) laptop users.

                    1. 2

                      Yeah, I push back against JSON, not the systemd stuff in the large – it doesn’t cause me much heartache, because I only have one Linux computer in my life, and I hate hate hate hate traditional SysV or BSD init garbage.

            2. 6

              I don’t see the problem? JSON is reasonably okay and widely implemented, which makes it a good choice for something that may be manipulated by multiple parties.

              1. 5

                Until jq becomes part of coreutils, newline-separated records have much better shell support. I haven’t looked into the kind of manipulation that will be done to these user records, though.

                1. 1

                  I’d assume/hope that’s mostly privileged to the system itself and maybe moderated through the daemon.

                  On coreutils, I have not enough insight and you are probably right, but on the other hand find the coreutils path becoming antique.

                2. 4

                  It doesn’t support comments. TOML or one of the JSON variants would be more appropriate.

                  1. 4

                    There’s a json fork called “hjson” (https://hjson.org/), which adds comment feature for json (among other small things), and it can be used for configuration files, but I doubt that it would be used by the systemd team.

                    Also I think TOML is pretty nice; trivial use makes it similar to .ini files, which systemd already uses, but at the same time it supports more complicated config structure.

                    1. 2

                      TBH I think that all systemd service files should be moved to the TOML as it is more standardised and IMHO cleaner than their custom format.

                  2. 2

                    I think it’s a bit surprising that they would some existing format; I assumed that the systemd devs would invent their own format.

                  3. 5

                    heck, what’s going on with young programmers today? Is there anything wrong with plain text files?

                    1. 11

                      we like data structures without having to write our own ad-hoc parser

                      1. 3

                        Well, does “plain text” include UTF-8?

                        1. 5

                          Yes, it does. But you do not need json to encode utf8 strings.

                          1. 2

                            The JSON spec states that the payload should be in UTF-8.

                            Edit I see what you mean now. Thanks for clarifying and thanks to @tentacloids for pointing it out for me even clearer.

                            1. 3

                              I think this is a misunderstanding: @coco is saying you can use utf8 without involving JSON, not that JSON works with other encodings.

                          2. 1

                            With punycode, yes, yes it does

                            1. 2

                              Why the heck would you want to use punycode for this? Most ascii-centric algorithms, like Linux path parsing, work fine on valid UTF-8. And the underlying storage system is 8-bit clean. As long as you define the encoding, it shouldn’t be a problem.

                              1. 1

                                Yeah, I really like my delicious shrimp sandwich[1] to be rendered as “xn–rksmrgs-5wao1o”.

                                And that adds a dependency to a punycode parser to your simple plain text format.

                                [1] Räksmörgås

                                1. 1

                                  It potentially adds a dependency to a punycode parser to your regular pipeline; it can be ignored in cases where you’re not looking for UTF-8 characters in the body of text.

                                  1. 1

                                    In the context of a file describing a home directory you certainly do need to accommodate Unicode - unless you want to forever restrict usernames and directories to only ASCII.

                                    I’m not saying JSON is the ideal format, just that alternatives cannot be restricted to ASCII.

                        2. 2

                          The claim that SystemD is just a better init replacement contains at least two lies.

                          This is a good example of that. I look forward to SystemD replacing the Linux kernel, at which point we can simply ignore it as a part of GNU/Linux.

                          1. 2

                            The claim that SystemD is just a better init replacement contains at least two lies.

                            The systemd project hasn’t claimed to be just an init replacement since 2014:

                            https://cgit.freedesktop.org/wiki/www/commit/Software/systemd.mdwn?id=47a25ac6194c8c15d7546ff163eb7cd8803c4996

                            1. 1

                              I know that markdown ignores newlines when translating to HTML, but it doesn’t mean you shouldn’t use any right?

                              Or maybe I’ve been writing paragraphs wrong this whole time?

                              1. 2

                                It really depends on your tooling. Personally, I have word wrapping on in vim and typically use newlines to separate ideas (typically one sentence = one idea) so that the git log is clearer.

                                A colleague only uses newlines for paragraph breaks.

                                I’m very much of the opinion that I should prepare my text in a way that makes sense to me and my collaborators, not to some hypothetical person who can’t configure their text editor in a sensible way.