5 ms·

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

by sleepytimetea 3y ago

poisonborz 3y ago
Luckily modern programs rarely use it.
fsckboy 3y ago
don't give the systemd crowd any ideas, the Windows Registry is right up their alley
- RandomBK 3y ago
  Dbus says hi
- fsh 3y ago
  All parts of systemd are configured entirely using plain text config files and symlinks.
  - mike_hock 3y ago
    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.
    - fsh 3y ago
      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).
      - SSLy 3y ago
        It's best not to engage with concern trolls.
      - mike_hock 3y ago
        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.
        fsh 3y ago
        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.unit.html#Unit%20File%20Load%20Path https://www.freedesktop.org/software/systemd/man/systemd.uni...
        mike_hock 3y ago
        > 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.
        fsh 3y ago
        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.
- arielcostas 3y ago
  GNOME's GConf says hi
rm445 3y ago
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?
- grenoire 3y ago
  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).
  - mike_hock 3y ago
    And how is that a bigger problem than people using the filesystem any way they wish and putting arbitrary content in files?
    - kevin_thibedeau 3y ago
      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.
      - mike_hock 3y ago
        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.

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

poisonborz 3y ago

Luckily modern programs rarely use it.

fsckboy 3y ago

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

RandomBK 3y ago
Dbus says hi
fsh 3y ago
All parts of systemd are configured entirely using plain text config files and symlinks.
- mike_hock 3y ago
  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.
  - fsh 3y ago
    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).
    - SSLy 3y ago
      It's best not to engage with concern trolls.
    - mike_hock 3y ago
      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.
      - fsh 3y ago
        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.unit.html#Unit%20File%20Load%20Path https://www.freedesktop.org/software/systemd/man/systemd.uni...
        mike_hock 3y ago
        > 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.
        fsh 3y ago
        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.
arielcostas 3y ago
GNOME's GConf says hi

rm445 3y ago

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?

grenoire 3y ago
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).
- mike_hock 3y ago
  And how is that a bigger problem than people using the filesystem any way they wish and putting arbitrary content in files?
  - kevin_thibedeau 3y ago
    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.
    - mike_hock 3y ago
      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.