LWN: Comments on "Better tools for kernel developers"

Better tools for kernel developers

muzg666 — Mon, 16 Aug 2021 13:29:37 +0000

hahah 2020 - https://en.wikipedia.org/wiki/Integrated_development_envi...

Better tools for kernel developers

Wol — Sun, 27 Dec 2020 09:36:46 +0000

Dunno whether it applies elsewhere, but I believe Linus' workflow is that all patches are against the first version in the series, so if 5.12 is the latest kernel and he's prepping 5.13, they all have to apply cleanly against 5.12.

Then I guess once 5.13-rc1 comes out, they all have to apply cleanly against rc1, even if he's up to rc8.

Not proof against cock-ups, but I think interactive-merge would actually be a change for the worse in that case.

Cheers,
Wol

Better tools for kernel developers

foom — Sun, 27 Dec 2020 04:23:25 +0000

Sure, that was a common convention in the past, but many other user agents have stopped hard-wrapping years ago, because at this point it does more harm than good.

Better tools for kernel developers

mjg59 — Sat, 26 Dec 2020 05:02:03 +0000

There's no hard requirement that user agents wrap text - it's convention to do so for the purposes of quoting stuff on 80 characters wide terminals, but doing so is inherently lossy when using plain ASCII (there's no way to tell the difference between a 72-character line followed by an 8-character line and an 80-character line that got hard wrapped). RFC5322 does say that agents SHOULD place a 78-character restriction on line length, but the context provided makes it pretty clear that it's talking about written language rather than code.

Better tools for kernel developers

zlynx — Sat, 26 Dec 2020 02:25:54 +0000

> Gmail hard-wraps plaintext mails at 78 columns. It should stop doing so. Fixing this in gmail would also make its plaintext emails more readable on mobile devices.

It's vague in my memory, but I am almost certain that wrapping around 72 and definitely before 80 is *required* for email user agents.

Yes, yes, it is commonly ignored for pasted or included content, but any email program that you type into is supposed to wrap long line at some point before 80, leaving room for at least three levels of quotes, like "> > > " which is six. So at least 74, more likely 72. 78 is being overly generous really.

This kind of sounds like someone complaining about Google's GMail *following standards*. Weird.

Better tools for kernel developers

geert — Thu, 24 Dec 2020 14:51:47 +0000

Using attachments is not an option, as it makes it hard to comment on attached patches.

Test procedure:

1. Generate patch with "git format-patch -1",
2. Revert top change using "git reset --hard HEAD^",
2. Open patch with e.g. gedit,
3. Paste patch into email body using gmail web interface,
4. Send email,
5. Open received email,
6. Select "Download message" from triple-dot menu,
7. Apply patch using "git am" (should apply cleanly),
8. Use "git diff" to check tree contents (should match state with step 1).

The above used to work, until Gmail started replacing TABs in pasted patches by spaces several years ago.
More things may have been broken afterwards (e.g. forced line break).

Thanks a lot!

Better tools for kernel developers

ncm — Thu, 24 Dec 2020 04:26:41 +0000

And, also, it was in Debian's packaging of OpenSSH, not SSL.

Better tools for kernel developers

foom — Thu, 24 Dec 2020 00:34:05 +0000

Gmail hard-wraps plaintext mails at 78 columns. It should stop doing so. Fixing this in gmail would also make its plaintext emails more readable on mobile devices.

Other popular mailers have stopped doing hardwrapping years ago, and now simply send long lines as long lines, without inserting any extraneous linebreaks. In order to remain compliant with SMTP standards, which prohibits long lines, you must encode the message as quoted-printable if the lines are too long. But, quoted-printable encoding is reversible and transparent to the content, unlike inserting hard linebreaks.

A previous solution to the mobile problem was to use text/plain;format=flowed, but that format=flowed was a complex spec that had many problems of its own, and never interoperated well. It's fallen out of favor in recent decades (yes, decades!!!), in favor of simply never hard-wrapping text/plain content.

Better tools for kernel developers

tbelaire — Wed, 23 Dec 2020 16:23:34 +0000

What exactly does Gmail break? Is it just line wrapping or is it anything else?

I do work on Gmail, if there's a clear test case maybe I could try and fix this. Though I'm a little afraid of touching that part of the code base as there are a lot of tools which parse emails, and I wouldn't know if my change broke something until too late.

I suppose more usefully, how would I test this? I could generate a patch with git, copy it into gmail (after the fix), send it to myself and copy the body from gmail web into a .patch file, which I feed to git?
Or would I need to set up mutt or something in order to get the email in a form git likes? I haven't sent patches by email successfully before.

Can you include the patch file as an attachment instead?

Better tools for kernel developers

nye — Tue, 03 Mar 2020 17:09:51 +0000

If you set it to "prefix each line", the precise behaviour depends on whether the original message is plain text or HTML, so you don't get the > prefixing for HTML emails (instead you get a coloured border on the side, which is inoffensive and actually quite useful). It's not quite as good as if it let you set this per message, but in practice the way it works seems basically sane and actually a fairly reasonable approach.

Also, when replying to a plain text email, it defaults to plain text so you don't need to change anything.

I don't really want to defend Outlook too much since I kind of hate it, mostly for reasons not covered in this thread, but in this particular way I think its reputation is a bit unfair.

Better tools for kernel developers

jem — Sat, 22 Feb 2020 19:09:55 +0000

You know, nowadays you can find answer to questions like this faster by looking them up in Wikipedia...

Better tools for kernel developers

jem — Sat, 22 Feb 2020 19:08:10 +0000

The line feed character represents a newline at a higher abstraction level. Unix uses the line feed character to represent a line break in a text file. This has little to do with what character(s) are actually output when the file is sent to a terminal or a printer; the translation is done by the terminal line driver. How the newline should be output is determined by the line settings.

The same goes for input: conventionally, the Return (CR) key is used to terminate a line when typing on a (virtual) terminal, but the line break ends up as a line feed character in a file or in the input to a process.

Better tools for kernel developers

PaulMcKenney — Sat, 22 Feb 2020 02:06:28 +0000

Bytes were expensive back then! But yes, some of the old drivers would add the <cr> for you. If properly configured, anyway. :-/

Better tools for kernel developers

Wol — Fri, 21 Feb 2020 21:48:27 +0000

Well, when the company I worked for first got a daisywheel printer, we discovered we actually needed <cr> to be carriage return, and <lf> to be linefeed. The printer driver read the print file line by line, with a maximum line length of 256. If your line was more than 256 characters long (easily achieved if you wanted bold text on an 80-char line) the driver stuck a line-feed in, splitting what should be one line on to two.

So imho, the *nix convention "line feed means carriage return" is actually broken ...

Cheers,
Wol

Better tools for kernel developers

Wol — Fri, 21 Feb 2020 21:39:45 +0000

> WhatsApp and Signal have long replaced email for person-to-person communication for me. It's encrypted by default, and doesn't require me pulling out my hair out gauging out the eyes of whoever I want to communicate with, to setup encrypted communications.

I avoid WhatsApp, and what on earth is Signal?????

Cheers,
Wol

Better tools for kernel developers

Wol — Fri, 21 Feb 2020 21:36:02 +0000

And Secretaries handle a different domain again ... (sorry, it's one of my pet peeves, my mum was a Secretary and it is a serious legal qualification...)

Cheers,
Wol

Better tools for kernel developers

Wol — Fri, 21 Feb 2020 21:29:07 +0000

> My last point is the big one - the process is no longer "use your existing email client to do this", instead it has become "install and configure one of these obscure programs to interact with our system".

Thing is, there's a thing called "the principle of least surprise". And MOST GUI systems absolutely *love* to ignore it. If you use an email client that abides by it, you should not have any difficulty communicating with the linux project.

That's why a lot of MS products are so awful - they keep breaking this principle. As soon as someone starts thinking "why the f... is this happening?" there's a problem with the tool. And if the answer isn't blindingly obvious in hindsight (it should be obvious in foresight, too, but that really IS hard) then the tool is broken. Sadly, this is true of a heck of a lot of today's tools.

Cheers,
Wol

Better tools for kernel developers

andresfreund — Tue, 18 Feb 2020 02:20:04 +0000

> Yes, but IIRC the guy asked on the OpenSSL developers' list whether it would be an OK thing to do and never got an answer.

And it was flagged as depending on uninitialized data by valgrind IIRC. Without comments explaining why there's no danger etc.

Better tools for kernel developers

anselm — Mon, 17 Feb 2020 11:04:16 +0000

Yes, but IIRC the guy asked on the OpenSSL developers' list whether it would be an OK thing to do and never got an answer.

FastMail

CChittleborough — Sun, 16 Feb 2020 11:26:12 +0000

(Sorry for posting this so late; I've just got around to reading the comments here.)

FastMail.com is a web mail provider built around the Cyrus IMAP server, a FOSS project to which FastMail make significant contributions (eg., JMAP).

As a FastMail customer*, I currently just use their web interface, but I previously used their IMAP interface with no difficulty.
*Full disclosure: I am a very satisfied FastMail customer.

Unlike gmail, FastMail does not mangle leading whitespace or long lines (at least in the simple test I just performed).

So maybe FastMail would be very useful to kernel developers. Does anyone use it?

Better tools for kernel developers

Conan_Kudo — Sun, 16 Feb 2020 04:10:37 +0000

Well, Debian did that change, it was never present in upstream OpenSSL.

Better tools for kernel developers

pizza — Thu, 13 Feb 2020 03:10:36 +0000

Only Outlook for Windows supports inline quoting. The rest (mac, android, web, etc) don't support it, and Microsoft has never indicated that this will ever change.

Better tools for kernel developers

chutzpah — Thu, 13 Feb 2020 02:46:01 +0000

Thanks for the pointer, but that is for the desktop client only. Unfortunately the web client does not have any such features that I have managed to discover.

Better tools for kernel developers

Cyberax — Thu, 13 Feb 2020 02:35:29 +0000

I don't use the online client, but Googling finds this: https://support.office.com/en-us/article/reply-with-inlin...

Better tools for kernel developers

chutzpah — Thu, 13 Feb 2020 02:31:20 +0000

I have recently had Outlook 365 thrust upon me, configured in such a way that all alternate clients are blocked.

> Outlook defaults to top-posting, but it supports traditional point-by-point replies as well. It also has tools to quote and unquote blocks of text. Most people are just not exposed to them.
I have yet to discover any way to configure it to work this way, at least with the Outlool 365 web client. If you know how to get this functionality, please share.

Better tools for kernel developers

milesrout — Wed, 12 Feb 2020 21:29:29 +0000

What you are saying about the email-based workflow that git was designed from the start to be used with is simply, factually, objectively wrong. Saying that it "isn't workable" isn't just incorrect, it's ignorant.

However if you put even the most basic research into sourcehut you'd know that the major goal of the website is to build online web-based contribution tools that use the "unworkable" email workflow underneath.

Better tools for kernel developers

jezuch — Wed, 12 Feb 2020 18:28:51 +0000

Sorry, I can't decide whether this classifies as a straw man or a red herring. Probably both.

(FWIW it never happens here. We have a separate snipping tool which recognizes that corporate users absolutely *love* screenshotting. Not that clueless cropping was ever a problem.)

Better tools for kernel developers

rahulsundaram — Wed, 12 Feb 2020 18:06:22 +0000

> XMPP works well too, now that the silos have given up trying and failing to weaponise it against each other.

XMPP has failed to get any traction because none of the implementations could be expected to be reasonably compatible with each other. That was the practical consequence of being extensible and having different features bolted on. Matrix has higher momentum now

Better tools for kernel developers

pizza — Wed, 12 Feb 2020 17:56:27 +0000

The entire federated XMPP userbase is barely a rounding error when compared to even one of the current IM silos.

...And if you think getting a usable semi-custom email workflow is too difficult... XMPP is an order of magnitude worse, with significantly worse tooling.

(I still have an XMPP server going for my domains. In the past few years, I've received a total of *zero* non-spam messages..)

Better tools for kernel developers

flussence — Wed, 12 Feb 2020 17:37:32 +0000

XMPP works well too, now that the silos have given up trying and failing to weaponise it against each other.

Better tools for kernel developers

Conan_Kudo — Wed, 12 Feb 2020 14:39:56 +0000

The problem with Sourcehut is that it provides no alternative workflow for submitting changes. It re-enforces the email-based workflow that myself and many others here have said is not workable.

Sourcehut itself does improve things from the "dumb" email model (such as basically integrating Patchwork's functionality), but itself does not provide any reasonable workflow improvements.

Better tools for kernel developers

spwhitton — Wed, 12 Feb 2020 14:25:43 +0000

Sourcehut also has this feature.

Better tools for kernel developers

Cyberax — Tue, 11 Feb 2020 23:26:09 +0000

FWIW, I have a fairly large Outlook mailbox and the Outlook process private memory size is 180Mb. And this includes all the GUI stuff like rich text editor. I don't consider this even remotely problematic...

Better tools for kernel developers

poruid — Tue, 11 Feb 2020 23:03:46 +0000

Ever noted that people insert screenshot cut-outs in mails sent with MS Outlook ?
If so, on reception, ever saved the image from the mail and found that it shows the whole screenshot? Not good, not in a tightly controlled environment, not good anywhere.

Better tools for kernel developers

poruid — Tue, 11 Feb 2020 22:51:47 +0000

This makes me rant.

Besides the usual nonsensical way that options, account setting or any entity are organised in MS Outlook (e.g. navigate from Advanced to Extra to whatever deeper and then end up again in the dialog the navigation started from, ESC deep down a dialog stack just ending the whole stack), its all-functionality-in-one-application is hell bound: load and startup times are terrible, memory usage is huge, etc etc. Having separate tools that do one thing good and work well together - sounds familiar ? - is much better. The balancing of tradeoffs at Microsoft its development process have very little to do with user demands and much more with squeezing out profits and locking customers in.

Better tools for kernel developers

nim-nim — Tue, 11 Feb 2020 10:44:11 +0000

587 is not redundant at all. You will typically open 25 without auth (to receive third-party messages), and 587 with auth (to allow your users to create new messages). The security pipeline is different.

Better tools for kernel developers

milesrout — Tue, 11 Feb 2020 10:16:26 +0000

I'm 24. I can use email. Being able to set up an email client has nothing to do with age.

Better tools for kernel developers

nhippi — Mon, 10 Feb 2020 14:27:37 +0000

Of course, the "them javascript kids" attitude is why average age of a kernel maintainers rises every year by about one year[1]. Which is going to create problems a couple decades down the line.

[1] Stetson-Harrison et all

Better tools for kernel developers

geert — Mon, 10 Feb 2020 08:42:02 +0000

I have used the GMail web interface for almost all of my interaction with Linux mailing lists since 2009, except for:
1. Sending patches (git send-email using the SMTP server of my ISP),
2. Replying to patches on mailing lists I'm not subscribed to, and thus downloaded from lore or patchwork (alpine is still in my fingers).

Yes, GMail has lost the ability to not corrupt patches copy-'n-pasted to the web interface many years ago :-(

Better tools for kernel developers

pizza — Sun, 09 Feb 2020 04:05:30 +0000

Email remains the *only* fully federated communication tool out there.

Everything else has dissolved into balkanized silos whose primary goal is to monetize the user.