6 ms·

If I was to reimplement it, I would not let any app read the DB directly. Instead I would make an HTTP like interface where you talk to a service that provides

If I was to reimplement it, I would not let any app read the DB directly. Instead I would make an HTTP like interface where you talk to a service that provides the get/set functionality and which always use a text format like an extended JSON with native support for date, int32, etc. This also enabled much easier and better backwards compability as you can specify app-version in the requests, so a version 5 server can respond in version 4 format. With a service it doesn't matter if things are stored as a single sqlite DB or as multiple files.

gizmo 4y ago
You can do everything you describe with a regular function call. Introducing an unnecessary service for something as trivial as config management is even worse than the broken Registry status quo.
- imtringued 4y ago
  In theory all we need is a libconfig with a standardized interface and distro specific implementations. There would be two use cases, storing hierarchical/tree like data aka JSON, YAML, etc and arbitrary graph like data with complex references. The same could be done with the shell. libcli would be called to parse the command line arguments and your program will have an entry point that receives the parsed data. libcli could also be used to produce structured program outputs which then can be fed into applications, possibly skipping the serialisation deserialization steps. Since libcli will have a standard interface each distro can choose their own CLI format or whether they output their data as JSON or CBOR. In both cases the benefit is that the choice of the data storage mechanism has been decoupled from the application.
  - rwmj 4y ago
    Augeas does this already: https://github.com/hercules-team/augeas https://github.com/hercules-team/augeas
kreco 4y ago
Is this sarcastic? I mean, the versioning part sounds good, but JSON like request? I do believe people don't know what inefficient/efficient a system can be depending on the data format they are using.
rougka 4y ago
the registry needs to be read by device drivers including the drivers for tcp and nics, including during very early boot. this would make HTTP a challenge. Also implementing a json parser in the kernel sounds like a bad idea
monocasa 4y ago
That's sort of already the case. Normal apps aren't really supposed to read it, the kernel hides the implementation, and get/set/etc is all system calls. It's tooling created for security and forensics that tries to manually read it.
layer8 4y ago
All the aspects you mention can be realized by a programmatic OS API as well. No need to sandwich a network layer and a weakly-typed data format (JSON) in between.
secondcoming 4y ago
I assume the service will run in a docker container too??
pie_flavor 4y ago
The article's complaints about the format being undocumented are ill-founded, because Microsoft repeatedly tells developers not to read the registry directly, and call the exquisitely documented functions instead. The applications that didn't listen to Microsoft and depended on particular features are most of why it hasn't updated to modern standards in the first place.
- rwmj 4y ago
  How's that supposed to work if you're modifying it in an offline image from a Linux host?
  - pie_flavor 4y ago
    With DISM.
    - rwmj 4y ago
      DISM is a proprietary Windows tool, so no use at all for modifying an offline image from a Linux host.
      - pie_flavor 4y ago
        I'm sure it runs under Wine. But knowing that that's how you service the image means you have no reason to be using a Linux host to do it.
sumtechguy 4y ago
https://docs.microsoft.com/en-us/windows/win32/sysinfo/registry-key-security-and-access-rights https://docs.microsoft.com/en-us/windows/win32/sysinfo/regis... Registry settings already have ACL items applied. You can see this behavior if you log in as a non admin user then try to view another users registry settings. https://docs.microsoft.com/en-us/windows/win32/sysinfo/registry-value-types https://docs.microsoft.com/en-us/windows/win32/sysinfo/regis... The thing is pretty free form with a choice of some very basic data types dword/qword and strings ascii/unicode/lists of strings. Adding a wrapper around the existing call to go towards a json schema registry could be a helpful thing.

gizmo 4y ago

You can do everything you describe with a regular function call. Introducing an unnecessary service for something as trivial as config management is even worse than the broken Registry status quo.

imtringued 4y ago
In theory all we need is a libconfig with a standardized interface and distro specific implementations. There would be two use cases, storing hierarchical/tree like data aka JSON, YAML, etc and arbitrary graph like data with complex references. The same could be done with the shell. libcli would be called to parse the command line arguments and your program will have an entry point that receives the parsed data. libcli could also be used to produce structured program outputs which then can be fed into applications, possibly skipping the serialisation deserialization steps. Since libcli will have a standard interface each distro can choose their own CLI format or whether they output their data as JSON or CBOR. In both cases the benefit is that the choice of the data storage mechanism has been decoupled from the application.
- rwmj 4y ago
  Augeas does this already: https://github.com/hercules-team/augeas https://github.com/hercules-team/augeas

kreco 4y ago

Is this sarcastic? I mean, the versioning part sounds good, but JSON like request? I do believe people don't know what inefficient/efficient a system can be depending on the data format they are using.

rougka 4y ago

the registry needs to be read by device drivers including the drivers for tcp and nics, including during very early boot. this would make HTTP a challenge. Also implementing a json parser in the kernel sounds like a bad idea

monocasa 4y ago

That's sort of already the case. Normal apps aren't really supposed to read it, the kernel hides the implementation, and get/set/etc is all system calls. It's tooling created for security and forensics that tries to manually read it.

layer8 4y ago

All the aspects you mention can be realized by a programmatic OS API as well. No need to sandwich a network layer and a weakly-typed data format (JSON) in between.

secondcoming 4y ago

I assume the service will run in a docker container too??

pie_flavor 4y ago

The article's complaints about the format being undocumented are ill-founded, because Microsoft repeatedly tells developers not to read the registry directly, and call the exquisitely documented functions instead. The applications that didn't listen to Microsoft and depended on particular features are most of why it hasn't updated to modern standards in the first place.

rwmj 4y ago
How's that supposed to work if you're modifying it in an offline image from a Linux host?
- pie_flavor 4y ago
  With DISM.
  - rwmj 4y ago
    DISM is a proprietary Windows tool, so no use at all for modifying an offline image from a Linux host.
    - pie_flavor 4y ago
      I'm sure it runs under Wine. But knowing that that's how you service the image means you have no reason to be using a Linux host to do it.

sumtechguy 4y ago

https://docs.microsoft.com/en-us/windows/win32/sysinfo/registry-key-security-and-access-rights https://docs.microsoft.com/en-us/windows/win32/sysinfo/regis... Registry settings already have ACL items applied. You can see this behavior if you log in as a non admin user then try to view another users registry settings. https://docs.microsoft.com/en-us/windows/win32/sysinfo/registry-value-types https://docs.microsoft.com/en-us/windows/win32/sysinfo/regis... The thing is pretty free form with a choice of some very basic data types dword/qword and strings ascii/unicode/lists of strings. Adding a wrapper around the existing call to go towards a json schema registry could be a helpful thing.