5 ms·

> Sometimes it takes very long for things to die definitively. And other times it occurs very quickly and for no good reason. Linux gleefully deletes functiona

> Sometimes it takes very long for things to die definitively. And other times it occurs very quickly and for no good reason. Linux gleefully deletes functionality like hardware accelerated framebuffer scrolling, because the devs can't be bothered to decouple code or maintain existing work. It is interesting because 15 years ago I'd have assumed it to be a byproduct of a free software virality strategy - making the use of outside code as painful as possible by providing no stability beyond exported GPL symbols. But now, with the wildly successful corporate push in Open™ Source©, I'm starting to wonder if it is just a happy accident that software-defined planned obsolescence is now a thing. All those GPL vs BSD licensed code debates... funny how things work out.

medstrom 5y ago
Can you unpack? Software-defined planned obsolescence?
- sennight 5y ago
  Sure. Hardware producers have zero interest in supporting hardware they don't sell anymore, and if they sell a newer version that competes with the old then such maintenance is doubly costly - as it cuts into potential sales. But they can rely on developer laziness to eventually render what would otherwise be a durable good - into a consumable that must be constantly replaced in a predictable cycle. See the entirety of the smartphone market, for example. Apple chose its logo well, it is well documented that they've crippled functional hardware through software updates - turning hardware into a perishable good. But Android might provide the best example of grotesquely wasteful consumerism - only made possible by the ever dependable, and yet somehow still plausibly deniable, software bit rot.
znpy 5y ago
> because the devs can't be bothered to decouple code or maintain existing work patches are welcome, I guess
- sennight 5y ago
  No they aren't, that is the point made when: the deprecation is announced, preprocessor flags are added to cordon off the code and throw compilation warnings, finally - the code is deleted. The burden is then shifted onto the hardware producer to maintain their now disconnected code, and adapt to breaking changes blindly made by anyone not accounting for the situation (basically everyone). This obviously doesn't happen, because maintaining code for hardware they no longer sell isn't profitable. At most, the manufacturers will offer a few pre-compiled blobs for the most popular system configurations - which really sucks for anyone who actually subscribes to the ideals originally espoused by free software proponents.
  - znpy 5y ago
    you can fork stuff and keep rebasing things around and/or maintain your own fork, I guess. > which really sucks for anyone who actually subscribes to the ideals originally espoused by free software proponents. the ideals of free software is for software to be free (according to the four fundamental freedoms) and not to work on all and every hardware and to maintain software indefinitely. anything besides the four foundamental freedoms is BS.
    - sennight 5y ago
      > the ideals of free software is for software to be free (according to the four fundamental freedoms)... No, it is to ensure that people are free - as software doesn't know the difference. Would you deny the existence of business strategies that endeavor to curtail such freedom, or do you view those as okeydokey 'cause SaaS wasn't explicitly mentioned by the FSF in the 80s?

medstrom 5y ago

Can you unpack? Software-defined planned obsolescence?

sennight 5y ago
Sure. Hardware producers have zero interest in supporting hardware they don't sell anymore, and if they sell a newer version that competes with the old then such maintenance is doubly costly - as it cuts into potential sales. But they can rely on developer laziness to eventually render what would otherwise be a durable good - into a consumable that must be constantly replaced in a predictable cycle. See the entirety of the smartphone market, for example. Apple chose its logo well, it is well documented that they've crippled functional hardware through software updates - turning hardware into a perishable good. But Android might provide the best example of grotesquely wasteful consumerism - only made possible by the ever dependable, and yet somehow still plausibly deniable, software bit rot.

znpy 5y ago

> because the devs can't be bothered to decouple code or maintain existing work patches are welcome, I guess

sennight 5y ago
No they aren't, that is the point made when: the deprecation is announced, preprocessor flags are added to cordon off the code and throw compilation warnings, finally - the code is deleted. The burden is then shifted onto the hardware producer to maintain their now disconnected code, and adapt to breaking changes blindly made by anyone not accounting for the situation (basically everyone). This obviously doesn't happen, because maintaining code for hardware they no longer sell isn't profitable. At most, the manufacturers will offer a few pre-compiled blobs for the most popular system configurations - which really sucks for anyone who actually subscribes to the ideals originally espoused by free software proponents.
- znpy 5y ago
  you can fork stuff and keep rebasing things around and/or maintain your own fork, I guess. > which really sucks for anyone who actually subscribes to the ideals originally espoused by free software proponents. the ideals of free software is for software to be free (according to the four fundamental freedoms) and not to work on all and every hardware and to maintain software indefinitely. anything besides the four foundamental freedoms is BS.
  - sennight 5y ago
    > the ideals of free software is for software to be free (according to the four fundamental freedoms)... No, it is to ensure that people are free - as software doesn't know the difference. Would you deny the existence of business strategies that endeavor to curtail such freedom, or do you view those as okeydokey 'cause SaaS wasn't explicitly mentioned by the FSF in the 80s?