Live data from Hacker News

Why kernel development still uses email

lwn.net

121–130 of 152 posts

Re: Why kernel development still uses email

#121
post #97

Earlier quoted context omitted.

I don't get how your pup situation doesn't get solved with a conversation with a co-worker.

I do. Do you want to really be "that guy" who hates puppies (and is ribbed about it all the time)? Software development teams often have all the maturity of a clique of middle schoolers; and exclusion can be just as harsh.

I'd say that people that don't have the maturity to raise a legimitimate work issue with their coworkers are more likely the immature ones.

I have been and continue to be "that guy" who says "this is interfering with work, let's fix it", instead of that guy who doesn't say anything and instead just complains anonymously on social media. It works better this way.

Re: Why kernel development still uses email

#122
post #112

Earlier quoted context omitted.

I can't abide ad-hoc synchronous communication , not just phone calls. It's the reason I'm almost constantly wearing headphones, whether I'm listening to something or not. I sometimes hear that a cow-orker is talking to me, but I ignore it on purpose, pretending not to notice. Then they usually figure out they need to attract my attention somehow, so they come over / wave their hands / throw an object at me. I respon…

Best workplace for creative work like programming is a room for yourself. The shared office concept was a mistake inspired by assembly lines. Sharing space with coworkers is good in factories because work is often dull and workers can talk to each other. For creative work, it's nothing but a hindrance.

I work in a team and find it very useful to easily speak with a coworker when necessary. The increased degree of communication has a very positive impact for me. And I don't feel the need to shit on factory work, which I have never done and suspect you never have, when discussing it.

Re: Why kernel development still uses email

#123
post #17

Email is an amazing tool. I don't understand the rush to get rid of it. It is a free standard with many implementations on both the client and server. It is exceptionally easy to manage email. Many servers have great systems for categorizing emails and storing them long-term. Email is fast. Everyone has one. There is this weird myth that Email magically kills productivity while Slack and GitHub don't. I never underst…

Email is tremendously complex, uses multiple protocols to accomplish different tasks (or even the same task), and is fundamentally vulnerable to spam and can only be patched with further complex hacks like SPF. Almost everyone now uses HTML email, an ill-defined and insecure idea, adding to the complexity of implementations. If you think that email is a good system, trying setting up postfix, dovecot, sendmail, and w…

My company provides my email access. As all companies do.

Re: Why kernel development still uses email

#124
post #16

"Some systems, like Outlook, will uniformly corrupt patches; as a result, companies doing kernel development tend to keep a Linux machine that they can use to send patches in a corner somewhere." Isn't a Linux desktop also convenient for the development itself?

I developed a series of patches for the RPi kernel fork. I use the Pi headless, and generally access it from a Windows machine. I never tried to send those patches upstream - and the Pi fork uses Github for such things - but I'm entirely confident that if I tried to paste those patches into an email client somewhere along the line, I'd get an upstream maintainer pointing out that magical line breaks blew something up…

What I read is "I am entirely confident about what would happen if I tried to do something I've never tried to do", which is useless speculation.

Re: Why kernel development still uses email

#125

Earlier quoted context omitted.

I don't really feel that you being a millennial or using vim is relevant. I have no idea how you would go about getting github to implement whatever functionality is desired and even so would come with the following disadvantages -- Requiring a chrome extension limiting people to using chrome + a singular website vs any email client under the sun -- wouldn't work offline -- Presumably it would be more challenging for…

> Requiring a chrome extension limiting people to using chrome And people who use extensions. Beyond ad blocker on some machines I don't use extensions on principle because of security concerns.

Catehorically not using extensions, regardless of their permissions system, sounds less like "security concerns" and more like "fear rooted in ignorance." Continuing to use some of them (ad blockers), regardless of said "security concerns", sounds like cognitive dissonance.

Re: Why kernel development still uses email

#126
Amusingly, the article references Kubernetes and its growing pains a couple times, but fails to mention that it adopted Reviewable (on top of GitHub) for doing more complicated code reviews. I don't know if Reviewable would scale to kernel development -- and it certainly doesn't support offline work, etc. -- but at least Kubernetes seems to be doing all right with it.

(Disclosure: I'm the founder of Reviewable.)

Re: Why kernel development still uses email

#127
post #91

Earlier quoted context omitted.

My inclusion of directory as a downside of email was a poor choice on my part -- I occasionally get swept up in writing something, and the thought's been kicking around my head for a few days that email is NOT based on a global directory, but a directory of directories, possibly hierarchical. This means that if you want to get something somewhere, as with routing and DNS, you kick it off first in the right general di…

Your poll-and-fetch suggestion sounds really interesting. Even if is not combined with a widely used reputation system, it would greatly increase the cost for spammers by requiring them to stay online indefinitely. It's basically graylisting on steroids, but without the annoying delay that graylisting imposes on every sender.

Bingo.

Mind that that cost can be met by some spammers, as it's effectively how a number of present online systems work. But in general, spammers tend to be taken down, and you remove the fire, cram, and forget mechanism of mail blasters, or the sparse, wide botnet model, where a given node emits only a relatively small number of messages.

Adding reputation to the mix strikes me as the secret sauce though.

Re: Why kernel development still uses email

#128
post #114
post #91

Earlier quoted context omitted.

Your poll-and-fetch suggestion sounds really interesting. Even if is not combined with a widely used reputation system, it would greatly increase the cost for spammers by requiring them to stay online indefinitely. It's basically graylisting on steroids, but without the annoying delay that graylisting imposes on every sender.

It's interesting to note that this idea isn't completely new, and raises some questions as noted by djb: https://cr.yp.to/im2000.html

Thanks for that. Yes, djb has thought through a lot of matters of trust and ought be considered. I'll take a look at that, I think I've read it before.

Re: Why kernel development still uses email

#129
post #99

Earlier quoted context omitted.

Email is tremendously useful, and whatever replaces it should borrow from those useful bits. It also has numerous problems. Some are listed in the article: 1. Clients (and some servers) mangle email. You can't be assured that what you send is what someone else will receive. I blame the clients and servers here, but ... 2. Privacy. This has become among the biggest downsides. Whether it's data-in-flight or data-at-res…

Regarding 5. what's wrong with opt-in and mandatory email lists? If you want to reach a team, email team@example.com. When you join a team, email team-subscribe@example.org, or maybe your hr/sysadm will add you to team@example.com. If you want to reach person@example.com - if you're part of the same company, your client does an ldap lookup. Or you have a look at https://example.com/employees.html or contact.html. It…

I think the matter of lists is orthogonal to the issue of global directories.

I have ... well, not quite nothing, but little against the concept of email lists. They're useful. I've used them extensively. They don't, of and by themselves, address numerous other problems with email. And they can and do insert a few of their own.

Regards lists and directories, I'm not entirely sure what your argument is, but I can interpret your comment at least two ways:

First, an email list is a directory. Yes, it is. It is not, however, a global one. In the right contexts, a list can address the question of discoverability, but that's somewhat secondary. There's the question of what mail is or isn't allowed on-list (e.g., is it open to all senders, or subscribers only?). Service lists -- the effective utilisation of addresses such as postmaster@ or webmaster@ -- typically have to be fairly widely open. This creates some well-known issues, mostly having to do with spam, but also of privacy and organisational confusion over who should or shouldn't be receiving such messages, or how they ought respond. For many corporate distributions, the names of such lists are not generally advertised outside an organisation, though likely targets include "all@", "sales@", "engineering@", etc. Again, this can be useful or not.

The other point you seem to be making is that an organisation can automatically manage its own lists through directory systems. Again, this is addressing the concept of a directory of directories, and any one of the (sub)directories might choose to expose or conceal elements to specific entities. Nothing in any of this is required or constrained by what I've written above.

More generally, you seem to be addressing the question of discoverability, which is a general one. The idea that organisations with their own individual entities might have or conceal means of reaching or contacting people is an old one. I'd call it the introductions problem.

An anecdote from personal experience. At various times, I've had an interest in contacting specific people at organisations. Two come to mind -- an IBM director over a matter somewhat concerning the company, and an issue involving spam transiting a Microsoft-run service. My general biases are that I'm favourably inclined toward IBM, and unfavourably toward Microsoft.

In each case, I found a general switchboard phone number and called, asking for the individual by name.

In the case of Microsoft, the operator said "just a moment", connected me through, the director picked up on the first ring, we had a brief conversation where I described the problem (about five minutes or less), he said he'd get me in touch with the person I needed to talk to, took my number, and within fifteen minutes I was talking to the manager in charge of the unit. We worked on the issue (I had better information than him) for a few months whilst they resolved it, quite measurably.

In the case of IBM, I was connected to an administrative assistant who said, and I think I'm quoting directly, "You can't talk to him, he's a director".

I'm struck by the difference to this day. Much as I don't care for Microsoft, my impression is that they know how to run a business and to transmit information. On the other hand, IBM may have its reasons for sheltering its upper-level management. I suspect otherwise.

Re: Why kernel development still uses email

#130
post #114
post #91

Earlier quoted context omitted.

Your poll-and-fetch suggestion sounds really interesting. Even if is not combined with a widely used reputation system, it would greatly increase the cost for spammers by requiring them to stay online indefinitely. It's basically graylisting on steroids, but without the annoying delay that graylisting imposes on every sender.

It's interesting to note that this idea isn't completely new, and raises some questions as noted by djb: https://cr.yp.to/im2000.html

And, yes, I've seen the IM2000 proposal before, it's undoubtedly influenced my thinking, though I didn't have it in mind writing above.

I'd really like to see a further exploration of the concept. djb's essay is still only a very rough outline.

Post reply on HN