linux-m68k.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Finn Thain <fthain@telegraphics.com.au>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
	Gerhard Pircher <gerhard_pircher@gmx.net>,
	Arnd Bergmann <arnd@arndb.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-m68k <linux-m68k@lists.linux-m68k.org>,
	Sparc kernel list <sparclinux@vger.kernel.org>,
	Linux-sh list <linux-sh@vger.kernel.org>
Subject: New platforms: bring out your dead, was Re: Old platforms: bring out your dead
Date: Thu, 14 Jan 2021 14:54:04 +1100 (AEDT)	[thread overview]
Message-ID: <alpine.LNX.2.23.453.2101141451370.7@nippy.intranet> (raw)
In-Reply-To: <CAK8P3a3hKSVXZEjQEbkOLhtAO0oR0+UP1dL10S3jQM72EsmsWA@mail.gmail.com>

On Wed, 13 Jan 2021, Arnd Bergmann wrote:

> 
> It's usually one of two things that happened before a platform gets
> deleted for good:
> 
> * The platform port was (almost) exclusively done by one company
>    with a commercial interest in it, and the company shifts its priorities
>    for some reason (acquisition, bankruptcy, product cancellation,
>    accidentally laying off all competent developers, ...) that causes it to
>    stop working on it. Sometimes the previously paid maintainers
>    keep up their upstream position, but without someone pushing the
>    last missing bits into an official release, users are stuck on an old
>    BSP kernel.
> 

Yes, that's the typical product life cycle. It presumes a short window of 
opportunity for sales (suggesting that demand is not organic).

Most vendors like to avoid having to compete with their own prior product 
lines. Hence the constrained lifespan that we get from devices with 
out-of-tree Linux ports.

AFAICS open source licenses cannot really prevent this (no matter how many 
freedoms the FSF would like to confer on people). However, consumer law 
could do it, if it were to disallow products which were not servicable.

> * A platform port is done in the open and actually works for upstream
>   users, but over time the last active maintainers move on in their
>   lives. Complex platforms inevitably break when a treewide change
>   goes wrong, so we rely on users that are able to bisect and report
>   bugs when they happen. 

And without bug reports, breakage gets leveraged into deletion, using the 
bogus argument that "broken" code is proof of zero potential users.

>   After a platform has been broken for too long, even competent users 
>   may decide to just give up and stay on their last working kernel. Some 
>   of these platforms eventually recover when a new maintainer steps up 
>   or someone discovers they depend on newer kernels for products, but 
>   after a few years it's usually beyond repair.
> 

So all a vendor has to do is make maintenance a bit too difficult for 
competent users e.g. by depriving them of access to existing 
documentation.

It was only a few decades ago that every applicance you bought came with a 
printed circuit schematic. These days, every device you buy comes with 
built-in obsolescence and a customer lock-in strategy.

>       Arnd
> 

  reply	other threads:[~2021-01-14  3:55 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAK8P3a2VW8T+yYUG1pn1yR-5eU4jJXe1+M_ot6DAvfr2KyXCzQ@mail.gmail.com>
2021-01-10 17:35 ` Old platforms: bring out your dead John Paul Adrian Glaubitz
2021-01-10 21:46   ` Sam Ravnborg
2021-01-11  8:05     ` John Paul Adrian Glaubitz
2021-01-11 14:55       ` chase rayfield
2021-01-12  0:26         ` Rob Landley
2021-01-12  0:50           ` chase rayfield
2021-01-12 14:37         ` John Paul Adrian Glaubitz
2021-01-11 18:09     ` Rob Landley
2021-01-11 15:04   ` Gerhard Pircher
2021-01-12 14:44     ` John Paul Adrian Glaubitz
2021-01-12 22:46       ` Linus Walleij
2021-01-13  8:09         ` Rob Landley
2021-01-13  8:21           ` Geert Uytterhoeven
2021-01-13 13:25             ` Rob Landley
2021-01-13 12:02           ` Andy Shevchenko
2021-01-13  8:15         ` Geert Uytterhoeven
2021-01-13 10:39         ` Arnd Bergmann
2021-01-14  3:54           ` Finn Thain [this message]
2021-01-14  9:41         ` John Paul Adrian Glaubitz
2021-01-14  9:48           ` Geert Uytterhoeven
2021-01-14 21:21           ` Arnd Bergmann
2021-01-14 22:54             ` Undesirable code, was Re: Old platforms etc Finn Thain
2021-01-14 23:09             ` Old platforms: bring out your dead Max Filippov
2021-01-15  8:31               ` Arnd Bergmann
2021-01-13  0:12       ` Old platforms never die, was " Finn Thain
2021-01-16  6:54         ` Rob Landley
2021-01-16 23:22           ` Finn Thain
2021-01-13 11:47       ` Andy Shevchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LNX.2.23.453.2101141451370.7@nippy.intranet \
    --to=fthain@telegraphics.com.au \
    --cc=arnd@arndb.de \
    --cc=arnd@kernel.org \
    --cc=gerhard_pircher@gmx.net \
    --cc=glaubitz@physik.fu-berlin.de \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=sparclinux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).