7 ms·

Shouldn’t the floppy driver be incredibly stable code after all these years? It’s surely in maintenance mode rather than feature development, and surely all the

Shouldn’t the floppy driver be incredibly stable code after all these years? It’s surely in maintenance mode rather than feature development, and surely all the bugs have been ironed out by now!

tachyonbeam 7y ago
> surely all the bugs have been ironed out by now! Famous last words.
rosser 7y ago
Maintaining that kind of code is often less about dealing with lingering bugs, than it is about making sure that it's kept in sync with changes to the rest of the kernel that might be relevant. If some kernel structure that the FDD driver uses changes, it needs to know that. EDIT: Phrasing
- ergothus 7y ago
  > about making sure that it's kept in sync with changes to the rest At one of my workplaces we had an application that was without a formal supporter and everyone hated to touch it. After I was assigned to dive in to fix a bug, I did a study of how it got that way. I was very surprised by the results I found. Basically, two things went wrong: * Firstly, due to some mismanagement, the local team moved away, leaving it unsupported. * Secondly, outside code underwent some paradigm shifts, meaning that anyone who knew outside code found this code to be foreign. Often, people assigned to fix bugs/add features in this code would try to apply the outside paradigms without understanding or adapting the local conventions, creating ugly code interfaces. Here was the part that amazed me: The time between this code being not-perfect-but-perfectly-normal and becoming ugh-I-hope-I-don't-have-to-touch-that was _6 months_(!) We've always known that technical debt becomes a problem, but I had no idea it would compound so quickly. Granted, this was at a "post-startup" company going through rapid change as the scope of work kept increasing, but that's still a startlingly fast decay rate for code that was decently written and tested. Definitely proved to me the value of an active maintainer.
  - rosser 7y ago
    Yeah, that kind of "process" probably invites code rot. It's subtle, insidious, and yes, sometimes, shockingly quick to set in.
  - rodgerd 7y ago
    As a witter person that I put it, "code ages like milk, not like wine".
  - tylerrobinson 7y ago
    It's remarkable how closely this fits with a system at my company. Without close attention, things can spiral out of control faster than you can imagine.
- dfcmt 7y ago
  That's what happens when you choose not to have a stable API for drivers. Maybe Linux developers should reconsider that ;-)
sp332 7y ago
Yeah, but you never know when something somewhere else in the kernel might break it. And not many people have the hardware (not to mention patience) to run a bunch of regression tests for new releases.
JustSomeNobody 7y ago
> Shouldn’t the floppy driver be incredibly stable code after all these years? Not if it calls or is called by code that changes more frequently.
scarejunba 7y ago
Say you modify the HAL interface, then you need to edit this to work as well.
- lostgame 7y ago
  'I'm afraid the floppy kernel can't do that, Dave.'
gpvos 7y ago
A very recent commit fixed some out-of-bounds and a divide-by-zero error: https://github.com/torvalds/linux/commit/47d6a7607443ea43dbc4d0f371bf773540a8f8f4 https://github.com/torvalds/linux/commit/47d6a7607443ea43dbc...
dpcan 7y ago
Software ages by association. Whatever system it's on or associated with dictates its life span. Like if you put a soda on a block of ice outside. It will last through the winter and stay solid. Wait until spring and things start getting slippery and wet. The ice and soda are showing signs of aging. Summer hits, and your soda crashes to the ground, spills, everything is just sticky, unusable, and bugs are everywhere.
- moosingin3space 7y ago
  This is an excellent analogy and I can't understand why it's being downvoted. Software is only as useful as its surroundings find it useful.

Shouldn’t the floppy driver be incredibly stable code after all these years? It’s surely in maintenance mode rather than feature development, and surely all the bugs have been ironed out by now!

tachyonbeam 7y ago

> surely all the bugs have been ironed out by now! Famous last words.

rosser 7y ago

Maintaining that kind of code is often less about dealing with lingering bugs, than it is about making sure that it's kept in sync with changes to the rest of the kernel that might be relevant. If some kernel structure that the FDD driver uses changes, it needs to know that. EDIT: Phrasing

ergothus 7y ago
> about making sure that it's kept in sync with changes to the rest At one of my workplaces we had an application that was without a formal supporter and everyone hated to touch it. After I was assigned to dive in to fix a bug, I did a study of how it got that way. I was very surprised by the results I found. Basically, two things went wrong: * Firstly, due to some mismanagement, the local team moved away, leaving it unsupported. * Secondly, outside code underwent some paradigm shifts, meaning that anyone who knew outside code found this code to be foreign. Often, people assigned to fix bugs/add features in this code would try to apply the outside paradigms without understanding or adapting the local conventions, creating ugly code interfaces. Here was the part that amazed me: The time between this code being not-perfect-but-perfectly-normal and becoming ugh-I-hope-I-don't-have-to-touch-that was _6 months_(!) We've always known that technical debt becomes a problem, but I had no idea it would compound so quickly. Granted, this was at a "post-startup" company going through rapid change as the scope of work kept increasing, but that's still a startlingly fast decay rate for code that was decently written and tested. Definitely proved to me the value of an active maintainer.
- rosser 7y ago
  Yeah, that kind of "process" probably invites code rot. It's subtle, insidious, and yes, sometimes, shockingly quick to set in.
- rodgerd 7y ago
  As a witter person that I put it, "code ages like milk, not like wine".
- tylerrobinson 7y ago
  It's remarkable how closely this fits with a system at my company. Without close attention, things can spiral out of control faster than you can imagine.
dfcmt 7y ago
That's what happens when you choose not to have a stable API for drivers. Maybe Linux developers should reconsider that ;-)

sp332 7y ago

Yeah, but you never know when something somewhere else in the kernel might break it. And not many people have the hardware (not to mention patience) to run a bunch of regression tests for new releases.

JustSomeNobody 7y ago

> Shouldn’t the floppy driver be incredibly stable code after all these years? Not if it calls or is called by code that changes more frequently.

scarejunba 7y ago

Say you modify the HAL interface, then you need to edit this to work as well.

lostgame 7y ago
'I'm afraid the floppy kernel can't do that, Dave.'

gpvos 7y ago

A very recent commit fixed some out-of-bounds and a divide-by-zero error: https://github.com/torvalds/linux/commit/47d6a7607443ea43dbc4d0f371bf773540a8f8f4 https://github.com/torvalds/linux/commit/47d6a7607443ea43dbc...

dpcan 7y ago

Software ages by association. Whatever system it's on or associated with dictates its life span. Like if you put a soda on a block of ice outside. It will last through the winter and stay solid. Wait until spring and things start getting slippery and wet. The ice and soda are showing signs of aging. Summer hits, and your soda crashes to the ground, spills, everything is just sticky, unusable, and bugs are everywhere.

moosingin3space 7y ago
This is an excellent analogy and I can't understand why it's being downvoted. Software is only as useful as its surroundings find it useful.