They’re the ones running a 10 years old database on a 11 years old os in a public facing server “because it just works”, not me
My point was that they upgraded to a newer database (also old, but newer), which is arguably better than containerization.
For example the issue of MySQL 5 being unavailable would be a non-issue with a container
So people careless enough to “just container it” for old, possibly security-compromised software - you call that a “non-issue”? How about upgrading and configuring for compatibility?
Except it isn’t: https://en.wikipedia.org/wiki/Sugar_cube
Similarly, how the kilogram is the SI unit for weight, not the gram.
Everyone in metric zone fails as well to guess weights of a few grams :) best I can do is estimate 1/4 kilos
Also a good solution but you will end up in a container anyway once the requirements will become too old to be satisfied on a current OS.
That might be - but depending on the platform, that container is trivial or not necessary at all (e.g. wine on Linux still runs 16 bit executables with just a config file). Also, until then, I can continue to run the game without worry. E.g. Unreal Tournament 99 still worked out of the box (last I tested) on Debian 12 - haven’t tried it yet on Debian 13.
Why ? Any technical reason beside your dislike for containers, in this specific scenario ?
Because jailing a container is even harder than jailing an application. “But a container is already jailed” you’ll say - I don’t trust any jail that I can’t choose & configure myself.
If the publisher only give you the server binary (and all the dependencies) there is way to be sure that the next OS update does not break something, assuming you are able to run it in the first place.
The source code you say ? Fine, when the copyright end, after 70 years, they will release it in the public domain, until then… good luck, laws are on their side.
How about: document the requirements for the execution environment (in industry this is called an interface definition document), based on which the gaming community can then generate their own container configs if they like, but no one has to run stuff in a container.
I firmly disagree that this would be a good use case. Allowing this kind of container shenanigans would introduce more incompatibilities than it solves.
Pardon my French but would you please kindly fuck off with “container solutions”? Cheers.
idiots…
This meme might be referring to the RedSun zero-day, currently unpatched in Win10 & Win11, where detected malicious SW gets installed to the system folder for you by defender.
The rule should be “if you get caught using LLMs or caling them ‘AI’, you’re a dipshit and will never ever be let near the Kernel again.”
About fucking time.
I am pretty sure this account is managed by Stephen Miller
Haha. Great summary.
This just keeps happening with npm, from the news I’ve read. Almost like npm devs are not qualified to maintain code.
That sounds like written by some dumbass vibe-coder who actually believes their LLM is “smart”.
as an outsider, reading the forum discussion, the split is not the crisis, the crisis is already ongoing, and the split from the company is actually a step towards a good solution. Also, the discussion tone seems to be very constructive.
Density of loose sugar is already between 0.7-1 grams / cm^3. Compressed sugar as in a cube weighs more, depending on the compression / packing factor. But 1cm^3 sugar cubes are rare, chances are you only think they are that big, while they are actually more near the standard cubes 16x16x12mm^3, which again triples the weight.
You kind of prove my point here: people typically fail to guess weights of a few grams.
Edit: corrected density, I had previously used the actual density, not the density of loose sugar, which is less.