robinhoodexe
I’m unsure how to automate this properly, maybe an LLM is the best starting point.
The Orality Theory of Everything
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.
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.
PyOCI – Publish and install private Python packages using OCI/Docker registries
A Sustainable Nix, State of the Union [video]
How the Passionate Male Friendship Died
Stagex – Container-native, full-source bootstrapped, and reproducible toolchain
For monitoring the network traffic for the whole cluster, the CNI and/or whatever ebpf-based runtime security stuff you’re using (falco, tetragon, tracee) is usually enough, but I can definitely see the usefulness of subtract for more specific debugging purposes. If run as a DaemonSet make sure to add some pod filtering such as namespace and label selectors (but I’m sure you’ve already thought about that).
I think Intel Macs will give a better result.
> After investigating the programming requirements, we have decided it’s best to cancel the Mac build for the time being. Porting the game over to Mac would take significant time and resources away from improvements to Fortress and Adventure Mode that simply don’t make sense for us to dedicate right now, given the low number of Mac-only users. There is a significant amount of work that would be required for maintaining a Mac build that would delay all patches in the future, and as we know, you all want patches faster. We aren’t saying it will -never- happen but do not count on it any time soon. We are very sorry to all the Mac users who have been waiting patiently for an update on this.
[1] http://www.bay12forums.com/smf/index.php?topic=169696.6135
https://www.proxmox.com/en/about/press-releases/proxmox-data...
Adding support for CRDs would be very nice. Maybe look up popular CNCF projects and find their official helm charts, that contain the CRDs?
We currently have a thanos instance in each cluster. We could move it to a separate cluster to reduce some overhead, but the current approach works. We’re ingesting about 60Gi per day of metrics into the S3 bucket, so we might have to optimise that.
It works pretty good tbh. I’m excited about upgrading to version 3, as is does take a lot of resources to keep going, especially on clusters with a lot of pods being spawned all the time.