Hacker News Reader

Comment by Tecuane | Hacker News Reader

> Inside of the home directory a file ~/.identity contains the JSON formatted user record of the user. It follows the format defined in JSON User Records.

Why couldn't this have gone into ~/.config/? There's enough garbage cluttering my home directory.

View on HN

Also this:

Since the user record is cryptographically signed the user cannot make modifications to the file on their own (at least not without corrupting it, or knowing the private key used for signing the record).

That sounds like something that shouldn't even be in the user's own home directory.

...and JSON, of all things. Every aspect of systemd which I've worked with seems to be full of sprawling complexity and overengineering, and this is no exception. I know "it's not the UNIX philosophy" is a common dismissive complait about it, but looking at the design gives a very different feeling than the "original UNIX" designs, which felt humble and simple.

>...and JSON, of all things. Every aspect of systemd which I've worked with seems to be full of sprawling complexity and overengineering

boolean, number, string, array, object, null

Sounds simple to me.

Please tell me what you'll end up with if you encode and then decode the number 1E12 using two different JSON implementations. Check the spec, and then tell me if it's simple.

Does the JSON number type permit me to store the number 123,456,789,098,765,432,123,456,789,098,765,432,123? When I read it in with a parser, what integer value will my code see?

This is not an academic question: large integers are common, for example, as cryptographic keys.

>...and JSON, of all things.

Right? Reasoning was "the web people are using it too". Why not just use key value based config files like every other system tool?

Likely because, despite looking similar, those key/value and .ini style config files like every other system tool are actually hundreds of subtly incompatible or poorly specified formats. Unicode handling, whitespace handling, quoting, indentation, multi-line, line continuation, comments, non-string datatypes, lists, maps... you use YAML for human maintained and YAML or JSON for machine so people can use an off the shelf parser instead of implementing your particular key/value specification. Even TOML is better than rolling your own, since at least it has a common specification.

I once found a .cfg file. It had an incomprehensibly foreign configuration format that is specific to the file. A standardized config format like YAML or JSON has lots gotchas but you can learn them once and then know forever. With custom_format5345 you have the problems of poorly designed configuration formats (lots of gotchas, sometimes more than YAML) and the downsides of having to relearn the undocumented configuration format.

People just like to use whatever's trendy. If this was 2 decades ago, it would be XML files.

Making it JSON is just begging for users to think they can edit it. I hope they put a big banner disclaimer at the top at least. (Does JSON officially have comments yet?)

Json does not officially slow comments, and the hjson project is unmaintained.

JSON is so lacking, wish they went for JSON5. I know it's not wide spread but so is what they're doing.

Json is particularly poorly suited for data which will be digitally signed because it does not reliably round-trip. E.g. you read the data in with a parser and re-serialize the same data, the output you get will often not be bitwise identical to the input.

They are probably “normalizing” the data before checksumming.

My favourite example of this is JSON's treatment of numbers. There it literally no way to serialise a number without putting it in a string. I'm just waiting for the first security vulnerability caused by a JSON decoder not deserialising a large integer correctly.

I'm the kind of guy who goes through $HOME every once in a while and start looking for workarounds or filing bugs requesting XDG Base Directory spec support.

But in this case I can't complain. It's literally about the behavior of the home folder. This one makes complete sense to me.

> I'm the kind of guy who goes through $HOME every once in a while and start looking for workarounds or filing bugs requesting XDG Base Directory spec support.

I used to be that guy. Now I’m not. Re workarounds: usually that means env vars, but all that crap in env is copied to the execution environment of every single process, which is pretty awful. Re bug reports: usually only a few “that guy”s care at all, sometimes there’s endless debate about whether things go into XDG_DATA_HOME or XDG_CACHE_HOME, the occasional accepted PR requires so much effort I might as well just try to forget about all the garbage sitting in the $HOME.

I would suspect (though I'll admit without looking into it) that in order to know where $XDG_CONFIG_HOME is, one first has to load the user info. Bit of a chicken and the egg scenario.

This should be configurable through systemd config itself then. I'm also against adding any $HOME clutter.

I'm already moving stuff out of home root wherever I can. At least vim and zsh allows you to move stuff out.

Thinking out loud, there is no reason .identity needs to be in the root of your home directory. The .identity file contains arbitrary metadata, which could just as easily specify which subdirectory should be mounted as $HOME. You could also move your other $XDG_ directories like .config out of $HOME.

I'm with you on this. They should use the XDG base directory standard

It's needed before the actual contents of the home directory are available (i.e. mounted), if I understand correctly. Nor is it actually user-modifiable:

> Since the user record is cryptographically signed the user cannot make modifications to the file on their own (at least not without corrupting it, or knowing the private key used for signing the record).

> This file system should contain a single directory named after the user. This directory will become the home directory of the user when activated. It contains a second copy of the user record in the ~/.identity file, like in the other storage mechanisms.

Not quite sure what the purpose of this copy is, given users can delete / replace it?

.config is a XDG thing. The location of it is configurable. Which is the opposite of a standard and is a bad idea in general.

Just out of curiosity, why is it the opposite of a standard if its configurable? XDG home seems to have a sane default of .config, but also provides configuration with the $XDG_CONFIG_HOME environment variable. To me it looks like thats part of the specified XDG base directory standard.

https://specifications.freedesktop.org/basedir-spec/basedir-...

It can hardly be considered a standard location if you literally make it so people will consider putting it wherever they like.

Reply on news.ycombinator.com