AI companies are seeing the endgame, more and more tasks can be done just fine by cheaper model, and there will be not enough money to be made to support model that is only needed for top 1% of the tasks.

And the goal is to slow competition down enough before IPO

Paperclip-optimizer-esque behaviour very much seems to be inherent to current methodology of building LLMs, there are only ways to lower the changes or mitigate the damage, not get out of it.

Same with prompt injection, current LLMs are commands in, commands out, there is no way to make sure it is "an agent working on data" rather than "an agent that can take commands from data if you phrase it right"

But it's not even going to optimize the paperclips, it's just going to reward hack them.

there is a thing apps have called configuration file.

They are. Debian + additional repo with scientific packages would be far more preferable for anyone involved.

You can pay companies just fine to support Debian.

> Debian is still easier to manage than RH based systems, and .deb is a really good package manager, and is arguably more sophisticated than RPM.

It's so bad. Coming back to RHEL (new client requirement) after sitting mostly on Debian for years is such a bizzare experience.

You want to install a PostgreSQL database, it doesn't even initialize it, you need to manually do DB init and the rest of the dance.

You want to run DRBD, sorry, we didn't bother to pick that kernel compile option, you can add extra repository for that. But hey, it's the kernel module, which means now you have to enroll cert in Secureboot, and that requires actual KVM access to the VM for someone to confirm it so now I'm on meeting with customer's IT just so they click some buttons in VM's boot process.

Even some common utilities are not in main repos but need EPEL

Ironically back around 2007 we had to use RHEL to get DRBD setup for the Redhat HA / Pacemaker things

RedHat has a bad habit of dropping support for things not because they need maintenance but because they're just old.

I once installed a Sun workstation with AMD processor (Athlon64?) and nForce (4?) chipset. The ethernet card was there but it didn't initialize, why? Because RedHat EOLd the kernel module. Why? Because.

Reinstalled the thing with Debian after fighting it for 30 minutes or so, and the thing worked happily ever since.

> You can pay companies just fine to support Debian.

Yes, but this sentence didn't convince who was making these decisions back at CERN, approximately 20 years ago! I'm not even convinced that it was that possible and painless 20 years ago.

We agree about the rest of us, but I still ask why about EPEL stuff while writing salt recipes.

Update system, install EPEL, update system, install creature comforts is a such a bizarre dance to make while I can just write a one long apt command and get a better system in 30 seconds.

...and aptitude. Yes, that TUI thing. It's magnificent.

It's a wonderful piece of software. We've had one of our clients wanting us to "just provide a simple PHP install for wordpress, just hosting" (among some more complex java stuff company wrote for them).

Site hacked within a day from install. Thankfully we have limited outogoing traffic (whitelist on proxy) so only thing exploit managed to replace is their main page with our proxy's 403 error page, but damn, how this piece of software remains so shit till this day is massive achievement in incompetence.

They also manage to fail on every level, like a simple problem of "a service behind a loadbalancer/reverse proxy" is still unsolved because devs refuse to support X-Forwarded-For header in core "because it's not official RFC", and also do not support official RFC for same feature.

They don't even need to. If you observe enough of them you can correlate traffic patterns between them and find out which one is used by which endpoint

Incorrect. Pointing out bad products is a warning to other people to not waste time on it. We should be doing it more, not less.

I also have no idea what company/service you're talking about

so it is a problem for majority of use

> The Git 2.45 release added reftables as a more efficient way of storing refs. It is a binary file optimized for both space efficiency and quick access. Since then, it has been possible to create a repository that uses a reftable rather than the old file-based mechanism, but that has never been the default. Switching to reftable should have no visible consequences (other than better performance) for users of Git itself, but it can be a problem for users of other software packages that access Git repositories. In his email, carlson mentioned libgit2 as a potential concern.

Looking forward to losing all references at once vs just the current one...

I've noticed persistent Git/fs interaction where on crash the current ref can just disappear...