baaym

The image this is about: https://x.com/Astro_Ayers/status/1940810789830451563

Also, title: "Entire HR team terminated".

First paragraph: "This led to the firing of half the HR department."

Either this error is due to clickbait purposes, or AI

Apparently it works great on WSL

See this other user's comment: https://news.ycombinator.com/item?id=42518033

You got the wrong conclusion from your argument. IPv6 is older than some of HN's audience.

I'm going to guess that git is not your VCS of choice for this language

Years ago I had a Graphite installation where I configured retention policies, and the same for InfluxDB if my memory doesn't fail me.

The downsampling feature at first glance seems to serve a different use case than Prometheus was built for, which I think is observability and alerting for a relatively short time period. For systems that need to work with years of data it totally makes sense, but I don't think Prometheus is used in those cases.

Since this feature has been built for a reason however, I could be wrong

And even included in the kernel

Ironically they can factually make that statement now as well.

Perhaps you're confusing rsync.net with tarsnap? When I compared services for my personal off-site backup I came across Tarsnap and their AWS-based infra as well.

I ended up using rsync.net with borgbackup.

I configured BTRFS for my data a couple of years ago on my Debian machine. It's using RAID10 - and the RAID 5/6 issue was widely known back then so I did not dare to touch that.

I must say that (fingers crossed) until now I haven't had any issues with it. There have been a couple of unclean shutdowns that haven't led to any corruptions. Scrub runs every couple of weeks and on top of that the data has an offline (external disk) and off-site (rsync.net through borgbackup) backup. I'm not expecting BTRFS to let me down, but if it does I have recovery options. I tend to be very careful with my 17+ years of photo archives, especially since I'm generating hundreds of megabytes of new content every week since my daughter was born.

It definitely doesn't look good that RAID 5/6 is broken, but I feel very safe using the other stable RAID modes.

Sometimes I'm dreaming of setting up ZFS - however the downside of that is that it doesn't live in the kernel and you're forced to work with kernel modules. It's certainly doable, but since I had a kernel module issue with Wireguard a few months ago I'll be "looking the cat out of the tree" for a bit more before I decide if I actually want to make the move. For now BTRFS feels stable for me, so until that changes - or the benefits of ZFS increase by a fair amount - I'll probably stay on this.

The image in the article shows it's measured in Fahrenheit.

For those working with Celsius: its 54,4 degrees.

When I reached the bottom of the page it even loaded an extra article. Now that's a real waste of CO2.

I'm not sure how this works in the US, but in other countries there are laws against such increases in rent - especially 'social' rent for those with low income.

I don't tweet much, but when I do I'd love to be able to sign them like I sign my git commits.

You kind of mentioned this yourself already, but this boon is more of a feature of the JVM (the classpath) rather than the dependency manager.

If Python would have a similar concept rather than depending on a global module location we would be able to replicate the same developer ergonomics as we have for the JVM.

Great to hear you're looking into it! I do have to clarify that I'm not the owner of the MR though, not meaning to take credit of @krotscheck's work.

I've been enjoying GitLab at my last three employers now, with the CI integration being the most liberating feature compared to the traditional CI providers. Especially the Docker CI runner gives you a great integration test environment, and I'm impatiently waiting for this MR [0] that will allow dependant containers to also talk to each other. It's the last missing piece for my ideal CI setup.

[0] https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1...

And then another downstream microservice fails when you deploy your change into a running environment, because you lack the integration testing capabilities of a monolith.

It's true you achieve higher isolation with microservices, but you also lose points in other areas. And you can get lost in your haystack of microservices just as easily as in your typical monolith ;)

My guess is that the system reservation change was very welcome for me as well.

Note that a service as AKS also draws in new customers that may not yet have years of Kubernetes experience. I'm one of those for example, and I created an AKS cluster so we could deploy short-lived environments for branches of our product. We're using GitLab and the 'Review Apps' integration with Kubernetes.

The instability experienced by the author of this article is something I experienced as well, and I have spent a lot of time draining, rebooting, and scaling nodes to try and find out what is happening. I would not have been able to guess the absence of resource limits could possibly kill a node.

Fortunately these instabilities disappeared a couple of weeks ago after a redeployment of the AKS instance, and it has been stable ever since. I guess the system reservation change was included there? From my perspective that was also the moment AKS truly started feeling like a GA product.