On Thu, Jun 22, 2023 at 05:02:10PM +1000, Finn Thain wrote: > > You mentioned wasted resources. If you want to generate e-waste, remove > drivers from the kernel. If you want to prevent e-waste, add drivers for > obsolete hardware and then watch the user count climb from zero as devices > get pulled from drawers and dusted off. You seem to making a lot of assumptions here, with no evidence to back up your assertions. The driver question is from twenty years ago, and talks to SCSI cards using LVD (low-voltage diferential) SCSI 3 cables (for 160 MB/s). SCSI Disks from that era are typically 20GB to 30GB. Compare that to modern SATA disks today that are 10-18 TB in size, and SATA-3 transfers data at 600 MB/s. So you are assuming (a) that people just "happen" to have ancient, 20 year old cards justlying around in drawers, (b) they have 20 year old SCSI disks and SCSI cables that these cards would actually talk to, and (c) they would think it would make sense from a power, space, and cooling perspective to take this kind of antique storage solutions are use it for actually storing data. > Anyway, your reaction is an interesting example of strong feelings in the > community as to how contributed code should or should not be used. E.g. > some get upset if their code runs on weapons systems, others get upset if > the latest release might not run on suitable hardware in the immediate > future. Some add or remove licence terms according to their convictions. Um, I don't even know where this came from. In any case, the Linux Kernel is licensed under the GPL2, which, like all Open Source compliant licenses, does not distribute against fields of endeavor (such as weapons systems, etc.) As far as getting upset if the latest release doesn't run on "suitable hardware", if they are upset they can submit a bug report, or better yet, submit a patch to address the situation. What people seem to forget is that free software does not mean that people will fix your software for your use case for free. It means that *you* are free to fix the software, or to pay someone to fix the software in question. > If there was consensus, it might be feasible to give a formula for > "recognized usage" which could be quantified. From there we could create a > kind of heat map to show which commits, maintainers, processes, models, > modules etc. were the most "useful" within some time interval. The best we have is we can see what users submit bug reports about (especially, for example, when we discover that some driver was accidentally broken a few years ago due to the need to upgrade code to use newer API's as we improve and refactor code, and no one has complained about the driver being used --- that's a good hint that no one cares), and what individuals and companies choose to spend time working to improve certain parts of the kernel. If code is under active maintenance, then it's worth *someone's* time to keep maintained. And of course, if remove a driver because it is unmaintained and is for obsolete hardware, if someone shows up saying (a) they care about that driver, and (b) they are willing to volunteer to maintain the driver, or are willing to pay someone to maintain the driver, and they have contracted with XYZ developer working for ABC company, then it's super simple to revert the driver removal. It is, after all, only a "git revert" away. I do have to concur with Greg that relying on this as way to get new people to be work on Linux kernel is a *terrible* idea. The number of people who are interested in retro-computing is quite small, in my experience. Cheers, - Ted
