Why kernel development still uses email [LWN.net]

Why kernel development still uses email

Posted Oct 5, 2016 13:20 UTC (Wed) by nhippi (subscriber, #34640) [Link] (1 responses)

Offline is a diminishing use case not much worth optimizing for. Most email users use gmail etc which essentially require connection. I'm one of the middle-aged grumpy men with meticulously tuned .procmail filters and .muttrc, yet I still find myself often rather using gmail. The younger generations won't arse setting up legacy email. The age of offline is going away (Also on the few moments without connection I'd usually use it to not work on patches and reviews).

I take email will still remain, but simply as a messaging queue backend between git send-email and patchwork.

Why kernel development still uses email

Posted Oct 6, 2016 10:31 UTC (Thu) by dunlapg (guest, #57764) [Link]

The younger generations won't arse setting up legacy email.

FWIW, I'm 40 and I use gmail to do development (my project, Xen, uses e-mail as the primary development method as well); but a number of my 20-something colleagues have set up fetchmail, and use mutt / alpine on local mbox'es.

I suspect rather that the number of people who prefer using services like gmail or prefer to set up fetchmail / procmail / &c is constant over time, but that 20 years ago the latter was the only option.

Why kernel development still uses email

Posted Oct 5, 2016 16:18 UTC (Wed) by louie (guest, #3285) [Link] (20 responses)

It is 2016, and in Asia, North America, and Europe, where most kernel developers live, networks are usually available on trains, planes, and (unfortunately) even in automobiles.

As far back as 2007, an LKML admin told me that over 1/2 of LKML subscriptions were to gmail, so network connectivity is even a mostly bogus argument for LKML (since gmail offline is mostly non-functional).

If someone were making a big push to cultivate LKML contributors in Africa, this conversation might be worth having, but they aren't, so "offline" is, as MarcH says, mostly just an excuse to stand still while the rest of the world passes you by.

Why kernel development still uses email

Posted Oct 5, 2016 18:53 UTC (Wed) by BlueLightning (subscriber, #38978) [Link] (6 responses)

If you find you've got connectivity everywhere then I wonder where it is that you go. In my experience in the UK and NZ, internet connectivity on trains, planes and from your mobile even in populated areas can be spotty to non-existent, in 2016 - and I'm not even particularly adventurous.

Why kernel development still uses email

Posted Oct 15, 2016 22:54 UTC (Sat) by Wol (subscriber, #4433) [Link] (5 responses)

I have 17MB connectivity in my home - ALLEGEDLY. (That's 20MB theoretical max, 17MB achieved IFF the internet is working.)

This is in the UK, in the capital London. And even with what is pretty much the best available connection over copper, I regularly have problems actually getting a WORKING internet.

So if you think everyone has reliable connectivity, I think you're fooling yourself. Why should I be unable to code most evenings, just because my internet has been swamped and fallen over?

Cheers,
Wol

Why kernel development still uses email

Posted Oct 16, 2016 8:35 UTC (Sun) by farnz (subscriber, #17727) [Link] (4 responses)

Just a nit - that's nowhere near the best available over copper. Using BT's copper wires (but paying AAISP for service, as they're extremely clued), I get 80M down, 20M up reliably. Helps that the copper stretch to the DSLAM in the cabinet is very short, but still, it's VDSL2 over copper (which BT sell as BT Infinity "Fibre Broadband", even though it's over copper), not fibre to the home.

And I don't have problems keeping the connection working - although relatives in the area using BT Broadband do. Changing which ISP the circuit is backhauled to does seem to help in the UK.

Why kernel development still uses email

Posted Oct 16, 2016 14:03 UTC (Sun) by Wol (subscriber, #4433) [Link] (3 responses)

But you're over mixed copper/fibre. That option is not available to me.

I don't have a cabinet to house a DSLAM and fibre link ... As I said, I have the best available connection over copper :-)

Mind you, if we move in the not too distant future (highly likely it looks like now) I shall almost certainly change ISP away from BT. My in-laws (on the same exchange, possibly also with no cabinet, like me) also get terrible connectivity with a different ISP.

Cheers,
Wol

Why kernel development still uses email

Posted Oct 16, 2016 14:06 UTC (Sun) by farnz (subscriber, #17727) [Link] (2 responses)

You're also on mixed copper/fibre, though - the DSLAM you're connected to (which isn't giving you the top speed of ADSL2+ - I've had higher sync speeds on ADSL2+ in the UK) is connected to the rest of the network by fibre, just like mine.

Why kernel development still uses email

Posted Oct 19, 2016 16:10 UTC (Wed) by Wol (subscriber, #4433) [Link] (1 responses)

So if the technical infrastructure is allegedly the same, why can't I get BT Infinity?

Okay, with no cabinet it's obvious why I can't get FTTC, but why can't I get the same speeds to the DSLAM in the exchange?

Cheers,
Wol

Why kernel development still uses email

Posted Oct 19, 2016 16:18 UTC (Wed) by farnz (subscriber, #17727) [Link]

Because the DSLAM in the exchange is configured to use a bandwidth of up to 2.2 MHz depending on line length; higher bandwidths are unacceptable, due to the RFI issues they cause in the exchange for other lines in the same bundle.

The DSLAM in a cabinet is configured to use a bandwidth of up to 17 MHz depending on line length; unlike exchange based DSL services, this presents no significant RFI issues, as the affected lines are all connected to the same DSLAM anyway (and thus would get the RFI at any permitted bandwidth.

In both cases, you have fibre to a DSLAM, copper from DSLAM to your home, signalling rate of 4 kilobaud. It's just that the permitted bandwidth is higher if the DSLAM is in the cabinet, and thus the numbers of bits per symbol is much higher.

Why kernel development still uses email

Posted Oct 5, 2016 19:26 UTC (Wed) by oever (guest, #987) [Link]

Offline is not about connectivity, it is about control.

I want my data locally under my control. I do not want to be bound to a closed cloud service. It should be possible to have data local in an open file format. Communication should be possible via an open protocol.

Why kernel development still uses email

Posted Oct 6, 2016 10:22 UTC (Thu) by jschrod (subscriber, #1646) [Link] (9 responses)

> gmail offline is mostly non-functional

???

Gmail is an IMAP server, as mentioned in the article. Of course, it's offline functionality is fine, almost all IMAP clients download the emails.

Why kernel development still uses email

Posted Oct 13, 2016 9:52 UTC (Thu) by davidgerard (guest, #100304) [Link] (8 responses)

GMail's implementation of IMAP is ... idiosyncratic. It mostly works, except when it doesn't.

offlineimap is the least-worst way to suck down everything from GMail, because they've had extensive dev discussion about the latest flaky thing GMail's done with IMAP. It appears GMail "IMAP" is to some defree best regarded as a separate protocol descended from IMAP.

Why kernel development still uses email

Posted Oct 13, 2016 9:52 UTC (Thu) by davidgerard (guest, #100304) [Link]

* defree -> degree

Why kernel development still uses email

Posted Oct 13, 2016 14:56 UTC (Thu) by spaetz (guest, #32870) [Link] (6 responses)

Previous offlineimap maintainer here. Gmail IMAP indeed resembles imap, but differs in many respects. The main problem is that it maps its "flags" to IMAP folders, ie a message with multiple flags in gmail is contained in many imap folders simultanously (and proper imap clients will download them multiple times). Once you delete a message from an imap folder you merely remove the corresponding tag, it will still be in your Gmail inbox.

Additionally, there is the "All Mails" folder or somesuch, so even if you delete a message from all folders it will still be there, iirc. If you delete a message from this folder, it will miraculously resurrect itself when it still has any flags attached. THings like this make it difficult to work with Gmail as a proper IMAP server.

Why kernel development still uses email

Posted Oct 14, 2016 17:49 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (5 responses)

Personally, I just hide the problematic labels from IMAP altogether (All Mail and Sent in particular). I just set Fcc to be INBOX and it has worked well enough for me.

Why kernel development still uses email

Posted Oct 15, 2016 15:03 UTC (Sat) by spaetz (guest, #32870) [Link] (4 responses)

Yes, you can do that but it (mostly) prevents you from using gmail in typical gmail fashion, using its features. :-)

Why kernel development still uses email

Posted Oct 15, 2016 18:38 UTC (Sat) by mathstuf (subscriber, #69389) [Link]

I guess? Then again, I also tend to completely delete email I no longer need rather than archive it at all *shrug*. What use cases do they really enable other than "all email I've ever received ever"?

Why kernel development still uses email

Posted Oct 19, 2016 16:13 UTC (Wed) by Wol (subscriber, #4433) [Link] (2 responses)

Why do you want to do that?

I have all my email locally in Thunderbird, and use gmail solely as an IMAP server. Why would I want to do anything else?

(Also, gmail is useful for sending mail when I'm away from home, though I've discovered it seems to tamper with the "reply to" which is a damn nuisance!!! If I use the gmail server to send mail, I do NOT want it setting replies to go to my gmail account unless I ASK FOR IT!!!)

Cheers,
Wol

Why kernel development still uses email

Posted Oct 19, 2016 17:48 UTC (Wed) by spaetz (guest, #32870) [Link] (1 responses)

> Why do you want to do that?

> I have all my email locally in Thunderbird, and use gmail solely as an IMAP server. Why would I want to do anything else?

Err, because I maintained OfflineImap and - believe it or not - most users of the gmail backend were actually using Google and were not happy to just use it as an imap backend?

*I* don't use gmail at all but most users actually do, at least the support issues we received suggested that.

Why kernel development still uses email

Posted Oct 19, 2016 19:12 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

I don't doubt that people wanted something more, but I guess I've never really wanted more (other than Gmail to recognize "move"). Looking at my configuration for offlineimap, I see that the local repos are marked as `GmailMaildir` and the remotes as `IMAP`. What features am I missing (with and without my "All Mail" and "Sent" exclusions)?

Why kernel development still uses email

Posted Oct 4, 2019 20:00 UTC (Fri) by ceplm (subscriber, #41334) [Link] (1 responses)

> gmail offline is mostly non-functional

that’s true, but I would expect that many uses GMail as a second-rate (or third-rate) IMAP server.

Why kernel development still uses email

Posted Oct 4, 2019 20:56 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Yep. I use gmail, but the only time I use the web interface is for label and filter management. Anything else, mutt is way more competent at doing.

Why kernel development still uses email

Posted Oct 6, 2016 7:11 UTC (Thu) by marcH (subscriber, #57642) [Link]

> you seem to be the most vocal opponent of email review in this thread.

Let's keep things in perspective: I didn't prepare and give a speech at a conference :-)

I think I understand the inertia, the highly efficient email shortcuts, scripts and workflows finely tuned over many years of experience, the limitations and immaturity of the current server-based alternatives... basically everything Damien said in his insightful blog post. On the other hand I really don't get the high-profile praise of the obsolete status quo when the rest of the world is moving on. That's seclusion and much more worrying. Worried that Linux is falling on the other side of this quote: "First they ignore you, then they laugh at you, then they fight you, then you win".

> In particular, e-mail works without a network connection – you can download your
> incoming e-mail at home, write replies to it during a train or plane ride where the
> connectivity is terrible, and send the replies when you're back on the net.

Offline is a fair question. I don't know any centralized review system with a good offline mode.

- This doesn't mean it's technically impossible. For instance before bitkeeper/git/mercurial/etc. most people didn't imagine that version control could support well both servers and offline. The following Gerrit client was mentioned above; I don't know it but it seems to basically solve this problem: http://princessleia.com/journal/2014/09/offline-cli-based.... But let's pretend users prefer to stick to official, "core" tools and are not ready for (experimental?) third-party extensions.

- While not as convenient as email, it is possible to perform some work offline with systems like Gerrit thanks to... email! Not open-the-flood-gates-and-then-filter kind of email but a limited number of throw-away notifications from selected/subscribed reviews. More specifically, offline reviews involve the following phases:
1. Pre-fetch
2. Read and write replies
3. "Fire and Forget" send while still offline
# 1. and 2. can be done and are being done today thanks to email notifications.
# 3. is typically not supported without third-party extensions. Ideally it should be however note this: "Fire and Forget" / offline send can make you look silly when your reply happens to be just an incomplete and inferior version of another reply that someone else already posted while you were offline. You look even sillier in today's cloud-based / always on-line world where some people will fail to even imagine you can send while off-line.