Red Hat Developer

Yes, and I think we're already seeing that in the general trend of recent linux work toward atomic updates. [bootc](https://developers.redhat.com/articles/2024/09/24/bootc-getting-started-bootable-containers) based images are getting a ton of traction. [universal blue](https://universal-blue.org/) is probably a better brochure example of how bootc can make systems more resilient without needing to move to declarative nix for the entire system like you do in NixOS. Every "upgrade" is a container deployment, and you can roll back or forward to new images at any time. Parts of the filesystem aren't writeable (which pisses people off who don't understand the benefit) but the advantages for security (isolating more stuff to user space by necessity) and stability (wedged upgrades are almost always recoverable) are totally worth it.

On the user side, I could easily see [systemd-homed](https://fedoramagazine.org/unlocking-the-future-of-user-management-with-systemd-homed/) evolving into a system that allows snapshotting/roll forward/roll back on encrypted backups of your home dir that can be mounted using systemd-homed to interface with the system for UID/GID etc.

These are just two projects that I happen to be interested in at the moment - there's a pretty big groundswell in Linux atm toward a model that resembles (and honestly even exceeds) what NixOS does in terms of recoverability on upgrade.

> ...includes support for a soft memory limit. This memory limit includes the Go heap and all other memory managed by the runtime, and excludes external memory sources such as mappings of the binary itself, memory managed in other languages, and memory held by the operating system on behalf of the Go program"

Of course it’s a runtime setting, it won’t affect other factors but you can’t say it didn’t solved anything “because there’s a GitHub issue open” Then Go runtime was unpredictable because of its ideology “CPU is unlimited but not Memory” and containers are kinda of a dynamic resource allocated but it did solve vast amount of problem dealing with kernel OOM and unpredictable GC cycles

> You still need to use a helper library like https://github.com/KimMachineGun/automemlimit or https://github.com/uber-go/automaxprocs.

I would be surprised if the Go team implemented it into the runtime, because some devs would love to have there own way of handling such settings so I don’t see it as an issue

> Forgot to add: The JVM does this for you since JDK 17 https://developers.redhat.com/articles/2022/04/19/java-17-wh...

We can’t just compare added features if don’t compare how backwards compatible the language is at that time I don’t know much about Java, but I wouldn’t say the same from upgrading from Go 1.9 to Go 1.19

Is there a specific aspect of k8s that's causing friction along the learning curve? I'm assuming your referring to the developer side of the equation, not the ops/admin workflows.

Before jumping straight into production k8s, something you can mess around with is using Podman to generate[0] and run[1] Kubernetes resources that you can parse through and familiarize yourself with. Paired with Podman Desktop[2] can produce a nice graphical environment. After that you could take a look at more production-simulating environments with minikube[3], OpenShift Local[4] (very much recommend if you have the resources to run it), and the no-cost OpenShift Sandbox[5].

In general, the Red Hat Developer[6] site has a lot of good resources to learn from, both passive and interactive. I highly recommend going through the courses and tutorials available if it can help your team skill up (assuming k8s is the direction you want to go in).

[0] https://docs.podman.io/en/latest/markdown/podman-generate.1.html

[1] https://docs.podman.io/en/latest/markdown/podman-kube.1.html

[2] https://podman.io/features | https://podman-desktop.io/

[3] https://minikube.sigs.k8s.io/docs/

[4] https://developers.redhat.com/products/openshift-local/overview

[5] https://developers.redhat.com/developer-sandbox

[6] https://developers.redhat.com/

Whilst I agree with the premise, I think you are actually underselling them.

Claude becomes near lobotomized at beyond 500,000 tokens. I don't believe much quality code gets outputted at such high token counts, not to mentioned drastically increased cost.

270k isn't massive, but its very usable with compaction. Not every task needs the full context history.

Quantized models do have a quality / accuracy impact, although it is not as drastic as you suggest. There is some good data on this [0].

"These findings confirm that quantization offers large benefits in terms of cost, energy, and performance without sacrificing the integrity of the models. "

One thing that is worth mentioning is quant models are not created equally, they are not always scaling at the same rate. [1] For example not all tensors contribute equally to model accuracy. In practice, the most sensitive parts (such as key attention projections) are often quantized less aggressively to preserve the quality of the inference.

[0] - https://developers.redhat.com/articles/2024/10/17/we-ran-over-half-million-evaluations-quantized-llms#text_similarity_and_manual_inspection

[1]- https://medium.com/@paul.ilvez/demystifying-llm-quantization-suffixes-what-q4-k-m-q8-0-and-q6-k-really-mean-0ec2770f17d3

At this point, I'm not sure why end users who care about Red Hat stability don't just use RHEL directly. Red Hat has multiple ways to take advantage of RHEL that involve no cost (that weren't available when the original CentOS project was conceived):

- Free developer licenses[0] (great if you're a home-labber, IIRC you can get up to 16, I think?)

- Red Hat UBI images[1]

I feel like most users of AlmaLinux won't see a huge difference between just using AlmaLinux's release cycle vs RHEL -- especially since AlmaLinux will be ABI compatible with RHEL. I.E. apps that work for RHEL should work for AlmaLinux.

So, back to your original question, I don't know what end-users want more of other than as was said by mrweasel in a different comment: "that's not what some people want, they specifically want RHEL, but for free".

[0] https://developers.redhat.com/blog/2021/02/10/how-to-activate-your-no-cost-red-hat-enterprise-linux-subscription

[1] https://developers.redhat.com/products/rhel/ubi

This is why you should never run plain-old-Kubernetes in prod (or in dev, if you want my opinion). Stock Kubernetes basically ignores security and, then, as you said, it requires a bunch of additional work to config.

There are several companies that take Kubernetes and polish it up, the two biggest examples are Red Hat OpenShift[0] (which I'm most familiar with, because I manage it as my day job), and Rancher[1]. Also, note OpenShift is a paid product, but Red Hat also releases OKD[2] for free, which is OpenShift without support.

OpenShift is Kubernetes with great default security policies. Storage, networking, logging, and more are all configured out of the box. I would recommend anyone who is using or looking to use Kubernetes to strongly consider OpenShift or OKD.

[0] https://developers.redhat.com/products/openshift/overview

[2] https://www.okd.io/

[1] https://www.rancher.com/