Live data from Hacker News

Why kernel development still uses email

lwn.net

91–100 of 152 posts

Re: Why kernel development still uses email

#91
post #38

Earlier quoted context omitted.

I think you're trying to have your cake and eat it too. Wouldn't a global directory of email addresses be the antithesis of privacy? The greatest difference between email and all of today's proprietary alternatives is that your email identity doesn't need to be vetted by any central authority. Of course this makes spam harder to deal with, but it's part of the cost of decentralization and one that we must learn to de…

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.

Re: Why kernel development still uses email

#92

Earlier quoted context omitted.

> I'll need to find and install one of the x tens of IM clients. Only one? :) It got so bad at my company, that at one time we were having conversations on 3 platforms. And, of course, no one emails anything! Because it's all done on Slack or whatever now. So everyone is 100% out of the loop at all times. I'm up to about 20 Slack channels. I'm constant switching between things to see if I need the information. We hav…

Man, your Github notifications are mixed into Chat? We have a #{{projcet}}-dev channel for talk and #{{project}}-admin for JIRA/Github/etc. Also, in Slack you can have it auto-close all expansions. You choose the Gifs you wanna see.

Unfortunately, slack doesn't allow you to block users - not even bots or webhooks. And even if you have expansions turned off, they're still there in collapsed form.

So if you're not an administrator, and some genius has set up a bot that posts a cute puppy every time a message includes /pup, and it triggers practically every line in a discussion about puppet, slack doesn't give you the option to do anything.

Well, apart from "complain to your boss and ask him to stop your co-workers' fun". As a professional, I don't want to be wasting my boss's time with trivial shit I ought to be able to fix myself.

Re: Why kernel development still uses email

#93

Earlier quoted context omitted.

Outlook it probably the worst email client currently on the market and has been for the all of it's existence. It is my belief of the issue at lot of people have with email stems from Outlook. One example is the weird instance of top posting has made it hard to read many conversations and fostered a mentality of firing of quick response, reducing Outlook/email to a poor mans IM client. There's a ton of improvements t…

Nope, Lotus Notes takes that prize.

I forgot about Notes. Yes, Notes is worse.

Re: Why kernel development still uses email

#94
post #72
post #51

Earlier quoted context omitted.

> There is this weird myth that Email magically kills productivity while Slack and GitHub don't. Yes. I really can't abide chat for work. If I have time and need synchronous communication, I make a phone call. Email forces me to think my communication through, and I can explicitly CC/BCC other people if I feel that they need to read my letter. PS: I find it telling that the product is actually called "Slack". ;)

I can't abide ad-hoc phone calls, unless somebody is bleeding out or the server rack is bursting into flames. If I'm trying to work on something, hitting me in the back of the head with a claw-hammer would be scarcely more disruptive than an unsolicited phone call.

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 respond politely, but with very visible annoyance. This quickly trains them to use IM instead. IM, for which I often have notifications turned off.

Avoiding distractions at workplace is a hard work in itself.

Re: Why kernel development still uses email

#95
post #81
post #66

tl;dr: my wish is a code review convention for git-notes and a friendly UI on top. If only Git would allow storing reviews and issues in the repo proper. Something like Git notes with conventions to refer to files/lines in a file/different revisions etc. Something similar to Fossil. This would solve half of the problem. The other half would be the UI layer. Now the reviews live in a database, outside of the repo, and…

Something like this https://github.com/google/git-appraise ?

Yes, something like that. I've seen it before and it sparked my interest.

Not sure about using json, though.

Now this project is just the first step, now it needs a code review tool (UI) on top that's good enough to match Gerrit, GitHub, etc.

Re: Why kernel development still uses email

#96

Earlier quoted context omitted.

Outlook loves messing with messages. "Detecting and removing" extra line breaks is one of its features

I remember reading that when Microsoft started contributing some code to the Linux kernel (to support Hyper-V mostly) they had to run their own Linux server in house so they could send properly formatted emails for their patches, since they had no way to send email that wouldn't be messed-up by their Outlook servers.

Not sure. I have successfully submitted patches to Linux using Outlook and Exchange.

All it took was going through configuration and disabling some features which intuitively looked like they may mangle my emails.

Re: Why kernel development still uses email

#97

Earlier quoted context omitted.

Man, your Github notifications are mixed into Chat? We have a #{{projcet}}-dev channel for talk and #{{project}}-admin for JIRA/Github/etc. Also, in Slack you can have it auto-close all expansions. You choose the Gifs you wanna see.

Unfortunately, slack doesn't allow you to block users - not even bots or webhooks. And even if you have expansions turned off, they're still there in collapsed form. So if you're not an administrator, and some genius has set up a bot that posts a cute puppy every time a message includes /pup, and it triggers practically every line in a discussion about puppet, slack doesn't give you the option to do anything. Well, a…

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

Re: Why kernel development still uses email

#98
post #60

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…

Number one on your list is a big issue with using e-mail for kernel development. If you want to submit patches by e-mail, you have to install and configure one of a handful of clients that doesn't mangle the patches first. There's a list in the kernel documentation and they're not terribly user friendly. (In fact, by necessity they have to be, because not wrapping lines automatically is terribly user-unfriendly and r…

Wait, I thought patches are typically attached, not sent in-line on lkml? Admittedly I've only ever submitted a patch once, in 2002 or something - and at the time I was using pine as an email client.

[ed: never mind, my assumption was wrong:

https://news.ycombinator.com/item?id=12620790 ]

Re: Why kernel development still uses email

#99
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 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 might at times be difficult to find a random person's email - if you know nothing other than the name - but it's generally very easy to find a contact email for a Dev/security team for a project or company?

Re: Why kernel development still uses email

#100
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…

> I'll need to find and install one of the x tens of IM clients. Only one? :) It got so bad at my company, that at one time we were having conversations on 3 platforms. And, of course, no one emails anything! Because it's all done on Slack or whatever now. So everyone is 100% out of the loop at all times. I'm up to about 20 Slack channels. I'm constant switching between things to see if I need the information. We hav…

GitHub is really useful for issue tracking on open source projects. It's annoying to have to hunt through whatever 90's era mailing list archive website to see if someone else has had the same issue on projects that don't use it.
Post reply on HN