zupo
Joined 9 years ago
Karma
92
Submissions
37
Member since
Jun 23
Recent submissions
Comment · 9 months ago
"The capability based approach is interesting, but trusting developers to declare all their needed capabilities seems brittle. Modern OS level sandboxing or containerisation provides strong isolation without relying on each library to opt in, which may be a more robust alternative."
Comment · 10 months ago
This is a good reminder that ‘AI pair programmers’ can create subtle bugs that are hard to spot.
Comment · 11 months ago
Fascinating vulnerability. It shows how browser integrations can create unexpected attack surfaces. I’d love to see more discussion around hardening these kinds of local browser modules.
Comment · 2 years ago
IIUC Magic Nix Cache uses Github Actions Cache, which means there is waiting for the cache contents to be loaded onto the runner instance. This can in no way be as fast as what namespace.so does, which is mounting a disk image with /nix/store.
Comment · 2 years ago
What worked great for me for speeding up CI was using Cachix + namespace.so. This works so well I moved all my personal and our company CI to GitHub Actions.
With "it works so well", I mean:
* CI is cheap because namespace.so runners are faster & cheaper than GitHub Actions
* the UX is exactly the same as using vanilla GitHub Actions, namespace.so's runner is a drop-in replacement
* the CI starts up very fast because `/nix/store` is stored on namespace.so's "Cached Volumes" which are like virtual disks attached to the CI runner, so there is nothing to download to prime the cache, Nix can just start running immediately
* https://github.com/cachix/cachix-action uploads whatever Nix builds to Cachix in the background so from this point on if any of our devs pulls the latest code, they don't have to build any derivations locally, and lose time waiting, everything is pulled automatically from Cachix to their machines, they can get right to work. Or if I have to purge the Cache Volume for some reason, nothing needs to be rebuilt, just pulled from Cachix.
It's taken a few years to get this dialed in, but now that it works, it's sooo good!
Comment · 3 years ago
I've seen the following multiple times in the past:
1. something changed in test layer setup that made all tests slower
2. something changed in application code that made all tests slower (!!)
And most of the times, they were avoidable, and fixed after we realized what happened.
Comment · 3 years ago
Not quite 2019 levels, but here they have mostly rebounded.
Comment · 3 years ago
Unit tests tend to get slower with time, wasting a lot of developer hours. BlueRacer helps you keep them fast by posting a unit test performance summary on every Pull Request.