AndrasKrigare

Also made the switch not too long ago, only using Manjaro. Steam's proton had gotten extremely good at playing Windows games, so there's a good chance that it could run your old strategy game.

You might already have this on your set-up, but having wine auto-launch for Windows executables has been fantastic. I regularly pull and run Windows executables without really giving it a second thought, and so far it's generally "just worked."

I just discovered meshmixer has a much better automated way to create supports for 3D models than the default curamaker I was using, so it's renewed my interest in printing miniatures and such.

🫡

I think it's used more often in computer science, but the difference between contiguous and continuous. Continuous means "without end" and contiguous means "without break."

See also, defenestration trilogy

Gas-filler. There's a couple states in the US where you aren't allowed to pump your own gas, someone else has to do it for you, and you're expected to then tip them.

The job is essentially getting me to pay to be inconvenienced. I'd prefer to pay to let me pump my own gas.

Exclusives are anti consumer

I think to some extent it's a matter of scale, though. If I advertise something as a calculator capable of doing all math, and it can only do one problem, it is so drastically far away from its intended purpose that the meaning kinda breaks down. I don't think it would be wrong to say "it malfunctions in 99.999999% of use cases" but it would be easier to say that it just doesn't work.

Continuing (and torturing) that analogy, if we did the disgusting work of precomputing all 2 number math problems for integers from -1,000,000 to 1,000,000 and I think you could say you had a (really shitty and slow) calculator, which "malfunctions" for numbers outside that range if you don't specify the limitation ahead of time. Not crazy different from software which has issues with max_int or small buffers.

If it were the case that there had only been one case of a hallucination with LLMs, I think we could pretty safely call that a malfunction (and we wouldn't be having this conversation). If it happens 0.000001% of the time, I think we could still call it a malfunction and that it performs better than a lot of software. 99.999% of the time, it'd be better to say that it just doesn't work. I don't think there is, or even needs to be, some unified understanding of where the line is between them.

Really my point is there are enough things to criticize about LLMs and people's use of them, this seems like a really silly one to try and push.

We're talking about the meaning of "malfunction" here, we don't need to overthink it and construct a rigorous proof or anything. The creator of the thing can decide what the thing they're creating is supposed to do. You can say

hey, it did X, was that supposed to happen?

no, it was not supposed to do that, that's a malfunction.

We don't need to go to

Actually you never sufficiently defined its function to cover all cases in an objective manner, so ACTUALLY it's not a malfunction!

Whatever, it still wasn't supposed to do that

The purpose of an LLM, at a fundamental level, is to approximate text it was trained on.

I'd argue that's what an LLM is, not its purpose. Continuing the car analogy, that's like saying a car's purpose is to burn gasoline to spin its wheels. That's what a car does, the purpose of my car is to get me from place to place. The purpose of my friend's car is to look cool and go fast. The purpose of my uncle's car is to carry lumber.

I think we more or less agree on the fundamentals and it's just differences between whether they are referring to a malfunction in the system they are trying to create, in which an LLM is a key tool/component, or a malfunction in the LLM itself. At the end of the day, I think we can all agree that it did a thing they didn't want it to do, and that an LLM by itself may not be the correct tool for the job.

Where I don't think your argument fits is that it could be applied to things LLMs can currently do. If I have an insufficiently trained model which produces a word salad to every prompt, one could say "that's not a malfunction, it's still applying weights."

The malfunction is in having a system that produces useful results. An LLM is just the means for achieving that result, and you could argue it's the wrong tool for the job and that's fine. If I put gasoline in my diesel car and the engine dies, I can still say the car is malfunctioning. It's my fault, and the engine wasn't ever supposed to have gas in it, but the car is now "failing to function in a normal or satisfactory manner," the definition of malfunction.

It implies that, under the hood, the LLM is "malfunctioning". It is not - it's doing what it is supposed to do, to chain tokens through weighted probabilities.

I don't really agree with that argument. By that logic, there's really no such thing as a software bug, since the software is always doing what it's supposed to be doing: giving predefined instructions to a processor that performs some action. It's "supposed to" provide a useful response to prompts, anything other than is it not what it should be and could be fairly called a malfunction.