3 ms·

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 to

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.
  - Aerbil313 2y ago
    I know those: Rewrites are bad, it's harder to read the code than write, a rewrite failing Netscape and many others, whatever. I aim to share a view I know is radical and controversial, that unequivocally all software needs a rewrite a decade, provided there is finances to do it.
    - dgfitz 2y ago
      I disagree. I think rewrites are sometimes the right thing, but rarely. The Linux kernel is a good example. Should we rewrite it? No of course not. So was your point about code that hasn’t been maintained in a decade? Sure, maybe then. But I can’t square “code that hasn’t been touched in a decade” with “still in active use today”
      - Aerbil313 2y ago
        The Linux kernel is the perfect example for my case. We should absolutely create a new OS to replace Linux. Just an example, and not only my opinion, rather a widespread one: There is no need for multiple mechanisms of interprocess communication, they only add to the complexity. Conway’s Law[1]: > Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. In his famous lecture [2], Casey Muratori makes the case that Conway’s Law applies over time too, meaning there is not a single organization, but multiple versions of the organization over time, and all of them end up adding more design (decisions) to the product. The best example, which he gives, is the 5 different UIs to change the sound level in Windows. Rewrites to old (10 years old as I said) software reset the age of the software to zero and very often drastically simplify both the design and the codebase. I’m not telling you to rewrite your 3 yo product. 1: https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law 2: https://youtu.be/5IUj1EZwpJY?t=1696 https://youtu.be/5IUj1EZwpJY?t=1696
- deleted 2y ago
  [deleted]
- nradov 2y ago
  Why?
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"?

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.
- Aerbil313 2y ago
  I know those: Rewrites are bad, it's harder to read the code than write, a rewrite failing Netscape and many others, whatever. I aim to share a view I know is radical and controversial, that unequivocally all software needs a rewrite a decade, provided there is finances to do it.
  - dgfitz 2y ago
    I disagree. I think rewrites are sometimes the right thing, but rarely. The Linux kernel is a good example. Should we rewrite it? No of course not. So was your point about code that hasn’t been maintained in a decade? Sure, maybe then. But I can’t square “code that hasn’t been touched in a decade” with “still in active use today”
    - Aerbil313 2y ago
      The Linux kernel is the perfect example for my case. We should absolutely create a new OS to replace Linux. Just an example, and not only my opinion, rather a widespread one: There is no need for multiple mechanisms of interprocess communication, they only add to the complexity. Conway’s Law[1]: > Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. In his famous lecture [2], Casey Muratori makes the case that Conway’s Law applies over time too, meaning there is not a single organization, but multiple versions of the organization over time, and all of them end up adding more design (decisions) to the product. The best example, which he gives, is the 5 different UIs to change the sound level in Windows. Rewrites to old (10 years old as I said) software reset the age of the software to zero and very often drastically simplify both the design and the codebase. I’m not telling you to rewrite your 3 yo product. 1: https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law 2: https://youtu.be/5IUj1EZwpJY?t=1696 https://youtu.be/5IUj1EZwpJY?t=1696
deleted 2y ago
[deleted]
nradov 2y ago
Why?

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"?