linux.dev mailboxes for kernel developers [LWN.net]

linux.dev mailboxes for kernel developers

Posted Jun 15, 2021 17:14 UTC (Tue) by ddevault (subscriber, #99589) [Link] (2 responses)

Migadu is a great service* and I would recommend it to anyone looking for a hosted email provider. I think with hosted email going the way it has been in the past several years, we need to start seeing the developer community investing in the maintenance and support of mail infrastructure which prioritizes our needs.

Not so excited about the choice of .dev, though. I don't think we need to be lending further legitimacy to Google's gTLD.

* Full disclosure: my business has a professional relationship with Migadu, but I have endorsed it since prior to our engagement.

linux.dev mailboxes for kernel developers

Posted Jun 15, 2021 17:30 UTC (Tue) by mricon (subscriber, #59252) [Link]

Largely, the choice of "linux.dev" was due to LF already having ownership of "linux.dev" (via Google granting it before .dev TLD was open to the public) and it wasn't doing anything useful just sitting there.

linux.dev mailboxes for kernel developers

Posted Jun 17, 2021 13:13 UTC (Thu) by tlamp (subscriber, #108540) [Link]

Hmm, I checked their plans and then checked my in/out in the proxmox mail gateway setup I got in front of the mail server here, and it seems that due to lots of ML subscription the only plan suitable for me would be "Maxi" one, as I get often 3200 to 3500 mail daily, and there's just no way I go for $900 yearly for a simple mail plan.

FYI/FWIW mailbox.org allows for similar features with a good price and an ok-ish privacy-sensible jurisdiction with no such rate limits in place.

linux.dev mailboxes for kernel developers

Posted Jun 15, 2021 20:00 UTC (Tue) by mfuzzey (subscriber, #57966) [Link] (13 responses)

I'm not entirely sure what problem this solves.

I get it that setting up patch friendly email can be a pain in some environments but until you've done that you're not going to be in MAINTAINERS or have a contribution track record to point to in order to qualify.

Also in a corporate environment while this will avoid patch mangling servers there may well be proxy / firewall restrictions preventing connections to external mail servers.

linux.dev mailboxes for kernel developers

Posted Jun 16, 2021 1:24 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (12 responses)

I can see it being useful for maintainers working at a company with a nice email setup leaving to go to some Outlook-driven nightmare of a place (who knows, maybe that allows them to pay engineers 3x as much or something). Or a place where Outlook or GMail become the company-wide standard.

> Also in a corporate environment

The corporate environment is pretty remote now, so just flip off the VPN or get some other machine that isn't on the VPN and send it through your ISP directly (hopefully they're not that draconian).

linux.dev mailboxes for kernel developers

Posted Jun 16, 2021 16:04 UTC (Wed) by scientes (guest, #83068) [Link]

Just set up openssh tunnel on port 443.

And if that is blocked (through DPI) then there is a project I keep putting off of doing wireguard-over-QUIC (although QUIC is ridiculously over-complicated, even the wire part of it).

linux.dev mailboxes for kernel developers

Posted Jun 19, 2021 16:02 UTC (Sat) by marcH (subscriber, #57642) [Link] (10 responses)

> I can see it being useful for maintainers working at a company with a nice email setup leaving to go to some Outlook-driven nightmare of a place (who knows, maybe that allows them to pay engineers 3x as much or something). Or a place where Outlook or GMail become the company-wide standard.

So basically most companies and all the big ones? Bottom-posting and ASCII email were killed by Exchange and others a long time ago. Then smartphones and instant messaging apps put the final nail in the coffin (together with IRC). The intense love of ASCII email seems to make some open source developers not realize they live in a bubble... How often do they use ASCII communication outside that bubble? So yes, that bubble is the exact (and official!) reason why this new server is needed.

BTW I finally understood after a couple decades in which cases top-posting is technical requirement and not just a bad habit: for confidential discussions where you want to copy a small and semi-random number of recipients, depending on the topic. This makes it possible for people added later to see the entire discussion. Granted: in practice most of these discussion should happen in some tracker or forum in the first place. However some discussions require sharing information with "unusual" participants and then permission schemes on trackers and forums are too static and too cumbersome.

Of course this important top-posting feature is often abused. The most hilarious is when people forget what the original topic was after the thread lasted for too long and then start accidentally sharing internal data with customers or even what they think of them :-)

Note this top-posting requirement is not an excuse to kill bottom-posting; Outlook could have kept supporting both. It didn't. Once you've decided to kill bottom-posting then there's no technical reason to support un-mangled ASCII email any more, simpler to support only "rich" formats. So ASCII went.

> The corporate environment is pretty remote now, so just flip off the VPN or get some other machine that isn't on the VPN and send it through your ISP directly

Or even better: don't route all the traffic through the VPN:
https://arstechnica.com/information-technology/2020/03/mi...

Flipping the VPN on and off is _really_ not convenient: it disrupts everything interactive including ssh (and yes I know about mosh, Eternal Terminal and others but it's still inconvenient)

Unfortunately some company policies forbid "split tunnelling" for security reasons.

linux.dev mailboxes for kernel developers

Posted Jun 19, 2021 17:53 UTC (Sat) by mathstuf (subscriber, #69389) [Link] (2 responses)

We use GMail at my office, but I still use Mutt because GMail's interface is…absolutely terrible. The only way it is responsive, at all, is to use the basic HTML interface (and this is after turning off all of the "smart" stuff too). I guess it works for others, but it has truly gotten bad over the last few years. FWIW, the only reason I even go to that interface anymore is to edit filters and I can get in and out with what I need in less time using the basic HTML site than it takes the fancy one to even decide it can show the Settings panel. And that includes using the Inspector to edit the woefully small form field limits they put there too.

Yeah, split VPN is a no-no due to US Government requirements, so anyone doing contracting with them is subject to their regulations.

linux.dev mailboxes for kernel developers

Posted Jun 19, 2021 18:43 UTC (Sat) by marcH (subscriber, #57642) [Link] (1 responses)

Email performance matters only when you spend a lot of time managing a fair amount of it. For merely top posting a "reply-all" + 1 or 2 people and then hit "delete" or "archive" performance is not that critical. Slowly searching all that mess locally used to be painful but that has been solved by the cloud; Exchange moved there too.

Outside open source, email has more or less become a lossy stream of throw away notifications, think RSS. Throw-away because pure notifications: the primary copy of the information is centralized and hyperlinked in some database somewhere, not just massively duplicated across all recipients. Hey, even Linus has been saying "please re-send this because I missed it", hasn't he?

The way to achieve "email performance" in this new and dominant model is with "unsubscribe" buttons with many different granularities. I miss the beauty and clarity of bottom posting too; that collateral damage wasn't necessary. On the other hand I really enjoy the fine grained "unsubscribe" model, I think it is a major progress that recipients and not senders finally have some control over what spa... email comes to their inbox. I think Knuth said something about that a century ago...

BTW Twitter and others seem to be repeating the same lack of control mistake: in the age of information overload and "available brain time", why would you let anyone including various trolls get anywhere close to your eyes and brain? Ah yes: "if it's free, you're the product". Of course.

PS: could you elaborate about these VPN regulations?

linux.dev mailboxes for kernel developers

Posted Jun 20, 2021 2:25 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

It's part of the new CUI regulations laid down last year. These affect any company working with sensitive US government data. Some links:

https://ndisac.org/dibscc/cyberassist/cybersecurity-matur...
https://www.reddit.com/r/NISTControls/comments/gje1r2/vpn...
https://cytellix.com/covid-19-remote-working-leveraging-n...

linux.dev mailboxes for kernel developers

Posted Jun 20, 2021 11:39 UTC (Sun) by flussence (guest, #85566) [Link]

> Then smartphones and instant messaging apps put the final nail in the coffin (together with IRC). The intense love of ASCII email seems to make some open source developers not realize they live in a bubble...

Maybe they could teach Google how to build services out of whatever that bubble's made out of. I wouldn't even trust it to keep the .dev TLD running until the end of the decade at this point.

linux.dev mailboxes for kernel developers

Posted Jun 25, 2021 3:39 UTC (Fri) by neilbrown (subscriber, #359) [Link] (5 responses)

> Once you've decided to kill bottom-posting then there's no technical reason to support un-mangled ASCII email any more, simpler to support only "rich" formats. So ASCII went.

You seem to be confusing charset=us-ascii with content-type: text/plain

text/plain is widely used in SMS and social media etc. The only email I get that isn't text/plain (at least in part) is auto-generate commercial email.

us-ascii is welcome to go. I much prefer utf-8.

linux.dev mailboxes for kernel developers

Posted Jun 25, 2021 9:29 UTC (Fri) by marcH (subscriber, #57642) [Link] (4 responses)

> You seem to be confusing charset=us-ascii with content-type: text/plain

I was tempted to write "text/plain" but then all my memories of quoted-printable, 8859 mismatchs, mojibake and broken accents in SMS came back.

> text/plain is widely used in SMS and social media etc

SMS is dead or dying and what social media still does not support animated gifs and other pictures?

linux.dev mailboxes for kernel developers

Posted Jun 25, 2021 10:01 UTC (Fri) by neilbrown (subscriber, #359) [Link] (1 responses)

> SMS is dead or dying

Is it? What other similar service is federated, rather than having a single point of control?

> and what social media still does not support animated gifs and other pictures?

Pictures, animated or not, are attachments - in email and on FB and in MMS. In my experience at least.
Animated emoji (which you didn't mention, but I thought of as I read your text) are the main reason I do not even try to use RocketChat. My eyes cannot tolerate the visual noise.

linux.dev mailboxes for kernel developers

Posted Jun 25, 2021 12:12 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

> > SMS is dead or dying
> Is it? What other similar service is federated, rather than having a single point of control?

Yes. My wife and I cannot send images to each other via texting because iMessage apparently refuses to talk MMS with non-iMessage-enhanced clients anymore.

linux.dev mailboxes for kernel developers

Posted Jun 25, 2021 13:49 UTC (Fri) by mbunkus (subscriber, #87248) [Link] (1 responses)

SMS is still the only text services you can reliably use to contact people if you don't know which messenger of the day they're currently using. While probably not being that important to you personally, it is important for all kinds of business services that must be able to reach you.

linux.dev mailboxes for kernel developers

Posted Jun 25, 2021 15:33 UTC (Fri) by marcH (subscriber, #57642) [Link]

Yes, like email SMS is merely a fallback. Google has (at last) been very aggressively replacing it by RCS which is now turned on by default on millions of phones.

linux.dev mailboxes for kernel developers

Posted Jun 15, 2021 20:03 UTC (Tue) by pono (guest, #108903) [Link] (1 responses)

As usual leave it to Konstantin for finding the most robust and free option to a general problem. His deployment of https://people.kernel.org turned me on to https://writefreely.org/
It's great to see someone throw their weight behind free software projects :D

linux.dev mailboxes for kernel developers

Posted Jun 16, 2021 16:26 UTC (Wed) by mricon (subscriber, #59252) [Link]

Thanks, Pono! :)

linux.dev mailboxes for kernel developers

Posted Jun 16, 2021 21:54 UTC (Wed) by birdie (guest, #114905) [Link] (1 responses)

What for? Another mail server (and a ton of infrastructure along with it), another possible source of vulnerabilities.

linux.dev mailboxes for kernel developers

Posted Jun 17, 2021 0:21 UTC (Thu) by ErikF (subscriber, #118131) [Link]

Having permalinks for the maintainers' e-mail for a mailing list-driven development system sounds like a good idea to me. It beats having to try to remember if "jdoe@foo.org" is the same person as "john.doe@baz.com", or if it was actually "jd123@baz.net", particularly if they are the person to contact about a subsystem, and getting someone to host a few mailboxes is not such an onerous task.