5 ms·

I 1000% agree. Not everything needs 64bit. This is forced manufactured obsolescence

WJW 6y ago
Linux is pretty much the original open source project. Just fork the repo and maintain 32 bit code yourself if you want to keep it.
- hnlmorg 6y ago
  > Linux is pretty much the original open source project It's not. GNU pre-dates Linux by nearly 10 years. But even if you're talking strictly about kernels, 386BSD and Hurd were started before Linux. > Just fork the repo and maintain 32 bit code yourself if you want to keep it. I've often noticed -- and not just on here -- that when commenters prefix "just" to a sentence, the work involved is usually non-trivial.
  - WJW 6y ago
    > I've often noticed -- and not just on here -- that when commenters prefix "just" to a sentence, the work involved is usually non-trivial. That was the joke, yes. The post I was responding to was complaining about "forced" obsolescence while there is nothing of the sort. Upstream maintainers want to drop some legacy code so they can spend more time on newer machines. GP apparently does not want to upgrade and is now complaining that other people don't do the non-trivial work of keeping 32 bit linux updated for free.
    - arp242 6y ago
      Maintaining a 32bit Linux fork which includes just security patches and (critical) bugfixes would actually be a lot less work than keep maintaining 32bit support for all new feature development. Maintaining a "32bit LTS" fork of Linux like this would probably be pretty viable.
      - the_why_of_y 6y ago
        Keep in mind that in this space, "security patch" might come in the form of rewriting the architecture specific virtual memory implementation... https://lwn.net/Articles/741878/ https://lwn.net/Articles/741878/
        arp242 6y ago
        You'd hope that we're finished with working around all the CPU bugs now, but yeah, it's not necessarily trivial, and the longer the fork exists, the harder it will be to backport patches. But I can see how you can build a business maintaining a Linux LTS (there are businesses offering Rails LTS, Microsoft offers updates for Windows XP if you pay), so there's some precedent here.
  - carlhjerpe 6y ago
    It's also nontrivial for the people currently maintaining the Linux kernel. I interpret the "just" as a way to hint that forcing someone else to keep doing something for free, you could just do it yourself.
diegocg 6y ago
You could argue the same for 16 bit CPUs. If the vast majority of CPUs sold are 64 bits, we will to a point (we are already halfway there) where 64 bit CPUs could be cheaper (more competence and variety) and even more energy efficient.
- pantalaimon 6y ago
  linux never ran on 16 bit CPUs. that being said, CPUs like the 8051 are still very much alive today.
  - cesarb 6y ago
    > linux never ran on 16 bit CPUs. https://en.wikipedia.org/wiki/Embeddable_Linux_Kernel_Subset https://en.wikipedia.org/wiki/Embeddable_Linux_Kernel_Subset
    - ohazi 6y ago
      This was a toy project that was never mainlined
      - usr1106 6y ago
        It doesn't need to mainlained in the same Linux upstream to be serious. I am not familiar with it to say whether it really wasn't that useful for inherent reasons or whether vendors in that space were just more lucky to defend their proprietary solutions than the (mainline) Linux competitors.
- usr1106 6y ago
  While 16 bit CPUs are good for many purposes, these are not the same purposes where you have run Linux ever and where 32 bit is currently being replaced by 64 bit. So the analogy is not helpful. Maybe 64 bit CPUs can get more resource efficient than older 32 bit models. But that's a misdirected use of resources if you use such technolgy to make 32 bit CPUs obsolete. With the same technology 32 bit will always use less resource-demanding than 64 bit. And the claim was that 32 bit has so many use cases (basically all phones and many PCs) that economics of scale are possible. Of course the nonsense model that you don't pay for Internet services directly, but use Javascript and a lot of other bloat software to run advertisements on your phone to pay via a massive detour is not an energy-efficient approach.

WJW 6y ago

Linux is pretty much the original open source project. Just fork the repo and maintain 32 bit code yourself if you want to keep it.

hnlmorg 6y ago
> Linux is pretty much the original open source project It's not. GNU pre-dates Linux by nearly 10 years. But even if you're talking strictly about kernels, 386BSD and Hurd were started before Linux. > Just fork the repo and maintain 32 bit code yourself if you want to keep it. I've often noticed -- and not just on here -- that when commenters prefix "just" to a sentence, the work involved is usually non-trivial.
- WJW 6y ago
  > I've often noticed -- and not just on here -- that when commenters prefix "just" to a sentence, the work involved is usually non-trivial. That was the joke, yes. The post I was responding to was complaining about "forced" obsolescence while there is nothing of the sort. Upstream maintainers want to drop some legacy code so they can spend more time on newer machines. GP apparently does not want to upgrade and is now complaining that other people don't do the non-trivial work of keeping 32 bit linux updated for free.
  - arp242 6y ago
    Maintaining a 32bit Linux fork which includes just security patches and (critical) bugfixes would actually be a lot less work than keep maintaining 32bit support for all new feature development. Maintaining a "32bit LTS" fork of Linux like this would probably be pretty viable.
    - the_why_of_y 6y ago
      Keep in mind that in this space, "security patch" might come in the form of rewriting the architecture specific virtual memory implementation... https://lwn.net/Articles/741878/ https://lwn.net/Articles/741878/
      - arp242 6y ago
        You'd hope that we're finished with working around all the CPU bugs now, but yeah, it's not necessarily trivial, and the longer the fork exists, the harder it will be to backport patches. But I can see how you can build a business maintaining a Linux LTS (there are businesses offering Rails LTS, Microsoft offers updates for Windows XP if you pay), so there's some precedent here.
- carlhjerpe 6y ago
  It's also nontrivial for the people currently maintaining the Linux kernel. I interpret the "just" as a way to hint that forcing someone else to keep doing something for free, you could just do it yourself.

diegocg 6y ago

You could argue the same for 16 bit CPUs. If the vast majority of CPUs sold are 64 bits, we will to a point (we are already halfway there) where 64 bit CPUs could be cheaper (more competence and variety) and even more energy efficient.

pantalaimon 6y ago
linux never ran on 16 bit CPUs. that being said, CPUs like the 8051 are still very much alive today.
- cesarb 6y ago
  > linux never ran on 16 bit CPUs. https://en.wikipedia.org/wiki/Embeddable_Linux_Kernel_Subset https://en.wikipedia.org/wiki/Embeddable_Linux_Kernel_Subset
  - ohazi 6y ago
    This was a toy project that was never mainlined
    - usr1106 6y ago
      It doesn't need to mainlained in the same Linux upstream to be serious. I am not familiar with it to say whether it really wasn't that useful for inherent reasons or whether vendors in that space were just more lucky to defend their proprietary solutions than the (mainline) Linux competitors.
usr1106 6y ago
While 16 bit CPUs are good for many purposes, these are not the same purposes where you have run Linux ever and where 32 bit is currently being replaced by 64 bit. So the analogy is not helpful. Maybe 64 bit CPUs can get more resource efficient than older 32 bit models. But that's a misdirected use of resources if you use such technolgy to make 32 bit CPUs obsolete. With the same technology 32 bit will always use less resource-demanding than 64 bit. And the claim was that 32 bit has so many use cases (basically all phones and many PCs) that economics of scale are possible. Of course the nonsense model that you don't pay for Internet services directly, but use Javascript and a lot of other bloat software to run advertisements on your phone to pay via a massive detour is not an energy-efficient approach.