3 ms·

> Moving really old and unused code out of the kernel just to get less AI-assisted bug reports Obviously, the parent is /s, but when I read this, I thought Lin

by fn-mote 4mo ago

> Moving really old and unused code out of the kernel just to get less AI-assisted bug reports Obviously, the parent is /s, but when I read this, I thought Linux was removing exploit paths that exercise rarely-used features. On phone OSes at least, quirky rare formats and features are (were?) a common source of exploitable bugs.

asgraham 4mo ago
Is the parent really being sarcastic? I read it as genuine. There’s presumably plenty of code bloat in the kernel, and while no human would ever scan for bugs in a corner of the kernel that hasn’t been used or touched in decades, AI 100% will. And while those bug reports might be useless as bug reports, they seem promising as “why is this code even here?” flags.
- dormento 4mo ago
  I don't mean to be harsh, but if there's a codepath that is exercised on your hardware, but not on mine, I don't think it would be fair for me to deem it as "bloat". There are a TON of supported devices and use cases that are not my own, but are essential to someone else.
  - WD-42 4mo ago
    If you are still using ISDN you could maintain a fork. This is one of the main examples of drivers that were removed.
  - asgraham 4mo ago
    Sure, sure. I’m not arguing for removing drivers for uncommon devices, or even rare devices. But there’s a line somewhere. Maybe it’s at “devices that no longer exist.” But I think it’s somewhere before that. And I have no idea how you’d figure out which devices fall where around this hypothetical line. I can only hope that they had good justification for these removals.
  - franktankbank 4mo ago
    Maybe that points to an architecture issue? Is kernel driver support general enough to support all hardware in theory? If so it should be on hardware to provide a compatible api IMO. Note: I really have no experience in any of this there is probably more important things to consider like security/control or something.
rixed 4mo ago
Exploit paths in unloaded modules, I guess.

by fn-mote 4mo ago

asgraham 4mo ago

Is the parent really being sarcastic? I read it as genuine. There’s presumably plenty of code bloat in the kernel, and while no human would ever scan for bugs in a corner of the kernel that hasn’t been used or touched in decades, AI 100% will. And while those bug reports might be useless as bug reports, they seem promising as “why is this code even here?” flags.

dormento 4mo ago
I don't mean to be harsh, but if there's a codepath that is exercised on your hardware, but not on mine, I don't think it would be fair for me to deem it as "bloat". There are a TON of supported devices and use cases that are not my own, but are essential to someone else.
- WD-42 4mo ago
  If you are still using ISDN you could maintain a fork. This is one of the main examples of drivers that were removed.
- asgraham 4mo ago
  Sure, sure. I’m not arguing for removing drivers for uncommon devices, or even rare devices. But there’s a line somewhere. Maybe it’s at “devices that no longer exist.” But I think it’s somewhere before that. And I have no idea how you’d figure out which devices fall where around this hypothetical line. I can only hope that they had good justification for these removals.
- franktankbank 4mo ago
  Maybe that points to an architecture issue? Is kernel driver support general enough to support all hardware in theory? If so it should be on hardware to provide a compatible api IMO. Note: I really have no experience in any of this there is probably more important things to consider like security/control or something.

rixed 4mo ago

Exploit paths in unloaded modules, I guess.