Would love to see a screenshot of the dashboard.
HN user
robinhoodexe
Wouldn’t the IP allowlist feature on the GitHub organisation work wonders for this kind of attack?
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.
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.
Agreed, it'd be nice to see the graphs with a linear scale.
Looks like it was just merged btw.
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).
I’m interested in how it is compared to seaweedfs[1], which we use for storing weather data (about 3 PB) for ML training.
The director also made Kim Jong Il’s Comedy Club[1], an absolutely insane documentary on North Korea.
It’d be neat to use subtrace in an ephemeral pod for debugging purposes, that just runs alongside the regular pod.
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).
So how do we enable the feature?
I tried an Ubuntu x86 VM with UTM on a M1 MacBook Pro, but the results was extremely slow.
I think Intel Macs will give a better result.
I asked for a status on the forums[1] but the it doesn’t look too positive. From a September 2024 steam post:
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
Is the book available somewhere online free of charge?
This link seems to work:
https://www.proxmox.com/en/about/press-releases/proxmox-data...
Very nice!
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’re extremely pleased with Talos. Much more secure than Azure (our cloud of choice, unfortunately) which run a full-blown Ubuntu underneath. We haven’t run into any issues with Talos and upgrading is super easy with the talosctl tool, both Kubernetes and Talos version.
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.
I can’t recall the reason for using thanos over mimir to be honest. I think thanos seemed like a good choice given it’s part of the kube-prometheus-stack community helm charts.
We’re running standard Prometheus on Kubernetes (14 onprem Talos clusters, total of 191 nodes, 1.1k cpu cores, 4.75TiB memory and 4k pods). We use Thanos to store metrics in self-hosted S3 (seaweedfs) with 30 days retention, aggressively downsample after 3 days.
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.
Is tuning the TCP buffer size for instance worth it?
A similar tool is detect-secrets[1].
We have been using seaweedfs for about 3 months and so far it’s pretty solid, the integration with kubernetes is nice and the maintainer is very active on slack and when opening GitHub issues.
What exactly are the problems with using it on macOS? So far (on my, admittedly, short nix journey), I’ve not encountered any issues that wasn’t fixable with 5 mins of google (even as a beginner).
I'm considering doing a pilot (~5 devs out of 120) with using nix to manage dependencies and build containers at $DAYJOB, and here I think devenv is nice as a "one package" plus an active community for support.
Sounds like nix using devenv[1] also would solve this problem.
Nix for developer environment and building containers.
I’m wondering if it’s worth it to introduce to the rest of the company. We’re pretty comfortable building/“maintaining” ~400 container images, and it’s relatively fast (~3-5 min build time if no packages are changed), but there a lot of shared dependencies between all these container images, and using nix to get actual reproducible AND minimal container images with a shared cache of Linux and language-specific packages (dotnet, node, python and R) would bring in a ton of efficiency, as well as a very consistent development environment, but I won’t force all the developers to learn nix, so the complexity should optimally be absorbed into some higher level of abstraction, like an internal CLI tool.
I’m aware that the caching of dependencies can be improved, as well as creating more minimal container images, but it’s tricky with R and Python in particular, and then I figured why not just to balls-deep on nix that actually solved these issues, albeit at a cost of complexity.
Out of curiosity, how would you run Python or R workloads in kubernetes without a distro or shell?
And just as we're about to migrate 4 kubernetes clusters with a total of ~4k pods. Terraform in github actions on selfhosted runners and argoCD is failing.
Looks somewhat similar to the talos Linux project[1]
Can you elaborate on this? We have some 300 internal APIs on a valid domain. We used to use let’s encrypt, but got rate limited for obvious and fair reasons when we were migrating between clusters. It’s a bit better with zerossl, but we still get 429s when cert-manager is issuing a ton of certs at the same time.