Usefulness of mnesia, the Erlang built-in database - <AUTHOR> http://erlang.org/pipermail/erlang-questions/2015-October/086429.html <comment><USER2> It is what it is. It's useful to prototype with in Erlang. It may be useful to ship with. If Mnesia turns out not to fit your problem, here in 2015, you've got literally _dozens_ of choices of alternate DB, with all sorts of consistency and distributibility and performance characteristics.

My guess is that if somehow Erlang was where it was in 2015 except it didn't have Mnesia, nobody would really perceive much of a hole there, and nobody would write it, because of the database explosion we've seen in the past 10 years. But it is there, and if it works for you, go for it.

My only slight suggestion is that rather than inlining all your mnesia calls, you ought to isolate them into a separate module or modules or something with an interface. But, that's not really because of Mnesia... I tend to recommend that anyhow. In pattern terms, I pretty much _always_ recommend wrapping a Facade around your data store access, if for no other reason than how easy it makes your testing if you can drop in alternate implementations. And then, if mnesia... no, wait... And then, if $DATABASE turns out to be unsuitable, you're not stuck up a creek without a paddle. With this approach it's not even all that hard to try out multiple alternatives before settling on something.

<comment><USER3> mnesia is great in isolation with bounded datasets. erlang is great for operational observability of both the data flow and your application. they go great together, sometimes, if you know all your requirements up front.

It's always good to keep in mind erlang+mensia were designed to run in a "network" consisting of a unified blade chassis (each blade is a new node, and the network is a physical backplane). So, things like network partitions around erlang distribution and remote mensia tables don't have easy/proper error recovery strategies.

Even with unbounded datasets, mensia is great if you devote an engineering team to managing the scaling of it because amnesia can't do simple things like move a DB from one node to another without semi-advanced erlang+mnesia knowledge. But, whatsapp was (is?) 100% mensia last I recall, even though they had to reengineer some of it: [http://www.erlang- factory.com/upload/presentations/558/efsf2...](http://www.erlang- factory.com/upload/presentations/558/efsf2012-whatsapp-scaling.pdf)

But, mensia still relies on dets and dets still, in 2015, has a 2 GB max file size. If your data grows beyond 2 GB, you have to do mnesia fragmentation which is just an operational burden.

My scaling thoughts tend towards: sqlite -> postgres -> riak

<comment><USER4> If you can fit all your data in ram, you can use disk_copies, which doesn't use sets. schema is always disk_only_copies, but if it gets to be 2gb, wow!

Edit to add: Adding nodes isn't that hard? Connect to dist, add to extra copies of schema table, then the tables that you want. More complex if you're trying to merge together different sets of tables into one schema though.

<comment><USER3> _Edit to add: Adding nodes isn 't that hard?_

Adding nodes isn't hard, but try restoring a mnesia table from service@node1 to service@node2. You have to do something like [http://stackoverflow.com/questions/463400/how-to-rename- the-...](http://stackoverflow.com/questions/463400/how-to-rename-the-node- running-a-mnesia-database)

It's not a great solution for modern AWS-style API-driven-deployment operational models.

<comment><USER4> Oh yeah... I would handle that by having node1 and node2 running at the same time, add copies to node2, delete copies from node1, and done; but that requires both nodes to be able to run at the time (which sounds like it wasn't really an option in the stack overflow post)

</comment></comment></comment></comment></comment><comment><USER5> I'm the Fred mentioned in the quoted text. As mentioned by FLGMwt, Mnesia being a 90s database was an offhand remark done at a workshop in a discussion doing a break.

The reasons I considered it a DB of the 90s is that back then, it could have been state of the art, but by today's standards, under its current form, it makes sense to be used mostly on fixed cluster sizes with reliable networks and a fairly stable topology.

Any fancier cases and you start requiring to dive into the internals when it comes to coming back up from failures, partitions, requiring repairs, and so on. The DB has 3 standard backends: all in RAM, all on Disk (with a 2GB limit), or as a log-copy (infinite disk size, but also bound by memory size).

That ends up leaving you with a DB that has a need for its whole dataset to fit in memory, supports distributed transactions but can't deal with network failures well out of the box (you need something like [https://github.com/uwiger/unsplit](https://github.com/uwiger/unsplit))

Mnesia gaining new backends (Klarna is currently open-sourcing code for an experimental postgres backend and are using a leveldb one) would fix a lot of issues as a single-node DB, but another overhaul would be required for the rest.

The problem I see is that it was a very cool database back then, but it started lagging behind for a long while and now it has to play a catch-up game. Its model and Erlang interface is still extremely nice and I wish it made more sense to use in production without committing to learning its internals in case of troubles.

</comment><comment><USER6> This has little to do with databases, erlang or mnesia, its just a moan against people writing ad tech.

mnesia is a database for the 90's because it was written by smart people in the 80's and like most of the rest of the otp stack was fairly under used or maintained.

I have a huge amount of respect for Klacke and the original authors behind a lot of this tech, however the erlang community that followed seems to suffer some cognitive dissonance around what problems it solves and how well they are doing them. It would be hard to pick a database less suitable for SMB use than a domain specific database in a niche ecosystem.

</comment><comment><USER7> I have much the same sentiment with SQLite. Much dismissed as a toy database, but absolutely appropriate for 99% of my clients - small and medium businesses, the same as mentioned in thread.

<comment><USER8> SQLite is amazing. It should definitely get more popular - it gives you relational DB features while still storing everything in a file. Which means portability, performance, and no bloating the entire OS with another database driver / server.

<comment><USER9> It's extremely popular: it's on pretty much every smartphone, IIRC.

<comment><USER10> apple's native graph database called "core data" is also built on sqlite.

mnesia lets you decide on a per table basis - where should be stored:

        1) ram only
        2) disk only
        3) disk copies ( cached, and persisted stored to disk)

as well the option of how it should be accessed in a cluster

        1) replicated (to a set of nodes you want)
        2) or location transparent ( accessible from any node you want )

i doubt any dbms gives you this kind of distributed systems friendly primitives.

my only peeve against mnesia is corruption. if you change these nodes, or one of them are down, or you call it with the wrong list of nodes ( eg: you may now need a distribtued store like zk just to get this list of nodes right), and many different things can go wrong which is why most folks use it for idempotent store. something that can be recreated if needed, and then used to great effect - but never as "the" persistent store. additionally there are limits on the size of these tables, and workarounds.

once bootstrapped - it works like a dream. mnesia is still my go to dbs for a distributed cache or router for actors.

~B

</comment></comment></comment></comment><comment><USER11> Many valuable considerations inside, read the post. Starting with this thought in the question: 'I hate transiting syntactic boundaries when I'm programming'.

But the answer is such a broader evaluation of the utility of the tools we are using, related to what we use those in.

And some rants that I share: "but really boil down to adtech, adtech, adtech, adtech, and some more adtech, and marketing campaigns about campaigns about adtech."

</comment><comment><USER12> Erlang (and by association Elixir) tooling has a nice progressive approach to managing state.

Agent -> ets -> dets -> mnesia -> riak (or sql tooling etc.)

(Agent [http://elixir-lang.org/docs/v1.1/elixir/Agent.html](http://elixir- lang.org/docs/v1.1/elixir/Agent.html) is just a state-holding process. Erlang folks can probably write one of these in their sleep, Elixir added a bit of wrapping-paper around it.)

If you're writing an app, I think it's best to be storage-agnostic from the get-go. You shouldn't be building up queries in your core app code- push it to the edge of your code, because otherwise it's not separating concerns. All your app (business logic) code should delegate to some wrapper to work out the specifics of retrieving the data; your app code should just be calling something like Modelname.specific_function_returning_specific_dataset(relevant_identifier) and let that work out the details. That way, if you ever upgrade your store, you just have to refactor those queries but your app code remains the same. On top of that, in your unit tests you can pass in a mimicking test double for your store to do a true unit test, and avoid retesting your store over and over again wastefully. (You'd still of course have an integration test to cover that, but it wouldn't be doing it _on every test_.)

</comment><comment><USER13> Not that this hasn't generated good talking points, but I was there at the workshop the OP mentioned and Fred's remark was very much said in passing to a small group of people during a break and he didn't seem to be making an intentionally negative remark. He certainly wasn't stating it as instructional fact.

</comment><comment><USER14> Well, you could summarise this article by saying: "Just because something got invented 25 years ago it doesn't mean it is useless". On the contrary - it is worth taking a look on technology that survived 25 years in the wildness.

</comment><comment><USER15> The article is light on actual details and heavy on rants about the current state of products built on the web.

However there is 1 thing that mnesia got absolutely and totally right. Database schema upgrades. You can create an mnesia database and upgrade it's schema on the fly as a part of it's operation without once bringing it down or running a script. I did this[0] for a toy project I did in erlang once that I unfortunately never finished since the need for it disappeared.

[0]: [https://github.com/zaphar/iterate/blob/master/src/db_migrate...](https://github.com/zaphar/iterate/blob/master/src/db_migrate_tools.erl)

</comment><comment><USER16> What? Mnesia is not fully-webscale graph-db so it's not useful in the 2010s?? Didn't get much from this piece.

</comment><comment><USER9> By the same argument, though, why not just use Postgres? And I write that as a fan of Erlang. Indeed: [https://github.com/epgsql/epgsql](https://github.com/epgsql/epgsql)

</comment><comment><USER17> I can't say I found the piece particularly insightful.

It seemed to imply that mnesia is the DB of the future as soon as everyone realises that everything they are doing is completely wrong and they should be doing things that are more suited to mnesia. Without saying what those things are.

I actually found one of the child comments [1] was pushing in a better direction. Essentially, the vast drop in $/TB of storage means that persistence of time series/ event type data is practical for the masses now. Sure it's found a niche in ads on the web, but it has much wider applicability than that. I personally think that Erlang is particularly well suited to this space.

[1] [http://erlang.org/pipermail/erlang- questions/2015-October/08...](http://erlang.org/pipermail/erlang- questions/2015-October/086432.html)

<comment><USER18> The reason why the comment is insightful is that suddenly Erlang has found itself in the crosshairs of an industry that it is particularly useful for (ad-tech) but there are _many_ more applications that have nothing to do with adtech which erlang is _also_ very well suited for. So for adtech to start pushing the direction in which erlang/mnesia evolve would be wrong.

As for the drop in $/TB of storage, that drop has been steadily going on since the 70's of the previous century and for a very large chunk of that period Erlang/mnesia have been adapting bit by bit to take advantage of that price- decrease.

Persistence of time series and event type data does not (usually) require the kind of storage solution that mnesia offers, a much simpler storage medium would probably suffice and/or be a better choice for that application anyway, storing such data without further processing in a relational database is a bit of a cop-out.

Most of those applications could benefit from digesting and compression which is something you're not going to easily retro-fit onto an existing database.

<comment><USER17> > Persistence of time series and event type data does not (usually) require > the kind of storage solution that mnesia offers

Indeed. That's precisely my point (just stated better than me). Erlang looks like being a very good fit for a large class of applications of this form. mnesia, on the other hand, is not well suited as the persistent storage for them. It would follow then that it could make sense for the "next gen" storage for Erlang to be more in line with this sort of thinking in the way you describe.

As to the drop in $/TB, it's been pretty steadily exponential. But the cost of consuming and analysing TB of data has only really been practical for non- specialist houses for 5-10 years. When you're in the low GB range then a static data picture makes sense. When you're able to play with TB of data then a dynamic picture makes sense and Erlang really shines.

</comment></comment></comment><comment><USER18> > This is much more interesting than chasing click statistics in the interest > of brokering ad sales at the speed of light so that users can continue to > ignore them.

That comment really packs a punch and should get much wider visibility. Ad tech and related software is where _way_ too much of our collective efforts are going.

<comment><USER19> Because it's one of the most important sources of funding for tech companies (justified or not).

<comment><USER20> Not really. There is a niche of social companies (twitter,facebook,google search engine) that make money from ads. There is a niche of media companies (youtube) that make money from ads. There is a nice of startups which make money from Funding/IPOs. These niches are a focus of HN and get talked about way out of proportion of their representational percentage.

Most most tech companies make products and get funding from sales (netflix, amazon, apple, ibm, microsoft, 99% of the Enterprise and 99% of small-medium market).</comment></comment></comment>


Commit messages guide - <AUTHOR> https://github.com/RomuloOliveira/commit-messages-guide <comment><USER2> This is one of those interesting bits where things feel more like personality types as opposed to ways to create maintainable software. I have yet to see a project fail because commit messages were or were not in imperative form or if the first letter was capitalized. I have no problem doing it if someone in the team finds it important, and I have no issue if someone on the team does not do it.

The same is generally true about rebasing etc.

Due to the high visibility of commit messages, a lot of details certainly look pretty bike shed-ish.

What can be important is simply a general concept of meaningful messages when they make sense. For example, bug fixes that may not be obvious by looking at the code, should probably have a reasonably detailed description of the bug. Commits implementing a brand new feature and involving a ton of changes, probably don't need a whole lot more than what the feature is and what is the expected behavior. Possibly some info about potential future bugs that could happen. When updating the readme, "Updating documentation" is just fine plenty of times.

Otherwise, probably just make sure you include some important keywords to make it easier for people to git-grep and I think most projects will be just fine.

There ar certain personality types that really enjoy organization and rules. And the feeling of security that comes from having a well defined set of procedures everyone must follow. It really isn't about making software more maintainable based on any existing research we have about how maintainable software is. But if it benefits some of my coworkers mental health by following those rules, it really doesn't take me any additional effort to follow those rules so I have no problem doing it.

<comment><USER3> I don't completely agree. By taking the time to write commit messages you are documenting your code at a fine-grained level. Think of it like a short email that explains to your (future) colleagues and future self what you changed and especially why you did it.

A good git log prevents unnecessary headaches and saves a lot of time. Typical situation: you just found a couple of lines whose purpose is not completely obvious. If the author is still there, you both waste time discussing. If she/he left the company and you have to figure it out by yourself. Now imagine using git log to identify when these lines where introduced/changed and getting an explanation as to why.

So yeah, writing good commit messages can feel like a waste of time. Like writing good code can feel like a waste of time. You should not be doing it to please your colleague, but rather to contribute to a maintainable codebase. It's worth the extra minutes here and there.

Bonus point: less documentation to write.

<comment><USER4> Nobody questions it is important to write clear commit messages. The issue is being nitpicky about what exact form is being used like whether to capitalize first letter or not.

When I look at the repository I am happy if I can understand the messages at all. It's challenging to get people to group changes in a logical way so that the commit makes sense. I am not going to pick on somebody because he used wrong tense or did not capitalize first word of the message if the changes are grouped logically and the commit mentions the correct ticket and purpose of the commit.

<comment><USER3> I feel it reduces cognitive load, like proper formatting of code.

Do you enforce consistent code formatting in your codebase (using CI, maybe)? If so, why wouldn't you do that with commits?

<comment><USER5> I used to be in the camp that cared a lot about formatting, but over time realized that it's more my OCD than any practical reason.

At this point, the only reason why I like consistent code formatting rules is because they prevent bickering between people who have strong opinions on how things should be. When there's a rule, even if people don't like it, they abide by it. When there are no rules, everybody who thinks that there _should_ be rules starts bikeshedding what they ought to be.

But as far as code quality goes, I don't think it matters much.

</comment></comment></comment></comment></comment><comment><USER6> The repository does not follow its own guidelines.

Also, there's a lot of unnecessary stuff in there. Capitalization and imperative? Not at the top of my list.

The relevant points are nicely summarized by Linus Torvalds: [https://github.com/torvalds/subsurface-for- dirk/blob/a48494d...](https://github.com/torvalds/subsurface-for- dirk/blob/a48494d2fbed58c751e9b7e8fbff88582f9b2d02/README#L88)

<comment><USER7> I heavily dislike the hard wrap requirement. Why do that if our clients could do it nicely, based on screen size, preference and everything?

<comment><USER8> Because very often the client will be some piece of command line tooling that doesn't do those things.

[https://commit.style](https://commit.style)

> Git is strongly opinionated that the author is responsible for line breaks; > if you omit them, command line tooling will show it as one extremely long > unwrapped line.

<comment><USER5> The terminal will still wrap that long line.

In general, this approach is broken by design, because the author cannot know where the commit message is going to be displayed. It might actually be in the context where wrapping at 80 or even at 72 is still not long enough (a tooltip in an IDE, say). Or it might be one where it results in a lot of wasted whitespace. It's much better to fix anything that does not handle wrapping properly to do so, than to impose an arbitrary limit that only really works for one environment.

</comment></comment></comment></comment><comment><USER9> While I've naturally gravitated toward the "capitalize and use the imperative," I've never been down with the "good commit messages are 50 characters or less" mantra. Why 50? Is there an important tool that breaks if my commit message is 55, 60 or even (gasp) 70 characters? Is there a real case to be made that "Add total vocab entries per capsule limitation" is a good commit message that becomes an utter irresponsible trash fire if one spells the entire word "vocabulary?"

Yes, short, clear commit messages are good. I'm not saying "write a paragraph"; I'm not even saying that it's bad to have an arbitrary maximum length beyond which a commit message can be considered poor form. It's just that 50 is a _weirdly_ arbitrary choice.

<comment><USER10> The commit header becomes the email "Subject:" line. 50 characters is less than 72, and allows for the inevitable "Re: Fwd: [Re:] Re:..." mess of email threads, without losing context.

<comment><USER11> Is that _the_ reason? So if your commits aren't getting emailed anywhere, you can ignore this rule (within reason)? I would think only a small minority of git projects have email notifications enabled.

<comment><USER12> Several ways to display the history, like "git log --oneline", or versions thereof that include the author and date, do profit from short head lines.

<comment><USER13> But "For long commit messages, give a summary in up to 50 characters first" solves that as well. There are good reasons to use longer commit messages:

* Link to issue in tracker (Projects can liver longer than the use of a single tracking software or use multiple in parallel - e.g.: public and private ones).

* Important changes in behaviour might warrant a deep link into the relevant docs, even though they are part of the commit.

* Justification why something was changed can be lengthy, especially in a loaded environment (crunch time, intra- or inter-team politics).

I am aware that various workflows exist, supported by various tools, that at least partially solve the problems I mentioned. But the larger the number of people involved or the longer the history of a project, the harder it tends to be to agree on a complete chain of tools just for the sake of keeping commit messages short.

<comment><USER12> Of course. Noone here said that the commit header shouldn't be followed up by a more detailed description. "git log --oneline" displays only the commit header.

<comment><USER11> Maybe you're mostly referring to some more complex use of --oneline, but to me that seems like more of an argument for _not_ editing useful information out of your subject line to fit the character limit. Of course all other things being equal, a short subject line is preferable to a long one. But if you have to make a choice, I think it's often better to treat the character limit rule as a guideline.

I'm sure I've broken this rule many times, and I'm not aware that it's ever caused a problem.

<comment><USER12> Of course. It's just a guideline. All I've done is given a justification for the guideline by presenting a common usage scenario (as intended by the authors).

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> I don't think that this guide is focusing on the important stuff. It's advocating really minor things like the capitalisation of the first letter and the use of the imperative form while it completely ignores the most important rule for a commit message: Add the Jira id (or whatever issue tracker you are using) in the commit message. In this way when doing a blame on a file it's immediately clear why something has been done in that way, with a in-depth explanation of the use case just one mouse click away in the issue tracker system. For me this is much more important than capitalising the first letter of the commit since it provides an immediate and durable value.

<comment><USER15> > most important rule for a commit message: Add the Jira id (or whatever issue > tracker you are using) in the commit message.

I think it's worth noting that the actual text in a commit message stays with the repository. The contents of an issue referenced by the id does not. This is something to be considered especially if this is for an open source project or otherwise somewhere where the git repository itself is more important/central than the issue tracker platform.

<comment><USER14> Obviously it's a possibility, but in my experience, in the several jobs that I had in my life I experienced 1 or 2 source control migration in pretty much each of the places that I have been, and a grand total of ZERO issue tracker software change between all of them. It's obviously anecdotal but pretty much everyone is migrating to git, changing issue tracker is something that you experience much less. And even if it happens a proper migration would preserve the ids, so nothing is lost if it's done correctly.

</comment></comment></comment><comment><USER16> I think the most important thing is to create atomic commits. Each commit should do one thing and do it cleanly. In other words, if you later regret the change, you should only have to revert one commit to remove it. If when reverting you need to go back and reapply part of the commit (due to it being unrelated), that's the sign of a bad commit.

I've worked with people who were adamant white space and formatting changes should always be in their own commit. But in my experience, it's never been a problem.

<comment><USER17> When you are trying to merge a commit to a branch, and it wont merge cleanly because of some trivial white space change someone made in an unrelated commit, you will understand why people dislike it.

It's a pain in the ass. At least if the whitespace / formatting changes are in their own commit, then you can just merge that one first and continue on with your day, rather than having to manually resolve the merge problem potentially leading to more merging problems down the road.

<comment><USER18> Wouldn't it be nice if git had an understanding of what was being committed, and could identify white-space/formatting changes versuses substantive changes? I suspect it could automatically fix these types of common issues.

<comment><USER19> Then Git would have to be content-aware, as sometimes whitespace is meaningful and sometimes just formatting.

Add different ways to format code in, say, C, C++, Java, and so on, and you'd add a whole lot of unnecessary complexity into a version control software...

<comment><USER20> I've dealt with tracking schematic capture and layout software. And just a infinitesimal amount of database stuff. The difference I note is that software version control systems are hopelessly broken because they work on text and not structured data.

With a schematic you can reorganize a schematic and then compare the netlist and parts and if they are different you broke something. You can generate meaningful descriptions of of changes. Changed all the parts of this type to that type. Renamed these parts to these new names.

Problem is no one designs languages to be able to do that.

<comment><USER21> The problem is that to properly understand the structure of the code you need to load in all dependencies of the code (both in other files and imported third party modules). That's time consuming and has to be done somewhere.

As a note, in Scala, scalameta will do just that and then dump out a structured view (in a specified protobuf format) of your code which you can work with.

<comment><USER20> That why I said a problem is languages aren't designed with that in mind. I think C# is pretty close since it was written with debugging as first class feature. But to really get the benefit you need a language that's tightly coupled to refactoring tools. And that means giving up on Unicode text as the file format.

There are other problems, anything more than naively comparing and diffing AST's is a hard problem. I've also seen some really bad things with editing non text data. Like the file you've been editing for a few days is corrupted.

<comment><USER5> There's nothing wrong with Unicode text as a serialization format, so long as all your diff tools operate on the deserialized graph. I mean, when you do a diff on a database, do you care about the binary format of its files on disk?

And I don't see why you can't do this sort of thing with most languages that we already had. Indeed, this immediately reminded me of structured code search in IntelliJ IDEA, which has been around since early 00s. What's special about C# in that regard?

<comment><USER20> > What's special about C# in that regard?

Not unique but far as I understand you can parse a C# module without knowing anything about it's dependencies.

> There's nothing wrong with Unicode text as a serialization format, so long > as all your diff tools operate on the deserialized graph.

The point is you need to actually edit the de-serialized graph not the Unicode expression of program. Changes to the code aren't expressed as changed to the text, they're expressed as changes to the graph.

AKA diff is object foo nenamed object baz. And that's it.

<comment><USER5> Most languages can be parsed without knowing dependencies of a translation unit. I would say that something like C and C++ (where you need to know if something is a type or not in many contexts) is an exception to that rule.

And you don't have to _edit_ the graph. You can still edit the serialized representation directly. So long as you _diff_ the graph, how the changes were made doesn't matter. For example, there already are XML and JSON diff tools that do advanced structural diffing, and they don't care how that XML or JSON was edited.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER22> This is strictly my own idiosyncrasy, I know, but it has stubbornly refused my many attempts to change it over the years: I cannot get used to the imperative. _Do this_ or _do that_ always signals some pending issue, something yet having to be _done_. Whereas a message saying _did this_ or _did that_ tells me exactly what I need to know, namely what the commit was about in the first place.

But then, my linguistic instincts are probably all slightly off: I have so far never gotten used to _pull request_ not meaning ' _kindly asking permission to download some code from your repo_ '. I really feel Linus should have consulted me on that one.

<comment><USER23> Past-tense is about the what the programmer did to get to the patch, present (imperative...) tense to me is describing in the absolute what is a diff is doing (it describes the act of `git am` this patch).

While the past tense makes sense from the author point of view describing what just happened until they typed `git commit`, I'm in the "present" camp since I find it more relevant to me when reading `git show <rev>`: it tells me what the _commit_ is doing at this particular point in history. I don't really care about the programmer/author centric point of view at the time the message was written.

<comment><USER24> Past tense is not necessarily programmer-centric. Release notes are generally written in the past tense (with headings like Added/Changed/Removed). If commits are written in the past tense and from the user's point of view they can be used pretty directly to create the release notes.

> it tells me what the commit is doing at this particular point in history

When I talk about a particular point in _history_, I use past tense. :)

<comment><USER25> > Past tense is not necessarily programmer-centric. Release notes are > generally written in the past tense (with headings like > Added/Changed/Removed).

... which makes past-tense release notes "team-centric". In other words, past- tense release notes are about justifying the work that was done (like some kind of work report), rather than being an exhaustive list of changes in the application behavior brought by a new version.

> If commits are written in the past tense and from the user's point of view > they can be used pretty directly to create the release notes.

Bad idea IMHO.

Making developers worry about their commit messages potentially being used "pretty directly" as release note lines seems dangerous:

\- It implicitly convey the idea that commits and release note lines should have the same granularity. This might be true in some cases for programming error fixes, but it's generally not for features.

\- What about confidential stuff? commit messages are going to get a lot less informative if there's technically relevant stuff that programmers can't mention anymore (like the names of other customers, the yet-to-be-announced next product, etc.).

<comment><USER24> Why do you think release notes are "team-centric"? Who do you think release notes are for?

[https://www.mozilla.org/en- US/firefox/66.0/releasenotes/](https://www.mozilla.org/en- US/firefox/66.0/releasenotes/)

</comment></comment></comment></comment></comment><comment><USER26> I find commits very relevant when grokking unfamiliar codebases. The history and changes (plus, how they're documented) are half the battle for me in that context.

The article mentions the use of line-length and commit-templates. Personally, I have my .vimrc [0] configured to handle columns for commits (50 for the title & 72 for the body). Then, in my .gitconfig [1] I set a template [2] to be used for all commits. It's a relatively minimal addition, but it's improved my CLI experience with Git immensely.

[0]: [https://github.com/Pinjasaur/dotfiles/blob/89ca76eaaef24165e...](https://github.com/Pinjasaur/dotfiles/blob/89ca76eaaef24165e877e51ddd524f79e16f3ca1/.vimrc#L89-L99)

[1]: [https://github.com/Pinjasaur/dotfiles/blob/89ca76eaaef24165e...](https://github.com/Pinjasaur/dotfiles/blob/89ca76eaaef24165e877e51ddd524f79e16f3ca1/.gitconfig#L71)

[2]: [https://github.com/Pinjasaur/dotfiles/blob/89ca76eaaef24165e...](https://github.com/Pinjasaur/dotfiles/blob/89ca76eaaef24165e877e51ddd524f79e16f3ca1/.gitmessage)

Edit: fix link formatting

<comment><USER20> Yes! Someone unfamiliar[1] with the code-base should be able to make basic sense of what was done and why.

[1] Like my boss tomorrow. Or me in 6 months.

</comment></comment><comment><USER27> I don't know how people are programming. I have good unit tests and regression tests and even though I commit frequently, most of the time I don't end up with single purpose commits and usually when I trace back commit history these single purpose commits don't help me much, even if the team mates were writing commit messages like these.

How much time do people spend to put too changes they did almost at once to make the code compile or the tests pass into two commits?

Much more valuable are larger commits at the size of a small PR.

<comment><USER28> I don't understand why the history of the code matters so much to some people. Give me well designed and commented (!) code, with tests, designed to be understood by humans. Thats a bar few code bases clear, if I need to look at the git history its a sign the code is crap and I have to use all the information that I can get, with history being my least favorite because it has shitty UX (discoverability, navigation).

<comment><USER5> As time passes, practically no actively maintained codebase is going to clear your bar. It's going to pass through several different teams, with different policies and standards. Eventually, parts of it are going to be put on life support, which generally means an understaffed team that scrambles to patch up the most egregious bugs, often with dirty hacks, because they have no time and resources to do massive rewrites that are necessary to fix things properly. Maintaining such codebases requires a lot of "code archeology", and good history makes it much, much easier.

<comment><USER28> Not sure I get your point. People will cut corners and mess up the code, but somehow the history could be excempt from this?

</comment></comment></comment></comment><comment><USER29> Gahhh. Ignore most of that stuff about language, it doesn't add much value.

Just use common sense: Be clear, be informative, don't waste people's time. You're not writing deathless prose or trying to craft the Greatest Commit Comment of All Time. The Grammar Police are not going to break down your door with their milspec copies of Strunk and White and put you up on charges.

One thing I try to do is be a little entertaining. Just little things, a twist of a phrase or something that might cause a commit to stick in someone's head for a while. I've had comments like "Best commit logs of the project," so at least people were looking forward to reading them. Which, if you are scientific and dry and oh-so-grammarly-correct, they won't be.

I've had people mention some source-code comments I'd made a decade or two earlier (e.g., in public headers). That was fun.

</comment><comment><USER30> I have been recommending this article to my teammates:

[http://chris.beams.io/posts/git-commit/](http://chris.beams.io/posts/git- commit/)

<comment><USER15> Agreed. This is by far the best guidelines for git commit messages I'v found.

</comment></comment><comment><USER31> I personally don't like hard wrapping the body of a commit message because it then looks terrible every where - GitHub website, git client etc. and it becomes much harder to read

<comment><USER32> That's interesting, IIRC short lines are supposed to increase readability because longer ones are harder to mentally wrap.

<comment><USER33> Sure, but there's no reason that has to be done manually. Leave it to the client.

<comment><USER34> Most clients don't wrap in a way that helps readability, though. Look at Hacker News comments for example. At 1:1 zoom the text is spread out across the screen in super-wide lines that are hard to read. The classic recommended 72-char hard wrap guarantees a good reading experience on all but the narrowest of screens.

<comment><USER8> I often browser HN in a half width window for this exact reason. To be clear, I don't fault HN for this; I can trivially resize my window to whatever works best for me. Commit messages are different because people often interact with them via command line based tooling.

</comment></comment></comment></comment></comment><comment><USER35> Look, the simple matter is that commit messages are designed from the bottom up to be a medium of prose in the same way email is. I would venture to guess that an email written with good grammar, capitalizes subject (that is less then 50 characters), and a articulated thoughts would ecstatically welcomed compared to the drivel we normally recieve. Commit messages are no different. If one feels that a one liner is sufficient to establish context because the code is so impeccable then that is nothing short of arrogance.

Think of commits like little emails. They have a subject that should fit in a subject cell of a table. They have a body. And they have attachments (the diffs).

Why wrap lines? Because it is text. If you feel every client ever created handles wrapping appropriately then I'd ask to move the rock you've been under. For 30 years I've watched client after client screw up text wrapping. Heck, just sample a few government websites. By claiming commit messages are text you are taking back control of the crazy cesspool that is the modern app era and crafting a prose and typesetting fit for your own high standards.

As Steve Jobs once quoted: "Be a yard stick of quality. Some people aren't used to an environment where excellence is expected."

<comment><USER36> > Think of commits like little emails. They have a subject that should fit in > a subject cell of a table. They have a body. And they have attachments (the > diffs).

In fact, git has a command[1] to convert your commits to email messages.

[1] [https://git-scm.com/docs/git-format-patch](https://git-scm.com/docs/git- format-patch)

</comment></comment><comment><USER37> I have my own notes here: [https://www.aizatto.com/engineering-code/commit- messages](https://www.aizatto.com/engineering-code/commit-messages)

I think what I really like Angular's Commit Message Guidelines that suggest you include a "type" (build, docs, feature, fix, refactor) prefix into the commit message to help organize at a quick glance what the commit does.

[https://github.com/angular/angular/blob/master/CONTRIBUTING....](https://github.com/angular/angular/blob/master/CONTRIBUTING.md#commit)

Here are some other resources

Erlang [https://github.com/erlang/otp/wiki/Writing-good-commit- messa...](https://github.com/erlang/otp/wiki/Writing-good-commit-messages)

Gerrit [https://www.mediawiki.org/wiki/Gerrit/Commit_message_guideli...](https://www.mediawiki.org/wiki/Gerrit/Commit_message_guidelines)

<comment><USER10> I can see the value in gerrit's suggestion of including the component name in the header. I'm not sure I see the value in adding the commit type. Where do you see it as useful?

</comment></comment><comment><USER38> The best advice that I got came from CodeSchool's github course (this was about 5 years back so I am not sure if they have updated it). It said that the commit message should indicate what will happen if that commit is applied by another user, not what changes have been carried out. It's worked well for me so far.

</comment><comment><USER39> I think the form being used is "infinitive" rather than "imperative". The forms are identical in English, so it's hard to be sure, but in other European languages it would be the infinitive, I think, so I would guess that it's the infinitive in English, too. Also, it just doesn't seem like a command to me.

The document is translated into two other European languages, but the examples are still in English, which is a shame. A translator who is keen to go the extra mile would provide the examples in English and the target language, in my opinion.

</comment><comment><USER40> The value of git is the tooling around pushing code to a central place. Version control is a relatively minor (albeit occasionally very helpful) part of the value of git.

I'd argue that central storage (somewhat ironically), open source support, CI automations (esp. web hooks), issue management, etc offer far more value.

In other words, GitHub (and friends) are the value worth spending time in, rather than being in the weeds of using Git "perfectly".

</comment><comment><USER41> I prefer conventional commits, I have created a tool that prompts some info to make it easier to remember, I can also bump automatically the version using the commits. I've been using it with friends with no issues. I really like how the commit log looks

[https://github.com/Woile/commitizen](https://github.com/Woile/commitizen)

<comment><USER10> I've seen real problems with using commitizen. The first, and probably most insidious, is that if you've got a tool to enforce a format, people stop thinking about the content, but still believe they're getting good commit messages because the tool tells them so. This makes it harder to convince them that content quality needs addressing. Worse, it gives you no flexibility to use the limited space in the commit header if you, the human, have a better idea of what the commit message should be than the tool has.

It breaks muscle memory. For me, `git commit` is something that happens frequently - on the order of several times an hour, and not necessarily only in a single project. If the steps to commit are different from project to project, that's a mental speedbump every time I make a change, which pulls me out of flow and distracts me from whatever it is I'm doing. This is made worse when the commit format rules are in flux, because I then get tripped up within a single project.

Lastly, it's Yet Another Thing That Can Break(TM), and a specific example of that pernicious class of Technical Solutions To Human Problems.

<comment><USER41> Hey I'm sorry you had problems with it. I myself don't use it always. My main idea is to make it easier for teams to share the commit conventions with new developers (at work, for example, there was other convention which I find it hard, so I made a plugin also for it). Sometimes I'm not sure what type of change it is, so I can trigger `cz commit` and the prompt helps me remember what is what and to choose a proper prefix. My main objective was to avoid writing lazy commits 'fixed api', which I've seen around.

You don't need to use commitizen to write the commit, if you want you can choose conventional commits and write directly git commit, or use nothing. But if you use conventional commits, later you can use `cz bump` and detect the type of increment, and there are already tools that help you create a changelog as well.

I'm using this stuff with some friends in a project we are working on, and we use conventional commits (whoever wants uses commitizen) for our git messages, and then after a PR is merged into master we can execute `cz bump` in our CI and we have a new relese ready to deploy.

</comment></comment></comment><comment><USER42> What's wrong with Angular commit message guidelines?

[https://github.com/angular/angular/blob/master/CONTRIBUTING....](https://github.com/angular/angular/blob/master/CONTRIBUTING.md#-commit- message-guidelines)

<comment><USER43> Nothing - in the context of angular project, which this is not. They are not general enough, everything isn't angular.

But if you want to compare, I also dislike how they choose to expand the line width to arbitrarily accommodate certain git web uis but shun minimum terminal widths.

<comment><USER21> Shouldn't your terminal view be able to wrap the text itself before showing it to you? That seems a UI display issue rather than one to solve by changing the underlying data representation. I understand why that's not good with code but commits are almost always non-code.

<comment><USER43> You know what, that's a fair point, but it's also just not how it works...

The reason for the 72 rule is that minimum terminal columns (since the beginning of time) is 80. git-log will pad the message with a 4 space margin, so to keep it centred you want it to be 72... alternatively to keep it from sprawling to illegible lengths you want to hard wrap it at about that width anyway.

So you will find one of 2 undesirable things happen if you don't hard wrap to this length:

1\. Your terminal or pager _will_ wrap the text, but knows nothing of the formatting, so it will wrap onto the next lines without indentation (this does reduce legibility, making it harder to see where one commit ends and another begins in the full log).

2\. Your terminal or pager _wont_ wrap, in which case have fun scrolling to the right - a lot.

You could rightly argue that if the terminal + cli + pager and git were one monolithic UI, then it would have a more holistic view of whats going on and smarter decisions could be made - but then we lose all the benefits of those separations (the unix way). There is no win win, but it is at least pretty trivial to hard wrap text automatically in your editor.

</comment></comment></comment></comment><comment><USER44> Subversion recommened commit messages to be single line, without breaks. The argument was that it's good for scripting, the one record = one line approach usual for unix scripts.

I have this habit since then and format all my git commits that way, despite the multi-line tradition in git.

Was Subversion wrong?

</comment><comment><USER45> I read the following tutorial on the topic few years ago and it has really helped me with commit messages:

[https://chris.beams.io/posts/git-commit/](https://chris.beams.io/posts/git- commit/)

</comment><comment><USER46> This guide is strange. The order of rules is in no relation to their importance: Imperative, Capitalize, Self-contained, Explain, Avoid "stuff", Length limit, Consistency.

That's like a health guide listing: Circumcision, Limit coffee, Exercise, Vitamins, Avoid "Russian roulette", Vaccination, Brush teeth.

</comment><comment><USER47> Author suggests using imperative form commit messages ("add X") as opposed to past tense ("added X"). Past tense should be avoided, but using imperative form sounds unnatural and incomplete. I prefer present tense. Just follow this template and you'll be fine:

      Q: What does the commit do?
      A: The commit <commit>.

Example:

      Q: What does the commit do?
      A: The commit adds extra padding to the header.

In this example, "adds extra padding to the header" is your commit message.

<comment><USER48> Both are natural, but imperative is simply more commonly used.

 _When applied_ , this commit will <refactor abc controller>.

This commit <refactors abc controller>.

I personally prefer imperative because when you look at a commit it hasn't necessarily been applied yet. But it's like arguing about the difference of potato and potato. As long as you're consistent (and write good messages in whatever style) it doesn't really matter.

</comment></comment><comment><USER49> When I look at commit messages its to know why the ____and who the __ __. Note. Its still OK to leave comments.

</comment><comment><USER50> I do not like the idea of giving anyone access to my email account. I'd rather see a desktop version of an inbox-clone.

<comment><USER51> Pssst...

[https://news.ycombinator.com/item?id=19705440](https://news.ycombinator.com/item?id=19705440)</comment></comment>


Ask HN: Growth hackers, how do you organize your outreach? - <AUTHOR> Do you keep a list of all the influencers you have reached out to? Do you use excel, google sheets, etc... <comment><USER2> Growth hacker is now the the facto designation of marketing analysts?

Most of the growth strategies that works day-to-day are not exponential nor against the rules of the system so they are not "hacks".

</comment><comment><USER3> Im not a GH, but I developed my own dashboard for this kind of things. Just a basic Django app admin panel CRUD.</comment>


Oxford Deep NLP – An advanced course on natural language processing - <AUTHOR> https://github.com/oxford-cs-deepnlp-2017/lectures <comment><USER2> Im taking this course at Oxford and they have been working through the practicals 1-3 (further ones will be posted)

For anyone considering working through this outside of Oxford: I think the practicals are the real gems here and should be doable without the practical lab sessions that you get when attending the course. With that being said, they use a dataset a bit closer to a real world assignment. Therefore, it requires some patience when wrangling the data especially for the later practicals.

However, the patience should pay off and it is rewarding once you build your own nonsense spewing TEDbot!

<comment><USER3> Regarding practicals: is there anything more than the overview slides ?

<comment><USER4> The org : [https://github.com/oxford-cs- deepnlp-2017](https://github.com/oxford-cs-deepnlp-2017)

That contains repos for practicals, eg. Practical 1: [https://github.com/oxford-cs- deepnlp-2017/practical1](https://github.com/oxford-cs-deepnlp-2017/practical1)

</comment></comment></comment><comment><USER5> here is what I don't understand about deep NLP (please keep in mind that I just began exploring this field):

I am currently working on an algorithm that uses elementary text cues in combination with large data-table lookups to determine things like relevant keywords of news articles scraped from various sites. I have given my results to hundreds of people independently to provide me with some feedback regarding the quality. Here is the current breakdown:

80% of the cases I get perfect score.

10% of the cases I get acceptable score.

10% of the cases needs improvement.

My questions here are:

1\. if deep nlp can only provide us with the same level of efficiency/accuracy, then why the hell would we use it?

2\. if deep nlp can provide us with more efficiency than what is stated above then wouldn't it be safe to assume that is UNREASONABLY efficient?

3\. why are most people using deep nlp or ML in general right off the bat. Theoretically, it would be far more interesting to construct a model where the result of a statistical/linguistically parsing is fed to some sot of ML algo in order to tackle that 10% of bad cases.

<comment><USER6> I've worked in the NLP research area (mostly with statistical metrics), and I can safely say that 80% (precision) is the empirical threshold that most metrics are able to reach quite easily. The threshold between 80% and 90% starts to get difficult and above that you have to do some tweaking to adapt to the specifics of your problem.

With that said, your values do seem to be in line with what I consider to be easily reachable, so it kind-of depends on how much work you need to do with the neural networks to extract those keywords. I'm not very knowledgeable on how NN are applied to this field, but I'm assuming that a drawback of that approach is that it may resemble a black-box in the sense that it may be hard to tweak the internals.

I prefer statistical metrics because they seem more simple to derive. For instance, you can think of things like "a relevant keyword is usually related with (or closer to) other relevant keywords" and you can test that hypothesis only by counting distances between words. This is what I've done in 2012 with quite good values, you can check the paper here: [http://www.sciencedirect.com/science/article/pii/S1877050912...](http://www.sciencedirect.com/science/article/pii/S1877050912001251)

<comment><USER7> I believe that NN provide the logical relations for you so perhaps they can be used to train and then inspected to understand the data better.

<comment><USER6> As I said, don't know much about deep NN, but what I can remember of neural networks from my college years, each "node" on the network only have weights associated with the inputs, which makes it a blackbox. In other words, it is not easy to "grab" a node from the network, check the weights associated with the inputs and understand how it relates to a language..

</comment></comment></comment></comment><comment><USER8> YOUTUBE-DL will download the lectures [https://rg3.github.io/youtube- dl/](https://rg3.github.io/youtube-dl/)

<comment><USER9> Thank you. I just wanted to complain about the need for the adobe flash player.

</comment></comment><comment><USER10> I am currently taking this course at Oxford and definitely recommend following this.

We will be using TED talks as our dataset, to create Question Answering, text completion, generating entire TED talks ourselves etc. Definitely very interesting and it is being taught by leading researchers in the field!

</comment><comment><USER11> Began this course earlier today and I think they appear to be pulling off the right combo of first principles foundation and tough problem sets, like cs224n (Karpathys CNN class). Other NLP courses that I've taken so far have gone over my head.

</comment><comment><USER12> > The primary assessment for this course will be a take-home assignment issued > at the end of the term. This assignment will ask questions drawing on the > concepts and models discussed in the course, as well as from selected > research publications.

Comes as a surprise that it's not a project, as, in my experience, all ML/ DL courses I've seen online from US universities (Cal, Stanford, etc.) require. Different university culture across the pond?

<comment><USER13> Oxbridge is very much exam based assessment. With your degree depending only on the exams taken at the end of the final year. So the take-home assessments are there just to make sure that you understand what you're doing and can progress to the next part of the course.

<comment><USER14> I must say that I am rather glad the degree I did at a Scottish university was based mainly of 4th year exams, with an element of 3rd year exams and coursework.

The idea of a averaging _all_ of your work across your course would have been a disaster for me as I did rather poorly in year 1, scraped through year 2 and did spectacularly well in years 3 and 4.

<comment><USER15> I'm not sure about Oxford but certainly for Cambridge you aren't graded overall, instead you get a grade for each part of the tripos[1] (two parts).

[https://en.wikipedia.org/wiki/Tripos](https://en.wikipedia.org/wiki/Tripos)

<comment><USER13> Yes but you generally treat your degree as being graded by whatever you got in part II

</comment></comment></comment></comment></comment><comment><AUTHOR> Stanford's version [https://web.stanford.edu/class/cs224n/](https://web.stanford.edu/class/cs224n/) Note: the videos will be available later.

<comment><USER16> Any idea when the lectures will be up?

<comment><USER17> Last spring's session's videos (so 9 months ago) are up on Youtube: [https://www.youtube.com/playlist?list=PLmImxx8Char9Ig0ZHSyTq...](https://www.youtube.com/playlist?list=PLmImxx8Char9Ig0ZHSyTqGsdhb9weEGam)

</comment></comment></comment><comment><USER18> If you want more advanced materials, both Kyunghyun Cho and Yoav Goldberg posted excellent notes: [https://arxiv.org/abs/1511.07916](https://arxiv.org/abs/1511.07916) and [https://arxiv.org/abs/1510.00726](https://arxiv.org/abs/1510.00726)

</comment><comment><USER19> 'Advanced' course with 'Sesame Street' introduction: [https://ox.cloud.panopto.eu/Panopto/Pages/Viewer.aspx?id=b7d...](https://ox.cloud.panopto.eu/Panopto/Pages/Viewer.aspx?id=b7d66d78-0deb-46d5-bc14-b1852b9d95e8) One of them should go :)

</comment><comment><USER20> How does the course content and rigor compare to the Stanford deep learning for NLP course? From a cursory glance at the practicals, it seems like the Stanford version has more variety and depth of problems.

<comment><USER11> If you're well-versed in DL + nuances of text-mining, then the Stanford one might be great. But, if you're a beginner like me, you'll find it a bit hard to catch up [1]. The Stanford assignments + Tensorflow class were very helpful. The assignments especially really get you thinking.

[1] I took the Stanford one and went through the videos (both 2015,2016).

</comment></comment><comment><USER21> Link should probably be to the org rather than a specific repo: [https://github.com/oxford-cs-deepnlp-2017](https://github.com/oxford-cs- deepnlp-2017)

</comment><comment><USER22> "Prerequisites: This not meant to be an introduction to Machine Learning course. Hopefully you've all got some knowledge to machine learning, otherwise you may find this a bit opaque. So at least you should understand/have taken courses in linear algebra, calculus, probability, ... we are not going to do anything particularly challenging in those areas, but ideas from those areas will be useful."

around 7 mins 30secs into the introduction

<comment><USER23> Those sound like standard pre-reqs for any ML course - it should probably be a standard disclaimer on every course except for intros (even there, though, you'll want the linear algebra and probability knowledge - at least the bare basics). I can only imagine the number of people who jump into such courses and get in over their head very quickly...

</comment></comment><comment><USER24> Here [1] is an example of the videos, the player has a handy search feature and links to video parts.

 __update: __It would be great to have a way to take your own notes, any chrome extension that can help with that ?

[1] [https://ox.cloud.panopto.eu/Panopto/Pages/Viewer.aspx?id=ff9...](https://ox.cloud.panopto.eu/Panopto/Pages/Viewer.aspx?id=ff91caf5-fa7c-42de-8b3d-41f4bc2365b4)

<comment><USER25> Where could I find a list of links to the videos?

<comment><USER24> On the README [https://github.com/oxford-cs- deepnlp-2017/lectures/blob/mast...](https://github.com/oxford-cs- deepnlp-2017/lectures/blob/master/README.md)

<comment><USER25> Thanks!

</comment></comment></comment></comment><comment><USER26> What are the practical uses of language modelling RNNs ? (apart from writing grammar/syntax checkers)

<comment><USER27> I wonder if they could be used to improve speech recognition accuracy. So you'd have two models running when someone utters a sentence: the first would generate the x most likely phrases that it thinks were spoken, and the second (the RNN) would select the highest ranked 'plausible' sentence (i.e. a sentence it would have been able to generate itself).

I guess that's a bit indirect, but these RNNs are essentially learning the 'rules' that actual phrases conform to. It'd definitely be better than trying to hard-code the rules (especially for a language like English!). And the training data is very easy to get: just feed it a few thousand ebooks, the comments section from HN etc.

<comment><USER28> Standard neural network-based speech recognition pipelines (i.e. RNN + CTC) always use a language model. Unlike a seq2seq model (or any autoregressive model, or a structured prediction output), CTC models output timesteps as conditionally independent. Hence, everyone uses an RNN LM or n-gram LM or both when retrieving probable sequences from a CTC model (e.g. with beam search).

</comment></comment></comment><comment><USER29> Is there any good introductory material? I have tried severally to understand the theory and the spirit of DL and ML, but I have not been able to connect the dots. Please direct my path.

<comment><USER30> Calculus, Linear algebra, Statistics, Probability theory. You won't get far studying "basic" ML without an elementary understanding of those subjects. Unless you blackbox the implementations and hack them, but you'll have trouble understanding why things work/when to use certain techniques vs others or how to tune for optimizations.

</comment></comment><comment><USER31> I'm reading 'Deep Learning' right now so this is going to be really useful. Thanks a lot!

<comment><USER32> Who's the author? I'd like to learn more about deep learning techniques, so I appreciate any suggestions on introductory materials!

<comment><USER33> The book 'Deep Learning' generally refers to deeplearningbook.org, though there are others by that name. Goodfellow, et al, I think of as the canonical.

</comment></comment></comment><comment><USER34> Darn - I did an MSc at Oxford last year and they didn't offer this course then

</comment><comment><USER4> This looks amazing, thankyou for sharing!

</comment><comment><USER35> coookie monster and the fairy keep exchanging apples <\----> bananas

how does this help me solve NLP

</comment><comment><USER36> Edit.</comment>


Study finds that a GPS outage would cost $1B per day - <AUTHOR> https://arstechnica.com/science/2019/06/study-finds-that-a-gps-outage-would-cost-1-billion-per-day/ <comment><USER2> Nobody's talking about what might cause an outage. There are three basic parts to any GNSS: The control segment, the space segment, and the atmosphere on the way back down.

The control segment is run by the military so let's assume it's as secure as any other military network, and that attacking it would be seen as an act of war. And there are several constellations run by various countries, who do not represent a common target.

The space segment is vulnerable to space weather, but has proven pretty darn resilient so far. Even if a big CME or something knocked out a few satellites, there are ton of them up there, and most of the most critical applications only rely on timing, not positioning, and would work fine with a degraded constellation.

The atmosphere is where it gets interesting; an airburst nuke will make the ionosphere basically opaque to such signals for quite some time. How long depends on a lot of details, but assume several weeks. This would affect all signals from all constellations for all users, and is IMHO the only threat worth worrying about. Because an airburst over the ocean might not be construed as an attack on any specific nation, but it would exact a huge economic toll on the most developed and tech-reliant nations. It must be a tempting option for a spastic tyrant who has a nuke or two and feels backed into a corner.

<comment><USER3> What about space debris? Isn't there a non zero chance that a satellite could hit some debris and cause a chain reaction?

<comment><USER4> Isn't there enough redundancy in space that one sat going down means nothing for the system

<comment><USER5> No, the issue with space debris is that we are quickly approaching the point where a single unfortunately placed collision could chain using a sort of exponential "shotgun effect", destroying virtually all satellites at a given orbit and rendering space travel impossible for decades if not centuries, setting human space exploration back significantly as launches have to deal with thousands of metal shards traveling at tens of thousands of mph.

See this video[1] by Kurzgesagt: "End of Space - Creating a Prison for Humanity."

[1]: [https://youtu.be/yS1ibDImAYU](https://youtu.be/yS1ibDImAYU)

</comment></comment></comment></comment><comment><USER6> It would be interesting to know of everything that uses GPS what % of use is purely for a very accurate synchronised time source vs uses that actually require the location aspect.

The article states 'The researchers found that the largest benefit, valued at $685.9 billion, came in the "telecommunications" category, including improved reliability and bandwidth utilization for wireless networks'. I wonder if location is actually required for these purposes or it's purely the synchronised time source (clearly a useful thing to have when building communication systems).

Edit: Ah the question is answered from another part of the article 'Wireless technology continues to evolve in ways that increase its reliance on highly precise timing, which in turn increases reliance on GPS.'

<comment><USER7> The article mentions only GPS. Most modern receivers can use multiple systems for redundancy; GPS, GLONASS, Galileo, BeiDou. They can also provide accurate timing. [https://gssc.esa.int/navipedia/index.php/Time_References_in_...](https://gssc.esa.int/navipedia/index.php/Time_References_in_GNSS)

It's not clear if they use GPS as synonym for all available GNSS or is the study GPS only?

EDIT: I skimmed the document. The underlying assumption seems to be that US based industries don't have or don't use multi-constellation capability.

>In looking across the many sectors and applications that require GPS's accuracy and precision, it becomes clear that GPS has some attributes of a utility. The signal is a public good and service provided by the U.S. government that enables productivity, quality, and efficiency benefits that would not otherwise be possible. For many years, it was the only comprehensive PNT signal available. Signals are now available from GLONASS (Russia), Galileo (Europe), and BeiDou (China). The global marketplace means that many devices are increasingly capable of receiving signals from multiple constellations. In the United States, however, critical infrastructure, industries, and applications leverage the GPS signal.

<comment><USER8> Products like [1] consider concurrent GPS+GLONASS tracking a paid upgrade.

However, they also have 'holdover performance' allowing them to remain accurate for several hours without a GPS signal.

[1] [https://www.microsemi.com/product-directory/carrier-grade- nt...](https://www.microsemi.com/product-directory/carrier-grade-ntp-ptp- grand-masters/4133-timeprovider-2700)

<comment><USER7> Similar product from Oscilloquartz has optional GNSS kit with GPS/GLONASS/BEIDOU/GALILEO

</comment></comment></comment></comment><comment><USER9> Note that GPS and "GPS technology" are different things. When people say "GPS" they normally mean the US system and that is the one the article is talking about. But there are several satellite networks that each act as a _global positioning systems_ using "GPS technology".

We are seeing more and more devices that can access many different networks. This is a good thing. Not only does it increase redundancy in case of a widespread outage of one network, it diminishes any one nation's ability to disrupt positioning. No longer can the US simply turn off or obfuscate location data (they used to blur it. Google "GPS selective availability"). The existence of competitor networks allows users to quickly identify and ignore such actions.

<comment><USER10> GPS is specifically the name of the US system. GNSS, Global Navigation Satellite System, is a general name that also covers other systems.

[https://en.m.wikipedia.org/wiki/Satellite_navigation](https://en.m.wikipedia.org/wiki/Satellite_navigation)

<comment><USER2> NAVSTAR is specifically the name of the US system.

GNSS is the generic term.

GPS could be used to mean either, and sucks as a term.

<comment><USER9> If we want to be really specific, the US program is now called "NAVSTAR GPS" and it was once manged by the "Interagency GPS Executive Board" ... so the people running NAVSTAR still call it GPS, internally at least.

</comment></comment></comment></comment><comment><USER11> "Collins Aerospace is coordinating with safety regulators and its equipment clients after a GPS connection outage on its parts resulted in the cancellation of hundreds of flights, especially flights on aircraft operated by US regional carriers." [June 10 2019] [https://www.flightglobal.com/news/articles/collins-gps- outag...](https://www.flightglobal.com/news/articles/collins-gps-outage- grounds-regional-flights-458819/)

</comment><comment><USER12> This seems pretty low. People depend on electronic navigation almost exclusively these days.

<comment><USER13> My thoughts exactly. How many millions would be unable to get to work (or stranded at work)? So many people have lost the ability to navigate without it.

<comment><USER14> Really, is that a thing?

I'm completely unable to redo a nontrivial GPS route without the GPS after a handful of times, but I can definitely redo routine routes. At first I'd expect so can anyone else.

<comment><USER15> What about all the people that started at a job recently?

<comment><USER16> They would get a paper map? You can buy, print, or draw maps.

</comment></comment></comment></comment></comment><comment><USER17> I would understand if it was a full GNSS outage, must most "GPS" equipment nowadays is multi-constellation, using as much as four (GPS, Galileo, Glonass, BeiDou). The loss of one constellation should go undetected by most end users.

<comment><USER18> What disaster would knock out only one constellation out of four (perfectly one) and also go unnoticed to users?

<comment><USER19> The phrase that should strike fear into the heart of any engineer who has to work at scale (any kind of scale, not just software): "Correlated failures". A software bug that affects only one of them. The political possibility mentioned elsewhere. Some computer virus never "intended" for a satellite manages to get into one of them for some reason, most likely a very bizarre one that nobody would have ever guessed could happen but still somehow did. Some hardware component that turns out to fail all at the same time (more or less), used by all of a particular constellation. Or most likely of all, something I can't even think of to put here as an example, but still it somehow turns out that a particular failure ends up having as a side effect greatly increasing the chance of failures in the rest of the system despite all the efforts to prevent that. (The "ones we can't even think of" end up with elevated probabilities precisely because we don't think to prevent them and thus put no engineering into preventing them.)

All of these outcomes are low probability, sure, but they are all _vastly_ higher probability than sufficient simultaneous independent failures to take down the system. It's why despite all the incredible software engineering that goes into Google and AWS, they still go down sometimes. Almost no conceivable set of independent events can take those things down, but correlated failures still can, do, and will continue to do so.

</comment></comment></comment><comment><USER20> If devices have other radios such as WiFi and GSM these can function as a backup plan (I don't think BT would suffice, unless there would be P2P between Bluetooth devices with devices who _can_ provide coordinates such as WiFi and GSM).

For example, the first iPhone used Apple WiFi positioning; it didn't have GPS. I still remember I had a an iPod Touch with a 3rd party GPS which worked with the predecessor of Cydia.

Check the sources UnifiedNlp [1] can use. Quoting:

> AppleWifiNlpBackend - Uses Apple's service to resolve Wi-Fi locations. It > has excellent coverage but the database is proprietary.

> OpenWlanMapNlpBackend - Uses OpenWlanMap.org to resolve user location but > the NLP backend did not reach release-quality, yet. Users interested in a > freely licensed and downloadable database for offline use should stick with > openBmap for now - Last updated in 2015

> OpenBmapNlpBackend - Uses openBmap to resolve user location. Community- > created, freely licensed database that can optionally be downloaded for > offline operation. The coverage varies from country to country (it's best in > central Europe).

> MozillaNlpBackend - Uses the Mozilla Location Service to resolve user > location. The coverage is OK. Only the cell tower database is free.

> LocalWifiNlpBackend - Local location provider for Wi-Fi APs using on-phone > generated database.

> LocalGSMLocationProvider - Local opencellid based location provider backend. > Has been surpassed by LocalGSMBackend which also has an OpenCellID option - > Last update in 2014

> LocalGSMBackend - Local location provider for GSM cells. It works offline by > downloading freely licensed database files from Mozilla, OpenCellID, or > lacells.db.

[1] [https://github.com/microg/android_packages_apps_UnifiedNlp](https://github.com/microg/android_packages_apps_UnifiedNlp)

<comment><USER21> I think a lot of cellular technologies rely on GPS on their base stations as a timing reference. Most cellular capabilities might fall off a cliff if GPS isn't available.

<comment><USER20> Why though? If the celltower has networking (e.g. 4G), it could use NTP. The databases with GSM just use triangulation. As long as they broadcast, the triangulation should work.

<comment><USER17> Best case NTP is in the order of millisecond precision. Completely inadequate for this case.

</comment></comment></comment></comment><comment><USER22> I think the headline is trying to imply that this is a big number, but at 1.8% of the world's daily GDP it doesn't seem like it. I would have thought GPS would have a lot more impact than that.

<comment><USER23> 1.8% of global GDP is huge!

<comment><USER22> It's 0.005% of GDP.

<comment><USER23> You said one day of GPS is 0.005% of one year GDP, but we're comparing a day of GPS to a day of GDP, so it seems proper to say it's 1.8% like your earlier quote, right? If we lost any length of time of GPS, it would be 1.8% of that period's GDP?</comment></comment></comment></comment>


Show HN: Hellobox.org – Company gear for remote teams - <AUTHOR> https://hellobox.org/ <comment><USER2> Here's some feedback:

1\. I don't get the Amazon gift card angle. Is that some allowance that you're giving the employee? Those gift cards can be sent electronically and they're more convenient to use that way since it's a website.

2\. You can drastically simplify the pricing. I would remove the two tiers and just make it one price. Increase the price a bit more and have shipping included. Reduce the complexity, reduce the friction.

3\. Why stop at new hires only? Market this as a way to keep remote employees happy whether it be at the time of onboarding, just for fun, or whatever milestone/event.

4\. Why compare what it costs you vs what it would cost them? The value is more than the cost savings. It's the convenience and the fact that you're made for it. Give the client an option to include a personal note or something to make it go from commodity to premium.

<comment><AUTHOR> Thanks for the feedback. You make some great points. I'll respond to each.

1\. I originally wanted to include the book REMOTE, but figured it'd be better to give customers a choice of books. Then I just opted for the gift card instead for simplicity.

2\. I like that idea. I didn't include shipping originally because I have no idea what it will actually cost, and was hoping to offset that risk initially. Totally agree going forward.

3\. Just picked a specific niche that I knew it would appeal to in the beginning.

4\. Good idea.

</comment></comment><comment><AUTHOR> OP here. I remember the first time I visited the Mothership as a remote employee. I was grabbing t-shirts and stickers by the handful. I've been wanting to build something for remote teams for quite a while, and this seemed like simple place to start. It's definitely rough around the edges, but I wanted to get it out there. It took two weeks to build in my spare time. Happy to answer any questions.

</comment><comment><USER3> Can you customize what's in the box? I know Hired sends out amazing swag to their companies/clients in boxes like these, it would be great to be able to use this to run something similar.

<comment><AUTHOR> I originally had that on the pricing page. $5 per box - ship us whatever you want and we'll box it up and send it out. So yes, it's totally doable.

<comment><USER4> I think this($5/box) model is preferable to the one currently offered. It strikes me that you are selling a $30 company t-shirt and that sounds expensive. Any printing company is able to duplicate your model very easily, undercut your pricing, and probably do it more efficiently with existing resources (admittedly, I don't know your resources, you may have great production and shipping capabilities already built out).

I have worked remote for a few different companies, and the more compelling offer is a service with a high-degree of customization, which can include a t-shirt and some stickers, too. Plus, you could charge more for curating and purchasing. Suppliers may also pay you to be part of your curated offering.

</comment></comment></comment><comment><USER5> Are you sure you need a 2.9MB hero image download which took about 20sec to load on a 12Mb broadband connection?

<comment><AUTHOR> Nope. Definitely not. It's actually even larger than that. Just got overlooked in shipping as quickly as possible.</comment></comment>


Toast hangover prevention gummies 35% off (code: cyberhangover) - <AUTHOR> https://toastgummy.com/discount/cyberhangover <comment><USER2> I was not able to find any link to a scientific publication backing the Toast Hangover gummies. The landing pages do quote Dr Joris Verster which was at least a Phd at the University of Utrecht [https://www.uu.nl/en/research/pharmacology/research/joris- ve...](https://www.uu.nl/en/research/pharmacology/research/joris-verster) I suspect Dr Joris Verster is simply being quoted with generic statements about hangover but is not endorsing the Hangover Gummy Bear neither he partecipated in the Research and Development. By nose it seems quite probable this product is not backed by actual scientific test but is just another (probably wrong) guess at fixing hangover.</comment>


The man who cracked the code to scratch-lottery tickets - <AUTHOR> http://www.thestar.com/news/article/933200--toronto-man-cracked-the-code-to-scratch-lottery-tickets

<comment><USER2> Previous discussion of a more in-depth Wired article here: <http://news.ycombinator.com/item?id=2166555>

</comment><comment><USER3> Just saw this. Awesome article. On another note, what is a geological statistician?</comment>


Mechanical Turk 101: How to use MTurk for tagging training data - <AUTHOR> https://monkeylearn.com/blog/mechanical-turk-101-use-mturk-tagging-training-data/ <comment><USER2> Are there any other option than MTurks, to get data tagged from team mates or Editorial teams.

<comment><AUTHOR> As an alternative, you can try Anafora [https://github.com/weitechen/anafora](https://github.com/weitechen/anafora)</comment></comment>


Germany breaks world solar power generation record in July with 5.1 TWh - <AUTHOR> http://www.treehugger.com/renewable-energy/germany-breaks-world-solar-power-generation-record-july-2013-51-twh-leaves-us-dust.html

<comment><USER2> That's a great accomplishment, but compare that to the US's [4143 TWh of energy consumption in 2010, alone]([http://en.wikipedia.org/wiki/Energy_in_the_United_States#Cur...](http://en.wikipedia.org/wiki/Energy_in_the_United_States#Current_consumption)).

Compare that to Germany's "whopping" 5.1 TWh of solar energy output, and that's hardly 0.12% - that's like saying "it takes $100 to purchase (some object X) - look at that panhandler, they earned 12 cents towards that goal - isn't it amazing? You only earned 1 cent panhandling: you should panhandle harder."

No, the reality is, investing money in solar energy without aggressive technological advancements that reduce our consumption is an arms race that we can NEVER win.

<comment><USER2> Oh, and before people start the old tired "but if we invest in solar energy today, it'll give us a head start!" realize that those dollars and effort spent is a finite and limited resource. A dollar and its corresponding effort spent on solar energy can no longer be spent on anything else, because spending it uses it up.

We HAVE to be smarter about how we spend our limited resources, or we're just paying feel-good lip service. Which, is okay: it's important to feel good! But, don't try and make other people feel bad because they're not making the same choice to ignore pragmatism and embrace feel-good jingoism ...</comment></comment>


Philz Coffee Raises Eight-Figure Round From Summit, Angels - <AUTHOR> http://techcrunch.com/2013/05/01/philz-coffee-raises-eight-figure-round-from-summit-angels-as-specialty-coffee-market-heats-up/

<comment><AUTHOR> I'm convinced Phil is the puppet master behind all of the productivity in South Park(Slurp).</comment>


Google Fiber franchise wins approval from Portland City Council - <AUTHOR> http://www.oregonlive.com/silicon-forest/index.ssf/2014/06/google_fiber_franchise_wins_ap.html

<comment><USER2> I think this is great, but it's really critical to understand the regulatory concessions Google won in this process (FTA):

> The agreement exempts Google from a 3 percent "PEG fee" that the city > charges Comcast.

> Unlike Comcast, Google Fiber is not required to serve all parts of the city. > Google says it will operate in "fiberhoods" where subscribers reach a > critical mass.

So far Google has gotten these sorts of concessions in most if not all of the Google Fiber Cities, over public opposition: [http://seattletimes.com/html/businesstechnology/2023420101_b...](http://seattletimes.com/html/businesstechnology/2023420101_briercolumn21xml.html). Provisions like these are key barriers to establishing competition in other markets, especially for companies that don't have the negotiating clout of Google.

The media has tended to focus on the Google versus cable/telco fight, but at least as important if not more so is the precedent that Google's hardball tactics are setting for municipalities: if you want fiber, you have to give up these terms in franchise agreements. Google's efforts here will be a huge boon to companies like RCN that are attempting to build fiber in cities with established cable or telecom competitors.

There's also a third interesting point:

> Portland and Google will participate in a "joint defense" of the franchise > if it faces a legal challenge over allegations it gave Google Fiber > preferential treatment, exceeded the city's authority, or violates the law > in some way.

<comment><USER3> > The agreement exempts Google from a 3 percent "PEG fee" that the city > charges Comcast.

NO NO NO NO NO NO NO

This is very very very bad and sets a horrible precedent. Portland has one of the best cable-access facilities and set of stations in the country. They serve a vital public interest, allow absolute free expression, and "professionalize" niche programs that otherwise would just be someone talking into a webcam.

<comment><USER4> Am I misunderstanding you or are you suggesting that anyone who provides Internet service in Portland should be subsidizing public access television?

<comment><USER5> Note that Google Fiber is essentially a cable company since they provide TV. Whether a company uses coax, twisted pair, or fiber isn't relevant to video franchise agreements. [http://en.wikipedia.org/wiki/Multichannel_video_programming_...](http://en.wikipedia.org/wiki/Multichannel_video_programming_distributor)

</comment></comment></comment></comment><comment><USER6> What would be really awesome would be Google Fiber covering Portland and somehow covering Vancouver, WA too.

<comment><USER7> And then the rest of WA!

</comment></comment><comment><USER8> Not that this isn't good news – it is – but it's taken 4 years to get to this point: [http://blog.oregonlive.com/siliconforest/2010/03/portland_ci...](http://blog.oregonlive.com/siliconforest/2010/03/portland_city_council_backs_go.html)

Still no fiber in the ground. This sort of negotiation is such a huge barrier to entry that only very big (or incumbent) companies have a fighting chance.

Obviously, Google entering the market is a big deal and good news – two competitors is better than one. But only a company of the size and regulatory savvy of Google would even try.

</comment><comment><USER9> Come on progressive portland, build a municipal fiber network like my redneck hometown in Tennessee.

</comment><comment><USER10> I thought America had free markets?

So then why do people need permission from government councils in order to compete in Internet access?

</comment><comment><USER11> I've been impressed with our city council so far. Now let's hope they legitimize short-term rentals so we can continue offering Airbnb in Portland.</comment>


Marketing Planning Tool Beta - Marketing-Plans http://www.hatchmarketingplans.com/beta-sign-up

<comment> Marketing-Plans Hatch Marketing Plans is seeking marketing professionals to help beta their new online planning tool.

Hatch helps businesses quickly create marketing calendars, dashboards and play books.

If you are using Microsoft Word, PowerPoint and Excel to build your marketing plans you'll love our easy-to-use, online planning tool that enables businesses to quickly create, manage and track their plans.

Sign up for our beta today!

[http://www.hatchmarketingplans.com/beta-sign- up](http://www.hatchmarketingplans.com/beta-sign-up)</comment>


There is no retirement - <AUTHOR> http://diegobasch.com/there-is-no-retirement
<comment><USER2> I share this sentiment...for me, retirement is not the freedom from work, but the freedom to work on what I chose. Life would be boring without productivity. Additionally, as I age, I've felt a gradually stronger internal pull towards _meaningful_ work.

The thing that terrifies me about the technology industry as a whole is that it plays favorites to the young, yet it's the only field I've ever truly been passionate about. I'm approaching 40 and have reached the executive level, which is great...yay. However, will I still be working in tech when I'm 70? I want to, but will companies let me? I doubt it.

It bothers me to think that the only way I'll be able to continue to work in the field I love dearly is to go my own way and start my own company. Hey, that's what I want to do anyway, but it'd be nice if that were simply an option rather than a requirement (and, even nicer if it odds were in favor of it happening successfully).

Best of luck to all of you aging techies who are in my boat (or further along). This industry is a harsh mistress.

<comment><USER3> The inescapable conclusion is that, if you want to be in the industry as you go along, you have to be largely, if not totally, in control.

To me this means always being at the value creating edge - whether this is in creating companies and products, or being indispensable to those who are. How you do that is the challenge - could be capital, could be contacts, could be experience or just a proven track record of having some clarity in the dim view that is the future.

You seem to realise that relying on a career and job security might be risky. That's probably true. The only way to mitigate that particular risk is to start spreading the risk around into other areas - like starting a company now. That's not a prescription to dump all and start again, but looking at your current career trajectory with a critical eye is certainly a good idea.

</comment></comment><comment><USER4> Your post touched me because my father, though retired, was also a very active man right up to the end. Towards the end much of his energy was directed towards taking care of my mother. He had a heart attack when my mother passed away and was bedridden for a while. I was amazed at how he clawed back from near death, going back to taking care of his finances and maintaining the household. Alas, he died 8 months after my mother. When I came back to the house the last time he was in hospital I noted how carefully he had organized everything which had been such a mess when I had last left (created mostly by me as I tried to go through my mother's papers to put some stuff in order). He was 76 and in his manner of leaving (I really like that word) he taught me as much about life as he had done when he was here.

<comment><USER5> I'm sorry for your loss. Losing two parents so close to one another must've been very difficult.

<comment><USER4> Thanks for your sympathy. It was hardest on Dad. After mom's passing dad and I got very close. I got to know him a lot better the last few months of his life.

</comment></comment></comment><comment><USER6> I'm very sorry, Diego. You have got to be in shock right now. I wish you well getting through it.

My father left last year (though not so unexpectedly). It changes one.

<comment><USER7> Thanks.

<comment><USER8> I thought it was a wonderfully written tribute, and I agree with all your points - why stop if you're enjoying yourself.

</comment></comment></comment><comment><USER9> Diego, your dad sounds like he was a good man and he looked very happy. My brother left unexpectedly too. Last year. He was only 46. He left a much bigger impression on me than even I expected. You will probably find out just how big your father was, too, and it will stun you for quite a while. So: Be here, now. You won't get another chance.

</comment><comment><USER10> I'm sorry for your loss but to some degree the premise seems a bit idealistic. I have a hard time believing the myth that there are people who truly enjoy every aspect of a job. If one is lucky they enjoy a portion of it. For example I love programming most of the time but sometimes I simply do not feel like doing work that needs to be done.

The true ideal in my mind is semi-retirement. Work less, less often, and if you don't feel like working simply don't. Adjust your schedule so it is absolutely to your liking - show up at 10 AM leave at 3 PM, etc. Peoples careers should degrade gracefully, not come to a crashing halt like we've come to embrace in our society

</comment><comment><USER11> Steve Jobs talked about looking in the mirror in the morning and thinking about one's forthcoming day, and that if what one was about to do that day, would not be what one wanted to do, were it the last day of one's life, and if that scenario played on for too many days in a row, it was time to do something else. It is true, I think, that if one really loves what one does, one would not want to "retire", and hence, "leaving" is the only thing that occurs, not "dying". Good post, and condolences for your loss.

</comment><comment><USER12> Diego,

Your post just knocked me on my keyster. Beautiful writing. It is absolutely relevant to hackers because all of us have parents, and we need to look at how they've lived their lives and figure out how we will live as we age. The prospect of retirement is terrifying; I expect that the concept as we know it is dead; we have to come up with another model that befits the time.

</comment><comment><USER13> Financial freedom is a hedge against the loss of your human capital. Most people dramatically overestimate the continuity of their human capital and are surprised when it starts to diminish. It's a great thing that a certain percentage of people remain vital their entire lives, but you can't count on it.

</comment><comment><USER14> I'm a native English speaker living in Argentina, and yours is the first English writing I've seen by an Argentine that is enjoyable (I read some of your other posts) and doesn't contain errors, and that includes people who were schooled bilingually.

Is there anything in particular that pushed you over the edge beyond fluent?

<comment><USER15> that's weird. Come around reddit.com/r/argentina and you'll see the same kind of writing quality.

<comment><USER14> Thanks for the link. While that looks interesting I was talking about English writing by Argentines, whereas that subreddit is almost entirely in Spanish.

<comment><USER15> Sorry for the late reply. Yes, it's 80% in Spanish but now and then some foreigner comes asking questions in English and that gives place to lengthy threads in English, mostly written by argentines.

</comment></comment></comment></comment><comment><USER16> This is a great post, and I hate to put a damper on things, but the title makes me think of something else I've been feeling in my gut for a while.

Retirement is not going to be an option for many future generations. The cost of living is getting too high, while salaries for many industries are falling too low.

This gut feeling first appeared in me when I saw GM renegotiate pension plans with its retirees. If even defined benefit pensions can be renegotiated, what is the actual rate of return on those suckers? Is it enough for anything? And it's not like I trust mutual funds, housing, or anything else to be much better anymore.

So I come to the conclusion that lifelong work will become a necessity for most. Retirement will be a luxury.

</comment><comment><USER17> I think there is a great message here. Most entrepreneurs I speak to believe that they must quit and start a company as soon as possible (early thirties?) or else they will never be able to start one.

I think this is a fallacy. My dad became an entrepreneur in his early forties and many other much later. It is not really a matter of age anymore in modern societies. It is about how sharp you keep yourself as you age.

Probably if you are a startup kind of person (as opposed to sustaining a company kind of person), you would be starting companies even in your nineties. It is never too late. It is just how old you feel.

</comment><comment><USER18> Great points, I appreciate the mindset that you and your dad share. I agree completely. I want to be financially stable enough to retire, but I would never want to stop accomplishing things.

</comment><comment><USER19> This is a moving story; I would tend to agree that he is fortunate to have been doing what he loved, with those he loved, even if he was taken before his time. I recently witnessed my grandfather going through years of idle physical and mental deterioration until he passed, though at a considerably more advanced age, and it was difficult for us, his family, and I'm sure especially for him to go through as well. I am sorry for your loss.

</comment><comment><USER20> The concept of retirement is flawed. What should be fostered in society is lifelong learning, wellness, and mentoring those around you.

<comment><USER21> It wasn't flawed. It was a necessity until very recently. Most people in the tech field fail to realize that most "jobs" are actually back breaking physical labor. Whether that is working a mile underground or standing on your feet for 8 hours. It beats the body up. So you pound the pavement for 40+ years until your body says I can't do this anymore. Now what do you do? You exit the circuit and let another person pound it out for 40 years.

And that is what retirement is about for most people. Not you complaining that tech companies won't hire you. But you've been doing this too long and your back is shot.

</comment></comment><comment><USER22> It's not as black and white as having a shitty vs fulfilling job. Many (most?) retirees are coming from ok jobs and are conflicted but positive about retiring, seeing it as a transition to antother phase of life.

The workaholic is a special type of person.

Edit: to add, I do understand how it's important for people to feel useful, and I agree it's a good idea to stay active after retirement.

</comment><comment><USER23> Condolences for your loss Diego. I think your post best sums up what I call "life's work". We are lucky when we find it.

And I need to call my Dad.

</comment><comment><USER24> A lovely tribute, and a view of retirement that matches mine completely. One might also add simply that, Calvinistic though this may be, work is good for us. My father retired at 59 for reasons that are still unclear to me (he loved his job) and died a year later.

</comment><comment><USER25> I'm sorry for your loss but I think your father would be happy with the legacy he left behind.

</comment><comment><USER26> It is wonderfully written! Thank you for sharing... I am very sorry for your loss!</comment>


Nyms: Anon Personas and Payment Pages for All - <AUTHOR> http://blog.coinkite.com/post/97057447171/nyms-anon-personas-and-payment-pages-for-all

<comment><USER2> Do you have a setting where the address used with a nym changes after every transaction?

<comment><AUTHOR> Already does! BIP 32 HD addresses for every new transaction :)

And you can also setup funds forwarding [here]([https://coinkite.com/accounts/send/forwarding](https://coinkite.com/accounts/send/forwarding))

<comment><USER2> That's pretty cool, will forward to my cold storage.

</comment></comment></comment><comment><AUTHOR> Ping us at support at coinkite dot com if you need any help!</comment>