Originally posted by rmfx
View Post
Announcement
Collapse
No announcement yet.
Linux Might Better Plan Its Code/Hardware Obsolescence From The Kernel
Collapse
X
-
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
-
Originally posted by rmfx View Postget 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.
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
-
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.
Comment
-
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
Comment
Comment