Date:   Fri, 5 Jun 2020 08:36:18 +0200
From:   Philippe Mathieu-Daudé <f4bug@...at.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        David Laight <David.Laight@...lab.com>
Cc:     Casey Schaufler <casey@...aufler-ca.com>,
        David Howells <dhowells@...hat.com>,
        Christoph Hellwig <hch@....de>,
        Al Viro <viro@...iv.linux.org.uk>, Ian Kent <raven@...maw.net>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        LSM List <linux-security-module@...r.kernel.org>,
        NetFilter <netfilter-devel@...r.kernel.org>,
        Nicolas Pitre <nico@...xnic.net>, Joe Perches <joe@...ches.com>
Subject: Re: clean up kernel_{read,write} & friends v2

Hi Linus,

On 5/29/20 9:19 PM, Linus Torvalds wrote:
> On Fri, May 29, 2020 at 6:08 AM David Laight <David.Laight@...lab.com> wrote:
>>
>> A wide monitor is for looking at lots of files.
> 
> Not necessarily.
> 
> Excessive line breaks are BAD. They cause real and every-day problems.
> 
> They cause problems for things like "grep" both in the patterns and in
> the output, since grep (and a lot of other very basic unix utilities)
> is fundamentally line-based.
> 
> So the fact is, many of us have long long since skipped the whole
> "80-column terminal" model, for the same reason that we have many more
> lines than 25 lines visible at a time.
> 
> And honestly, I don't want to see patches that make the kernel reading
> experience worse for me and likely for the vast majority of people,
> based on the argument that some odd people have small terminal
> windows.
> 
> If you or Christoph have 80 character lines, you'll get possibly ugly
> wrapped output. Tough. That's _your_ choice. Your hardware limitations
> shouldn't be a pain for the rest of us.

Unfortunately refreshable braille displays have that "hardware
limitations". 80 cells displays are very expensive.
Visual impairments is rarely a "choice".
Relaxing the 80-char limit make it harder for blind developers
to contribute.

> Longer lines are fundamentally useful. My monitor is not only a lot
> wider than it is tall, my fonts are universally narrower than they are
> tall. Long lines are natural.
> 
> When I tile my terminal windows on my display, I can have 6 terminals
> visible at one time, and that's because I have them three wide. And I
> could still fit 80% of a fourth one side-by-side.
> 
> And guess what? That's with my default "100x50" terminal window (go to
> your gnome terminal settings, you'll find that the 80x25 thing is just
> an initial default that you can change), not with some 80x25 one. And
> that's with a font that has anti-aliasing and isn't some pixelated
> mess.
> 
> And most of my terminals actually end up being dragged wider and
> taller than that. I checked, and my main one is 142x76 characters
> right now, because it turns out that wider (and taller) terminals are
> useful not just for source code.
> 
> Have you looked at "ps ax" output lately? Or used "top"? Or done "git
> diff --stat" or any number of things where it turns out that 80x25 is
> really really limiting, and is simply NO LONGER RELEVANT to most of
> us.
> 
> So no. I do not care about somebody with a 80x25 terminal window
> getting line wrapping.
> 
> For exactly the same reason I find it completely irrelevant if
> somebody says that their kernel compile takes 10 hours because they
> are doing kernel development on a Raspberry PI with 4GB of RAM.
> 
> People with restrictive hardware shouldn't make it more inconvenient
> for people who have better resources. Yes, we'll accommodate things to
> within reasonable limits. But no, 80-column terminals in 2020 isn't
> "reasonable" any more as far as I'm concerned. People commonly used
> 132-column terminals even back in the 80's, for chrissake, don't try
> to make 80 columns some immovable standard.
> 
> If you choose to use a 80-column terminal, you can live with the line
> wrapping. It's just that simple.
> 
> And longer lines are simply useful. Part of that is that we aren't
> programming in the 80's any more, and our source code is fundamentally
> wider as a result.
> 
> Yes, local iteration variables are still called 'i', because more
> context just isn't helpful for some anonymous counter. Being concise
> is still a good thing, and overly verbose names are not inherently
> better.
> 
> But still - it's entirely reasonable to have variable names that are
> 10-15 characters and it makes the code more legible. Writing things
> out instead of using abbreviations etc.
> 
> And yes, we do use wide tabs, because that makes indentation something
> you can visually see in the structure at a glance and on a
> whole-function basis, rather than something you have to try to
> visually "line up" things for or count spaces.
> 
> So we have lots of fairly fundamental issues that fairly easily make
> for longer lines in many circumstances.
> 
> And yes, we do line breaks at some point. But there really isn't any
> reason to make that point be 80 columns any more.
> 
>                   Linus

Regards,

Phil.

Powered by blists - more mailing lists