nicolast
Joined 15 years ago
Karma
1,108
Submissions
100
Member since
Dec 19
Multi-language, multi-paradigm hacker, spreading noise using @eikke, formerly working at @Scality on #Kubernetes and #OSS projects.
View on Hacker NewsRecent submissions
Comment · 3 years ago
Exactly: a non-blacklisted IP with good reputation, correct mailname and valid PTR record is the foundation, ideally augmented with SPF. I've been running an e-mail service without DKIM and DMARC for many years without any delivery issues, only adding those very recently.
Comment · 3 years ago
I am indeed. Feel free to reach out, would be happy to learn from the approach you took.
Comment · 3 years ago
You may be interested in https://discourse.haskell.org/t/towards-an-actor-framework-f..., then!
Comment · 3 years ago
For this kind of decisions, why not simply keep notes as comments in the code? These can easily be added later, even 14+ years after the code was written. Then, when someone dives into the codebase to figure out why something was done this or that way, the answer is right there. No need to dive into (and scavenge, sometimes) VCS history.
Comment · 4 years ago
GoPro would like a word.
Comment · 5 years ago
There's also 'AX_APPEND_COMPILE_FLAGS' [1] (and its dependency 'AX_CHECK_COMPILE_FLAG' [2]), next to many other (related or unrelated) macros in the autoconf archive.
[1] https://www.gnu.org/software/autoconf-archive/ax_append_comp...
[2] https://www.gnu.org/software/autoconf-archive/ax_check_compi...
Comment · 5 years ago
An 'easy' way to deploy a cluster could be using kubeadm. Then you'll need a CNI like Calico to get Pod networking up-and-running. However, you'll want to install a bunch of other software on said cluster to monitor it, manage logs,...
Given you're running on physical infrastructure, MetalK8s [1] could be of interest (full disclosure: I'm one of the leads of said project, which is fully open-source and used as part of our commercial enterprise storage products)
Comment · 5 years ago
> first of all with k3s keeping a production cluster running is still pretty easy.
Fair enough. I'll admit I have no direct experience with K3s. There are, however, many K8s deployment systems out there which I would not consider 'production-ready' at all even though they're marketed that way.
> second you should always be ready to start from scratch, which is also pretty simple, because of terraform.
That may all be possible if your environment can be spawned using Terraform (e.g., cloud/VMWare environments and similar). If your deployment targets physical servers in enterprise datacenters where you don't even fully own the OS layer, Terraform won't bring much.
> a lot of people are scared of k8s but they did not even try. they prefer to maintain their scary ansible/puppet whatever script that works only half as good as k8s.
We've been deploying and running K8s as part of our on-premises storage product offering since 2018, so 'scared' and 'didn't try' seems not applicable to my experience. Yes, our solution (MetalK8s, it's open source, PTAL) uses a tech 'half as good' as K8s (SaltStack, not Ansible or Puppet) because you need something to deploy/lifecycle said cluster. Once the basic K8s cluster is up, we run as much as possible 'inside' K8s. But IMO K8s is only a partial replacement for technologies like SaltStack and Ansible, i.e., in environments where you can somehow 'get' a (managed) K8s cluster out of thin air.