Message-ID: <f54e2fc8-0aba-3b62-7870-023f25e11e8f@linux-m68k.org>
Date:   Fri, 23 Jun 2023 10:52:08 +1000 (AEST)
From:   Finn Thain <fthain@...ux-m68k.org>
To:     Theodore Ts'o <tytso@....edu>
cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jonathan Corbet <corbet@....net>,
        tech-board-discuss@...ts.linux-foundation.org,
        Kees Cook <keescook@...omium.org>,
        Dan Williams <dan.j.williams@...el.com>,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Documentation: Linux Contribution Maturity Model and
 the wider community

On Thu, 22 Jun 2023, Theodore Ts'o wrote:

> 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.
> 

No, those are not my assumptions, those are my observations.

Also, you've incorrectly conflated my comment about "devices in drawers" 
(which was a reference to old Android phones and the like) with an old 
thread about an HBA driver. The former comment goes to the value of old 
code. The latter goes to the size of the talent pool.

> > 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.

I'll explain it.

> 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 I understand it, supporting ancient hardware in certain sectors is 
highly profitable, where red tape prevents those customers from upgrading.

> 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. 

I think you've missed my point, which was that some maintainers require 
that released code is executed promptly otherwise it should be deleted. 
Please see also, 
https://lore.kernel.org/all/7c2a6687-9c4e-efed-5e25-774b582e9a27@linux-m68k.org/

> 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.
> 

Given that products like mobile phones etc. often get made obsolete within 
a few years from launch, my guess is that billions of users are now 
interested in retro-computing.

> Cheers,
> 
> 					- Ted
> 

Powered by blists - more mailing lists