Announcement

Collapse
No announcement yet.

Linux Might Better Plan Its Code/Hardware Obsolescence From The Kernel

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by rmfx View Post
    get rid of the max things you can !

    32bit / useless arch / uselss fs / prehitoric hardware drivers...

    Programs need a shower time to time too.

    People who want to use very obsolete hardware shouldn't not be given the privilege of getting the very latest software... efforts go in both direction.
    How very elitist of you...

    Comment


    • #22
      The concept of "obsolete hardware", to quote the term used in the presentation slides, MUST BE carefully defined.

      Some vendors like to change their hardware more frequently than most people change their undershirts.

      If "obsolete hardware" is defined as "hardware no longer in production", then we could see something I would call "source code thrashing" taking place in the Linux kernel. Code being inserted 6 months to a year after the hardware appears, only to have it disappear in 6 months to a year because "hardware no longer in production".

      While code inserts and deletes are typically not a problem for a source code repository, it's the interactions among all of that code that now gets called into question. Somebody has to fix the bugs once they are reported and reproduced. Sadly, bug fixing depends upon accurate bug reports and the ability to reproduce the bug; those situations that don't occur often enough according to many developers. The end result is a Linux kernel that was relatively stable (one of it's hallmarks), even in it's RC versions, eventually becomes a churning morass of instability due to unresolved bugs. The thought of "WONTFIX" replies to submitted bugs due to "obsolete hardware" that resulted in now deleted code is scary.

      It has been cool to watch Linux kernel developers to write code, compile it, and occasionally break stuff that requires subsequent and sometimes arduous code bisects and code fixing or outright code removal; an acceptable process for development, but challenging for building customer support in some market sectors. Poorly designed "planned obsolesence" policies can have negative to very negative public relations impacts with the public that use that product; you want people to use your product, not run from it or even fork it.

      And as we have all seen over the years, the Linux community is not well known for it's public relations savvy; that limits their market sector appeal. Linus gave the finger in public to Nvidia; no corporate CEO acts like that. Qt and ODF stumbling around "community" versus "paid support" versions and associated product labels; we all saw those stories unfold recently here on Phoronix. The heavy-handed impact of Linux kernel code fixes for bugs in Intel, AMD, and other processors; performance impacts that divided some users in the Linux community. To many others.

      In summary, the Linux kernel developers need to carefully consider, carefully plan, and very carefully implement any policy that introduces "planned obsolesence" to Linux kernel code. Good ideas can be quickly sunk by bad implementations; just ask people that have submitted version after version of their code to the Linux kernel for acceptance into Linux mainline code.


      Comment


      • #23
        Originally posted by rmfx View Post
        get rid of the max things you can !

        32bit / useless arch / uselss fs / prehitoric hardware drivers...

        Programs need a shower time to time too.

        People who want to use very obsolete hardware shouldn't not be given the privilege of getting the very latest software... efforts go in both direction.
        32 bit is still very much a thing on many microcontrollers and embedded systems where Linux is widely used. It won't go away any time soon.

        Some useless fs have been culled, for example xiafs or extfs, but beyond that, even historical filesystems like ext2 or reiserfs are still used in production.

        Comment


        • #24
          Originally posted by jacob View Post

          32 bit is still very much a thing on many microcontrollers and embedded systems where Linux is widely used. It won't go away any time soon.

          Some useless fs have been culled, for example xiafs or extfs, but beyond that, even historical filesystems like ext2 or reiserfs are still used in production.
          so... no new kernel for raiserFS systems. you have 2 choices - 1: upgrade FS, 2: stay with old kernel

          Comment


          • #25
            Originally posted by NomadDemon View Post

            so... no new kernel for raiserFS systems. you have 2 choices - 1: upgrade FS, 2: stay with old kernel
            I don't think that telling users "reformat your storage or gtfo" is a good way to run a project. Besides I don't think that filesystems like reiserfs are much of an issue; they are maintained by separate developers/teams and don't impose any burden to the core kernel devs. A much bigger problem would be obsolete CPU architectures. Let's be honest; Linux is used in production in any relevant way on x86-84/amd64, ARM and POWER, with a number of Itanium servers left (but those have been dropped by distros anyway). Only a few hobbyists would be running it on m68k, SPARC, HPPA etc and the core developers could legitimately decide that they don't want to spend money and time maintaining support for those platforms.

            Comment

            Working...
            X