“Problems” with git format-patch | Hacker News Reader

“Problems” with git format-patch

public-inbox.org

134 pointsdavvid49 comments

Gmail is wrong? And no surprise there.

Don’t get me wrong: having written enough email-stuff myself, I can fully sympathize with Linus.

That said: Just like the worldwide web is quickly turning into whatever Google pushes through Chrome and their web assets, internet email now slowly seems to become whatever Gmail does or supports. Which is terrible.

90% of the programming guides for various languages and libraries now are not “This is how you send an internet email using SMTP from $X”, they are “This is how you send a Gmail from $X”.

And all that’s because of one single thing only: Market-share.

Get off Gmail. Get off Chrome. And help others do that too. Help bring down that market-share, and you may help restore balance to the internet.

I've been hosting my own mail for more, than a decade. It pays off; eg. I can access it even in China, unlike gmail.

Despite the myths, it's not _that_ hard to set it up, but you do need your clean own ipv4 address for everything to go smooth - I mean go around and get it off blacklists before you actually start using it as mail server. Test it here: https://mxtoolbox.com/blacklists.aspx

Once that's done, things like SPF, DKIM, DMARC are time consuming to set up, but not particularly hard or tricky, and there are tonnes of good guides out there.

The problem is that for some people it's even to hard to switch to another provider than Gmail, how are they supposed to setup their own mail server?

If you have an ISP, that ISP is providing you email _right now_. Not being able to find another provider isn't an issue.

> you do need your clean own ipv4 address

Actually you need to clean /24 your address belongs to. Some people use blacklists which assign reputation to the whole /24 and unless you control that, you're going to have a bad day.

(Yes, it's a really silly idea to use those lists, but some people do. And you want their users to get your emails.)

I had my own mail service. I switched to gmail when it first came out because the spam filtering was much much better than anything than available to the public. Kind of like why I switched from altavista to google search.

What's the spam filtering picture like for DIY these days?

I use rspamd. Works really well for me.

Greylisting + weighted dnsbl from multiple sources stops the majority of it. The remaining can be caught even with bogofilter.

How's the false positive rate?

It is so sad. Isn't email meant to be decentralized and distributed? Instead people go to Gmail although it's full of ads and Google is abusing their privacy. The death of Google Inbox (which used to have a strong fan group) could have been an opportunity for many users instead of using Gmail switching to another email provider, instead they just install another client and continue using Gmail. I really hope Gmail is going to implement harder restrictions against those clients, so that people finally understand that Gmail is bad and look for other options.

Doing my part. I've been an Inbox user ever since it was released, and liked it due to how much simpler it was to keep the inbox clean, and a much improved layout and usability over regular Gmail (centered, cleaner layout, grouping by day / age etc). But lack of attention to the product for smallest basic things (e.g. number of unread messages in tab title) for years, and eventually announcement of shutdown, with simultaneous missteps with Chrome, really did it for me. Looking at a garbled mess that is Gmail UI on a larger resolution was not an option. Aqua Mail is amazingly customizable for Android, Postbox works nicely on OSX, and Firefox is better than ever and much easier to go back to than I expected. Not looking back for sure. If only I could get rid of my Gmail address as well, but that's significantly harder...

I have thought about using something else than gmail, but it seems hard to find something reliable enough, free, that will still be there in 10 years, which a good enough spam filter, with customizable filters and labels.

Changing one's email address is not a trivial task, I would not do it if I would be sure it's worth it.

I totally understand the political issues of privacy and monopolies, but fighting those by not using gmail is not going to improve things that much.

Everybody knows privacy is an issue, but switching to a privacy-oriented mail provider will also make somebody rich over some paranoia, and it won't necessarily make things more secure.

> it seems hard to find something reliable enough, free

I’m sure if you decide that your privacy and the health of the Internet holds value to you (as in, you’re willing to put your money where your mouth is), finding good options will be much easier.

Personally I use a paid FastMail-account which I’m super-happy about, but I’ve heard there are other good options out there too.

But if you don’t want to pay for a core service you use every day, for everything, you can’t complain about that service degrading, now can you?

You have to pay for it basically. My Fastmail subscription is absolutely worth it.

If you buy a domain through gandi.net, they give you 2 email addresses free. They use SOGO, so it's decent.

I like Gmail. I like Chrome.

Why would I sacrifice my productivity for some abstract over-arching notion of "balance"?

Because you might not like where Google takes Gmail or Chrome in the future. Like when we had a decade of zero progress in web technology because Microsoft was holding everyone back with their virtual Internet Explorer monopoly.

Why would I not simply stop using them at the point where I no longer like them?

Because by then the web might not work without Chrome.

Okay. And this interfers with my routines, how?

When did I say it interfered with your routines?

In other words, "fuck you, got mine" ?

Why would my completely reasonable action be interpreted as something rude? There's no "you" featured in my decision.

Or more graciously, it's an example of how most or all of us prioritize what is convenient today over the very real risk of negative things tomorrow. Harm to others in the future doesn't weigh as heavily as as immediate harm to myself now.

We don't usually realize we're doing it, but I think we all do this. Using Google products is a very common example.

It's a valid example only if you buy into the idea that Google is dangerous.

It's invalid only if Google could never be dangerous. That's why I referred to "the very real risk of negative things tomorrow" rather than "harm to others today."

As an aside, this is a superbly professional e-mail, with clear references to the applicable standards, and the disapproval of the broken service stated firmly, but using clean language. Does anybody really think that Linus' (hopefully) past practice of starting with a foul mouthed rant, and only drilling down into the technical detail three pages in was a more effective way of communicating?

It wasn't "past practice". Linus' rants were a rare event, in case of major "sins" commited by core contributors. They are what made it out in the open, but a lot of Linus' messages in the mailing lists is actually a sane, technical discussion.

I recall Linus calling some filesystem brain-dead (-damaged?). Could be [1] or [2], but I'm getting a cloudflare error when I try to visit the links. Not as bombastic as some of his rants, but this email is much more professional.

[1] http://thread.gmane.org/gmane.comp.version-control.git/70688...

[2] http://article.gmane.org/gmane.comp.version-control.git/7076...

It was more entertaining, and also working to figure out others' mistakes is more rewarding if you get to berate them in public, so not being allowed to rant reduces the incentive to do the work and thus makes more likely that mistakes will remain unnoticed.

I'm sure Linus used clean language 99.999% of the time. He sends dozens of mails daily, so his rate of swearing is not out of the ordinary. The media made it to be something newsworthy, when it was not.

Well, there may be some selective reporting, but I'm pretty sure you could go through the public writings of other prolific open source contributors (e.g. Larry Wall) without even digging up ONE instance of public profanity.

Here’s a copy of the thread with a light color scheme: https://marc.info/?l=git&m=155260711429449&w=2

It has a light color scheme, if your browser supports the media query `screen AND (prefers-color-scheme:light)`. Currently that’s Safari 12.1, and Firefox beta channel or later.

(I run Nightly, so I was initially puzzled by your comment, since I was seeing it light.)

I had no idea. Cool!

It's tempting to pile on Gmail and its monopoly and use this as an example of them "taking over" email but at the same time this type of ossification for long-used protocols is fairly common in my experience. In practice everybody ends up relying on a safe subset of the spec that everybody is expected to understand correctly.

Try implementing a fuzzer for HTTP, SMTP, NTP, USB-C, CD-ROM or, say, TLS that tests every obscure corner case of the spec and see how many implementations fail to conform.

Given that I wasn't aware of this issue before reading this email shows that it's probably not much of an issue in practice. I can imagine that whoever implemented this at Google took a shortcut originally, adding a "// XXX maybe we should allow arbitrary order for headers?" comment and it never turned out to be an issue in practice (better yet, it might help them discard bogus emails early in the pipeline).

Still, I can empathize with Linus's frustration, it's always annoying when you write technically correct code and it doesn't work because a third party didn't do it right.

Would it help to shuffle the order of the headers in new protocols so software is forced to deal with it actually being optional? Either the order is fixed, or you have to actually experience variety so code in the wild is written to deal with it.

> (better yet, it might help them discard bogus emails early in the pipeline).

I wouldn’t expect it to be deliberate, but at the same time it wouldn’t surprise me if it was in fact deliberate. SpamAssassin certainly has various rules around precise unusual patterns in headers, penalising things that are perfectly legal, but close to never seen on legitimate email.

The main reason I wouldn’t expect it to be deliberate is actually that it’s too helpful: they tell you they’re rejecting it, whereas Gmail’s regular spam filtering is a black box that discloses nothing. I could imagine them black-holing emails like this deliberately as part of a spam-filter, but rejecting them isn’t their style.

> this type of ossification for long-used protocols is fairly common in my experience

Agreed HTTP (and all it's intermadiary like proxy and cache servers), FTP, IRC, SMTP, ... When you take a peek at what the incumbent actually do and support it's a real wonders that anything works at all.

Everyone has their own specific thingy and they own way to understand this or that part. Are they wrong ? Yes, probably, but at the end of the day it's just like this case: the question is not is gmail right or wrong, it's do you want your mails to go through gmail or not.

>Given that I wasn't aware of this issue before reading this email shows that it's probably not much of an issue in practice

Two economists walk down a road. One of them says, "look, a $20 bill on the ground."

The other one says, "that's impossible, if there was money on the ground, someone would have picked it up already."

I don't understand how that applies to what I was saying. I was commenting that it's not an issue that crops up often in practice, which is probably why the engineers at GMail made the assumption that it could reasonably be ignored.

I'm not saying that it can never be an issue (this it obviously is in this case), I'm saying that it's not necessarily a bad engineering decision. Adding code to handle weird corner cases of a standard means adding code that won't be used 99.999% of the time (a number I pulled freshly out of my buttocks, but wouldn't be surprised if it was close to the truth in this case), that's more likely to rot, be poorly tested and become a maintenance liability.

I'm not saying people never find $20 bills on the ground, I'm saying that if most people routinely found $20 bills on the ground every other day we'd probably have heard about it by now. The fact that it only came to my attention in this email (and I hosts my own email server and have written SMTP clients and server code in the past) tells me that it's probably not such a widespread problem. If GMail started routinely bouncing incoming mail because they didn't support the standards correctly I'm sure we'd see an article or ten pop up on the front page of HN.

Maybe you're right. I just like that joke.

Making errors while producing software is natural. Deciding to ignore complaints and refuse to fix your errors is not. It's just Google arrogance.

I'm more disappointed about the RFC than gmail... Publishing a specific syntax which uses specific ordering and just leaving a note that it's actually incorrect is a really bad way of writing specifications. RFCs should be really clear and explicit in things like that.

You are supposed to read the whole RFC (and then some more) when implementing it.

Sure, that's the theory. The practice is that people won't, and you either have to accept the bad implementations or make sure that everything is as explicit as possible. (And that you don't contradict yourself) If people implemented specs 100% correctly, we wouldn't have bugs.

Even without malice or incompetence, people will make mistakes.

> I have a very strong suspicion that it's easier to fix "git format-patch" than it is to fix whatever odd gmail issue.

Third option: Update the RFC so that it's more opinionated and makes the ordering of the headers a mandatory part of the spec.

Have the entire world change their implementation rather than the one company which is doing it wrong?

This is not how RFCs work. There's a reason RFCs came about, and it was to prevent this exact type of situation. Just because a company has a large market share, doesn't mean RFCs should be changed to suit it.

So instead of a non opinionated RFC that most clients and servers mostly follows you now have an opinionated RFC that nobody follows and is useless. I'm not sure what the gain is there.

Reply on news.ycombinator.com