Trello generates $4m in annual revenue, Atlassian earnings report indicates - <AUTHOR> http://www.zdnet.com/article/atlassians-customer-roster-swells-delivers-solid-q2/ <comment><USER2> If true, and if the internet is correct about company size being between 51 and 200, then that means each employee only generates between ~$78K and ~$20K. Anyone know if that is low or not? Seems low to me (compared with software engineer salaries), but I suppose that depends on what kinds of employees they have and how much they pay.

<comment><USER3> From their 2016 Annual report ( [https://s2.q4cdn.com/141359120/files/doc_financials/2016/Q4/...](https://s2.q4cdn.com/141359120/files/doc_financials/2016/Q4/Atlassian- FY2016-Annual-Report.pdf) )

Employees = 1760 (page 43)

Revenue = 457 Million (page 48)

Revenue per employee ≈ 260k

<comment><USER2> That's for Alassian, not Trello.

</comment></comment></comment><comment><USER4> Duh.

We wanted to pay for Trello, we tried paying for Trello, we even explicitly asked _how_ can we give you money, but the only option was to get stickers and smileys as premium pro features. So $4m sounds not a bit surprising.

<comment><USER5> What do you mean? Couldn't you sign up for a Business Class account? [1]

[1] [https://trello.com/pricing](https://trello.com/pricing)

<comment><USER4> In the end we did, but it was ultimately a donation, because none of paid features was useful in our case.

<comment><USER5> I get that. That was my company's experience with Slack.

</comment></comment></comment></comment><comment><USER6> So it was acquired with a multiplier of 106x its revenues. WOW

</comment><comment><USER7> Wow, this is news. Trello is such a popular product and it only makes like 4m a year? That really is very very low. I wonder what changes we will see now that Atlassian have to make up for 400m.

</comment><comment><USER8> Atlassian is really good at growing Trello like business. I bet their marketinf/growth folks are salivating.

<comment><USER9> Userbase is large enough already... problem ia more of a monetization one?

</comment></comment><comment><USER10> Does this mean that Atlassian is looking for Trello to generate more sales for their core products? I think it does. Having said, how long until they see (whatever that means in this context) the $425MM they paid for it? How are they defining a successful acquisition?

<comment><USER11> Obviously this wasn't about revenue!

A sane valuation is 2x-10x revenue, so their bet is that this quickly can be turned into something that generates $30m a year. You could think about this as incremental to a business with $400mm a year in revenue: are there enough people using Trello that, with a few points of integration, could be convinced to switch to Atlassian products? You'd "only" need to add 10% to your growth for this year to feel like this is worth it.

Realistically, this is probably more of a strategic play. Atlassian wants to own the development workflow, and Trello is one of only a couple players in this space that are entrenched enough to be attractive. If you assume the market for dev tools is $100b (think total value of Github's market + Slack's market + StatusPage's + ...), buying a dominant market share in one of ~10 major products for half a billion isn't crazy. As Trello-type tools move from "a good way to interact with the business" to "crucial for all development teams", this may just be a way to keep themselves from dying. Success is merely being a player in this space.

<comment><USER12> Some have found the opposite. In the recently published RethinkDB postmortem [1], the founder suggests that the dev tools market is inherently unattractive for startups:

 _" Unfortunately you're not in the market you think you're in – you're in the market your users think you're in. And our users clearly thought of us as an open-source developer tools company, because that's what we really were. Which turned out to be very unfortunate, because the open-source developer tools market is one of the worst markets one could possibly end up in. Thousands of people used RethinkDB, often in business contexts, but most were willing to pay less for the lifetime of usage than the price of a single Starbucks coffee (which is to say, they weren't willing to pay anything at all)._

 _" This wasn't because the product was so good people didn't need to pay for support, or because developers don't control budgets, or because of failure of capitalism. The answer is basic microeconomics. Developers love building developer tools, often for free. So while there is massive demand, the supply vastly outstrips it. This drives the number of alternatives up, and the prices down to zero._

 _" To see how this plays out for other companies consider MongoDB (valued at roughly $1.6B with ~700 employees), and Docker (valued at roughly $1B with ~300 employees). Both companies completely dominate in their respective markets. Two very rough rules of thumb for private growth stage technology companies is that valuations are a 10x multiple of annual revenue, and that revenue per employee is around $200K/year. Which means that MongoDB's annual revenue is around $140-$160M, and Docker's annual revenue is around $60-$100M._

 _" That looks pretty good, until you look at dominant B2B technology companies in markets that aren't developer tools. Companies like SalesForce, or Palantir, or Box (which faces stiff competition). All of a sudden MongoDB and Docker start looking tiny."_

[1] [http://www.defstartup.org/2017/01/18/why-rethinkdb- failed.ht...](http://www.defstartup.org/2017/01/18/why-rethinkdb-failed.html)

<comment><USER11> I don't actually disagree with that post-mortem. Databases (and similarly, SDKs, widget libraries, and all other sorts of code-only deliverables) are rough to monetize, precisely for the reason that the RethinkDB founders believe. In addition, if you need some capability to build your product, purchasing it always means buying more capability than you need and doing more integration work than you thought you would have to.

On the other hand, workflow tools, especially if hosted, do really well and get to charge money. Jira, Github, New Relic, PagerDuty, and if you stretch it far enough, AWS do a rocking business selling to developers, because (imho) they are tied to the business process of delivering a product, not the developer need to build things.

The market for selling to developers is huge, because the market for things created by developers is huge and developers are expensive to hire. You can't sell just anything because of the supply problems cited above, and I think Trello's user base is the big story here that RethinkDB didn't have.

<comment><USER12> Good points, thanks!

It's interesting to consider that PagerDuty is a developer product that can be successfully monetized whereas RethinkDB isn't. This runs counter to developers' own assumptions about what are the "hard" (and therefore presumed valuable) problems.

Maybe a rule of thumb: If you can come up with a developer product that solves a need but is not technically interesting for developers themselves to build, you might have a winner.

</comment></comment></comment></comment></comment><comment><USER13> Trello blows. Sorry, it does. It seems more for show than actually getting things done. Functionality was sorely lacking for me.

Last year I tried to do my first Android app, a Trello widget and found the functionality of the REST API lacking too, and there was no way to use the Trello credentials from their own app not interface with it well. After some exchanges with their dev team I basically gave up.

</comment><comment><USER14> We've updated the title from "Trello only generates $4m in revenue, Atlassian earnings report indicates", which breaks the submission guidelines by editorializing.

<comment><USER15> The reason people seem to be in this thread is because of the tidbit of information about Trello, not because Atlassian's had a "solid Q2". The new title is not very discussion worthy.

I appreciate HN has policies around editorialization but it seems titles that better tell the story HNers would be interested in are changed to more opaque ones on a frequent basis. (Admittedly I'd have dropped the "only".)

<comment><USER14> I appreciate this thoughtful comment, but this is more like DNA than policy. Hacker News is emphatically focused on content. Titles are not the things that should be discussion-worthy, content is. And titles are subservient to the content they aim to represent, and need to do so as accurately as possible. Original titles are often best suited for this.

It's not up to the submitter to decide what readers might find interesting, especially when doing so misrepresents what the content actually is. It's not fair to mislead readers with a title about Trello when the article is primarily about Atlassian.

But all is not lost: if there's a particular tidbit that the submitter has found interesting, the perfect place to bring that up is in the comment thread.

<comment><USER15> _I appreciate this thoughtful comment, but this is more like DNA than policy._

I considered it policy because it has changed. Up until about two years ago, it was okay to provide context in titles as long as they weren't "over- editorialized" \- I believe this word was actually used in the guidelines document.

 _And titles are subservient to the content they aim to represent, and need to do so as accurately as possible._

Titles are an unavoidable and valuable gateway to content because a reader's decision to read rests upon them.

For 2 hours today there was an item just titled "Joxa" on the front page that meant nothing. It was basically clickbait because HN junkies like me _had_ to click on it to work out what it meant. You've since edited it, yet I frequently see titles here being edited the _other_ way.

 _It 's not fair to mislead readers with a title about Trello when the article is primarily about Atlassian._

What _is_ the best, HN-friendly approach to highlighting more interesting "background" stories, such as this? Would it have been for someone to write their own blog post quoting the original story? This sort of thing has sometimes been shot down here as "blogspam" (although I'm fine with it).

<comment><USER14> On reflection, this seems a fair point; we've restored the submitted title (removing "only" as suggested) from "Atlassian's customer roster swells, delivers solid Q2". If the original title weren't such droning PR-speak there might be a stronger case for sticking to the rule, especially since the article is particularly light on Trello details, but it's close enough.</comment></comment></comment></comment></comment>


5G is the 'largest existential threat to broadband providers - <AUTHOR> https://www.thisisinsider.com/5g-could-disrupt-the-cable-industry-2018-8 <comment><USER2> 5G is replacing copper even companies are not competing with different technologies.

In countries where telecom companies provide both fixed broadband and mobile broadband there are plans to shut down last-mile copper and move into fiber and 5G only. Telenor Norway plans to end last-mile copper by 2025. Fixed wireless access has already started with 4GLTE. Already existing services where you get both fiber and 4GLTE together for faster service are also already a reality.

The main benefit from 5G over 4G is larger bandwidth cost effectively.

<comment><USER3> I have 200Mbit/s cabel in the city and they are offering up to 1Gbit/s here, I guess they can keep up with G5 for quite a while.

But DSL, that was the savior of broadband here in Germany, doesn't seem to keep up.

I really prefer DSL/cabel to "radio" based stuff, latency wise, but I have to admit, if they would let DSL die and pump massive money in G5 to get every last square meter of Germany on mobile connections, it would be better for everyone.

<comment><USER2> 5G does not replace fiber everywhere, just copper.

One of the benefits of 5G over 4G is extremely low latency.

In the industry 5G shows promise in factory/robot automation inside plants. 5G has ultra low latency and free operator independent frequencies that make it WiFi competitor.

<comment><USER3> Ah yes,

Somehow I always misstake 5G with LTE.

In Germany they're currently selling 200Mbit LTE, which works okay, even for stuff like Skype.

And yes you're right. The latency seems to be really low, I just read they target under 1ms and the technology they use also works with LTE, which they got down to 2ms with it.</comment></comment></comment></comment>


Ask HN: How do you define success? - <AUTHOR> Just wondering what you guys think makes a person successful? <comment><USER2> Not doing whatever he doesn't want to do. And maybe also doing what he loves to do.</comment>


Monorepos - <AUTHOR> https://qafoo.com/resources/presentations/froscon_2015/monorepos <comment><USER4> Everyone I've ever met who's worked at Twitter _hates_ the monorepo.

They have a single git repo with _way_ more files than that tool was ever designed to maintain. As such, normally instantaneous commands like status, log, ls, etc. take an inordinately long amount of time to execute. Apparently their onboarding process is "have someone copy his working copy to a flash drive, then copy it from there to your laptop" because git pull would take too long.

<comment><USER5> This has to be a sick joke. The monorepo at Google was the bane of my existence, and everyone else that I knew.

I don't know what it's like now, but at the time Google was on svn, and there had to be a specially hacked version of it. It used a home-grown internal requirements system, to pull down the tree in a sparse way. And to accomplish that you had to re-specify all your dependencies in these special text files (because specifying deps in two places is obviously better.) And then the tool would spend a lifetime figuring it all out, and then you would still download like 35% of the repo anyway, because the nature of giant repos is to get tangled together.

With languages like PHP it might not be so bad, as you typically are editing one file at a time. But most of Google is Java, and most people like using IDEs for that, so it was a disaster. An IDE likes to touch everything all the time, to re-index and re-compile. And, fun fact: at the time Google recommended you store your entire home directory on an NFS network drive, for security. Everyone quietly ignored that.

It was better in one way: everyone could see everyone else's source, re-using libraries was more common, and branching and contributing patches was more common. It prevented people from hoarding their source code, and just throwing .jars or .so's over the wall. But I think the Github era has shown that this did not require everything being in one giant repo! I mean, at the time, Google had Codesearch and other great tools; even though git wasn't super common at the time, this could have been solved in other ways.

My current company is in the process of breaking up their monorepo, even though our codebase is nowhere near the same size. Lately I get to taunt my co-workers because I created a new project in the new broken-up way. All the tests on my micro-repo pass in 5 seconds, and it takes many minutes for the big one.

<comment><USER5> Missed the edit window, but of course it was p4 and not svn. Small blessings.

</comment></comment></comment><comment><USER6> > Facebook, Google and Twitter

Aren't these the companies all terrible at taking outside contributions, except for the projects that they don't manage in their monorepos?

<comment><USER7> Based on some brief experience at Oracle, accepting outside contributions is a legal nightmare - it is frequently less expensive to do a clean-room re- implementation of a feature than go through the lawyers and contract negotiations now and in the future to get code ownership rights worked out.

<comment><USER8> agree with this. I think monolithic repos are part of legal strategy in enterprise.

</comment></comment></comment><comment><USER9> The key is enabling maximum developer leverage - and one aspect of this is to get rid of as many systems errors and inefficiencies as possible.

I think build systems and internal code management schemes are large interconnected systems. It feels fairly pointless just to expose one facet of the entire systems since the total system encompasses all of the individual entities dealing with the codebase - including developers, platform - <USER2> whole works.

For example, I see no overhead in my daily work from the fact that our codebase is split to several libraries with dependencies through explicit built release versions. On the contrary,there monorepository would be just horrible.

So, before saying X is great one should firsr define what type of software is built, what is the specific toolchain, what are the specific configurations, how many developers modify the same codebase frequently, and so on.

<comment><USER10> hi, author of those slides here, I actually mention this during the talk, that the talk is over-emphesizing the awesome point to take a point across. It definately is not a technique to use everywhere, so I agree with you.

It works for some kind of projects and i was motiviated for this talk, because I saw so many projects using manyrepos in cases where it may not fit very well.

<comment><USER9> Hi, yeah, sure, effective communication requires simplification.

A few points got me concerned in the slides - namely, concerning emphasizing how _easy_ this makes to change things. I would consider that it is not a positive thing that adding a library is cheap and easy, and I find that component versioning can be bypassed even more so.

It all sounds like grievous local greedy optimization without a view of the entire lifecycle of the codebase. The slides say _change_ is the only constant. I would claim that unless the change is backed by good and strong architecture - which throwing all architectural firewalls away does not support - then the end result will be a mess of spaghetti the older the codebase gets.

But, I may just be too much set in _my ways_ of coding and I respect the fact that these may be non-issues in the particular domain these slides address.

</comment></comment></comment><comment><USER11> Is it really a single big repo for the whole organization? What happens if you want to deploy your code on servers? Do you have to upload all the mobile app code and history as well? Doesn't the history get very polluted this way?

<comment><USER12> Are you really using a checkout on a production server to install and configure your software?

This feels like a "Doctor, doctor - it hurts when I stick a spoon in my eye" moment - "Don't do that!"

Build tools and build servers exist for a reason.

Subversion has "svn export" if you insist on working that way. git can git clone repos --depth 1; rm -rf repos/.git if you really, really must.

And what you are calling polluted history, they are calling efficient collaboration.

<comment><USER11> > Build tools and build servers exist for a reason.

What's the build server going to do? Copy the Python code from the repo to the other server? It doesn't seem like setting up a build server just to do "git checkout; rm .git" is worth the effort.

<comment><USER12> I mostly work with java, so the build server is doing a clean compilation, to ensure the code word outside my dev environment. Pulling in known versions of dependencies, some packaging, unit and integration tests etc. Mostly using Maven.

Whilst some of that is somewhat specific to java, I'd still want a build server to ensure I hadn't managed to pollute my dev environment with and undeclared dependency before I pushed my code to production. And I'd still want to run at least some integration tests, even for the simplest project.

And I really REALLY don't want my internet facing servers to be able to reach into my internal network, which means a checkout simply isn't going to work anyway.

Lastly I don't want my code on those servers either. You can set up .htaccess or equivalent to prevent access to .svn or .git (or dotfiles in general..) but those files really shouldn't have been there in the first place.

<comment><USER11> > I'd still want a build server to ensure I hadn't managed to pollute my dev > environment with and undeclared dependency before I pushed my code to > production.

In my case, the production server is the build server. You can't have dev dependencies there, because you don't develop there.

> And I'd still want to run at least some integration tests, even for the > simplest project.

Integration tests run on the dev or CI server, in my case.

> And I really REALLY don't want my internet facing servers to be able to > reach into my internal network, which means a checkout simply isn't going to > work anyway.

The code servers aren't in the internal network, in my case. They're already internet-facing, since I need to pull from them.

> Lastly I don't want my code on those servers either. You can set up > .htaccess or equivalent to prevent access to .svn or .git (or dotfiles in > general..) but those files really shouldn't have been there in the first > place.

In my case, if my code isn't on the server, the server doesn't run. There's no need to set up .htaccess, since the HTTP server doesn't serve anything off the filesystem.

<comment><USER12> >> I'd still want a build server to ensure I hadn't managed to pollute my dev environment with and undeclared dependency before I pushed my code to production. >In my case, the production server is the build server. You can't have dev dependencies there, because you don't develop there.

The problem is not that dev dependencies exist, the problem is that they might be undeclared or unrecorded. I have imagemagic on my dev machine, but if it isn't installed as part of the server setup script, then it won't be on the production server. The tests might run fine on a dev server that happens to have imagemagic on it, but fail in production.

>Integration tests run on the dev

If you run your integration tests in your dev environment, you might not catch some on the fly configuration changes or utility installations - <USER3> dependencies.

<comment><USER11> I'm using "dev environment" and "dev server" distinctly. The dev environment is whatever I have on my computer, the dev server is a server that mirrors production. If there's a dependency on your dev environment that isn't on production, you'll catch it when you deploy to one of the dev servers. Same with the integration tests.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> > Require Trunk-Based Development

This I think needs bit of expanding. Does he mean in contrast to feature- branches? Why monorepos would not be compatible with feature-branches?

<comment><USER14> Not to answer your questions directly, but Paul Hammant has written a bunch about this over the years:

[http://paulhammant.com/2013/04/05/what-is-trunk-based- develo...](http://paulhammant.com/2013/04/05/what-is-trunk-based-development/)

[http://paulhammant.com/2013/05/06/googles-scaled-trunk- based...](http://paulhammant.com/2013/05/06/googles-scaled-trunk-based- development/)

[http://paulhammant.com/2014/04/03/microsofts-trunk-based- dev...](http://paulhammant.com/2014/04/03/microsofts-trunk-based-development/)

[http://paulhammant.com/2014/01/06/googlers-subset-their- trun...](http://paulhammant.com/2014/01/06/googlers-subset-their-trunk/)

[https://dzone.com/articles/legacy-app- rejuvenation](https://dzone.com/articles/legacy-app-rejuvenation)

<comment><USER13> I just read the first link (adding the others to my reading backlog), based on it it seems like trunk based development is less of a _development_ model and more of a _release_ model. Especially it does not seem to conflict directly with feature branch model.

<comment><USER14> Perhaps partly. But Paul also mentions "Developers do not break the build with any commit" \-- that places a pretty heavy constraint upon regular development outside of releases.

See also the so-called "not rocket science rule of software engineering": [https://graydon.livejournal.com/186550.html](https://graydon.livejournal.com/186550.html)

<comment><USER15> See also got-dmz or atlassian bamboo's gatekeeper feature. Team city has something similar too. Surprised the guy who wrote bors hadn't seen more examples, I have seen the idea come up over and over again (and strongly support it).</comment></comment></comment></comment></comment>


Tablet: personal computer of the year 2000 (CACM 1998) - <AUTHOR> http://portal.acm.org/citation.cfm?id=62959.62960&coll=DL&dl=GUIDE&CFID=13829434&CFTOKEN=22666209

<comment><AUTHOR> Looks a lot like the Apple iPad.</comment>


How the Web Became Our 'External Brain,' and What It Means for Our Kids - <AUTHOR> http://www.wired.com/2014/08/end-of-absence-how-technology-changes-our-brains-society-children/ <comment><USER2> From the article:

"Some experts expressed concerns that trends are leading to a future in which most people become shallow consumers of information, endangering society."

A key part of this argument is that people are becoming (or are going to become) more shallow than those in the past. But how shallow were people in the past? I have a sneaky suspicion that many of these dissenters are just being nostalgic. Anything beyond their own lifespan is also questionable--how do we know how well people were able to focus in previous generations? Are people _really_ more shallow than they used to be, or does it just feel like that?

This whole topic incredibly nebulous, so I question the value of jumping to these conclusions when we don't even have a clear understanding of what we're talking about in the first place.

<comment><USER3> I recall reading somewhere that when books were invented, people thought they'd degrade the mental ability of people to accumulate and hold "wisdom". Did that happen? And even before that, when writing was first invented, it was some kind of devil magic. Now, where might I begin finding out where this might've been said?

<comment><USER4> ...but when they came to the letters, "This invention, O king," said Theuth, "will make the Egyptians wiser and will improve their memories; for it is an elixir of memory and wisdom that I have discovered."

But Thamus replied, "Most ingenious Theuth, one man has the ability to beget arts, but the ability to judge of their usefulness or harmfulness to their users belongs to another; and now you, who are the father of letters, have been led by your affection to ascribe to them a power the opposite of that which they really possess.

"For this invention will produce forgetfulness in the minds of those who learn to use it, because they will not practice their memory. Their trust in writing, produced by external characters which are no part of themselves, will discourage the use of their own memory within them. You have invented an elixir not of memory, but of reminding; and you offer your pupils the appearance of wisdom, not true wisdom, for they will read many things without instruction and will therefore seem to know many things, when they are for the most part ignorant and hard to get along with, since they are not wise, but only appear wise." (Plato, Phaedrus 274c-275b)

</comment></comment></comment><comment><USER5> What will also be interesting is how it will affect education.

We were all told we have to memorize things because we can't carry the textbook around with us, that's simply not true anymore.

Filling our brains with dates for civil war battles and the dates of birth/death of random authors was completely pointless.

I think that more critical thinking style education will certainly be a good thing.

Educational material should focus much more on how to keep kids interested in the material rather than making sure you know every detail of every event.

I think the educational system needs a major overhaul. Let kids learn the subjects that interest them at their own pace rather than constant exposure to random bits and pieces. Or at least try it, now that technology is so cheap and powerful we can track and allow access to everything imaginable for education (other than instant learning, but it's probably not too far off).

If I had something like Khan Academy and a tablet in school it would be amazing. Now would be a great time to be starting school, you still need teachers and parents that are willing to inspire and know how to appeal to the interests of children of course.

<comment><USER6> right, but not committing any of history to memory, collectively, makes it pretty easy to rewrite.

<comment><USER7> No, history is all about writing. That's pretty much its definition. The invention of history happened precisely when people decided to start writing things down for the future.

We prevent the rewriting of history by distributing the writing as widely as possible. And that's precisely what the internet is doing.

<comment><USER8> A post on archive.org estimated the average lifetime of a URL as 100 days.

Physical distribution of acid-free paper books are better at preserving history.

Edit: blog post by archive.org on digital preservation efforts for Wikipedia outbound links: [http://blog.archive.org/2013/10/25/fixing-broken- links/](http://blog.archive.org/2013/10/25/fixing-broken-links/)

<comment><USER7> > Physical distribution of acid-free paper books are better at preserving > history.

I don't doubt that those books have better survivability, but they also represent only the tiny fraction of written information that was worth publishing in book form.

archive.org is a great example of how a relatively small nonprofit organization can now afford to archive historical information at volumes that were previously impossible.

<comment><USER8> Archive.org wrote a post explaining why they are keeping physical copies of their digital assets, [http://blog.archive.org/2011/06/06/why-preserve-books- the-ne...](http://blog.archive.org/2011/06/06/why-preserve-books-the-new- physical-archive-of-the-internet-archive/)

</comment></comment></comment></comment></comment></comment><comment><USER9> I've thought for quite some time now (last 5+ years, which as a 23yro seems like a long time) as the internet as an extension of my brain. I've joked to friends that I simply keep a small "cache" of "pointers" in my brain to the internet where I know I can find the information if I need it but I have little use to memorize the details.

I fully understand that if the internet were to disappear tomorrow that I would be very lost but it's not something worth preparing for IMHO. While I agree with preparing for the future I do not think preparing for the fall of humanity/technology to be a good use of my time. Call me naive or stupid (or lazy), you may be right, but I find little advantage in remembering large swatches of information when it can be called up (from either local copy or the internet) at will. It's one reason I vehemently opposed the C++ exams I took in college that required me to know the boilerplate of a C++ program as there would never be a time in my life that I could imagine I would be without an IDE or the internet to generate/fetch it for me.

I'm not saying that I think this is a "more advanced" way of living/existing but just that it is the way I live/exist. I have friends who have expressed similar feelings but I'd be very interested in what both people older and younger and I think/feel about this issue.

<comment><USER10> The human brain is incredible at making connections and finding patterns. When you feed more and more information into the brain and think about it the potential for better, more accurate and more profound connections increase. You see an apple fall from a tree and understand how the planets move around the sun.

What worries me is that your "pointer latency" makes it increasingly difficult to get those aha moments. Vast amounts of knowledge at our fingertips but very little understanding and wisdom.

As for education systems, I (mostly) agree with this dude: [http://www.ted.com/talks/ken_robinson_says_schools_kill_crea...](http://www.ted.com/talks/ken_robinson_says_schools_kill_creativity)

I'm one of the older btw :) 35yro.

</comment></comment><comment><USER8> Note that evolution depends on random mutations.

What's the techno-environmental equivalent to random mutations? Remix culture, open-source software, fan fiction, fair use, cross-corporate IP licensing, emergent outcomes of search engine SEO and Google's top ten revenue categories?

If we are going to expose children to technology, should we expose them to open-ended technology with many degrees of freedom and possible innovation, or walled gardens/devices with a limited menu of pre-approved operations?

</comment><comment><USER11> Imho, while it is not important to blindly memorize data, it is difficult to build mental models if you don't hold some information in your brain. For starters, it is not quite feasible to have all the information be stored in a secondary location (the internet/cloud) but have your brain process that information to make conclusions, to the best of its ability. Even if it were possible, in such a situation, a person would be completely dependent on the source of information, and could be easily misled by a wrong resource -- because they might have little primary data developed from their experience of the world, on which to base their decision making -- in a sense, how does one develop a sense of whether or not to believe something one reads on the internet, without regard to the reputation of the source? This is an example of what I would call critical thinking.

If one is always used to having the information at one's fingertips, then how does one acquire the ability to "figure things out"?

Isaac Asimov touches on something along these lines in his wonderful story -- "Profession" ( [http://www.abelard.org/asimov.php](http://www.abelard.org/asimov.php) )

<comment><USER8> Great quote from the Asimov story: "It won't do to say to a man, 'You can create. Do so.' It is much safer to wait for a man to say, 'I can create, and I will do so whether you wish it or not.'"

Memory training speeds up the recognition of design patterns, [http://www.patternlanguage.com/](http://www.patternlanguage.com/)

.. and anti-patterns, [http://tvtropes.org/pmwiki/pmwiki.php/Main/TruthAndLies](http://tvtropes.org/pmwiki/pmwiki.php/Main/TruthAndLies)

</comment></comment><comment><USER12> I dont understand how this article can claim that our brains are malleable, but then go on to claim that our children's brain will be wired differently to ours.

Surely those two points are incongruous.

<comment><USER13> Young brains are extremely malleable. Our brains grow (and we learn fastest) during infancy and toddler-hood with a second, less impressive, burst during adolescence. So, our children's brains are malleable in the sense that they readily adjust to this new reality while their brains are growing fastest, but since the reality during their most formative years is different from the reality during our formative years, their brains will be wired differently.

One could argue that this happens to a certain extent with every generation, however, and it is not necessarily a new thing. One might also argue that as technology changes faster, the inter-generational gap grows larger. One might also argue that while our adult brains change more slowly than a toddler brain, they do keep changing which might mean the difference is not so large after all. Interesting questions to be sure.

</comment></comment><comment><USER14> How the Written Word Became Our 'External Brain' and What It Means for Our Kids

</comment><comment><USER15> I wonder how much IQ I gain from the web. Anybody done that experiment? Take an IQ test with and without access to the web.

<comment><USER16> Depends does farming out the questions to mechanical turk count? Or would that be more a hive minds cumulative IQ?

<comment><USER15> Totally! Access to the web is the issue to be tested; not my skill at research.

</comment></comment></comment><comment><USER17> Dream on. Most likely you and your kids are gonna be wiped out by intellegent machines just in a few decades.

<comment><USER8> Or some other kid's human-augmenting machines will make irrelevant the "intelligent" machines.</comment></comment>


Beyond CI/CD: GitLab's DevOps Vision (2017) - <AUTHOR> https://about.gitlab.com/2017/10/04/devops-strategy/ <comment><USER2> We have explored GitLab in the past and a lot of our CI/CD is heavily inspired from GitLab.

They seem to be consistently taking right decisions at the micro level. Their CI/CD design and execution is way more usable and reliable than <name suppressed> pipelines (still no manual stages, still no re-triggering, etc). Their design and integration with Kubernetes is also a great choice.

So on the micro picture, things are quite good. On the macro picture, they are building a universe. On the Issues front, they're trying to be like Trello (and in some places, reminds of Jira). They're trying to tie Issues with customer support, getting slightly in the way of Zendesk/Freshdesk. They're building deployment. Then monitoring - they support Prometheus. Now post- deployment/post-monitoring. And of course, they are competing on core git hosting as well.

Of course, they'll do a great job. Heck, if they get into the messenger domain, they'll pick a nice strategy and just integrate deeply with Slack maybe.

But the core of the problem is: None of these are instrumentable/hookable. Want to enforce some of your own organization policies before deployment? Want to use everything _except_ with your own monitoring tool? Sorry. If you use GitLab, you use their universe and everything that comes with it. There is no graceful integration with a broader set of tools.

Maybe for a small startup, just "doing things the GitLab way" and subscribing to all their micro choices (which are good) make sense. But organizations grow, and they'll outgrow these micro choices sooner than later. Then the lack of extensibility, hooks, etc. will bubble up.

All this is assuming GitLab continues to build out a perfect application platform with all the right choices (and all the version and time matrices of those choices). Hugely laudable work so far though!

<comment><USER3> On the topic of messaging, GitLab acquired Gitter about a year ago:

[https://about.gitlab.com/2017/03/15/gitter- acquisition/](https://about.gitlab.com/2017/03/15/gitter-acquisition/)

Edit: I first said "not too long ago" then realized it was just about a year ago.. Where is time going!?

<comment><USER4> Also, omnibus GitLab includes Mattermost, and there are integrations between both (notifications, slash commands, auto channels...).

</comment></comment></comment><comment><USER5> I like gitlab, but a mixed open source / closed source product is always going to be a challenge in terms of hearts and minds. Take this quote from the article.

> The other way to look at it is that this is pretty advanced stuff, and > frankly, it doesn't deserve to be, free, open source.

So is all the stuff that gitlab builds on, like git, or ruby, or linux, that's all pretty advanced stuff I'd say.

<comment><USER6> Wow that really is a poorly worded phrase. If someone from GL is reading this, please fix that, it makes you look pretty bad.

Just be honest and say you want to charge for advanced features, because there's little money to be made in open source and you're a business after all and want to pay your employees a living wage.

<comment><USER7> >it makes you look pretty bad.

But they are being honest, they are saying what they are thinking....

<comment><USER8> They could rephrase it to: "we consider this an enterprise usage pattern for our software so this feature will be included in the paid Enterprise Edition".

</comment></comment></comment></comment><comment><USER9> Is it just me or is gitlab becoming more and more bloatware? Is it realy a good idea to bundle everything in one application? Why do i need an integrated artifact management with solutions like sonatype nexus? Is it worth it to add an "awesome environment for ops" on top of kubernetes? why add this complexity?

Dont get me wrong, i like gitlab and use it since the beginning. I just have a problem with this "munch it all together" style of products.

<comment><USER10> Gitlab in a way suffers from being open source. Their open source product is so good and includes so many features (even a full featured CI/CD pipeline!), that they need something big to justify their paid version. So I don't blame them. You can disable a lot of stuff that eats away your memory.

<comment><AUTHOR> Corollary: do you hate Gitlab becoming bloatware and integrated suites? Then pay them! Even if you only use their open source offering, pay them. And not just "pity money" like 100 USD per year, but really pay them as if they're a serious commercial software vendor.

Yeah I know people won't do that. But think about this for a second. It does not apply only to Gitlab but to lots of independent open source software vendors too.

<comment><USER11> How is that going to solve anything? The more you pay them the more bloated version you're going to get. In fact, if you want to travel lite the community edition is actually your best choice there.

<comment><USER12> The item it would solve is that if you "pay" then you can more directly influence their road-map. As a customer they want you to be happy and to remain one, that gives you the ability to influence direction. Individually, it may not be a lot, but in aggregate customers have power.

</comment></comment></comment></comment></comment><comment><USER13> Slightly offtopic from what the article focuses on, but the thing that bothers me about all these built-in CI/CD things in software like Gitlab is that people seem to be perfectly content with building an artifact and then just ... pushing it out.

In traditional deployments that may be some kind of "copy this thing over SSH and make it go!", in Kubernetes-land it's more like "lets just modify this API-state to point at the new image tag!".

Neither of those produce a consistent record of changes applied and state mutation like that is very error-prone.

We actually use Gitlab's CI at work, but we have our own deployment solutions built on it that end up making git commits into the NixOS & Kontemplate repositories which then run their own pipelines to deploy.

This way we can always answer the question "what _set_ of applications at which versions was deployed at $time?" and also roll back consistently.

<comment><USER14> Sorry but it's not clear what you are saying.

What is the fundamental difference between modifying your k8s deployment to point to a new tag and your solution?

You can easily roll back (except with database migrations) and easily see what version is deployed when.

<comment><USER13> When you update a Kubernetes deployment in the API directly you're essentially modifying a global variable. If you do this as the result of some imperative process (e.g. a CI pipeline), you don't have any record telling you what the value _should_ be - you only know what it currently _is_.

You're also only modifying a single piece of your whole state at any given time, meaning that if you have the services A and B and their deployment pipelines independently modify state - you have nothing that declares any relationship between which versions of these should be deployed together.

There's a little piece of infrastructure wisdom I've learned over the years, I refer to it sometimes as "tazjin's law":

Any infrastructure component not controlled by a reconciliation process will eventually fail.

Versions of dependent components will get out of sync, configuration is being deployed independently of the application, and so on.

In order to reconcile your current state with your desired state you must know what your desired state is.

Does that explain it?

<comment><USER14> That doesn't explain it. You always need some global variable saying what the current state is. In your case, maybe it's the branch pointer in your git tree. In the k8s deployment, it's a tag value.

<comment><USER13> No, those don't contain the same information.

Our Kontemplate repository contains the state of an entire cluster, including _all_ versions and _all_ configuration.

A tag value is a single piece of mutable data that is in no relation to the other relevant data.

<comment><USER14> The tag points to the current version of your docker image, which contains the current configuration, except secrets which you don't want in a repo. Older deployments point to the older docker images which contain the older versions.

Still don't see any advantage to justify the additional complexity in your system.

<comment><USER13> We have more than one service, more than one environment, and auditability requirements (due to being a financial institution).

I find it more complex to try and keep track of remote state modifications than to have a single source of truth, but whatever floats your boat ;-)

<comment><USER15> You can export k8s state as JSON/YAML and put that into a git repo if you want.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER16> This is awesome; it's something that I've slapped together out of disparate components (that've then gradually fallen apart) so many times I've lost count. Having a tool which can manage it all -- from commit, to builds, to deploys, to monitoring -- is a massive boon for small business (and personal projects).

I look forward to the next releases of Gitlab!

</comment><comment><USER17> Now I'm pretty sure GitLab has a focus problem. It's already very complex with somewhat unrelated things. You can't be everything for everybody. This will even further decrease quality of individual parts of the system. It has been unusably slow for a long time. If they try to do everything, they will have way bigger quality issues than slowness.

</comment><comment><USER18> I'm upvoting/adding this in my favorites if only for the pipeline diagrams.

Dunno whether their vision will pan out though. I do not use gitlab so I'm probably not that qualified to speak but I wouldn't like using one PaaS for all things CICD. I'd be afraid of locking myself in plus loosing a few degrees of flexibility.

</comment><comment><USER19> I don't get the beyond part, especially monitoring.... will Gitlab only have a Prometheus view in their UI or do they want to create their own monitoring? And when using own monitoring... this is a bit crazy... we have from day to day more and better Prometheus for that.

<comment><USER20> We are indeed leveraging open source tools like Prometheus, and not seeking to build our own. We do believe however that the data and insights that Prometheus provides can be much more impactful to an organization if it is provided in the workflow that developers already use, rather than a separate tool/UI.

For example when looking at a CI/CD deploy to an environment, you can easily access important Prometheus metrics and in the future logs, from the same console.

This also allows us to build more intelligence into the platform, as GitLab is more aware of your application and its health. One example is to incorporate Prometheus monitoring to compare the performance of a new release in an incremental deployment, and automatically pausing it if key metrics have degraded.

</comment></comment><comment><USER8> Is anyone here using the Gitlab CI/CD for anything a bit more complex?

I'm especially interested in a pipeline with parallel executions of different kinds of tests, maybe some manual checkpoint in there, a more complex chain with execution on different kinds of hosts or containers.

<comment><AUTHOR> Last time I checked (a few weeks ago), Gitlab's CI/CD system is great for most use cases as long as you can describe your pipeline as a list of non- interactive tasks -- some of which may be parallelized -- that each can run in a Docker container.

For one of the software projects I'm involved in, I have more complex needs. We release binaries for multiple platforms so our Jenkins master delegates certain tasks to slaves running on specific OSes. Then at the end the Jenkins master downloads the built artifacts from all slaves and publishes everything to our artifact hosting server. As far as I can tell, Gitlab CI does not support this.

In future CI jobs I may even require user interaction, e.g. I may ask a human to sign off a report. I don't think Gitlab CI can do this.

But if your needs aren't so complex then Gitlab CI is great. It's UX- philosophically similar to Travis and setting it up is super simple, as opposed to Jenkins which is a pain to use.

<comment><USER21> Can't you put the gitlab runner on whatever you want and set up CI environments to the runner?

<comment><USER22> The issue is that the configuration format makes complex jobs difficult to define. It's good for the simple case, but versus e.g. a Jenkinsfile[0] where you get a complete groovy DSL that can interact with it's environment across tasks, pipeline, branch, etc with ease it's rough. Having fine-grained control becomes important.

[0] [https://jenkins.io/doc/book/pipeline/jenkinsfile/](https://jenkins.io/doc/book/pipeline/jenkinsfile/)

<comment><USER23> > a Jenkinsfile[0] where you get a complete groovy DSL

Apache Groovy _isn 't_ "complete" as shipped with Jenkins. It's collections API is deliberately crippled so it doesn't work.

</comment></comment></comment></comment></comment><comment><USER24> I would like to know what the goal for auto devops is...

Will it be able to look at a project and compile it? For example: [https://gitlab.com/postgres/postgres/-/jobs](https://gitlab.com/postgres/postgres/-/jobs)

<comment><USER25> Yes, it attempts to detect the language/framework, and build it. It doesn't work for all languages, and is based on Heroku buildpacks so has similar limitations. If autodetect fails, but some Heroku buildpack would work, you can specify it manually. Or, just include a Dockerfile and it'll build that instead.

</comment></comment><comment><USER26> From the team who know basically nothing about ops? (unless they've hired actual ops people in the last year)</comment>


Ask HN: What's the best API documentation you've ever seen? - <AUTHOR> What works best for you? <comment><USER2> The formatting and styling is a little dated and claustrophobic, but I always liked how thoroughly (with plentiful links to convenient test examples and a dev console) the New York Times documented their APIs: [http://developer.nytimes.com/docs/congress_api](http://developer.nytimes.com/docs/congress_api)

</comment><comment><USER3> Does language documentation count? If so, [http://docs.racket- lang.org/](http://docs.racket-lang.org/) is probably as good as it gets.

</comment><comment><USER4> I've always found Qt's docs very usable: [http://qt- project.org/doc/qt-5.1/qtwidgets/qmainwindow.html](http://qt- project.org/doc/qt-5.1/qtwidgets/qmainwindow.html)

Also, although not an API, the diagrams in the SQLite docs are extremely helpful in structuring statements: [http://www.sqlite.org/lang_createtable.html](http://www.sqlite.org/lang_createtable.html)

</comment><comment><USER5> I like the way the Stripe documentation is done. I've seen other tools/libs use a similar format but I'm not sure what the underlying doc generator is.

</comment><comment><USER6> In PHP I generally use a framework called Yii. Their documentation is amazing: [http://www.yiiframework.com/doc/api/1.1/CActiveDataProvider](http://www.yiiframework.com/doc/api/1.1/CActiveDataProvider)

</comment><comment><AUTHOR> [http://developer.klout.com/io-docs](http://developer.klout.com/io-docs)

</comment><comment><USER7> I think Parse has really great documentation.

</comment><comment><USER8> stripe docs</comment>


Ask HN: Who are hackers who also like sports? - <AUTHOR>

It seems like hackers and sports just don't go together. I don't know why. I hack. And I love sports. I'm curious to know who are the hackers out there who are total geeks but also into playing/watching sports. Seems like a rare breed. I'm curious who's out there. I wanna meet you. Speak up. <comment><USER2> I've found that a lot of my hacker friends are huge fans of fantasy leagues. Being able to track all that data (stats) and put together a coherent team is very challenging. It's the mixture of hard numbers ("Dirk is averaging 27.7 points a game but I really need to win the 'steals' category to edge out a victory) and gut feelings ("Although he has been on a week long cold streak") that draws in nerds like myself.

</comment><comment><USER3> I've played soccer all my life. Everyone talks about flow when coding, but I've never come close to how it feels when I'm in a soccer game.

I've played a bit of softball and kickball and I'm not a huge fan. Likewise most dodgeball. Otherwise it's all great.

I'd like to see an adult renaissance in capture the flag and other 'kid' games.

</comment><comment><USER4> I love sports and have always loved it.

I get the same kind of rush when I'm playing a sports game and when I'm coding. Sometimes, you just go into a sweet mental zone where you feel unstoppable. and winning a close sports game at the very end is very similar to when you get a complex app to run and functioning. The moment when everything just works out is pure bliss.

Video games are also similar. I remember the same feelings playing DOTA, where you have a super close game at the very end and both teams are going for the final push, and you end up executing a perfect plan. Pure bliss.

For all of these though, you need to have a certain level of competence through practice or coaching. I'm guessing a lot of people, not just hackers, just never gets to that stage and give up.

</comment><comment><USER5> I hack and I'm actively involved in MMA. It's a rare combo, but I like the way it is so completely opposite to hacking. With hacking, a lot of time goes into the thought process. With MMA, you don't have time for thinking, it's all about training your reflexes. I also like the way there are a lot of physics involved: leveraging, momentum, et al.

The sport has a bit of a knuckelhead image to it, but the guys I train with vary from construction workers to sales/IT guys. We all have to show up at our jobs tomorrow, so we don't beat the crap out of each other, although things can get pretty tough sometimes...

</comment><comment><USER6> I'm very into association football (both watching and playing), although I attribute that more to growing up in Europe as a boy more than anything else. I also spent 4 years studying jujitsu (ended up taking a break because of school, but am hoping to be back into it once I graduate). I have found it to be a great way to stay in shape both physically and mentally, and was also lucky enough to find a great community of people to train with.

</comment><comment><USER7> I as well love sports. And I feel like there are definitely hackers out there that do like sports. I think that sports have barely been touched by hackers and feel like there are a lot of cool possibilities out there for people to pursue.

Mike, Hope things are going well with the new digs and everything is going smoothly.

brett

</comment><comment><USER8> I'm into a lot of stuff besides programming. I surf, wakeboard, I train in capoeira (had to postpone that because I had to move places) and I'm also into boxing. I find that doing other things besides purely coding helps with mental flow.

</comment><comment><USER9> I do both as well. I love sports in all forms. I go to the University of Miami and haven't missed a home football or basketball game yet. Also I am always ready to play a game a pickup anything really.

</comment><comment><USER10> I surf. If anyone likes to go surfing and thinks that they'd go more if they knew someone at the break.. drop me a line. I surf at Pacifica.

</comment><comment><USER11> I'm very into sports as well, in particular soccer and bboying/tricking.

</comment><comment><USER12> I love to play Basketball, if you are in Germany lets play :)

</comment><comment><USER13> I'm somewhat surprised at the general lack of response (so far) to this question (on the other hand, it is like the middle of the night basically where I am).

There are people here who do Parkour: <http://news.ycombinator.com/item?id=2857239>

There is an old-ish poll indicating people pursue a variety of sports/fitness activities: <http://news.ycombinator.com/item?id=2178056>

There are people into rock climbing and surfing: <http://news.ycombinator.com/item?id=2287603>

I notice these types of comments constantly on HN. I hadn't noticed that hackers are particularly non-athletic or something. I do personally know an IT professional who is not very fit/athletic. On the other hand, this person had a childhood health issue which undoubtedly places significant limits on them. Off the top of my head, it seems like people in the IT department at the company I work for are generally slimmer and trimmer (and presumably more active/athletic) than is true on average in other departments I am familiar with.

(Edit: Maybe it's partly the title? "who ... like sports" could be interpreted as being a fan who watches sports rather than a participant.)</comment>


This is the mail system - <AUTHOR> http://dewith.com/2012/this-is-the-mail-system/ <comment><USER2> I completely disagree 100%. I think the mail system is exceptionally well- functioning. It's a massively-scalable, decentralized, asynchronous messaging system that supports large file attachments. At this, it excels. There's not one big evil company controlling all messages and unless you're sending massive amounts of emails every day, your messages almost always end up exactly where they're supposed to. I'd challenge anybody to do better.

The author's main gripe is Mailer Daemon messages. It's not _email's_ fault that people write shitty clients that don't display a pretty failure message. If your car doesn't have anti-lock breaks, it's not the road's fault when you hit a patch of ice and slam into a tree.

Email is great not only because it works simply and beautifully, but because it's so extendable. People think it's broken. It's not. It's just simple...and it's this same simplicity that makes it easy to build on top of. Look at Gmail or Xobni. Both have incredible features that "email" doesn't have because they took the time to build extras on top that make it work nicely.

Email is NOT broken. There's nothing to fix. Whatever fixes you think it needs _you can make yourself_. The underlying platform works great. If you have a problem, write/patch a client.

<comment><USER3> Exactly. It would be no small matter to come up with an alternative system that has the simplicity, flexibility (including flexibility of archival), and most of all the freedom of email – and have it work anywhere near as well in practice as email does already.

(Google Wave showed promise... but it also introduced a ton of new complexity, and given the pattern of messages "living" on the sender's server, it wasn't clear how archival should actually work.)

It seems most people who advocate this notion that email is "broken" would rather us all use some centralized, proprietary system akin to Facebook messaging. This would be an unimaginable step backward for reasons that I hope do not require elaboration.

<comment><USER4> Federated XMPP seems rather nice alternative if it were extended to support asynchronous communications (eg servers would store messages when clients are offline). Yes, it is XML based and XML is not fashionable these days. But still I think it has potential if it were developed further.

btw Facebook messaging is partly based on XMPP so it's not completely proprietary.

</comment></comment></comment><comment><USER5> Hi. This is the qmail-send program at yahoo.com. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. : 184.108.40.206 does not like recipient. Remote host said: 550 : Recipient address rejected: undeliverable address: unknown user: "[list name]" Giving up on 184.108.40.206.

That's a pretty good error message. Most people glaze over as soon as they see it.

Most people ignore the content of error messages as soon as they realize what they're reading. An awfully large percentage of people ignore it entirely.

I don't know what to do about people.

<comment><USER6> > _Recipient address rejected: undeliverable address: unknown user_ //

Hmm, it's okay.

It's a person masquerading as a computer masquerading as a person. This doesn't really help IMO. Why can't it be

"Hi, this is the Yahoo! email support team. You sent a message to someone but when we tried to pass it on the email address didn't work so we can't send the email for you. Here's some things to try ... technical details and the text of the email you sent are below [ _or_ attached]."

The response could also include info like that the domain is live.

<comment><USER7> That sounds like someone at Yahoo is reading my email.

<comment><USER6> Well the chances are slim because they cant read that much at a time.

Probably a computer at the CIA is reading it though.

</comment></comment></comment></comment><comment><USER8> Every MTA used to have their own way of reporting bounces. These days, the big ones (at least by volume) seem to all obey RFC 3464[1], which defines a MIME type and required and optional fields for delivery reports. Of course, the old MTAs are still around and still delivering their bounces in a myriad of different formats. The bounce processor I work on at work has about a dozen different variants on "The message could not be delivered. There is a copy of the original message/headers below this line". Those plus the RFC 3464-style messages cover roughly 95% of what we see day to day. The other five percent are so unrecognizable that we can't process them automatically.

[1]: <http://tools.ietf.org/html/rfc3464>

</comment><comment><USER9> Please do no encourage admins to replace useful debugging output with useless HTML shiny.

But, by all means, improve the text itself.

<comment><USER10> You missed a crucial part of the post:

        Machines can read [these error messages] just fine, though.
        Here's an idea: machines shouldn't slap us in the face.
        They should help us along if they fail to do our bidding.

He's _not_ encouraging admins to replace useful debugging output. In fact, it's the opposite: he's encouraging email client designers to actually _use_ the debugging output to let people know what went wrong. His mockup is quite clearly of an email client showing users relevant recovery options based on an underlying error message the client has parsed.

In other words, he's proposing that email clients treat MTA error messages precisely as they already handle raw headers. Full headers contain useful debugging information, but you aren't normally debugging.

<comment><USER11> No, they can't. There's no standard format for these error messages that I know of.

Maybe there should be, but that's a problem that has to be solved before the shiny UI can be placed over it.

<comment><USER12> There is no standard format for the plain text part of bounce that your MUA shows to you as it's just that: plaintext part to show when MUA knows nothing better to do. RFC 3464 specifies format of additional MIME parts of message that specify what happened in machine readable format. It's interesting to note that it's exactly same mechanism as is used for sender-requested notifications for delivered email in which case these messages are processed by MUAs just fine.

</comment></comment></comment></comment><comment><USER13> Yes, the email system could be better. But for something that was designed _decades_ ago it works surprisingly well.

Should somebody try to do some smart parsing of failure notifications to make them more readable? Sure, I don't see why not. But don't pitch the baby out with the bathwater here. The underlying system is not that bad.

<comment><USER14> Actually, the underlying system is absolutely putrid, a sentiment that pg agrees with based on his latest talk at PyCon. Mail is, unequivocally, the worst part of my daily existence and you are kidding yourself if you're calling it "not that bad".

Using pg's words, mail is a to-do list that anybody can put shit on, and I don't have any control over who puts things on it. We live in an era of technology that can do e-mail so much better, and replacing it must happen in my lifetime. Everything, from the architecture to the messages themselves, need an overhaul. The extraneous shit we bolt on to e-mail (SPF, DKIM, PGP)...it's just making it a big, unwieldy mess.

<comment><USER15> _> mail is a to-do list that anybody can put shit on, and I don't have any control over who puts things on it_

That's a misuse of email on the _receipient's_ side, not on the system's side. Email is about messages, not about tasks. Although there might be more comfortable (i.e., more automatic) ways, there's nothing wrong with maintaining a TODO list that is 100% separate from the INBOX.

For example, in my TODO list I describe _shortly_ (and in my own words) what I consider to be important. Why should I waste my time scanning through the INBOX everytime I want to check what needs to be done?

In other words: It's _me_ who decides what gets on my TODO list, nobody else! I'm _in total control_ because I'm a free citizen living in a democracy, and as such it's _my responsibility_ to organize my life. In particular, to decide what to do (to-do) in my life.

If you decide to give other people access to your TODO list (e.g. by defining your INBOX to be your TODO list), you're _voluntarily giving up control_ of an important part of your life. Nobody forces you to do that. In fact, almost every organization guideline strongly advises against that kind of nonsense. (The most famous one being the "Inbox zero" series at <http://www.43folders.com/izero>)

<comment><USER16> I think that part of the idea is that reading a message, replying to a message & all other things that you do with mail can be considered as "tasks".

</comment></comment></comment></comment><comment><USER17> What annoys me about SMTP is that it's poorly implemented. Have you tried sending a message to the postmaster at any large firm in recent years? Chances are nobody even reads that. I clicked on the link to submit a tip to my local news station last week; later I got a reply telling me that those mailboxes didn't exist. The largest broadcast media organization in the Bay Area can't even operate its own wesbite properly. So while SMTP is great on a technical level, it's only as good as the people who administrate it, and system administration is not as valued as it used to be because it's too labor- intensive.

<comment><USER18> Reminds me of the time I filled in a form on Microsoft.com and submitted it, I think it got sent to an internal nonexistant address, was autoforwarded, and then bounced to my email, containing the content of my original message and a reassurance to the internal person that their email address wouldn't be revealed to the outside world. It was.

</comment></comment><comment><USER19> I suggest returning the error in a .doc file so that people can read. At least some.

And yes I get you idea, this is actually a RFC <http://tools.ietf.org/html/rfc6522>

And the MUA (Mail Program) should just deal with it properly. But then you have all these Bloatus Notes, M-SExchange and other broken system in the wild...

<comment><USER20> .doc file? Why use a proprietary binary format when a suitably standardized plain text format would work just fine? I don't even open .doc files from unknown senders.

<comment><USER19> You obviously missed the sarcasm.

<comment><USER20> Sorry, sarcasm doesn't always come across clearly on the Internet.

<comment><USER21> Neither do email bounces!

</comment></comment></comment></comment></comment><comment><USER22> I generally prefer email to any other form of electronic communication. It's sortable, archivable, easily formed into lists, decentralized, encryptable, supports attaching images, well-known, implemented in a number of protocols...

While you could implement a shiny-for-the-laypeople status code parser, email as a system works unbelievably well.

<comment><USER20> > _archivable, ... decentralized, encryptable_

This. I shudder every time someone mentions replacing e-mail attachments with Dropbox/iCloud/etc., which somebody already did in this thread. With e-mail, I am beholden to nobody; and if I pay some company to handle my e-mail, it's only because I voluntarily chose to do so. I could drop that company at any time, fire up my own mail server, and have a 5TB mailbox with 10, 20, 30 years of searchable history if I wanted to. I can also access it with a whole bunch of free and open-source software, from ESR's original fetchmail all the way to the latest alpha of Thunderbird.

Every other messaging system that I've heard about, on the other hand, is either held hostage to one company's proprietary platform or clearly not intended for people who need to look up conversations they had 10 years ago.

So please, folks, by all means fix what's currently wrong with e-mail. But please think twice before suggesting that everyone replace it wholesale with some proprietary cloud-based TODO app.

<comment><USER23> I was one who suggested Dropbox as a replacement for attachments (although it was really just an example, I don't even use Dropbox personally), and the point I was trying to make is that you can either have flexibility, or you can have standardization. The OP is suggesting we somehow standardize email error messages, but this doesn't seem possible while email remains a free-form, very simple protocol, which gets used for an infinite number of different purposes by different people.

"Fix what's currently wrong with email" is so overly vague as to be basically meaningless. Different people have completely different ideas about what is "wrong" with email, and it is such an entrenched technology that you will almost certainly never be able to make structural changes to it unless the problem set it addresses is radically diminished.

<comment><USER20> I don't see any reason why something like SMTP error messages can't be standardized if several major e-mail software vendors and related groups get together and agree to implement, over a period of 5-10 years, an extension to SMTP. Sure, it might not be as clean as rewriting the protocol from scratch, but it would work for all practical purposes. A lot of features of HTTP that we take for granted, like cookies and anti-clickjacking headers, were added through a similar process. The problem is political and economic, not technical.

I also don't see anything wrong with having a free-form, vendor-neutral, decentralized messaging protocol that can be used for a million different purposes. As long as the underlying protocol itself is reliable (e.g. it has proper error handling) and extensible (e.g. you can add custom headers and MIME types that other software won't mess with), innovators are free to implement whatever functionality they want on top of that protocol. Heck, Richard Stallman uses e-mail to browse the web! If you restrict the protocol to what you think should be its only purpose, you're unnecessarily limiting what other people can do with it. That would be like restricting HTTP to hypertext documents only, no AJAX, no API calls, no streaming.

IMO, e-mail doesn't need to _become_ a TODO list or notification system. When I say "fix it", I mean we should clean up old cruft from the protocol (e.g. make it 8-bit clean) and make it extensible so that it is not too difficult for interested parties to _implement_ a TODO list, notification system, etc. on top of it if they want to. People will obviously disagree about how exactly that should be done, but people disagree about everything anyway.

</comment></comment></comment></comment><comment><USER24> You want to strip out all of the useful information needed for debugging mail problems, and replace it with web 2.0 bullshit ajax and lickable icons that won't render in most mail clients?

Sorry you couldn't send your attachment but go back to your blog and leave us alone.

<comment><USER25> They are suggesting that the client generate those UIs based on the message in the email, not that the message have that UI in it.

</comment></comment><comment><USER23> All mail systems have different rules for what is "acceptable", what is perceived as "spam", etc. One mail server may allow attachments up to 10MB, another 20MB. Some mail server somewhere may allow attachments up to 50MB but will not allow attachments with a .exe extension, and due to the vast and wide uses of email it actually is important for this flexibility to be available.

Given the amount of variablility around mail handling, relays, spam filtering, etc, I'm not sure that it's entirely feasible to "standardise" error or bounceback messages. RFC 3464-style messages get us part way there but it just doesn't approach something as "nice" as HTTP error codes (which themselves still aren't handled in a standard way by web browsers, they are handled on a case by case basis, if at all, by web developers).

I think this problem is only going to approach being solved when some of the more edge-case uses of email (such as attaching/sending files) are deprecated by more targeted, more efficient services. For example, lets say everyone started using Dropbox or YouSendIt to send files instead of attaching them in emails. And alongside that perhaps a separate protocol such as iCal or similar takes over the "meeting arrangement" space. Eventually the usefulness of email may be narrowed down into a small enough band of "send and forget" messaging that someone can actually, finally, come up with a better, more efficient and usable alternative.

Until that happens, or something else equally radical, email is something we're just stuck with, worts and all.

<comment><USER6> > _One mail server may allow attachments up to 10MB, another 20MB [...] not > allow attachments with a .exe extension, [...] important for this > flexibility to be available._

 _[...] I'm not sure that it's entirely feasible to "standardise" error or bounceback messages._ //

Well couldn't we use something akin to SPF - ie a TXT field in the domain's DNS record with a shorthand for the acceptable receiving protocol in operation, kind of an RPF.

So you'd have something like:

alicious.com TXT v=rpf1 deny-ext:exe,reg,dll max-size:15MB req-field:sender ip4:xxx.xxx.xxx.xxx/16 req-format:txtonly req-other:spf ...

would tell the MTA (or the forwarding relay) that this address will likely reject emails containing exe, .reg, .dll files; emails over 15MB; emails without a sender field; emails apparently originating from servers outside the given address range; emails not in text format; emails from domains without a SPF; ...

Whoops got carried away there.

What would be the problems with this sort of scheme?

[FWIW there's already a milter called RPF but that's not what I'm proposing here I'm talking instead about a policy to give to a sender to tell the sender what you intend to accept so that they can choose to match your requirements and avoid having the mail rejected. Obviously an MTA/MUA can choose to receive mail that doesn't adhere to the policy if they wish.]

<comment><USER23> From a technical standpoint something like that could work to a limited extent (enough to be helpful in some situations, when both parties are using modern, up to date MTAs / mail clients). It still doesn't fix the error message from a bounce, it's more like a hint to the email author to say "this email _might_ not be accepted for the following reasons: x, y and z".

Ultimately though, the inertia to implement such a thing on existing MTAs is somewhere close to the difficulty of implementing IPv6. Except the need for IPv6 is verging on dire, and not many people seem to be rushing to fix that one. How will we convince people to act with any expediency over something that is, at most, an inconvenience?

<comment><USER6> The MUA would do the work up front, query the TXT field for the rpf and tell yiu up front "I can't do that, $user wont accept attachments over 15MB". Then as the OP suggested the MUA can offer to zip, upload and link, or whatever.

</comment></comment></comment></comment><comment><USER26> Status codes:

[http://www.iana.org/assignments/smtp-enhanced-status- codes/s...](http://www.iana.org/assignments/smtp-enhanced-status-codes/smtp- enhanced-status-codes.xml)

<http://tools.ietf.org/html/rfc3463>

I'm guessing most e-mail client providers just haven't found a reason to prettify the responses. If anyone is up to the task, then can you explain PGP/GPG so the entire world can also understand and use that?

</comment><comment><USER27> Client side parsing won't be as reliable as you expect.

SMTP bounce codes are notorious for changing on a per domain basis whenever someone feels like it.

I work with StrongMail supporting their Email Marketing Platform and their solution is to have a central database that is updated regularly for all major ISPs to basically be able to have a conversion process between the SMTP bounce codes and the 30 classifications for mail failures StrongMail groups failures by (such as User not existing, blocked due to spam complaint, service temporarily offline, etc). This conversion process has to be updated regularly to keep up with changes.

Server side generation of multi-part NDR reports including HTML email could be a solution, i am not sure if it violates the rfc to send NDRs in multi-part, it could perhaps need an amendment.

But if you want to show this then your in luck since all the major SMTP servers besides exchange are open source, go produce a patch set for postfix, sendmail and qmail.

</comment><comment><USER28> My main problem is that spammers hacked the "sender unknown" error message long ago and use it to spam me (they send mails pretending to be me, so the error message gets delivered to me). So I had to filter them all away.

I wish Thunderbird's spam filter would check if I actually sent the message the error message refers to.

</comment><comment><USER29> I really like this idea.

You can apply this to every transactional email, not just to bounce messages.

Off the top of my head:

\- Vacation auto-replies

\- Receipts

\- Error reports (ok, that might be a bit coding specific)

</comment><comment><USER30> Part of this would have to do with the fact that mail servers are never really updated with new "features."

\- Sendmail was first released in 1983 initially. \- Postfix was released in 1997 initially.

Though both are getting maintenance updates, and new processing features, none have improved the actual error path system. Maybe someone should write a better MTA?

</comment><comment><USER31> It is a perfectly reasonable error message that mail clients should try to beautify. The message itself is absolutely necessary, but should perhaps be cleaned up by the client. All of the calls to write a new "protocol" by the posters on that blog make me wonder if they even understand what the word means.

</comment><comment><USER32> This could be a good idea to improve bounce management from the client, if only for the reason that 80-90% of the world population simply don't understand english at all -- all bounces AFAIK are always in english, for a start.

</comment><comment><USER33> Its old, it doesn't look nice. But it is surprisingly reliable.

</comment><comment><USER34> Coming up with ideas to fix Email in 2012 is like coming up with ideas to fix IM - why bother?

<comment><USER35> Why not? If any of them turn out to be good, then we've improved something, haven't we?</comment></comment>


Introduction to Architecting Systems for Scale - <AUTHOR> http://lethain.com/introduction-to-architecting-systems-for-scale/

<comment><USER2> Great intro to scaling, and great material for answering the inevitable "how do you scale?" question in interviews.

I wish there was more explanation about the 'platform layer'. Author also kind of skirts around map-reduce.</comment>