agartner
Joined 11 years ago
Karma
153
Submissions
27
Member since
Jun 11
[ my public key: https://keybase.io/agartner; my proof: https://keybase.io/agartner/sigs/2r4U0CNtZutA3juG1FZMrJlmKse5R4inmkCcTOjBi8I ]
View on Hacker NewsRecent submissions
Comment · 3 months ago
Comment · 4 months ago
I'm a big LXD and now Incus fan. But I went with NixOS rather than IncusOS for my latest build because I prefer the LTS linux kernel over the mainline kernel.
Comment · 4 months ago
> the courts don’t care if the license is “as-is”.
There isn't any case law to show that. Certainly not in the age of AI. On the criminal side, the CFAA requires "intentionally causes damage" and that's entirely impossible to prove in the age of AI. On the civil side, liability waivers and warranty disclaimers generally cannot shield intentional or willful misconduct or gross negligence.
Comment · 6 months ago
Yeah I think I've finally had enough. I need to start seriously advocating for alternatives since this is starting to impact our business. It's clearly not getting any better.
Comment · 6 months ago
There was another really bad incident today: https://www.githubstatus.com/incidents/zsg1lk7w13cf
> We have resolved a regression present when using merge queue with either squash merges or rebases. If you use merge queue in this configuration, some pull requests may have been merged incorrectly between 2026-04-23 16:05-20:43 UTC.
We had ~8 commits get entirely reverted on our default branch during this time. I've never seen a github incident quite this bad.
Comment · 8 months ago
If anyone is looking to make a similar thing in go I suggest https://pkg.go.dev/mvdan.cc/sh/v3/interp
I've been using it to make my own sandbox that is much more configurable than the default claude code sandbox: https://github.com/gartnera/lite-sandbox
Comment · 10 months ago
Tailscale policy tests are a bit hard to write but help us have confidence in our changes.
Comment · 10 months ago
I guess it was only a matter of time...
Part of this is fair since there is a cost to operating the control plane.
One way around this is to go back to using check runs. I imagine a third party could handle webhooks, parse the .github/workflows/example.yml, then execute the action via https://github.com/nektos/act (or similar), then post the result.
Comment · 11 months ago
I've been using this for a ~year now and it works very well. Thanks!
Comment · 11 months ago
https://github.com/Foxboron/ssh-tpm-agent works well for me
Comment · 1 year ago
Working on decently cool things with relatively limited bureaucracy.
Comment · 1 year ago
Yeah just typical Debian stuff. jwz has been ranting about this for years. It's not worth spending any time on it.
Some suggestions:
- Only "supporting" the latest mainline kernel and latest tools. I prefer to point to CI system configurations to show exactly what it "supported"
- Make this clear via your website and a pinned issue on Github.
- Force users to report the versions they use via an issue template: https://docs.github.com/en/communities/using-templates-to-en.... Immediately close any issues not meeting your version/system requirements without further discussion or thought.
Comment · 1 year ago
I've been patiently waiting to convert my ZFS array to bcachefs. I'm very excited about better SSD promotion logic. But I'm not willing to spend any time on an experimental filesystem on my main systems.
> But you can expect to get flamed about running Debian, or perhaps more accurately, not being willing to spearhead Kent's crusade against Debian's Rust packaging policies.
It is quite unfortunate that Kent couldn't have just said "Debian isn't supported, we will revisit this when bcachefs is more stable" and stopped talking after that. Debian and experimental software just don't work well together.
Comment · 1 year ago
Here's a quick example I put together on how to use these runners to accelerate docker builds: https://github.com/gartnera/actions-arm64-native-example
Comment · 2 years ago
There are attestations that the binaries were built via CI:
https://userdocs.github.io/qbittorrent-nox-static/artifact-a...
Here's a verification of the latest build:
gh attestation verify x86_64-qbittorrent-nox -o userdocs
Loaded digest sha256:af9ceace3fea1418ebd98cd7a8a7b6e06c3d8d768f4d9c9ce0d3e9a3256f40d9 for file://x86_64-qbittorrent-nox
Loaded 1 attestation from GitHub API
Verification succeeded!
sha256:af9ceace3fea1418ebd98cd7a8a7b6e06c3d8d768f4d9c9ce0d3e9a3256f40d9 was attested by:
REPO PREDICATE_TYPE WORKFLOW
userdocs/qbittorrent-nox-static https://slsa.dev/provenance/v1 .github/workflows/matrix_multi_build_and_release_qbt_workflow_files.yml@refs/heads/master