No need to be an extremist. Linux (and Debian especially) allows for things like installing older kernel versions which are less slopified.
(Sometimes that’s necessary according to the Debian Wiki too because of things like certain drivers coughnvidiacough coughatheroscough not being well functional after a given kernel version, but so far I’ve fortunately avoided that scramble)
I mean if you are ok with literally thousands of known exploits older kernels are fine. Personally I run modern Linux. I don’t want to run an older version with literally thousands of known exploits.
Read the release notes for each kernel release. Literally 1000+ CVEs each.
I mean it’s not like I’m gonna plug a machine directly to a T1 connection on the building where the DNS root server is hosted, with no firewall or NAT or something. Specific exploits are good to know, but they are not the end-all of how a machine interacts with the outside world.
A good bunch of exploits require someone to already have an account on the system to run software, for example. That already creates a boundary for the scope of how to protect the system.
Plus, I (and anyone else) can only work within the frame of options that are actually provided. If no one is stepping up to make a «Debn» (Debian-minus-AI), then my choice is limited to just keep using the Debian that I can until I can jump to a better option. Similarly, if no one is stepping up to fix a given atheros driver so it works on a next kernel, I’m forced to use an older kernel if I need that device.
It’s not just remote. It’s any software you run getting root for free level stuff.
People are setting up an alternative. It’s NetBSD. Supporting no LLM assisted projects is the only long term solution.
It’s similar to the “windows 7 for life!” people. To them I say try Linux.
To the never LLM assisted code people I say. Don’t be like the windows 7 people. Have a long term mentality. Plan ahead. Use the systems that people are building without LLMs and support them.
I have no issue with NetBSD, but compatibility is a thing so I have to watch it while it progresses. The safest and securest system is useless if it can’t run your workflow after all.
The current kernel I’m using (coughatheroscough) can do what I need to do. If a later kernel comes that also can, that’d be wonders. Until it does, I’m exploring my alternatives but I’m also reserving my right to not be anyone else’s free alpha tester.
No need to be an extremist. Linux (and Debian especially) allows for things like installing older kernel versions which are less slopified.
(Sometimes that’s necessary according to the Debian Wiki too because of things like certain drivers coughnvidiacough coughatheroscough not being well functional after a given kernel version, but so far I’ve fortunately avoided that scramble)
I mean if you are ok with literally thousands of known exploits older kernels are fine. Personally I run modern Linux. I don’t want to run an older version with literally thousands of known exploits.
Read the release notes for each kernel release. Literally 1000+ CVEs each.
I mean it’s not like I’m gonna plug a machine directly to a T1 connection on the building where the DNS root server is hosted, with no firewall or NAT or something. Specific exploits are good to know, but they are not the end-all of how a machine interacts with the outside world.
A good bunch of exploits require someone to already have an account on the system to run software, for example. That already creates a boundary for the scope of how to protect the system.
Plus, I (and anyone else) can only work within the frame of options that are actually provided. If no one is stepping up to make a «Debn» (Debian-minus-AI), then my choice is limited to just keep using the Debian that I can until I can jump to a better option. Similarly, if no one is stepping up to fix a given atheros driver so it works on a next kernel, I’m forced to use an older kernel if I need that device.
It’s not just remote. It’s any software you run getting root for free level stuff.
People are setting up an alternative. It’s NetBSD. Supporting no LLM assisted projects is the only long term solution.
It’s similar to the “windows 7 for life!” people. To them I say try Linux.
To the never LLM assisted code people I say. Don’t be like the windows 7 people. Have a long term mentality. Plan ahead. Use the systems that people are building without LLMs and support them.
I have no issue with NetBSD, but compatibility is a thing so I have to watch it while it progresses. The safest and securest system is useless if it can’t run your workflow after all.
The current kernel I’m using (coughatheroscough) can do what I need to do. If a later kernel comes that also can, that’d be wonders. Until it does, I’m exploring my alternatives but I’m also reserving my right to not be anyone else’s free alpha tester.
What kernel are you using? If it’s from the past year or two it’s LLM assisted. Any supported LTS kernel is LLM assisted even if it’s older.
Also what software are you using that doesn’t run on NetBSD? All proprietary software is LLM assisted, Steam for sure.
Nvidia and AMD Linux drivers are LLM assisted too.
All Wayland desktops have an x11 version that are pre LLM.
Even stuff like kden live works on NetBSD.
What would you miss?