jzelinskie

Lots of very bad uses for JWTs for service-to-service communication, too. There are often way more standard/foolproof alternatives than how lots of people use JWTs on the backend.

I feel like discussions like these usually will surface PASETO/Macaroons/Thin Mints as the fix without acknowledging that the complexity of distributed token passing with arbitrary attenuation isn't a fit for most use cases.

That all being said, sometimes JWT is the right solution for the job! It's the core skill of software engineering to be able to take in all the arguments and tradeoffs and make the right choice for your scenario.

Full disclaimer: Take what I say with a grain of salt because I build a project (SpiceDB) that advocates for a more centralized approach for one of the backend JWT use cases: fine-grained authorization.

Sorry for the "asking for more"-style comment, but it would be amazing if this came in epub and not just PDF.

Hi Brandon!

Have you tried Apple's container CLI[0]? I'm still mostly using OrbStack, but container gives me some hope for the future that Apple cares about this experience.

[0] https://github.com/apple/container

"Understanding _using_ singleflight in Go" would be a better title. This generated article doesn't give the reader a real understanding of the implementation and its various tradeoffs that you might care about depending on your workload (e.g. should the first execution to reach a key spawn a goroutine or is that allocation too much)

That being said, singleflight is a fantastic library and pattern that helps so much with p95 latency. It's a little noisy code-wise, but if you use it in the right places the gains are huge.

Also, totally agree with the below comment that recommends janos/singleflight -- start there, but most of the critical projects at my company, AuthZed, have reimplementations with tailored semantics.

I think I need a deeper-dive into the "diagonal scaling" presented. From my understanding, this is actually no different from "industry decoupling" he disparages earlier in the presentation. There are even off-the-shelf libraries for LSMs backed by object storage like SlateDB.

Security has always been a game of just how much money your adversary is willing to commit. The conclusions drawn in lots of these articles are just already well understood systems design concepts, but for some reason people are acting like they are novel or that LLMs have changed anything besides the price.

For example from this article:

Karpathy: Classical software engineering would have you believe that dependencies are good (we’re building pyramids from bricks), but imo this has to be re-evaluated, and it’s why I’ve been so growingly averse to them, preferring to use LLMs to “yoink” functionality when it’s simple enough and possible.

Anyone who's heard of "leftpad" or is a Go programmer ("A little copying is better than a little dependency" is literally a "Go Proverb") knows this.

Another recent set of posts to HN had a company close-sourcing their code for security, but "security through obscurity" has been a well understand fallacy in open source circles for decades.

An emulator for integration testing against the major cloud providers seems like it should:

1. be table-stakes for a SDK from the cloud providers themselves

2. have the obvious home in a foundation like the CNCF; how else could you be "cloud native" afterall?

I'm just waiting for them to exhaust LotR and move on to Roverandom

Sorry to piggyback, but if this is of interest to you, feel free to reach out to me over to email (contact info in my profile). I'm one of the founders of the most popular ReBAC solution, SpiceDB, which secures quite a few AI products including big players like OpenAI. I'm always interested in hearing about more use cases or where folks are struggling the most.

I'd love to have someone else chime in on this because I did some spelunking and am not sure if this comment is true.

I checked my DNS logs and saw zero attempts to resolve `log.tailscale.com` having ran tailscale for many years (I added it to a blocklist anyway). From their admin panel, it appears "networking logging" requires paying for Premium[0], so it's not being used for free users (or Personal Pro).

Also, from looking at some source code (because the docs don't include this), I discovered you can disable logging for the macOS App Store client by doing:

     echo "TS_NO_LOGS_NO_SUPPORT=true" > ~/Library/Containers/io.tailscale.ipn.macos.network-extension/Data/tailscaled-env.txt

Cool idea, for sure, but I can't help but wonder: for the code that's been ported, is there a concern that you'd have to perpetually watch out for CVEs in glibc/musl and determine if they also apply to the Zig implementations?

I think the most common tools for similar workflows is Google's crane[0] and Red Hat's Skopeo[1]. It might be slightly more low-level than most developers want, though.

[0] https://github.com/google/go-containerregistry/blob/v0.20.7/...

[1] https://github.com/containers/skopeo

I'm curious if someone could chime in on the state of adoption of these these Rx libraries in other language's ecosystems.

My poor memory seems to recall them gaining traction ~10 years ago, but they've fallen hard off my radar.

My fear with adopting a library like this for Go is actually that it might end up being very unfriendly to the profiler once bottlenecks start occurring.

I rebuild from HEAD using homebrew quite regularly and have maybe had a single crash in years using Helix, so I'm shocked to see Julia report she's had crashes. But because I run HEAD, I can tell you what's actually merged which might not be released yet:

Code actions on save

There are command on save hooks which solve the problem for Go, but I could see this being not as applicable for other languages.

Fuzzy search

Man, I'm pretty sure this shipped before telescope was particular stable or popular. Although, I don't recall if Helix originally used the ripgrep backend at first. They reworked it earlier this year and it was a massive improvement.

Automatically updating buffers

+1 to this. I constantly suspend (ctrl+z) my editor and sometimes forget about it and could really use this prompt.

File tree in browser

Space+e or Space+E opens a hierarchical file explorer on HEAD, but this is definitely relatively new

I watched a video recently that dove deep into this as well[1]. It turns out there's not an easy way to figure out if it's borosilicate other than if it has "made in France" on it or if you know it was purchased in Europe. AFAICT, you can't really buy borosilicate Pyrex in the US.

The video does also show off a cool "mineral oil test" to tell the difference, but probably is only effective if you had something to compare it against.

My takeaway though was that I need to thrift some Corningware, though!

1: https://youtube.com/watch?v=2DKasz4xFC0

I don't think my config works anymore (to my earlier point), but this is the balance I struck when I used neovim: https://github.com/jzelinskie/dotfiles/blob/426768c61078a77c...

I'd explicitly configure which servers were triggered which filetypes (aka autocmd and when I first started doing this, the binding for autocmd didn't even exist in lua yet) and have to bind lsp functions to keybindings across languages. FWIW, I have no idea what I would've done in vimscript, lua is a godsend with tables, loops, and lambdas. At this point in time, I was an early adopter neovim's built-in LSP and everyone else was recommending coc.nvim.

But the juxtaposition at the time was that Helix ships `languages.toml` that includes all of this already out of the box. You can override it, if you want, but actually all I wanted was cohesive keybindings for basic LSP functions.

What's the state of the world for neovim today?

I was never a big user of netrw or nerdtree, but Helix has <space>+f for a fuzzy-finding file browser or more recently they added <space>+e or <space>+E for a hierarchical directory explorer.

I build HEAD from source using brew, so I'm not actually sure if the directory explorer is in a stable release.

I wanted to provide an anecdote because I hold the opposite opinions of the author in a variety of ways, but still have used Helix as my primary editor for years now.

I don't chase shiny new tools nor do I aspire to replace my toolchain with things just because they're built in Rust. I've used vim/neovim ~15 years. I don't use many TUIs (I actually can't think of any others besides my editor), but my development workflow is entirely terminal-based. I use native splits/tabs in my terminal emulator instead of screen/tmux/zellij. I spent years balancing having a minimal vim configuration that included plugins (but not compiled ones so that it was portable) but didn't include hundreds or thousands of lines in my vimrc. I'm excited to see how neovim is making progress with native LSP, but for years getting it working meant continuously tweaking vimscript/lua code or adopting a massive plugin written in TypeScript.

When I first tried Helix, LSP just worked; it read what was on the $PATH and used it. That's perfect because it solves for another source of annoyance: having different versions of tools for different projects. As the author notes, there are some LSP features that don't work with Helix, but whenever I dig into the issues, I almost always come to the conclusion that the issue lies in LSP being a VSCode monoculture rather than a deficiency in Helix itself. However, using the right version of a tool for a specific project and not spending any time configuring LSP servers were the top problems plaguing my usage of neovim.

If you're a vim user and you're concerned about muscle memory, by the first week I was proficient and by two weeks, Helix was the default in my brain.

I was a huge supporter of neovim -- I actually was submitting patches to the vim mailing list to fix vim on a beta version of macOS at the time taruda posted his original async patches that kicked everything off. If you had asked me the day before I tried Helix that you could reimplement a vim-like codebase from scratch well enough to abandon the original vim code, I would've agreed with you.

I've seen projects like this for years and I still have the genuinely honest question: what are people doing that managing their dotfiles is significant problem for them?

I've managed my dotfiles (12 different configuration files all compatible with cygwin, wsl, linux, macOS) for the past decade in a git repo with a 50 LOC shell script that creates symlinks for me in an intelligent way. What am I missing?

I've written a reference because I've had this conversation so many times, haha

https://jzelinskie.com/posts/p-what/

After reading about the recommendation system breakthrough[1], I'm more curious about just how much we're leaving on the table with classical algorithms. If you raised the amount of money being funneled into quantum computing and spent it purely funding classical algorithm research, would you be better off?

[1] https://www.quantamagazine.org/teenager-finds-classical-alte...

This is an incredibly useful one-liner. Thank you for sharing!

I'm a big fan of jq, having written my own jq wrapper that supports multiple formats (github.com/jzelinskie/faq), but these days I find myself more quickly reaching for Python when I get any amount of complexity. Being able to use uv scripts in Python has considerably lowered the bar for me to use it for scripting.

Where are you drawing the line?

Just wanted to say thanks for such a good write-up and the great work on Otter over the years. We've used Ristretto since the beginning of building SpiceDB and have been watching a lot of the progress in this space over time. We've carved out an interface for our cache usage a while back so that we could experiment with Theine, but it just hasn't been a priority. Some of these new features are exciting enough that I could justify an evaluation for Otter v2.

Another major for on-heap caches that wasn't mentioned their portability: for us that matters because they can compile to WebAssembly.

Another good comparison would be against https://pkg.go.dev/github.com/puzpuzpuz/xsync/v3#Map

I recommend folks check out the linked paper -- it's discussing more than just confidentiality tests as a benchmark for being ready for B2B AI usage.

But when it comes to confidentiality, having fine-grained authorization securing your RAG layer is the only valid solution that I've seen in used in industry. Injecting data into the context window and relying on prompting will never be secure.

Container runs OCI (docker) compatible by creating lightweight VMs.

This repository houses the command-line interface which is powered by containerization[0], the Swift framework wrapping Virtualization.framework to implement an OCI runtime.

[0] https://github.com/apple/containerization

The screenshot in TFA pretty clearly shows docker-like workflows pulling images, showing tags and digests and running what looks to be the official Docker library version of Postgres.

The Brooklyn Public Library in Green Point has a tool library, although it isn't very large if that's close to you at all. I'm not sure if it's available at any other library locations but the one in Green Point is fairly new and has great programming.

No commentary on your latter points about Oxide's compensation structure, but I fundamentally don't share the same sentiment you have about the dynamics of cash flow for venture-backed startups.

Maybe there are still VC-backed companies having catered food, but I think they're by far the exception and not the rule. ZIRP is long over and a decent portion of this generation of startups began in COVID and subsequently don't even have an office. Maybe I'm the one that's in the bubble, but when you take VC money you're on the line to hit growth numbers in a way that you aren't when you bootstrap and can take your time to slowly grow once you've hit ramen profitability.

Thanks for the response. In my opinion, oso does the best of job of any policy engine at prescribing how input data to their system is fed (and your linked blog demonstrates it well!).

I do think you might have pivoted the conversation, though. My post was purely about federation strategies and policy engines, but you appear to discussing consistency and Zanzibar, which is only tangentially related. Federation and consistency aren't necessarily coupled. Oso also would require a complex scheme for achieving strict serializability, but it instead chooses to trade-off consistency of the centralized data in favor for the local data.