4 ms·

An ideal cache implementation would transparently recognize the need to update itself when required, and do so efficiently and transparently. In the particular

by secure 7y ago

An ideal cache implementation would transparently recognize the need to update itself when required, and do so efficiently and transparently. In the particular case of the font cache, I’d say that the library which uses the cache should recognize that an update is needed. I.e., the update happens at next use, not at package installation time. On server systems, where fonts might never be loaded, this saves some compute :)

viraptor 7y ago
But in this case they're building an OS from existing components and not redesigning GUI libraries. The current reality is that you run fc-cache to update the cache. Hooks in this case don't impact servers because fonts are not installed in the first place so caches don't need updating.
- secure 7y ago
  “they” is really mostly just me :) You’re right that this cache currently isn’t great to use! You need to run fc-cache manually when changing your fonts, I wasn’t annoyed enough with it to patch it yet. Regarding servers: I found that package systems which are finely granular enough so that fonts are not installed on servers are not as easy to use—I need to manually look at and install dependencies before things work. A system which is coarser, but avoids the work as well, seems preferable to me.
  - aflag 7y ago
    And what about kernel modules that need to be recompiled, like virtualbox's?
    - secure 7y ago
      In general, computation is pushed out of the package installation phase and to wherever it absolutely must happen before continuing. In this case, one could place a wrapper to wherever kernel modules are loaded (modprobe/insmod for interactive usage, and something within systemd for automated use, I suppose?). Overall, I don’t like the concept of dynamic kernel module compilation, though I understand it has to be done realistically in some cases.
      - waddlesplash 7y ago
        > Overall, I don’t like the concept of dynamic kernel module compilation, though I understand it has to be done realistically in some cases. On Haiku, kernel modules are relocateable ELFs, which is much more suited to this style of package management.
aasasd 7y ago
You might find this a problematic approach: - You make packages track more state―“stuff has changed”―and if there are no triggers, you can't even set a flag for the package's runtime: instead, you have to paranoically check for changes at the run time and compute the difference. Meanwhile, an installer/updater knows exactly that something was changed, and what precisely it was―because the installer just done that. - You're shifting work from install time to run time, which e.g. in backend web programming is exactly the opposite of the right thing to do. Because modifications, in most cases, occur much more rarely than usage, and because making the user wait is a no-no. So, an admin who wants to prepare installed packages for the use, would have to patch the ‘trigger’ stage back in, via their scripts or something―with the caveat that they can't pause the installation in the meantime, so that all changes are processed before the updated programs are run.
- secure 7y ago
  > Meanwhile, an installer/updater knows exactly that something was changed, and what precisely it was―because the installer just done that. Except the distri installer does not modify files, it only ever adds images to the package store (which, to be fair, might result in changes to the contents of exchange directories, which are derived from the package store contents). I agree with the larger point that state tracking might be hard, but it’s not clear to me that it would be easier in distri’s architecture if the installer was responsible for it. > You're shifting work from install time to run time, which e.g. in backend web programming is exactly the opposite of the right thing to do Absolutely. My observation here is that I always want to shift that work. Frequently, I had to wait for extra work to finish that was entirely unrelated to what I wanted to accomplish. E.g., if you don’t update your Debian machine for a few weeks and want to install a new package, maybe that requires a libc update, which requires service restarts, etc. I wanted to explore whether shifting the work improves my experience, and so far it does.
  - aasasd 7y ago
    > the distri installer does not modify files, it only ever adds images to the package store The set of installed packages also comprises state of the system. It's the same as in OOP: modification of data in objects is equivalent to a function accepting prior state and outputting an updated state—only it's more difficult to track the changes when they're done from the inside and/or in a far-reaching manner of OOP. So, in this example, known changes on the installer's level would encompass the installed/updated packages, leaving determining file-level changes to setup scripts of each package. I guess different strategies may exist, but pretty sure this is approximately what other package managers do. > if you don’t update your Debian machine for a few weeks and want to install a new package, maybe that requires a libc update, which requires service restarts, etc. Afaik, if you don't restart services, you can run into incompatibilities between old and updated libraries at the runtime of a service. Suppose I'm running a web server in e.g. Python, and I happen to call a script for the first time after such an update. The script loads an extension which relies on freshly updated libc (for example), while the server has the old one loaded. In short, the system also has state in memory, which after an update differs from the state on the disk—and using mismatching parts of those two is not advisable. I'm not even sure what would happen in C-level libs in this case (“symbol missing” probably?), but I guess everyone lived through mismatched parts of code at the level of scripting languages, and the result is usually an exception. If you catch this situation at the update time, you can gracefully restart the web server while handing new requests to the newly-started instance. If you bump into it at the run time, that's an error for at least one client.

by secure 7y ago

viraptor 7y ago

But in this case they're building an OS from existing components and not redesigning GUI libraries. The current reality is that you run fc-cache to update the cache. Hooks in this case don't impact servers because fonts are not installed in the first place so caches don't need updating.

secure 7y ago
“they” is really mostly just me :) You’re right that this cache currently isn’t great to use! You need to run fc-cache manually when changing your fonts, I wasn’t annoyed enough with it to patch it yet. Regarding servers: I found that package systems which are finely granular enough so that fonts are not installed on servers are not as easy to use—I need to manually look at and install dependencies before things work. A system which is coarser, but avoids the work as well, seems preferable to me.
- aflag 7y ago
  And what about kernel modules that need to be recompiled, like virtualbox's?
  - secure 7y ago
    In general, computation is pushed out of the package installation phase and to wherever it absolutely must happen before continuing. In this case, one could place a wrapper to wherever kernel modules are loaded (modprobe/insmod for interactive usage, and something within systemd for automated use, I suppose?). Overall, I don’t like the concept of dynamic kernel module compilation, though I understand it has to be done realistically in some cases.
    - waddlesplash 7y ago
      > Overall, I don’t like the concept of dynamic kernel module compilation, though I understand it has to be done realistically in some cases. On Haiku, kernel modules are relocateable ELFs, which is much more suited to this style of package management.

aasasd 7y ago

You might find this a problematic approach: - You make packages track more state―“stuff has changed”―and if there are no triggers, you can't even set a flag for the package's runtime: instead, you have to paranoically check for changes at the run time and compute the difference. Meanwhile, an installer/updater knows exactly that something was changed, and what precisely it was―because the installer just done that. - You're shifting work from install time to run time, which e.g. in backend web programming is exactly the opposite of the right thing to do. Because modifications, in most cases, occur much more rarely than usage, and because making the user wait is a no-no. So, an admin who wants to prepare installed packages for the use, would have to patch the ‘trigger’ stage back in, via their scripts or something―with the caveat that they can't pause the installation in the meantime, so that all changes are processed before the updated programs are run.

secure 7y ago
> Meanwhile, an installer/updater knows exactly that something was changed, and what precisely it was―because the installer just done that. Except the distri installer does not modify files, it only ever adds images to the package store (which, to be fair, might result in changes to the contents of exchange directories, which are derived from the package store contents). I agree with the larger point that state tracking might be hard, but it’s not clear to me that it would be easier in distri’s architecture if the installer was responsible for it. > You're shifting work from install time to run time, which e.g. in backend web programming is exactly the opposite of the right thing to do Absolutely. My observation here is that I always want to shift that work. Frequently, I had to wait for extra work to finish that was entirely unrelated to what I wanted to accomplish. E.g., if you don’t update your Debian machine for a few weeks and want to install a new package, maybe that requires a libc update, which requires service restarts, etc. I wanted to explore whether shifting the work improves my experience, and so far it does.
- aasasd 7y ago
  > the distri installer does not modify files, it only ever adds images to the package store The set of installed packages also comprises state of the system. It's the same as in OOP: modification of data in objects is equivalent to a function accepting prior state and outputting an updated state—only it's more difficult to track the changes when they're done from the inside and/or in a far-reaching manner of OOP. So, in this example, known changes on the installer's level would encompass the installed/updated packages, leaving determining file-level changes to setup scripts of each package. I guess different strategies may exist, but pretty sure this is approximately what other package managers do. > if you don’t update your Debian machine for a few weeks and want to install a new package, maybe that requires a libc update, which requires service restarts, etc. Afaik, if you don't restart services, you can run into incompatibilities between old and updated libraries at the runtime of a service. Suppose I'm running a web server in e.g. Python, and I happen to call a script for the first time after such an update. The script loads an extension which relies on freshly updated libc (for example), while the server has the old one loaded. In short, the system also has state in memory, which after an update differs from the state on the disk—and using mismatching parts of those two is not advisable. I'm not even sure what would happen in C-level libs in this case (“symbol missing” probably?), but I guess everyone lived through mismatched parts of code at the level of scripting languages, and the result is usually an exception. If you catch this situation at the update time, you can gracefully restart the web server while handing new requests to the newly-started instance. If you bump into it at the run time, that's an error for at least one client.