News for hackers. Stuff that matters.
Re:Reverse engineering GitHub Actions cache to make it fast by theideaofcoffee on Wednesday July 23, 2025 @11:14AM (#44660155)
Programmatic interaction with iptables ... isn't difficult and has been a relative constant in all of the systems I've managed for nigh on two decades now. Hint: strict ordering of rules for a firewall is a feature, not a bug! Sure it's not as nice as pf(4), but it feels like nftables carries on some of the DNA that made pf nice to work with. If you're going that low-level you should probably just make use of the base netfilter primitives by the kernel and dispense with the userland, these having been available since -1999-. Better yet all of this could now live as a handful of bpf programs. But what do I know, I've only been doing this for more than half my life.

Maybe it's for the best that the project was scrapped, considering the bar for technical competence at Vercel has been embarrassingly low across my interactions, I'm not surprised that iptables and networking as a whole has been a challenge.

Re:Reverse engineering GitHub Actions cache to make it fast by junon on Wednesday July 23, 2025 @12:27PM (#44661016)
What a delightfully arrogant comment :) This was about ten years ago. At the time, given the constraints, iptables did not have a public, stable programmatic interface, no. Perhaps you used other firewall systems/frameworks. We had to interop with Docker. I don't remember specifics; I do remember going very deep down that rabbit hole.

For what it's worth, the development team, at least in the early ZEIT days, were the most competent engineers I've ever worked with on a team.

Re:Reverse engineering GitHub Actions cache to make it fast by dang on Wednesday July 23, 2025 @01:37PM (#44661836)
Please don't cross into being a jerk on HN. You may not feel you owe the person you're speaking with better, but you owe this community better if you're participating in it.

If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.