4 ms·

>> The next step would be manipulating the OS as relations. This approach could be a good fit for package management. So that packages are updated and run wit

by 7952 12y ago

>> The next step would be manipulating the OS as relations. This approach could be a good fit for package management. So that packages are updated and run within a transaction and changes can be committed in a single seamless step.

kbenson 12y ago
This would really require the underlying package management system support this, and then it's simply a shim from osquery to the package manager to do the actual work. The main problem would probably being making it work across all the disparate systems it's supposed to support. That said, it would be awesome to query specific package versions, or even individual package file MD5s from an SQL interface to check system exposure when new exploits come down the pipe.
andrewchambers 12y ago
package managers usually work with transactions already.
lifty 12y ago
Package managers usually have non-idempotent actions that might change parts of the operating system in non desired ways. That means that you could not have atomic operations ala SQL. There is one packager manager that solves that, Nix(from NixOS), on top of which you could apply something like an SQL language.
- amelius 12y ago
  I'd rather see an OS and package manager that has a "functional" design (as in functional programming language, functional data structures). This would allow conflicting packages to be installed next to eachother in different branches of a functional filesystem.
  - mej10 12y ago
    The Nix package manager refers to itself as "The Purely Functional Package Manager", and that is exactly what it lets you do. "It provides atomic upgrades and rollbacks, side-by-side installation of multiple versions of a package, multi-user package management and easy setup of build environments." http://nixos.org/nix/ http://nixos.org/nix/
    - amelius 12y ago
      This seems interesting. But I find it a bit unsatisfying that it can only be used as a package manager then. How about using this functional machinery, e.g., for a general build system? A "functional make" so to speak. And I bet there are plenty of other use cases.

by 7952 12y ago

kbenson 12y ago

This would really require the underlying package management system support this, and then it's simply a shim from osquery to the package manager to do the actual work. The main problem would probably being making it work across all the disparate systems it's supposed to support. That said, it would be awesome to query specific package versions, or even individual package file MD5s from an SQL interface to check system exposure when new exploits come down the pipe.

andrewchambers 12y ago

package managers usually work with transactions already.

lifty 12y ago

Package managers usually have non-idempotent actions that might change parts of the operating system in non desired ways. That means that you could not have atomic operations ala SQL. There is one packager manager that solves that, Nix(from NixOS), on top of which you could apply something like an SQL language.

amelius 12y ago
I'd rather see an OS and package manager that has a "functional" design (as in functional programming language, functional data structures). This would allow conflicting packages to be installed next to eachother in different branches of a functional filesystem.
- mej10 12y ago
  The Nix package manager refers to itself as "The Purely Functional Package Manager", and that is exactly what it lets you do. "It provides atomic upgrades and rollbacks, side-by-side installation of multiple versions of a package, multi-user package management and easy setup of build environments." http://nixos.org/nix/ http://nixos.org/nix/
  - amelius 12y ago
    This seems interesting. But I find it a bit unsatisfying that it can only be used as a package manager then. How about using this functional machinery, e.g., for a general build system? A "functional make" so to speak. And I bet there are plenty of other use cases.