Hacker News Reader

Comment by sleepytimetea | Hacker News Reader

Let me introduce you to the nightmare that is the Windows Registry...

A system-wide key-value store, that's distinct from file storage, seems like a pretty great idea. The Windows Registry is icky, we all know that, it somehow appeared out of nowhere in Windows 95 already crusty as hell. But if it were designed by people with taste and discretion, would it be good?

When you give people the freedom to use the KV store as they wish, you inevitably run into a meta-problem whereby the way they write their data structures in to the KV store is varied across applications. I don't know if you could standardise this structure beyond enforcing applications to use an OS-assigned private store, but I don't see how that would work with portable executables etc.

I suppose you'd need to be very opinionated for it to work, but people will still bodge it to make it work with their needs that your system doesn't natively satisfy (people putting JSON strings in the values, for example).

And how is that a bigger problem than people using the filesystem any way they wish and putting arbitrary content in files?

The filesystem is manageable by users (with few exceptions). You can't easily discover which part of a registry hive is associated with an application.

It's precisely as discoverable as the filesystem. It's a tree like the filesystem. With names given to nodes by the application, just like the filesystem.

Luckily modern programs rarely use it.

don't give the systemd crowd any ideas, the Windows Registry is right up their alley

Dbus says hi

All parts of systemd are configured entirely using plain text config files and symlinks.

It's indeed "configured using symlinks" but not in the sense that you're free to use symlinks the way they're supposed to work but in the sense that if you don't want to use systemctl to place them, you can place them "by hand" if you know all the magic ways in which systemd interprets them and will remove them as it sees fit when you invoke a management command.

I have no idea what you mean by that. A systemd target is a folder in /etc/systemd/system/ which contains a bunch of symlinks to unit config files. When the target is requested, systemd makes sure that all these units are running. This is how symlinks have been used for configurations since forever (for example by apache on Debian).

It's best not to engage with concern trolls.

ln -s /path/to/mydaemon.service /etc/systemd/system/

systemctl daemon-reload

systemctl disable mydaemon.service

ls /etc/systemd/system/mydaemon.service

ls: cannot access '/etc/systemd/system/mydaemon.service': No such file or directory

It has no business removing that symlink. It was placed there by me, and it should be treated no differently than if it was a regular file.

I have no problem with systemctl enable/disable creating and removing links in the appropriate target.d directories, but this symlink had nothing to do with that mechanism. Leave my stuff alone.

This doesn't work because unit files have to be in one of the load paths. Have you tried adding /path/to/ to $SYSTEMD_UNIT_PATH? This is documented in the Unit File Load Path section of the manpage [1].

[1] https://www.freedesktop.org/software/systemd/man/systemd.uni...

> This doesn't work because ...

> This is how symlinks have been used for configurations since forever (for example by apache on Debian).

This is not how symlinks have been used for configuration "since forever." You didn't have to add the link target to some "load path" variable when the link itself was in the correct directory.

I have a suspicion that you are not really interested in using the software which makes this discussion entirely pointless.

P.S. Debian's a2ensite and a2dissite also assume that your configs are in the sites-available folder, not elsewhere in the file system.

a2dissite doesn't delete symlinks outside sites-enabled, right?

I think it's a reasonable complaint.

GNOME's GConf says hi

Reply on news.ycombinator.com