linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Dave Airlie <airlied@gmail.com>, Peter Jones <pjones@redhat.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	Dave Airlie <airlied@redhat.com>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andrew Lutomirski <luto@kernel.org>, Peter Anvin <hpa@zytor.com>
Subject: Re: [PATCH] efifb: allow user to disable write combined mapping.
Date: Thu, 20 Jul 2017 10:20:22 +0000	[thread overview]
Message-ID: <20170720102022.cwbqlf62nc3eal3f@gmail.com> (raw)
In-Reply-To: <CA+55aFyU3QrFeq4Lr9tgxR+6D9-eXZFZTzfqHdozHS72qE5q1w@mail.gmail.com>


* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Tue, Jul 18, 2017 at 2:21 PM, Dave Airlie <airlied@gmail.com> wrote:
> >
> > Oh and just FYI, the machine I've tested this on has an mgag200 server
> > graphics card backing the framebuffer, but with just efifb loaded.
> 
> Yeah, it looks like it needs special hardware - and particularly the
> kind of garbage hardware that people only have on servers.
> 
> Why do server people continually do absolute sh*t hardware? It's crap,
> crap, crap across the board outside the CPU. Nasty and bad hacky stuff
> that nobody else would touch with a ten-foot pole, and the "serious
> enterprise" people lap it up like it was ambrosia.
> 
> It's not just "graphics is bad anyway since we don't care". It's all
> the things they ostensibly _do_ care about too, like the disk and the
> fabric infrastructure. Buggy nasty crud.

I believe it's crappy for similar reasons why almost all other large scale pieces 
of human technological infrastructure are crappy if you look deep under the hood: 
transportation and communication networks, banking systems, manufacturing, you 
name it.

The main reasons are:

 - Cost of a clean redesign is an order of magnitude higher that the next delta 
   revision, once you have accumulated a few decades of legacy.

 - The path dependent evolutionary legacies become so ugly after time that most
   good people will run away from key elements - so there's not enough internal 
   energy to redesign and implement a clean methodology from grounds up.

 - Even if there are enough good people, the benefits of a clean design are a long
   term benefit, constantly hindered by short term pricing.

 - For non-experts it's hard to tell a good, clean redesign from a flashy but
   fundamentally flawed redesign. Both are expensive and the latter can have 
   disastrous outcomes.

 - These are high margin businesses, with customers captured by legacies, where
   you can pass down the costs to customers, which hides the true costs of crap.

i.e. typical free market failure due high complexity combined with (very) long 
price propagation latencies and opaqueness of pricing.

I believe the only place where you'll find overall beautiful server hardware as a 
rule and not as an exception is in satellite technology: when the unit price is in 
excess of $100m, expected life span is 10-20 years with no on-site maintenance, 
and it's all running in a fundamentally hostile environment, then clean and robust 
hardware design is forced at every step by physics.

Humanity is certainly able to design beautiful hardware, once all other options 
are exhausted.

Thanks,

	Ingo

  parent reply	other threads:[~2017-07-20 10:20 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-18  6:09 [PATCH] efifb: allow user to disable write combined mapping Dave Airlie
2017-07-18 14:34 ` Peter Jones
2017-07-18 19:57   ` Linus Torvalds
2017-07-18 20:44     ` Dave Airlie
2017-07-18 21:21       ` Dave Airlie
2017-07-18 22:22         ` Linus Torvalds
2017-07-18 23:16           ` Dave Airlie
2017-07-18 23:16             ` Dave Airlie
2017-07-19  0:00               ` Dave Airlie
2017-07-19  1:15                 ` Linus Torvalds
2017-07-20  4:07                   ` Dave Airlie
2017-07-20  4:28                     ` Andy Lutomirski
2017-07-20  4:44                       ` Linus Torvalds
2017-07-21  4:27                         ` Dave Airlie
2017-07-20 10:20           ` Ingo Molnar [this message]
2017-07-31 19:13       ` H. Peter Anvin
2017-07-25  4:00   ` Dave Airlie
2017-07-25  8:56     ` Bartlomiej Zolnierkiewicz
     [not found]       ` <CGME20170731171022epcas1p2c5537a0a79eca05a729773d4cabaac27@epcas1p2.samsung.com>
2017-07-31 17:10         ` Bartlomiej Zolnierkiewicz

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=20170720102022.cwbqlf62nc3eal3f@gmail.com \
    --to=mingo@kernel.org \
    --cc=airlied@gmail.com \
    --cc=airlied@redhat.com \
    --cc=b.zolnierkie@samsung.com \
    --cc=hpa@zytor.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=pjones@redhat.com \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@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).