Since I could not find a quickstart to run opengrep with the full set of rules from their fork I thought I'd document what I found out. Setup Download the opengrep binary from github and make it executable with chmod +x . Clone the rules repo: git clone git@github.com:opengrep/opengrep-rules.git and clean it up to make it usable to opengrep: cd opengrep-rules rm -rf ".git",".github",".pre-commit-config.yaml", "elixir", "apex" find . -type f -not -iname "*.yaml" -delete rm -rf .github rm -rf .pre-commit-config.yaml Ensure opengrep can load the rules with: opengrep_manylinux_x86 validate . The same can be done for custom rules maintained in a separate repository. AFAIU Multiple repositories can be specified by repeating -f option as needed, see below. We are now ready to scan a repo, from the repo root directory run: opengrep_manylinux_x86 scan \ -f <path_to>/opengrep-rules \ --error \ --exclude-rule=VAL some ti...
Once again , some supremely well-thought and useful content from Oxide: https://rfd.shared.oxide.computer/rfd/0576 This time it is about the use of LLMs within Oxide , here are my main take aways: start from values ! A phenomenal example of how values can be so much more than the vanity checklist that most companies use them for focus on the receiving end : why should I spend time reading something that the author did not think was worth enough spending the necessary time to write it? Again, goes back to their strongly writing-oriented culture and values corollary of item number 2: self review AI-generated code before asking others to review it!
The ZFS filesystem has many features that once you try them you can never go back. One of the lesser known is probably the support for replicating a zfs filesystem by sending the changes over the network with zfs send/receive. Technically the filesystem changes don't even need to be sent over a network: you could as well dump them on a removable disk, then receive from the same removable disk.