4 ms·

> Even just keeping the driver compilable with each kernel release often took some non-trivial refactoring, I realise that the kernel contributors themselves a

by exe34 2y ago

> Even just keeping the driver compilable with each kernel release often took some non-trivial refactoring, I realise that the kernel contributors themselves are mostly volunteers and as such can just do what they want, and writers of non-upstreamed drivers will need to get used to chasing trunk, but to me this sort of thing seems like a waste of human talent. once something works, it should never not work again. it seems to me that despite all the layers of cruft that we've accumulated over the decades haven't really helped much with this, in fact they probably mean more work just to stay still.

freedomben 2y ago
I've struggled philosophically with that very question as well (especially having to update my own WORKING code just to conform to API changes), and I'm very torn on it. I just don't think there's a good point to pick at which to "freeze" the API and say no more changes are allowed. It would greatly hamper innovation and IMHO ultimately lead the Linux kernel having major forks or being displaced by something more adaptable. Despite the pain points, I think it's an overall good, though that doesn't stop the stinging of having to keep up. It really forces you to either be in or out. It can be very difficult to be a part time contributor.
- exe34 2y ago
  I've always wondered about how versioning could help. i don't think it would work with a monolithic kernel, but a microkernel might allow you to run multiple versions of different things, and they would still work. I've also fantasised about the same thing in application programming languages - e.g. the way racket runs loads of different dialects, you could also have versioning for different things running at the same time.
  - dTal 2y ago
    POV-Ray does exactly this, and warns you if you do not include a #version statement in your source file.
- Aerbil313 2y ago
  Just accept the fact that software does age with time. If it didn't change a literal bit, the real world in runs for and the software ecosystem it runs on did. Any software older than 10 years should be rewritten from absolute scratch, not be kept on life support at ever increasing expense.
  - exe34 2y ago
    virtual machines exist, and it might be easier to run something in them than to port them every two years.
    - Aerbil313 2y ago
      I'm talking about innovation and progress. In an ideal world retro computing remains a hobby.
      - exe34 2y ago
        in my ideal world, innovation and progress means new software brings new functionality - not half the old functionality that barely works because "rewrite".
      - Piskvorrr 2y ago
        Progress is in the eye of the beholder. Case in point: Fiddler. A debugging HTTP proxy, originally a one-man-show; the Classic version is still amongst the most powerful tools out there. Except...well...there's no way to monetize it. So, a New and Innovated version, which is less powerful (yes, it has some new features, but at the expense of dropping the actual power tools), more bloated, and subscription-based. Progress!
  - dgfitz 2y ago
    I would encourage you to read this if you haven’t: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... There are exceptions to every rule, re-writing old software because it’s old needs a rare exception indeed.
- rob74 2y ago
  It not only makes it difficult to be a part time contributor, I imagine it also makes life more difficult for maintainers: before they accept a patch from a part time contributor, they always have to ask themselves "will this guy still be around to update his code when needed"?
JohnMakin 2y ago
Much of windows OS weirdness can be attributed to the fact they have a relentless dedication to backwards compatibility.
- wvenable 2y ago
  Much of Linux's weirdness can be attributed to that as well -- at least the userland API.
ak217 2y ago
The Linux kernel has an incredibly strong userspace API stability guarantee. I think in practice this guarantee is unmatched in modern computing, and it's what allows things like containers to deliver such incredible long term value. Software is defined by its interfaces, and unlike userspace APIs, this guarantee does not apply to internal kernel APIs. The ability to update the latter is what enables the former. Inability to update internal implementation details inevitably leads to ossification and obsolescence of the whole system. Linus Torvalds spoke about this recently in the context of new Rust code in the kernel.
- shiroiushi 2y ago
  >Inability to update internal implementation details inevitably leads to ossification and obsolescence of the whole system. No, in practice I think it leads to growing complexity, because the system then adds additional APIs (e.g., v1, v2, v3, etc.) to support new features, but has to continue to maintain the old APIs for backwards compatibility, leading to lots of extra code and a huge maintenance burden.
  - ak217 2y ago
    Yes, precisely. The escalating complexity, maintenance burden and constraints eventually cause the whole system to lose momentum, lose support and become obsolete.
  - viraptor 2y ago
    Like winapi with its ...Ex and numbered functions (NdrClientCall4).
    - poincaredisk 2y ago
      Or Linux with it's numbered syscalls (dup, dup2, dup3).
- nradov 2y ago
  Is there some reason that the Linux kernel couldn't offer a stable API for device drivers? At least for common types of devices. Would that really lead to ossification? Stable APIs usually make it easier to change code at lower levels.
regularfry 2y ago
Kernel contributors are mostly employees of hardware companies getting paid to contribute: https://lwn.net/Articles/941675/ https://lwn.net/Articles/941675/ It may be that in the hypothetical absence of a salary giving them an excuse, many of these individuals may also choose to volunteer, but it's wrong to call contributors "mostly volunteers" when that's their day job. Changesets from those known to be spending their own time on contributing are a relatively small fraction of the changes.

by exe34 2y ago

freedomben 2y ago

I've struggled philosophically with that very question as well (especially having to update my own WORKING code just to conform to API changes), and I'm very torn on it. I just don't think there's a good point to pick at which to "freeze" the API and say no more changes are allowed. It would greatly hamper innovation and IMHO ultimately lead the Linux kernel having major forks or being displaced by something more adaptable. Despite the pain points, I think it's an overall good, though that doesn't stop the stinging of having to keep up. It really forces you to either be in or out. It can be very difficult to be a part time contributor.

exe34 2y ago
I've always wondered about how versioning could help. i don't think it would work with a monolithic kernel, but a microkernel might allow you to run multiple versions of different things, and they would still work. I've also fantasised about the same thing in application programming languages - e.g. the way racket runs loads of different dialects, you could also have versioning for different things running at the same time.
- dTal 2y ago
  POV-Ray does exactly this, and warns you if you do not include a #version statement in your source file.
Aerbil313 2y ago
Just accept the fact that software does age with time. If it didn't change a literal bit, the real world in runs for and the software ecosystem it runs on did. Any software older than 10 years should be rewritten from absolute scratch, not be kept on life support at ever increasing expense.
- exe34 2y ago
  virtual machines exist, and it might be easier to run something in them than to port them every two years.
  - Aerbil313 2y ago
    I'm talking about innovation and progress. In an ideal world retro computing remains a hobby.
    - exe34 2y ago
      in my ideal world, innovation and progress means new software brings new functionality - not half the old functionality that barely works because "rewrite".
    - Piskvorrr 2y ago
      Progress is in the eye of the beholder. Case in point: Fiddler. A debugging HTTP proxy, originally a one-man-show; the Classic version is still amongst the most powerful tools out there. Except...well...there's no way to monetize it. So, a New and Innovated version, which is less powerful (yes, it has some new features, but at the expense of dropping the actual power tools), more bloated, and subscription-based. Progress!
- dgfitz 2y ago
  I would encourage you to read this if you haven’t: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... There are exceptions to every rule, re-writing old software because it’s old needs a rare exception indeed.
rob74 2y ago
It not only makes it difficult to be a part time contributor, I imagine it also makes life more difficult for maintainers: before they accept a patch from a part time contributor, they always have to ask themselves "will this guy still be around to update his code when needed"?

JohnMakin 2y ago

Much of windows OS weirdness can be attributed to the fact they have a relentless dedication to backwards compatibility.

wvenable 2y ago
Much of Linux's weirdness can be attributed to that as well -- at least the userland API.

ak217 2y ago

The Linux kernel has an incredibly strong userspace API stability guarantee. I think in practice this guarantee is unmatched in modern computing, and it's what allows things like containers to deliver such incredible long term value. Software is defined by its interfaces, and unlike userspace APIs, this guarantee does not apply to internal kernel APIs. The ability to update the latter is what enables the former. Inability to update internal implementation details inevitably leads to ossification and obsolescence of the whole system. Linus Torvalds spoke about this recently in the context of new Rust code in the kernel.

shiroiushi 2y ago
>Inability to update internal implementation details inevitably leads to ossification and obsolescence of the whole system. No, in practice I think it leads to growing complexity, because the system then adds additional APIs (e.g., v1, v2, v3, etc.) to support new features, but has to continue to maintain the old APIs for backwards compatibility, leading to lots of extra code and a huge maintenance burden.
- ak217 2y ago
  Yes, precisely. The escalating complexity, maintenance burden and constraints eventually cause the whole system to lose momentum, lose support and become obsolete.
- viraptor 2y ago
  Like winapi with its ...Ex and numbered functions (NdrClientCall4).
  - poincaredisk 2y ago
    Or Linux with it's numbered syscalls (dup, dup2, dup3).
nradov 2y ago
Is there some reason that the Linux kernel couldn't offer a stable API for device drivers? At least for common types of devices. Would that really lead to ossification? Stable APIs usually make it easier to change code at lower levels.

regularfry 2y ago

Kernel contributors are mostly employees of hardware companies getting paid to contribute: https://lwn.net/Articles/941675/ https://lwn.net/Articles/941675/ It may be that in the hypothetical absence of a salary giving them an excuse, many of these individuals may also choose to volunteer, but it's wrong to call contributors "mostly volunteers" when that's their day job. Changesets from those known to be spending their own time on contributing are a relatively small fraction of the changes.