robinhoodexe (u/robinhoodexe)

robinhoodexe commented on Shai-Hulud compromised a dev machine and raided GitHub org access: a post-mortem trigger.dev/blog/shai-hul... · Posted by u/nkko

moh_quz · 13 days ago

Really appreciate the transparency here. Post-mortems like this are vital for the industry.

I'm curious was the exfiltration traffic distinguishable from normal developer traffic?

We've been looking into stricter egress filtering for our dev environments, but it's always a battle between security and breaking npm install

robinhoodexe · 13 days ago

Wouldn’t the IP allowlist feature on the GitHub organisation work wonders for this kind of attack?

robinhoodexe commented on Google denies 'misleading' reports of Gmail using your emails to train AI theverge.com/news/826902/... · Posted by u/causenad

tietjens · a month ago

The only reason I am still using gmail is due to choice paralysis. I do not know which email service to choose and pay for. I do not like Proton. Is Fastmail the way to go? There is also the German one posteo. Should I just use Apple's mail? I'm taking suggestions if you have anything to share.

robinhoodexe · a month ago

I've been using mailbox.org for 5 years and like it very much. Cost some 3 EUR per month (actually there's a 50% discount this week).

Dead simple email that just works. Their webUI is fine, but I almost exclusively use it on iOS or macOS with the default mail app. They also have some other features (calendar, office suite, video calls) that I don't use. I really like the option to create up to 25 email aliases.

robinhoodexe commented on Run Nix Based Environments in Kubernetes flox.dev/kubernetes/... · Posted by u/kelseyhightower

jeremy_flox · a month ago

Jeremy from Flox, here, I want to chime in here so Ron can be with his family, even though he will no doubt be right back on here:

Re: Relationship to nix-snapshotter and prior art This is original work, though very much built on prior innovations. Our approach hooks into the upstream containerd runc shim to pull the FloxHub-managed environment and bind-mount the closure at startup. The key distinction is that we use how Flox environments are rendered to avoid Nix evaluation entirely, making it safe and fast for a k8s node to realize packages directly on the node. Less about images and containers, per se, and more out bringing the power of Flox and Nix at the buildtime end to the runtime end of SDLC.

The cache story is surprisingly strong: nix store paths effectively behave like layers in the node’s registry, but with dramatically higher hit rates -- often across entirely unrelated pod deployments. Because all pods rely on the same underlying system libraries drawn from the “quantized” Flox catalog, different environments naturally share glibc, core utilities, and common dependencies, where traditional containers typically share nothing.

Tools like nix-snapshotter, Nixery, and others have pioneered this space and we're grateful for that work. This rising "post-Docker" tide raises all ships.

Re: Open Source The software is brand new -- only slightly older than Ron’s baby -- and currently in alpha. KubeCon was our first opportunity for broad feedback, and we uncovered a few issues we’re still addressing. Our intent is to open-source the project once we’ve fully vetted the approach, ideally in the coming weeks.

Yes, we launched early and the product is imperfect, but we’re doing so transparently and with a commitment to getting it right and releasing it to the community, we will continue to release early and often.

Re: Abstraction depth concerns I appreciate @rootnod3’s point about deeper abstractions complicating debugging. We’re thinking hard about how to keep things simple for people who need to run and fix systems quickly. It’s encouraging to see the broader ecosystem—like FreeBSD—lean further into reproducibility, especially as AI-centric stacks make this increasingly important.

Re: Nix vs traditional approaches Skilled Dockerfile authors can achieve great caching results -- and you can pin and you can prune registries, etc -- but our goal is to make these best practices the default. Nix enables finer-grained caching and a universal packaging format for building and consuming open source software.

We see intrinsic value in Flox environments -- whether on the CLI, k8s, Nomad down the road, or other platforms. Our aim is for Flox environments to be as universal and natural as Nix packages themselves -- essentially extending “flox activate” into the k8s world.

We likewise got a ton of valuable feedback at KubeCon, most of which was validating, all of which was very inline with this conversation.

robinhoodexe · a month ago

First, congrats on the release. I’ve looked at flox and devenv for nixifying our container builds. Our distribution of languages is about 40/30/20/10 of Python, F#, R and nodejs.

A dilemma I’m facing is that the win from nix in terms of faster builds and smaller images would be largely from python and R images (where the average size is often 1Gi or larger). However, the developers that use Python or R are less likely to “get” the point of Nix and might have a steeper learning curve than F# developers (where the builds are quite efficient).

That was the context, my question is, how’s the integration with Flox and R/RStudio? I know there’s Rix[1] for managing R packages with Nix.

[1] https://github.com/ropensci/rix

robinhoodexe commented on Cache Benchmarks github.com/tidwall/cache-... · Posted by u/jjwiseman

junon · 5 months ago

The choice for log graphs here probably wasn't necessary and seems to have hurt more than it helped. Despite looking relatively similar, memcached performed 3x faster than redis on some benchmarks whilst appearing only slightly above average.

Otherwise, very thorough and well done benchmark from the looks of it. Redis my beloved not holding up so well against some others these days it looks like.

robinhoodexe · 5 months ago

Agreed, it'd be nice to see the graphs with a linear scale.

robinhoodexe commented on Understanding the Go Scheduler nghiant3223.github.io/202... · Posted by u/gnabgib

xyzzy_plugh · 7 months ago

Relevant proposal to make GOMAXPROCS cgroup-aware: https://github.com/golang/go/issues/73193

robinhoodexe · 7 months ago

Looks like it was just merged btw.

robinhoodexe commented on Tini: A tiny but valid `init` for containers github.com/krallin/tini... · Posted by u/thunderbong

robinhoodexe · 8 months ago

We use this for internal base images at $DAYJOB in order to get SIGTERM properly passed in Kubernetes, mostly a problem with Python, R and Elixir. Works wonders with only a default ENTRYPOINT in the base image, so it’s completely “hidden” from the developers (most of them don’t care, and rightly so).

robinhoodexe commented on An intro to DeepSeek's distributed file system maknee.github.io/blog/202... · Posted by u/sebg

robinhoodexe · 8 months ago

I’m interested in how it is compared to seaweedfs[1], which we use for storing weather data (about 3 PB) for ML training.

[1] https://github.com/seaweedfs/seaweedfs