Except they're not? Very few tools are deterministic. Only Mathematics is, and that's only a small subset of tools.

You're free to argue that non-deterministic tools lack value, but that's clearly false: OCR only exists because of lossy training machine learning algorithms. Or, going even more basic, Monte Carlo simulations are by far the most efficient method of testing entire categories of problems that are intractable deterministically.

LLMs can be shitty, as a business practice, due to their unpredictability, but (hopefully obviously) that depends on how it's used.

I think AI needs to be regulated on a larger scale. The tools need to be restricted if you want to stop people from using them.

Putting up rules against tool use without making access to the tool more difficult are worthless.

Putting up slop PRs doesn't have to be intentional from the authors side.

How would you check commits for AI use if it is not mentioned anywhere? How would you enforce anti-AI rules?

You’re correct but still completely missing the point.

Thanks ;)

The only way to implement anti-LLM rules is to detect AI-assisted code.

From direct experience, this just isn't true. I contribute to a small open source project, and we're doing well enough for our purposes by simply saying "no AI". We're not checking, we work on good faith. That's enough for us. We have no reason to think people are circumventing it.

I contribute to a small project, where we simply ask that PRs don't include AI, then we proceed on the basis of good faith.

No, calling pigs rolling around in the mud pigs is neither an insult nor taking part in the strange mud bath ritual.

But as you seem to be bad with analogies:

Spouting ideology for the sake of it is bullshit no matter which side does it. Pitting your ideological dogmas against each other is not a discussion. If that's your thing start a new religion (that's not even far off from some of the influencer and tech-bro bullshit nowadays anyway...).

Most people are sick of the always same "AI is the evil and will destroy us all!", "No, you need to embrace our saviour AI that will save us all or get left behind!" idiocy repeated a million times in slightly different spelling. You need to be absolutely lost in a delusion to miss the costantly alternating pattern of pro-AI / anti-AI posts in social and other media pushed to keep engagement going. Ffs... when it's about the Linux kernel it's even worse and even more obvious when we are bombarded with alternating pro- and anti-AI statements from the same single person. People can't be that dense. So why pretend that at this point it's something else but induced insanity.

On the small scale the good faith approach works. But on the scale of the linux kernel it would have minimal to no effect to ban AI contributions.

For the code quality it's better to enforce proper reviewing and checking of the code instead of banning specific methods of producing code.

Banning AI is as enforceable as banning vscode.

I myself don't use ai in general and I despise the attitude towards ai of some people in the community but I don't think banning ai on this side of the problem has any effect on the code quality and the way things are contributed. I think ai needs to be regulated on a government level. Like removing datacenters or financing of ai companies, which both can also be done on a local government level.

If we're playing the altruism olympics game, everyone is already throwing stones in a glass house as it is, because virtually all electronics and batteries on Earth are made from materials mined by forced/child labor.

They were already irrelevant in real life years ago. You only see these loser holdouts on places like lemmy.

I can well imagine things are different at that scale

Yes, but... here comes the next squeeze. I know that they would sell us the rope to bang them with, but god damn.

The last paragraph of the screenshot is problematic regardless though.

Software Developers need to learn that there is a world outside of their projects. I do not care if it makes your life easier, this technology is having worldwide impacts we are not prepared for. It's leaf blower mentality. They don't care that the neighborhood stinks like 2 stroke exhaust, they don't care that it's loud as hell, they don't care where the leaves go, their yard is clean and that's all that matters.

Surely the Linux kernel gets used by those same organizations too, in some way

Assuming you didn't know what tools were used to write the code that you are reviewing, how would reviewing it be any different? You would still ask the human author questions about intent if that were not clear. The quality of their responses may or may not be impacted by their use of LLMs, but that is up for you to reason about as the reviewer, and it's perfectly fine to tell someone they are being a jackass for only sending slop to you.

where you have to focus and review everything line-by-line

Do you not think all code deserves this level of focus?

Don't compilers have some guarantee of behaviours? I.e even if you don't know exactly what instructions and order the compiler generates there is a guarantee that it is computationally/mathematically equivalent to the statements you wrote. Otherwise it would be a pretty terrible compiler. That's a pretty big jump to writing instructions you don't understand, since LLMs can't make the same guarantees about a prompt/request.

Not parent commenter, but no, not to the same degree.

The level of trust I have in a source greatly changes how I review it. If I know that I'm reviewing code from a competent developer, I'm going to see a for loop and look for why is this here, how does it play into the larger objective and if I'm happy with it, I move on. But if I don't trust the developer as much, I'm looking at far more like what data type is being used in the indexing, what's the break condition, can go off the rails into random memory.

I'd argue that Monte Carlo is a bad example here, and is an example of a deterministic tool.

You use a tool to create an outcome, you're looking for an answer or a solution that you can trust.

If you want to examine behavior of a system that has input variables across some known range, you could brute force it, try every single possible combination and wait a millennia. Or you use a monte carlo strategy, let randomness enter the simulation to build out a basic characterization. You want more detail? More confidence? Increase the number of runs. I can trust that if I increase the number of runs I gain higher fidelity, if the tool/strategy was non deterministic I couldn't do that

This is exactly right and I love Linus so much for cutting through the emotion every time. All he cares about every single time is if the commit is good or bad. Thats how it should be.

That's the false dichotomy gospel of social media, that says only two extreme polar opposite opinions are possible on any issue, and anyone who claims otherwise is secretly on whichever side is wrong. But I agree, most controversial discussions are nothing but mud fights because few people bother to think about the nuances of an issue. They take in minimal information and make a value judgement based mostly on preconceptions, so they can scroll on to the next item as fast as possible.

Yes, they are deterministic. LLMs are not.

Tell me you weren't around for the early days of compiler development without telling me you weren't around for the early days of compiler development...

(Actually, for niche architectures LLVM is also pretty bug-riddled. Maybe with AI we can finally fix some of that.)

and its code is... well, it's not bad, so let's quantify it as good, or good enough

If "good enough" isn't actually good enough, why are you calling it that? Your entire argument hinges on high code quality not being high code quality. Like... yeah, of course bad code is going to lead to bad outcomes. That's literally the entire point he's trying to make: the tool doesn't matter, the result does.

No part of my argument hinges on ZFS code being good quality. My argument is that ZFS code is desirable.

the tool doesn't matter, the result does.

The argument "the method doesn't matter, only results" has been the source of so many ethics and academic violations. You saying that with a straight face says enough about you. Bye.

Don't call me Shirley, though

Competent developers make mistakes too. I think it's worth at least skimming every line in a PR. Things like indexing out of bounds should probably be handled by testing or using a memory safe language.

I don't think code review is the place where you should be trying to catch bugs in the minutia of the code. You should be assessing readability/maintainability, architectural decisions, risk, and testing strategy. That does involve reading all of the code, even if only by skimming.

They don't even need to be pretty good. They just need to be better than the parade of absolute morons who couldn't engineer their way out of a paper bag but think they are a Senior Developer because they managed to bluff their way through 3 years in an outspurcing company by cutting and pasting from Stack Overflow. They make up 90% of the software development workforce, and they are the ones that have been burning out the real Software Engineers since the day the first Bangalore development centre opened.

Thankfully, that bar has been crossed; AI is already at the level where you don't have to explain to it what a semaphore is using stick figures and crayon - this is an absolute golden fucking era for senior engineers and architects.

It's because he's making a poor argument, as explained better by others throughout this thread.

I won't, if you need an academical definitions of fascism or genocide to be able to spot and fight them, better go to Reddit or 4chan for this kind of troll-y shit. Fascism is not tolerable, period.

Our thoughts and prayers are with Linus and his family at this difficult and tragic time.

The point is a tool is something you wield. Your skill is needed for and improved by the use of a tool. An LLM is an automation. You don't wield it, you give directives. Your skill is unnecessary for its use and is left untrained. The worst part is that, unlike a good, deterministic automation (like cruise control), where you understand the limitations and can take over to avoid them, you can't do that with LLMs. The best you can do is carefully review the slop output.

I think you are critically (I'm not saying intentionally) missing the middle ground in your assessment. Large generative models are great for repetitive, homogenous tasks like surveillance, speech recognition, assembly line quality control, etc.

If I try to look at it from your point of view, regarding creative tasks like developing new software, you have one side claiming that you can make hammers out of chocolate and throw away all your proper ones, and another that's portrayed as being unreasonable for opposing that.

1990 Berlin, I spent the day with a "Kein Fußbreit den Faschisten" punk, he didn't have his mohawk "up" but he was vehament: "When you see a fascist you must beat him up" - which, to me, is missing the point - bringing yourself down to their level. Of course this was on the actual streets with actual fists, knives, bats, and firebombs where people were actually dying, and worse: being maimed for life - not some idealistic internet ranting.

So, yeah, rant all you like, but even if they are calling themselves Neo-Nazi skinheads all over again, don't be killing each other on my lawn - thanks.

I'm not missing the middle ground. I am criticising that there is no middle ground in this fake discussion manufactured to keep engagement going.

Every single time someone makes a nuanced argument that is not matching one of the two dogmatic extremes (so exactly that Linus Torvalds is doing here, just –Linus being Linus– not very diplomatically phrased) the same kind of people start screaming about the end of the world (see again: this very thread where idiots express their condolences for Linus finally going insane by not denouncing AI alongside those praising the fact that he finally has seen the light an embraces AI as our saviour).

I guess I don't really count skimming as reading haha

When looking for readability, maintainability, etc what I mainly look for are design patterns. If you're using the same boilerplate and layout I'm going to start skipping over sections

I also mainly work on high performance embedded systems that are difficult/nearly impossible to unit test and I dont always have line coverage metrics. A lot more verification by inspection in my corner of the world

You do that inherently when you are writing the code. Every line you write has already had that focus, because you had to come up with it.

That you should also not trust every line of the compiled assembly after you wrote the code, and check it lime by line, is an extremely stupid argument.

Of course, you should get someone else, with a fresh/unbiased opinion to review your code too, but just the act of figuring out every line you write is in some sense a rewiev, that there is at least a plan or reason why it was written.

AI just randomly generates code without thought or reason, and you have to check everything. Unlike assembly generated from code.

What was the non-determinism in compilers? Honest question. Like, where does it comes from?

If you had a bug in a compiler, and a code that caused it, would it, for the same input and architecture only show some of the time? Does it included randomness in how it handles output?

Being bug-ridden is not the same as non-determinstic, if you can reproduce the bug everywhere and thus fix it, so I'm honestly curious where would the non-determinism of compilers come from.

Firstly, non-determinism isn't nearly the gotcha you think it is - it's trivial to make an LLM deterministic by just passing one parameter to the inference engine.

Secondly, nothing is non-deterministic in a strict sense on any traditional computer architecture (including the ones LLMs run on). Given all the inputs, and all the algorithms I can recreate the output; what makes the output 'non deterministic' is the complexity of the input and the feasibility of doing that. Frankly, compilers come pretty close to reaching the necessary complexity to be practically non-deterministic; anyone who had never spent days banging their head against code that works perfectly with debug enabled but fails utterly when compiled with release optimisations, but only when two logically entirely unrelated pieces of code happen to be written in a particular order, and then only if interrupts are enabled on the target... Well, anyone who hasn't been through that has no business calling themselves a software engineer - and certainly no business telling other software engineers what tools they are allowed to use.

Honestly, a bunch of wets brought up on PHP and Javascript and managed runtimes now thinking they're qualified to dictate what Real Programming entails is just laughable.

Frankly, compilers come pretty close to reaching the necessary complexity to be practically non-deterministic; anyone who had never spent days banging their head against code that works perfectly with debug enabled but fails utterly when compiled with release optimisations, but only when two logically entirely unrelated pieces of code happen to be written in a particular order, and then only if interrupts are enabled on the target… Well, anyone who hasn’t been through that has no business calling themselves a software engineer - and certainly no business telling other software engineers what tools they are allowed to use.

that is still deterministic.... you don't understand what deterministic means.

go ahead and show us an llm that is deterministic with a parameter passed to the inference engine. I'll wait.

high performance embedded systems that are difficult/nearly impossible to unit test

Sort of a change in topic, but I'm curious why that would be so difficult to test.

That you should also not trust every line of the compiled assembly after you wrote the code, and check it lime by line, is an extremely stupid argument.

I guess it's good that no one is making that argument then.

'all he should care about is that we increased profits, the effect on everything external has no bearing on my decisions"

the earth hates people like you.

AI detection doesn’t work and leads to a lot of false positives

Anthropic have begun watermarking their outputs (which is possible thanks to EU legislation) so yes you can detect ai output.

that is the argument linus is making... he is comparing a deterministic tool (a compiler that outputs the same assembly every time) to a non-deterministic tool and saying that they are the same type of tool. that require the same level of review, when they do not.

tell us of a software tool that isn't deterministic.

There's a couple big reasons, sometimes you only have to deal with one or two, other times you're hit with all of them.

The data source for the algorithms often comes from arbitrary memory addresses that live outside the context of the C, C++, or Rust runtime. If I want to read CPU core temp I send magic numbers to one address to configure ADC channel conversion, another magic number somewhere else to do the conversion, wait a few dozen microseconds, then read a third new address that I squint one eye, spin around 10 times, and do a handstand and I'll get a number that looks like temperature.

If I'm running on the microcontroller, I'm essentially in production environment and I can't control what the data is. If I recompile for a different system (say x86 Linux) then I'm almost certainly going to segfault. I could abstract out the reading of the data, but then on my tiny 8MHz microcontroller that has to run it's main loop at 1000Hz, I only have a few thousand clock cycles to get everything done, calling functions, pushing/popping the stack takes a lot of time.

Adding to the pile-on most microcontrollers have <1MB of RAM, many in the tens of kilobytes range so I don't have much of a stack to work with and I need to keep even the number of instructions down.

Even if you do all the abstractions, you then have extra logic you have to write to simulate what is happening and subtle behaviors that are timing dependant. It frequently is extremely difficult to do that as the documentation rarely fully describes everything, so you can lull yourself into a false sense of security that you've tested the code and it's correct, but then you get stuck on a register value that never changes and a watchdog timer comes along and resets the hardware on you.

And that's not the getting into the runtime or build environments, flashing procedures, limited flash cycles, and a million other business constraints that technically you can do it, but at that point your dev team has all taken the month off to go play Half Life 3

he is comparing a deterministic tool with a non-deterministic tool

Yes, but that's not the argument Mikina was stating. Linus was never advocating for reading assembly line by line. Linus was using that as a satirical example, not suggesting anyone should actually do that.

That definitely increases the challenge of writing tests or trusting that they are faithfully representing your production environment.

I could abstract out the reading of the data

I was going to suggest this, and it sounds like that ends up being expensive. It seems like you need some kind of test harness that's able to emulate your specific hardware while still allowing for testing hooks that don't impede the tight clock scheduling.

If unit tests are being done, some kind of emulator is usually what gets used and the scope of testing is significantly limited.

The more common approach is to abandon unit tests all together and go for board functional tests where as many of the external interfaces are controlled and put through representative loads. The complexity of the software is rarely that high so we can be pretty confident that we're covering everything we need to care about anyways.