Show HN: Pyrustic – Software suite for developing your next Python desktop app - <AUTHOR> https://pyrustic.github.io <comment><AUTHOR> I want to clarify, the homemade widgets (megawidgets to be precise) Tree and Table are not superfluous in the project. There is indeed TreeView in Tkinter.

It is legitimate to wonder why there is Tree when TreeView already exists. Let's do a little genealogy to get some context before answering.

Well, Tkinter is the standard Python interface to the Tk GUI toolkit. In the face of the competition, Tk guys added a new set of widgets: the famous Tk themed widget (ttk).

It was not just an increment like 1 + 1 = 2 but rather a new direction slightly different from the old one without loss of compatibility of course. This document is great to go deeper in the topic: [https://core.tcl- lang.org/tips/doc/trunk/tip/48.md](https://core.tcl- lang.org/tips/doc/trunk/tip/48.md)

<comment><AUTHOR> Well, TreeView is part of ttk.

I wanted total consistency across Pyrustic's components, so I decided to stay on the original tk widgets.

Of course people still can use tkk, but Pyrustic Widgets don't use ttk at all.

I also designed a nice to use theme/style system to convince users to follow my way and I find that the visual is not so bad, maybe even too charming ...

</comment></comment><comment><USER2> Looks very interesting. A bit of feedback the website does not display well with mobile devices.

<comment><AUTHOR> About the mobile devices, I'll check that out. For the moment I will hope that people connect to it by computer.

</comment></comment><comment><USER3> Looks cool. But why isn't it available through pip?

Also, how is the support for windows? I couldn't find any mention of it.

A last note, if I may, is to put more time into the github README.md. That's where I usually go to read all the important technical details.

<comment><AUTHOR> Thank you ! Yes you are right about the Readme, it will be updated soon. I have not yet tested under Windows, it will be done soon. Regarding pip, indeed it is to be done too. Thank you again for your contributions.

</comment></comment><comment><USER4> It seems awesome! In addition to the GUI, both the database editor and the test runner are great features for the command line.

<comment><AUTHOR> Thanks ! And yes, the command line still has a long way to go !

</comment></comment><comment><USER5> This is awesome

<comment><AUTHOR> Thank you ! I struggled a lot with Tkinter to let us not worry about small problems like this one: [https://mail.python.org/pipermail/tkinter- discuss/2014-May/0...](https://mail.python.org/pipermail/tkinter- discuss/2014-May/003622.html)

<comment><USER5> Sure i really liked and I'm looking forward to build desktop apps using python</comment></comment></comment>


Is the Berlin Airport ready yet? - <AUTHOR> http://istderberschonfertig.de/ <comment><USER2> Fun page. The whole BER project and its delays is such an astonishing example of management that it is hard to believe it happened. I first thought it could only happen in some 3rd world country, but in fact, it couldn't happen in a 3rd world country. In a 3rd world country, the political leadership would simply jail bureaucrats until someone signs off the safety papers and says, go ahead and open the airport, never mind that the fire safety regulations were not followed.

But in Germany it was possible to have a) strong-willed politically elected project leaders who think they can waive off the regulations, and b) bureaucrats who still stick to the rules and keep their jobs.

What was most surprising was how the opening of this airport was "on track" until almost the last minute. I could imagine that many subprojects were late, but every subproject knew that some other subproject is even more late than they are, so everyone kept reporting "on track and in schedule" trusting that the other part will get the blame. Until the bubble burst.

In a way, this affair, although ridiculous, is a compliment to the safety culture and integrity of German bureaucracy, even if it irritates those of us who are squeezed at TXL.

<comment><USER3> _In a 3rd world country, the political leadership would simply jail bureaucrats_

You have a sweet understanding of third world countries.

In a third world country (at least the one I live in) all projects have the same fate. That's the default path a project takes. And that's not due to mismanagement but corruption.

Edit: Spelling mistake.

<comment><USER2> I had "parse error", but with faith I suppose you mean fate?

Well, I was painting with a broad brush, of course. Sorry about that. There are many very different 3rd world countries. Botswana is different from Zimbabwe even if it is not that far away, but generally, in the 3rd world, you can expect delays and that things are mañana or insha'allah. And many countries have autocratic leaders who wouldn't put up with fire regulations delaying an important project. Yes, it might be acceptable that the project is delayed because the material for runway pavement was used to build the road to El Presidente's summer house so he can get there when he wants to avoid Scorchio. But it wouldn't be acceptable that he doesn't get to cut the tape in an opening ceremony because some stupid says the smoke eviction ducts in the terminal are built wrong.

<comment><USER3> Yes. Sorry, fate is the correct word. I will correct my post now.

</comment></comment></comment></comment><comment><USER4> As an explanation for non-germans: Berlin is supposed to get a new airport, the BER, but the project is massively mismanaged, and already way over schedule and budget. Recently, for the first time, a schedule for completion has been released. This site provides a way to track the progress made on this schedule.

<comment><USER5> They released many schedules over the years, the first announced opening date was 1997 [1]. They even postponed dates for the announcement of (new) dates.

[1] [http://www.bertrug.de/Geplante_Inbetriebnahmen_Flughafen_BER](http://www.bertrug.de/Geplante_Inbetriebnahmen_Flughafen_BER)

<comment><USER4> Did they release schedules or just completion dates? I was just parroting what the Morgenpost wrote on the page, "Erstmals gibt es einen Terminplan, mit dem wir den Baufortschritt regelmäßig überprüfen können."

</comment></comment></comment><comment><USER6> For those that are not aware, the delays regarding the Berlin Airport are a running joke by now. And to add insult to injury, there are estimations that the new airport may already be too small to handle the projected number of flights to and from Berlin.

Just like the Therac-25[1] is used a a case study for proper software engineering, I'm positive the BER will be taught in engineering schools as a cautionary tale one day.

[1] [https://en.wikipedia.org/wiki/Therac-25](https://en.wikipedia.org/wiki/Therac-25)

<comment><USER7> Was it an engineering problem? Why would you teach this in engineering school? Looks like the project was hopelessly mismanagement, so likely above the heads of the engineers.

<comment><USER8> There are different opinions but most people don't think it was a engineering problem. From the beginning the project had three responsible managers with different interests: Klaus Wowereit (Governing Mayor of Berlin), Matthias Platzeck (Minister-President of Brandenburg) and Meinhard von Gerkan (famous Architect).

Meinhard von Gerkan published a book about the project, offering his view: Blackbox BER [1]

[1] [http://www.amazon.de/Black-Box-BER-Brandenburg- Gro%C3%9Fbaus...](http://www.amazon.de/Black-Box-BER-Brandenburg- Gro%C3%9Fbaustellen/dp/3869950609/ref=la_B001JOMZKO_1_1?s=books&ie=UTF8&qid=1433429865&sr=1-1)

</comment></comment></comment><comment><USER9> For you German speakers, this is a hilarious article (on the German answer to The Onion) about having to create a new verb tense in order to discuss the airport: [http://www.der-postillon.com/2012/08/neue-zeitform-futur- iii...](http://www.der-postillon.com/2012/08/neue-zeitform-futur-iii- eingefuhrt-um.html) (2012)

<comment><USER10> Wow. That's incredible. I'm not really literate enough in German to get that many of the jokes, but just the headline is awesome.

</comment></comment><comment><USER11> Ha! That's nothing. In Sweden we've been building a tunnel since 1992 and managed to create a poison scandal in the process.

Current estimates is that it will be completed this year.

[http://en.wikipedia.org/wiki/Hallands%C3%A5s_Tunnel](http://en.wikipedia.org/wiki/Hallands%C3%A5s_Tunnel)

<comment><USER12> We might've got you beat there... [http://en.wikipedia.org/wiki/Second_Avenue_Subway](http://en.wikipedia.org/wiki/Second_Avenue_Subway)

"The Second Avenue Subway has been a plan, and occasional construction project, since 1929. The reasons for the line's many false starts and delays are numerous and complex. The line is sometimes referred to as 'The Line That Time Forgot'."

<comment><USER13> In better news, Switzerland just announced the date for the opening of its biggest infrastructure project ever :)

[http://en.wikipedia.org/wiki/Gotthard_Base_Tunnel](http://en.wikipedia.org/wiki/Gotthard_Base_Tunnel)

edit: [https://news.ycombinator.com/item?id=9659697](https://news.ycombinator.com/item?id=9659697)

</comment></comment></comment><comment><USER14> The airport contributes to the overall image the rest of Germany has of Berlin: A subsidized place where politians hide and everybody else has an art (or nowadays startup) project going on and real work is only done when punks gather on May 1st to throw stones at the police.

</comment><comment><USER15> I quite like the site, having lived in Berlin for a little bit I am also aware of the fact the new airport is quite a discussion point... personally I will be sad to see Tegel go as it represents simple air travel which just worked (maybe just lucky for me)... Schonefeld was never that enjoyable in comparison, but meh, it's just a means to an end :-).

Also, I think many people who have setup buildings/shops in Berlin will tell you the regulations (especially ones around fire) are infuriating.

<comment><USER16> Tegel might be efficient once you know your way around, but god is it a confusing claustrophobic mess.

</comment></comment><comment><USER17> So they built the terminals with a novel smoke extraction system where the smoke extraction vents were placed on the floor rather than the ceiling, upon the final fire safety inspection the buildings didn't pass and given the complete integration of the system with the structure the only realistic option was to pretty much rip them down and start again.

<comment><USER18> "...novel smoke extraction system where the smoke extraction vents were placed on the floor": How does that make any sense whatsoever? Are there any links explaining how it's supposed to work?

</comment></comment><comment><USER19> This recent Econlog podcast has a good discussion of megaprojects and why they fail: [http://www.econtalk.org/archives/2015/05/bent_flyvbjerg.html](http://www.econtalk.org/archives/2015/05/bent_flyvbjerg.html)

</comment><comment><USER20> I thought Berlin has many airports (I remember Tegel and the other one). So this is another new one ? If yes, why is there a need for a new one :) For example Frankfurt has only one and it's capable much more than Berlin, because it's also a Hub for Lufthansa.

<comment><USER21> The two operating airports are tiny, Cold-War-era relics that aren't sized appropriately for a large city. FRA is probably 20 times the size of TXL in terms of footprint.

They also lack many modern conveniences that travelers expect. TXL has a Burger King, a convenience store, and maybe one working power outlet.

<comment><USER22> Traverls expect their airport to be like a kafkaesque mall that forces them to see all the possible wares they can purchases before getting out of it.

</comment></comment></comment><comment><USER23> Wasn't that airport supposed to be open in 2010?

<comment><USER2> When planning the project in 2000, the tentative opening was planned for 2007, but that was clearly too optimistic even if everything had been done properly. The attempt to actually open in 2012 was quite serious, and transfer from TXL was supposed to be just weeks away after the final acceptance round (which then failed spectacularly).

<comment><USER24> To corroborate its seriousness, I actually had a ticket issued to BER in 2012 that was changed to TXL about a month before the flight.

</comment></comment></comment><comment><USER25> Nein.</comment>


Stay away from rebase - <AUTHOR> http://geekblog.oneandoneis2.org/index.php/2013/04/30/please-stay-away-from-rebase <comment><USER2> The whole misunderstanding ``git-rebase mangles history'' revolves around the concept of history.

For me, history in DVCS should be about _logical_ changes that introduce given feature(s), fix bug(s) etc., and _not be_ about raw, unprocessed changes, _not be_ edition of `physical' bytes. Whenever I make a mistake in a commit (be it a typo, a small bug or perhaps I went in wrong direction and backtracked later on) I either _\--amend_ it, or, if it's an earlier commit, _git rebase --interactive_ to fix it.

In other words, ask yourself, ``Would this commit stand for a good LKML submission?'' Until it does, it's _\--amend_ or _git rebase --interactive_ time. Refactor history just as you refactor code ;-)

Of course, once the code is pushed to a shared repo, the genie is out of the bottle and there's no changing it. But that's a different matter.

What you want to do is:

      * 1) clean up history with git-pull --rebase, git-rebase --interactive and git commit --amend,
      * 2) then optionally perform git merge --no-ff --log --edit  $your_feature_branch while on $upstream_tracking_branch, to create a new, merge-ish commit that covers the whole new feature you've been working on.

This way you have:

      * clean history
      * logical, standalone commits
      * complex features introduced by a separate merge-ish commit (which you can git-rollback as whole, if need be).

My rule of thumb for the step 2) -- do it when there's three or more commits introducing a particular feature.

I perform the step 2) often enough to have created a short wrapper script for it [1].

[1] <https://gist.github.com/dexen/f36cb1668b5c04eb5abd>

[ lotsa small edits for cleanups -- sorry ^^; ]

<comment><USER3> Even the "don't rebase once code is pushed to a shared repo" thing is more of a guideline than a hard and fast rule. For example you might reasonably want to clean up the history on branches that you have previously:

* Pushed to a distributed test system * Pushed to a branch based code review tool (e.g. Opera Critic or Gerrit).

Using a heavily rebase-centric workflow for several years, with rebases on semi-public branches like those described above an expected part of the process, I don't think that history rewriting has ever caused me an actual problem. So my gut feeling is that people spend a lot of time trying to avoid something that sounds theoretically bad but isn't much of a problem in practice as long as some common sense is employed.

<comment><USER4> The intent is "don't rebase if you might have a downstream". You're welcome to rebase branches that you push as long as your workflow specifies that they are still volatile. For example, we push unfinished topic branches to our team repo as backup and to allow "passive review" (a pull request is "active review"). Comments at this stage are communicated by bitbucket line comments (or by email/chat) and are handled by amending the topic branch. This unmerged topic branch is rebased any time the author prefers to start from a later 'master' in exchange for re-testing the series.

When the topic is considered complete by the author, she either makes a pull request or merges to 'next' herself. Merging to 'next' signifies that another topic may depend on that branch.

In this workflow, an unmerged topic branch is roughly equivalent to a patch series on a mailing list, but doesn't require email client integration and degrades more gracefully with less disciplined commit factoring and less sophisticated tool use.

</comment></comment></comment><comment><USER5> Every complaint I've read about rebase is this same one, over and over, and I think it's based on a false premise.

> Rebasing destroys your history, and therefore destroys the point of using a > VCS.

The answer, of course, is _don't do that_. Don't rebase public branches, and that includes master and whatever else you're deploying from.

In any case, you _can't_ rebase master unless you're willing to force push, and if that hasn't tipped you off to the fact that you've gone off piste, what will?

> If you've got an entire history that's been heavily-rebased and your problem > is "This bug started happening on Tuesday last week", you have a big > problem: You can't just track back through your simple, linear branch until > you get to last Tuesday's commits.

This hypothetical scenario of last Tuesday's bug therefore makes no sense. You can do exactly that, because you don't rebase history: you rebase work in progress _onto_ the canonical record.

In summary, rewriting history would be bad, but that's not what rebase is used for.

<comment><USER6> Alas, "Stay away from rebase" will get more clicks than "Git-rebase caused me some problems and I should be more careful". I've found rebase essential in maintaining nice clean feature branches. Occasionally I run into issues, but I make sure I can back out of any changes even if it means copying the whole damn repo to somewhere else on disk.

<comment><USER5> git reflog will save you from any amount of rebase-induced chaos. Pick the last good point, reset --hard, and carry on.

</comment></comment></comment><comment><USER7> Stay away from rebase? What are you nuts?

What the hell is everyone doing working on master anyway?

Make your own working branch and merge it when it's ready. Don't mess with master if you're working with others.

If you are working on master (or merging to master, or doing something with master), merge and push right away, and if someone does something else upstream in-between, then rebase yours on top of it.

If you have local changes, and other people pushed changes to your upstream remote, first of all, you should have pulled _before making changes_ (you know that's usually the reason) which would have done a nice fast-forward merge with no merge commit. If your commits are just local anyway, _no one cares_ if you just rebase so it's cleaner! It's equivalent to having pulled first and then made changes. Exactly the same. No one wants to see an unnecessary merge commit anyway, that's just annoying.

All of this makes sense. Merge works, rebase works, sometimes they do the same thing, sometimes one's better, sometimes you should just not be dumb.

What's the problem? Geez, it's just git.

</comment><comment><USER8> I very strongly disagree with this post. But I should be clear that I also strongly disagree with the statement 'always use rebase!'.

Merge and rebase are two similar but distinct ways to update a branch in git. They are both appropriate at different times. A very good guide to sensible merge/rebase policy can be found here

<http://lwn.net/Articles/328436/>

(see also <http://lwn.net/Articles/328438/>)

I use rebase regularly. I always work on branches other than master, i.e. task and feature branches. I never rebase branches that are shared with other developers - development to these shared public branches is always just adding new commits to a stable history. Merging is important but rebasing is a wonderful tool.

With respect to the issue of timestamps, I did not know this and am very glad to learn it, you do have a problem here. My position would be that I would rather throw out the timestamp chronology than abandon rebase. Typically in my experience bugs can, and usually are, tracked against a particular commit, which solves this problem. However, I appreciate that this won't always be the case, but throwing out rebase for this is a high price for a moderate reward IMHO. :)

<comment><USER4> The timestamp thing is a red herring. Git tracks CommitDate and AuthorDate separately. CommitDate gets updated by default in a rebase. Use 'git rebase --ignore-date' to also update AuthorDate, though I like having both pieces of information.

<comment><USER8> Thanks Jed, that's great stuff.

For anyone else who wants to see this directly you can compare the two dates side by side with

git log --pretty=format:"%cd - %ad"

Where %cd is committer date and %ad is author date.

%cd is the value that resolves the op's bisect problem.

</comment></comment></comment><comment><USER9> The issue that I can't figure out, is how to deal with refactors, or more broadly, a codebase that changes. If my feature takes two weeks to develop, when I'm ready to merge, I'm applying my changes to a codebase that's two weeks newer than when I branched. For a merge to be not-painful, the master branch should stay reasonably steady. This, I think, creates a conservative, change-adverse culture, rather than a IMO superior "if it's wrong, fix it, fix it right and fix it now"-culture.

If I continuously rebase (and especially after a colleague emails saying he's pushed a big refactor), I can fix these things as and when they happen, and I can feed back to my colleague if something they've done works poorly with what I'm working on, and they can then address that while they still have the context of the rebase in working memory.

Finally, I think the history criticism is based on a too narrow view of history, as a single, linear reality. My code might have been weeks in the making, and while it's true I wrote that particular function on Monday, if I didn't push it until Thursday, it simply didn't exist in the world of my peers until then. Merging history so something I wrote on Monday appears as having existed on Monday, even though it didn't and couldn't affect the world until Thursday is also dishonest.

<comment><USER10> Try to continually merge in upstream changes when you're working on a long- term branch, to minimize the individual deltas.

<comment><USER11> This is exactly the best practice for feature branches.

</comment></comment></comment><comment><USER12> Hm... I think this post is rather myopic and very specific for the author's workflow.

> "This bug started happening on Tuesday last week" [...] If you aren't aware > of this and you start running your "git bisect" using your "good" base as > the last commit made on Monday last week [...]

Well, or you could find the first commit on Tuesday last week and start with its parent. Or, better yet, have "releases" tagged or at least have a log of deploys (timestamps, commits); what if I developed something on Sunday and pushed it to production on Tuesday?

> You only get the plethora of merges if you're using git wrong.

I've seen it in real-world codebases. Some people just don't know how to use git very well (either can't understand it, or don't try to), and produce ugly history. I agree that for "noobs" it's better to merge than to rebase (less opportunities for failure), but good developers should know there's a place for both `rebase` and `merge`.

> And you do have a problem, because not only are you writing crap code, but > you're committing it as well!

Well, one idea of git is to "commit early, commit often". It's much better to commit bugs and then commit fixes as well than to not commit and loose a bunch of code (due to a mistake or hardware failure).

I use rebase often. I should probably commit more often. Everyone has their own way, and we can all learn other ways and improve our work and life. But getting all angry and upset because someone uses rebase more often than you is an ineffective way to learn.

</comment><comment><USER13> >If you're consistently writing buggy code and rebasing to fix it, then you're coding badly. Don't fix the symptom by rebasing endlessly, figure out your problem. And you do have a problem, because not only are you writing crap code, but you're committing it as well!

>Look closer at your diffs. Write more unit tests. Run them more often. Whatever, figure out what you need to do to avoid routinely making bad commits.

I disagree with this. Git is fast enough that you can commit early and often - more often than you can afford to run unit tests, even. I find it very useful to be able to commit each minor change of direction; half my commits don't even compile (I also believe in using strong type systems and the "compile error tells me what I need to change next" approach). If I need a "clean" history for review or similar (though honestly I don't see why you would - just review the differences between the branch head and branch base) I can always squash those commits thanks to git's nice history-rewriting features.

<comment><USER14> > half my commits don't even compile

This sounds awful to me. This does not work especially if you are working in a continuous integration environment like Hudson or Jenkins.

<comment><USER13> I suspect I push working commits as often as anyone else - I just make a lot more local commits in between.

<comment><USER15> It'll still mess up CI, sadly.

<comment><USER16> No, it does not. CI never builds those broken commits because they never go outside of authors personal computer. Commit often, push when it's done and only push commits that work.

<comment><USER17> The only way they never go outside of the author's personal computer is if the author squashes (or discards!) them before pushing. Otherwise, they _will_ go outside of the author's personal computer.

However, they will never be a _head_ outside of the author's personal computer, because they are pushed along with later commits that fix the brokenness. CI only ever builds heads, so the existence of the broken commits doesn't matter.

<comment><USER15> Not all CI only builds heads. Some build and test all commits.

<comment><USER11> Well, then it will mark them fixed in HEAD then

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> Merge commits are more than just a cosmetic issue. If you have merge commits from pulling master into your working branch you have broken the relationship of the commits which you just merged into your branch from master. Once you merge your branch into master, these changes you pulled in will now appear to be changes that were part of your branch.

So say you have your branch, Sally's branch, and master. You create a branch from master, and then Sally merges her changes into master, and then you pull those changes in, when you merge your branch into master it will look like Sally's changes came from your branch. If something went wrong and you revert your merge all of Sally's changes get taken out of master. Yup.

Not being able to do a clean revert of all the changes is just one problem with pulling master into your branch, another problem is being able to tell just what in the hell you are about to push to production. If you have merge commits your change diff may include all kinds of stuff already deployed, in which case you have to do a manual diff of the code deployed and what's in master instead of just relying on what the merge commit tells you.

So please rebase.

<comment><USER17> What? No. If Sally has already merged her commits into master, then those commits will never look like they've come from your branch.

If i'm misunderstanding this, then a worked example would be a really great way of clarifying it.

<comment><USER18> I believe you are wrong. The merge commit would make it look like her changes were in your branch. Try it out with a new repository. Create a new repo. Add some commits. Create Sally's branch, add commits to her branch. Create your branch from master, add some commits to your branch. Merge Sally's branch into master. Merge the updated master into your branch. Add some commits to your branch. Merge your branch into master. Revert your merge, and see, Sally's changes are no longer in master.

</comment></comment></comment><comment><USER19> What is with these preachy headlines? "Why you should..." "Please use ..." "Please stay away from..."

It's very presumptuous to assume that you know the intricacies of thousands of developers' workflows well enough to tell them how to do thier jobs.

<comment><USER20> It developed originally as a fairly cynical way to make blogs posts stand out, but now everyone seems to be doing it. I hate it.

In fact, I might write a post on it: Why Your Post Titles Are Annoying and What You Can Do About It

<comment><USER21> I think a better title might be: "Your Titles Suck."

<comment><USER20> 7 Reasons Why Your Titles Suck

<comment><USER22> How I wrote a title that didn't suck, and saw my productivity increase 30%

<comment><USER16> With "Please, oh please use git pull --rebase" I didn't mean to preach but to convince some of the people I code with to maintain at least basics of a clean git history, thus the 'please' in title. I wrote it some time ago and only yesterday I was surprised at the sudden popularity of that post :)

<comment><USER20> Don't take it personally, it's more of a general observation that a problem with your post in particular

</comment></comment></comment></comment></comment></comment></comment><comment><USER23> > Rebasing destroys your history, and therefore destroys the point of using a > VCS.

I don't think this is true. Rebase, as the name suggests, simply rebase the starting point of your local history. It preserves your history better than that merge commit and having your series of commits intertwined with commits from other people implementing features not related to yours.

Rebasing also makes merging even easier, because now merging is done on a commit by commit granularity rather than branches. This also preserves the history better.

It's funny that the main rational for most people to use rebase is that it provides better history and this article is arguing that it does the exact opposite without carefully comparing the history in both scenarios. His only argument is that it's not "Real", but what we really care about is "clear" history, not necessarily whose commits come first.

</comment><comment><USER24> I was with the author until he/she got to the point of saying "bug started last tuesday". I don't know any serious development/testing teams that think like that, nor any developer that would search by day to find a bug.

Its much more likely to hear "the bug was in build 'x.y.z'" to which the next question is which build was green, and then bisect from there.

Searching for commits on tuesday because a tester happens to notice a bug on tuesday is a recipe for disaster... Or at least a completely wasted work day.

</comment><comment><USER25> Rebase is for cleaning up history. Merge is for introducing new features. Use the best tool for the job.

Always "git pull --rebase"; it is fast, easy, and meaningful. You can change the default configuration and probably should; same goes with other tools like emacs and vim.

Worried about date rearrangements? For those few situations where it is important, git log --since="$DATE_OF_LAST_TUESDAY".

<comment><USER26> Better yet, git log --since='last tuesday'. Try it.

<comment><USER25> I wanted to suggest that, but I couldn't get it to work on my repo. Might be my version.

</comment></comment></comment><comment><USER27> "If you've got an entire history that's been heavily-rebased and your problem is This bug started happening on Tuesday last week", you have a big problem: You can't just track back through your simple, linear branch until you get to last Tuesday's commits. You have to keep going back until you're absolutely certain there are no other commits further back in the history that are newer chronologically."

I think the author is mistaken. As mentioned by jedbrown, git has a separate AuthorDate and CommitDate, and rebase updates the CommitDate. You can see them both using:

        git log --format=fuller

Furthermore, when you use @-limiting to filter logs by date, the CommitDate is used. For example, if you have a bug that started last Thursday, you can show all the commits that were either written or rebased since then with:

        git log HEAD@{last.thusday}..

<comment><USER28> I think this is the most important bit because it makes the whole article fall apart (for my use case - code reviews).

Both my UI (Tower) and bitbucket sort by commit date. There is no way to sneak a broken commit into last week; for that I'd have to rebase master on top of the buggy commit.

</comment></comment><comment><USER16> Why would someone take one of the most important features of git (local history) and throw most of it away by abandoning ability to edit it?

If you pushed a broken commit push another fixing it, just like in merge-based workflow.

Having dates switched is not important, having four different branches on said Tuesday gives you a lot headache searching who introduced a bug. And git bisect won't help you. ;)

</comment><comment><USER29> As an experienced developer and a git noob, this article makes much more sense to me than the plea to use rebase all the time.

<comment><USER30> Rebase is a powerful tool, and with great power comes great responsibility. It's easy to get stuff wrong with rebase, and it's also hard for most developers to get their heads around because it offers something that no other VCS does. I'm also very much reminded of <http://tomayko.com/writings/the- thing-about-git>, except to extend it even further, most VCS will tell you "you should have not committed broken code or written a bad message" or "you should have cleaned up your patch before committing it." Git, on the other hand, is _extremely_ forgiving. I've lost count of the number of times I've gone off the rails and deleted a branch name or some other pointer to a commit in git, yet I could always pull it out (even if I had to resort to reflog). But enough about my shortcomings; why should you rebase?

I can think of two very good reasons to rebase: to cleanup a patchset before submitting it to a "central" repo, and to move your patch forward on top of another patch set (avoiding a merge). Often times, you might be working on something and get distracted, so you stash or commit and come back to it later. For whatever reason, you may have multiple commits that are conceptually related, but are separate. With git, it doesn't matter if these commits are one right after the other, or separated by other commits. You can rebase them into one commit that makes conceptual sense. If one commit reverts part (or all) of a previous commit, once you rebase and squash them together, the change and reversion cancel out so you don't get unnecessary twiddling of code in your commits.

The other time to rebase (that the article argues against doing all the time, which may have some merit), is when another repo you are pulling from has newer changes. So you've got your nifty new cleaned up commit, now you want to push it. But what's this? You can't push it because someone else beat you to it! No worries, you'll just merge. Hold on to that thought though: what's really happening here? Well, you want to put your changes on top of the changes from the repo you pulled from (and hopefully double check that they still build and the tests still finish successfully). Should this operation necessarily be called a "merge"? What if you just pretended that your commit had been based on the new stuff in the remote repo all along? That "pretending" can be accomplished with a rebase, and it also has the nice benefit of keeping your history clear of content-free "merging" messages.

So, when should you _not_ use rebase? Never on a public repo that others have pulled from. Even if you are exposing your own repo as a master and warn people that things could change radically at any time, it's still probably best if you clone a personal/private repo off that, do your rebases there, then push clean commits to the public repo.

</comment></comment><comment><USER31> This is a well-written article and it makes a compelling case, but it hand- waves away the benefits of a linear history by blaming the user for "doing it wrong" in some ill-defined way. The fact is even if you are doing it "right" with strict topic branches you still can get very hairy unbisectable conflicts that would be easier to reason about with a rebased history. Let's look at specific statements:

> _In our simple one-off examples above, this is no big deal. If you've got an > entire history that's been heavily-rebased and your problem is "This bug > started happening on Tuesday last week", you have a big problem: You can't > just track back through your simple, linear branch until you get to last > Tuesday's commits. You have to keep going back until you're absolutely > certain there are no other commits further back in the history that are > newer chronologically._

This has literally never come up for me in 5 years of using git because if you are looking at bugs that were introduced at a certain point of time you aren't looking at commit timestamps anyway. The important thing was when was the commit deployed (in the case of production bugs) or pulled (in the case of development bugs).

> _The whole reason to use a VCS is to have it record your history. Rebasing > destroys your history, and therefore destroys the point of using a VCS._

That is a complete non-sequitur. Rebasing doesn't destroy history, it rewrites it. It's no different from accepting a patch via email. Or writing down a ticket that your going to make x change then y change then z change. The fact is VCS is a tool. Git gives you incredible power to curate history, and understanding of how to use this power in the here and now can make for a more understandable future. Rebasing is potentially just an extension of not breaking the build by committing half a feature.

> _The "simple linear history" is a lie. The branched history might not be as > pretty, but it's an accurate representation of what happened._

A linear history has real mathematical benefits that I wrote about at <http://darwinweb.net/articles/the-case-for-git-rebase>. In practice I've done things both with a topic-branch orientation and a rebase-to-master orientation, and I understand both intimately, and a rebased linear history does not destroy nearly as much information as this article would have you believe. You can still see when a commit was written in addition to when it was rebased which provides most of the value of seeing the whole branch structure (which incidentally is not a magic oracle into the developer's mindset either—there is always out-of-band information).

The idea that the git tree be immediately frozen and never-changing after every single commit is an unnecesarily rigid perspective. It works perfectly well in practice to imagine rebasing as the developer having implemented their topic branch instantaneously based on the current state, and resolving conflicts on a commit-by-commit basis rather than accumulating them into one opaque merge commit.

> _It's so tempting to stay on master, to think "It's just a quick fix, it's > not worth branching for!"_

You can have your cake and eat it too. Just do `git branch new_topic; git reset --hard origin/master`. There's no reason to branch prematurely because there's nothing to stop you from branching any time. This is the thing about _distributed_ version control, and git in particular, you do whatever makes sense locally and you don't need to care at all what anyone else is doing until you fetch.

> _Because if you keep your work on the main branch and you frequently commit > bad code, then the day will come when you hit the absolute no-no of > rebasing: You'll push a bad commit to a remote, and then you'll be stuck > because you absolutely must not rebase published history._

In that case you simply push your fix. Why does a rebase-based workflow lead this to be a catastrophe? It doesn't matter what workflow you are using, you will push a bug eventually, then you will fix it.

> _The best thing that could happen to rebase is that it gets relegated to > "power tool that you don't find out about until you're a git wizard" because > far too many people use it as a crutch to support their ability to use git > without understanding it._

I'll agree here, you shouldn't use rebase if you don't know what you're doing with git. New users should definitely be forced to work entirely with merge and possibly --no-ff to get the basics of how git works. Rebasing is a power user feature, but it's not difficult to understand if you understand git fundamentals. That is if you understand commits and trees and branches, if you don't then it's way too sharp a tool.

> _If you use rebase more than once a week, I maintain that you have a > problem. It might be hard to spot, it might be rough on your ego, but that's > my opinion._

Rebasing is just a tool. Maybe someone likes to commit every file and then curate with rebase -i, who are you to tell them their doing it wrong? You certainly haven't demonstrated that with a bunch of strawman arguments about committing buggy code or that direct collaboration on a feature should axiomatically happen via pairing vs any other method. All of this is just a distraction to the core questions: what are the pros and cons of rebasing? What history is destroyed by rebasing? What are the advantages of branched history vs linear history?

<comment><AUTHOR> > This has literally never come up for me in 5 years of using git

I get the impression that, unlike the article's intended audience, you know git well enough to not need to follow its advice. When giving advice, you have to aim at the expected level of understanding. That can easily lead to examples that frustrate people with a higher level of understanding, because they seem to over-simplify.

In this case, you're taking me too literally - I was trying to give quick & simple examples for a complex issue. It's just an illustration of how "simple linear history" is a non-sequitur - you now have to factor in that a specific commit could very easily have been made _after_ a commit that comes _after_ it in the history. You're moving complexity around, not reducing it.

> Rebasing doesn't destroy history, it rewrites it.

Rewriting _is_ destroying.

Worse, it's lying - it's saying "These commits were made in this order" when they weren't.

> Why does a rebase-based workflow lead this to be a catastrophe?

It doesn't. You've ignored the context - which was of someone who wants his commits to be de-bugged and habitually uses rebase to do so.

> you shouldn't use rebase if you don't know what you're doing with git

That was kind of my point - people are using rebase _instead of_ learning to use git. And should therefore be advised to stay away from it until they _have_ got the fundamentals down.

> All of this is just a distraction to the core questions:

Sorry, those might be _your_ core questions but they weren't mine: I was writing specifically to counter the suggestion that rebase should be heavily- used by people who don't really understand its ramifications.

<comment><USER32> Rebase is not a lie, it is the developer _explicitly putting commits in this order_.

Best practice certainly depends on your environment. In small projects, let's say two/three devs working with a couple dozen tightly-coupled files (like HTML/CSS/JS), you have to keep up with changes frequently; that means pulling all the time, otherwise you'll always have monster conflicts to solve. That 'tiny window of opportunity' when someone else has pushed and you have changes is _all the time_. In a codebase where you can happily work on an isolated feature for a week, things are different.

<comment><USER33> And you'll ultimately have to decide whether you want your codebase to represent a series of physical commits, bits that people happened to type out... or whether it should represent a series of logical changes to the codebase.

But git and git-rebase were explicitly designed to make the "series of logical changes" easier, because it was designed for Linux kernel development, and they _like_ series of logical, meaningful changes over there because it assists in understanding the changes which are being integrated.

Now, I'm sure there's some business case where the series-of-physical-changes sequence is more important to someone. I don't personally agree that's the best way to program in general, but not everyone's compelled to agree with me. And in that case, don't use rebase.

<comment><USER34> > And you'll ultimately have to decide whether you want your codebase to > represent a series of physical commits, bits that people happened to type > out... or whether it should represent a series of logical changes to the > codebase

We're on the same page here, but there's a bit of a deeper point being hinted at, which is that being able to be "physical-series-of-commits" is _useful_ when you're in experimenting-dev/refactor mode, and _isn't useful at all_ for people trying to understand your history. Well, mine's not at least -- it's a lot of shitty diffs and "fuck shit checkpoint" commits that don't live long.

Logical history is basically always useful, but you often want temporary checkpoints for yourself before your changes are going to coalesce into something that represents a logical patch-set.

Rebase, in it's most commonly useful ... use case, lets you tack new incoming history that other people have shared onto history you haven't shared yet. For the people other than you, your changes exist in the future.

History rewriting in general lets you fuck around locally with stuff you haven't shared, making trashy checkpoint commits or whatever you want to do, and clean that all up to represent a logical series of changes for sharing.

In short:

Don't work on tracking branches. Branches are cheap.

Periodically bring in others changes into your work with rebase. Your work isn't public and theirs is, theirs is part of public history, yours is part of future history. Always rebase before bringing your changes back into the tracking branch, and then merge your changes into the tracking branch. Often, the history cleanup I want to do is handled by merge --squash, bundling up the change I'm pushing as one commit.

You, whoever is looking at my incoming change, care about the fix for bug FOO or feature BAR being completed. You don't care that I made a bunch of stupid typos. If you do, I don't want to work for you unless you care because your doing some sort of awesome stat analysis on typos made by people like me.

</comment></comment></comment></comment></comment><comment><USER35> No no no. Rebase is an important tool that should be used for cleaning up pre- pushed history, and should be avoided on commits pushed to branches that other people pull from.

</comment><comment><USER36> This article is pretty much the correct response to the pull --rebase discussions. No need for it -- you should be using a branch.

But I'm not sold on no rebase at all: a common workflow for me is commit often while getting something working, then rebase 4 or 5 commits into a presentable unit (using magit). I have to admit I hadn't noticed that the timestamps were preserved by rebase. And there doesn't seem to be a rebase option that tells git to create new timestamps with chronological order matching the new commit order? I could use `filter-branch`, but it seems heavyweight.

One other criticism of the article:

> A soft reset back to origin's HEAD, and then re-commit your work

That leads to errors: if you've added new files, you may very well forget to add the same set again after the soft reset.

<comment><USER37> I think you want `--ignore-date`, The man pages are very confusing about such things (in fact there is a minor documentation error in the current documentation on Debian Wheezy).

My concern with using a soft reset mirrors yours, but I would also like to add that it is effectively doing a manual rebase (albeit with different semantics around date) so it seemed rather odd in an article arguing against rebase.

<comment><USER36> Thanks. However `--ignore-date` is incompatible with `--interactive`. I should have said in my description above "rebase --interactive 4 or 5 commits into a presentable unit".

</comment></comment></comment><comment><USER38> If people are still struggling with this, I can recommend looking into the git flow model. You can read more here: <http://nvie.com/posts/a-successful-git- branching-model/>

</comment><comment><USER39> Please, stay away from not using caching with static websites.

<comment><AUTHOR> Yeah, that's on my todo list

<comment><USER40> Better put it on your 'done' list.

</comment></comment></comment><comment><USER41> "please understand wtf you're doing" "please read the docs" sums both articles up ;-)

if you don't get what its doing underneath, you'll never get it right. yes, effort is needed.

</comment><comment><USER42> I've found that when teaching people Git, the most important thing is that they understand the state of their DAG, since that is at the core of everything we do in Git. A confusing DAG full of unnecessary merge commits is much worse for a beginner than exposing them to rebase.

Git lends itself as a development tool as well as a version tracker, and rebase is an important part of that for both beginners and experts.

</comment><comment><USER43> To rebase or not is a religious war. Also on HN today/yesterday: \- git pull --rebase until it hurts: [http://jrb.tumblr.com/post/49248876242/git-pull- rebase-until...](http://jrb.tumblr.com/post/49248876242/git-pull-rebase-until- it-hurts) \- Please, oh please, use git pull --rebase <https://coderwall.com/p/7aymfa> I've seen a ton of posts like this on both sides.

The non-chronological history is unfortunate. In practice, when `git pull --rebase`ing several times per day the way we do, commits will only end up a few minutes out of order, which won't affect queries like `git log --since=1.week.ago`.

One of the things we optimize for is early integration. I conceptually like his recommendation, but I think it'd slow us down since we're always depending on each others' commits.

> Don't fix the symptom by rebasing endlessly, figure out your problem. And > you do have a problem, because not only are you writing crap code, but > you're committing it as well!

Translation: make sure your code is perfect before you commit. That's ridiculous.

> You really, really need to collaborate in real-time with another dev. and so > must share all your code? At this point you're pair-programing - maybe look > up GNU screen & its 'acladd' command to allow you to share a terminal with > your collaborator. Or just tell each other when you're about to commit.

False and ridiculous.

I am a fan of heavily rebasing non-public history. Non-public obviously meaning local branches, but also, a loose definition for us is a public branch that you own and are confident no one else is working on. (If GitHub let us fork private repos without counting against our private repo limit, we could have true private remote branches). Sometimes I commit things very cleanly, creating separate commits for each concern, and sometimes I don't. When I don't, I'll often do a quick interactive rebase to re-group changes into logical commits–the purpose being a clean history that makes it easy to read/revert/cherry-pick/bisect specific, individual changes.

So there are pros and cons to both philosophies - it just depends on what you're optimizing for. This guy is writing in support of his particular needs, but makes the mistake of asserting they are the best or only.

Also, I think a future version of git could address the non-chronological history issue, which was the only con I'm aware of.

</comment><comment><USER44> For me the posts arguing in favour of using rebase explain why much more clearly than the posts favouring avoiding using it.

</comment><comment><USER45> Rebuttal: why not use tags to identify your major revisions and feature work? This way your bisect is rooted on feature releases or versions, rather than relying on git log --since.

It appears the time aspect is the primary argument presented, and I wouldn't consider using a workflow that didn't tag revisions, so I don't consider that an issue.

</comment><comment> klj613-- Please use rebase... but only if you understand it!

Do not commit to your commits...

I experiment on branches... I use commits as stashes... I end up with 100s of local branches...

-

Only rebase non-shared commits.

Normally people say "dont rebase pushed branches" but what if you merged your local branch into a different branch which is pushed? them commits are already shared...

Then again.. I would rebase branch X but because branch Y was branched off X I also rebase branch Y onto the new X.

-

I even rebase pushed branches, because they are _my_ branches.

-

To those who say rebase is a "lie".. I say don't commit to your commits... do you commit each time you hit the keyboard? well that is history which _could_ be captured for the sake of useless history...

-

Before merging cleanup your branch so it is clear what the branch is doing and add in more useful commit messages (use the body of the message, not just the subject).

-

Do you end up with a load of local changes which are hard to give clear commit messages to? so you end up doing "git add ." instead? then you should be committing more often.

</comment><comment><USER46> > Error establishing a database connection! > (mysql_connect(): User > oneandon_oneone2 already has more than 'max_user_connections' active > connections)

I wonder why you have a website that needs mysql to render, and why you appear to be leaking the connections...

This problem was solved ages ago by the likes of CityDesk.

<comment><USER47> it's probably a wordpress blog

<comment><USER48> Nope, it's b2evolution[1]. There is a meta comment at the top of the page:

        <meta name="generator" content="b2evolution 4.1.6" />

I looked for all the common wordpress signs and didn't see them in the html. EDIT: also, there is a "Credits: blogging software" at the bottom of the page that links to [1].

[1] <http://b2evolution.net/>

</comment></comment></comment><comment><USER49> Mirror: [https://gist.github.com/anonymous/5488616/raw/019c5fbfad1c16...](https://gist.github.com/anonymous/5488616/raw/019c5fbfad1c1616ff863634316c103c5a621721/gistfile1.txt)

Anyone know how to make gist do word wrap with textfiles?

<comment><USER50> Thanks for the mirror. Not sure of the answer to your question, but pastebin wraps <http://pastebin.com/tBXZ7DDU>

</comment></comment><comment><USER51> Giving tech recommendation while using the deprecated since several years mysql extension is funny, if nothing else.

<comment><USER52> Ad hominems generally are nothing else..

</comment></comment><comment><USER53> I learned it as rebase on branch, merge to master. Is it too much to assume, this being git with it's focus on branches, that what the original pro-rebase article was espousing was to rebase on branches so the merge back to the parent was cleaner? What am I missing here?

</comment><comment><USER54> As someone that has used for years but never in a team settings it amazes me what I don't know about using git to its fullest. Were would one start to learn about proper use of git in a team setting... just in case I it ever happens.

</comment><comment><USER55> the use of rebasing is simple: You have contributors and one committer. The committer is also a developer whose branch can have changes anytime. The contributors must rebase on committer's main branch so that the committer can do a fast forward, clean merge when the time to merge comes.

Clean upstream merge is important, since you have multiple committer's who are contributors to a bigger branch. The hierarchy goes on and on until the top (e.g. linus torvalds). So rebases are a way of achieving clean upstream merges, and it becomes more important when you have many levels of hierarchy.

</comment><comment><USER56> gosh now I know even less about rebase than I did before, which was nothing...

</comment><comment><USER34> "Do whatever the hell you want with your git repo until it's public, at which point continue, but don't rewrite public history".

</comment><comment><USER57> This is Hacker News at it's finest. One post says use rebase, the next post says don't.

</comment><comment><USER58> Do people not know about git merge --no-ff?

</comment><comment><USER59> Please, stay away from MySQL

</comment><comment><USER60> I totally agree rebase is not needed, and used incorrectly a lot of the time.

</comment><comment><USER61> I avoid frequent merging this way: 1\. Make my changes. 2\. try git pull, if succeeded - no merges needed, no merge in history. 3\. Commit changes. 4\. git push.

</comment><comment><USER62> Can't agree more. I never use rebase; the author's contention that using rebase is a sign that you've f@cked something up is spot on.

</comment><comment><USER63> There's an elephant in the room that he missed.

Rebase breaks bisect.

If you have a sequence of patches, wherein each patch compiles cleanly, and you merge it with another sequence of patches, you _still_ have a sequence of patches that compiles cleanly.

If however you _rebase_ your sequence of patches onto another sequence, and this introduces build errors (not uncommon), bisect _no longer works_ on this segment of history, _even after_ you fix the build issues with a final "cleanup" patch.

Rebase destroys semantic history. Merge preserves it.

EDIT: whomever downvoted me, care to explain what's wrong with my reasoning?

<comment><USER64> "If however you rebase your sequence of patches onto another sequence, and this introduces build errors (not uncommon), bisect no longer works on this segment of history, even after you fix the build issues with a final "cleanup" patch."

Well, not if the cleanup patch goes at the end of that sequence rather than the beginning. Guess what tool you can use to change that.

I don't really see how introducing a breaking change in a merge commit rather than a rebase fixes anything. In any case, you should squash, build locally, and fix before merging to master anyway.

<comment><USER63> _Well, not if the cleanup patch goes at the end of that sequence rather than the beginning._

That's what I meant by a "final cleanup patch". However this is not an issue that any sequencing of such patches can fix:

Without rebase, every patch has an implicit implication that if it builds cleanly when applied to its parent, it builds cleanly no matter what other patches are merged into the tree in the future.

Once you start rebasing, you _lose_ that guarantee unless you edit the patches themselves: there's _no guarantee_ that just because sequences A-B-C, A-D and A-D-E each build, that A-B-C-D will build. Hence bisect (which may need to build A-B-C-D) breaks.

<comment><USER64> The thing is, when you rebase, you don't _have_ A-B-C-D at all. If you have A-B-C and A-D and you rebase A-D onto A-B-C, you actually have A-B-C and A-B- C-D', where D' is the same _diff_ as D, but it's a different _revision_. And when you build, you may find that D' doesn't work when D did.

Merging doesn't even help, because if you merge A-D to A-B-C, you end up with:

      A-B-C-M
       \_D_/

at which point M would be broken in the same cases where D' would be broken.

<comment><USER63> The point is _M contains the fixes required to make A-B-C plus A-D build_. Then you have _no histories in that tree that don't compile_.

Like you said, A-B-C-D' DOESN'T build, PRECISCELY because _D' is the same diff as D_. You need to make A-B-C-D'-M to get a working build, but the history A-B-C-D' is STILL BROKEN.

<comment><USER64> So you run a build on D', make the necessary fixes, and amend it. Which is exactly what you would have had to do with M anyway, or else M wouldn't build either. I don't see any difference at all.

Merge commits don't magically fix broken builds. All they do is ensure that you've resolved merge conflicts, but rebases do the same thing!</comment></comment></comment></comment></comment></comment>


2009, SF is the worst run big city, has anything changed? - <AUTHOR> http://www.sfweekly.com/2009-12-16/news/the-worst-run-big-city-in-the-u-s/ I read this a while back and was reminded by another post on SF public transport today. HN community, has anything changed? <comment><USER2> Please don't editorialize titles, as the HN guidelines say.

<comment><AUTHOR> Thanks for the tip, I don't think I can change it now (correct me if I'm wrong), and will keep this in mind for future submissions.</comment></comment>


The IRS is paying Equifax millions for a login system that's been hacked twice - <AUTHOR> https://qz.com/1094442/equifax-efx-built-the-irss-login-system-that-was-hacked-in-2015-and-the-irs-just-renewed-its-contract/ <comment><USER2> > _The system, known as Knowledge-Based Authentication, or KBA, asks questions > based on a person's credit history, such as "On which of the following > streets have you lived?" or "What is your total scheduled monthly mortgage > payment?"_

So it authenticates you based on facts that can't be changed, and are either publicly-available knowledge or easily discoverable with some lite social engineering?

</comment><comment><USER3> Boggles the mind.</comment>


Ask HN: YC send rejection letters to those who applied after deadline? - <AUTHOR>

Hi, I was wondering if Y Combinator sends rejection letters to all startups who are not called up for an interview, including those who applied after deadline? <comment><USER2> They do, at least I remember reading this. Give them time. They're still considering the applications that were on time.</comment>


Has the notion of "files" outlived its usefulness? - <AUTHOR> http://www.25hoursaday.com/weblog/2012/06/30/HasTheNotionOfFilesOutlivedItsUsefulness.aspx <comment><USER2> Someone who doesn't understand what he's talking about telling everyone that we don't need X because the future is the cloud and the cloud is just so different.

Yup... another day on HN.

<comment><AUTHOR> Who are you talking about?

The article posted here is about why we _do_ need files, as is the article this is a reaction to (the filepicker.io post).

</comment></comment><comment><USER3> Money quote:

"Have files outlived their usefulness? Only if you think reusing data across multiple applications has."

<comment><USER4> Won't the applications be files anyway?

</comment></comment><comment><USER5> If files could package and pass around metadata in the same way they pass around data, I might agree with Dare's conclusion. However, for me, metadata is becoming too important and has destroyed the utility of files (and pure data) being truly useful.

Example: Photos. The file is the photo. However, think of all the things besides that: face tags, text tags, album, ratings, etc. If you've ever tried to import 5GB of photos from iPhoto to Picasa (or vice-versa) you'll understand what I mean.

This is why "stuff in the cloud" is so useful: API support is there from day 1 so that you always know what CAN be exported and how.

<comment><USER6> "If files could package and pass around metadata in the same way they pass around data"

They can. It's all just bits. If your files don't and your API does, it is simply because your files don't and your API does, not because files can't and APIs can. Files can have metadata and APIs can be written that treat things as blobs.

There is a distinction, but it's not API vs. file, it's what semantic context you're in. Your MP3 player reads out the ID3 tags, because it's in a music player context. Your backing cloud store (like Dropbox) just sees blobs. Interoperability is less about agreeing on file formats than agreeing on semantic contexts. (Yes, file formats are important but they come later, and most arguments about them are actually arguments about semantic contexts.)

<comment><USER5> Saying "it's all bits" is too simplistic a view of file formats vs. APIs. I'm thrilled that MP3 files have ID3 tags, unfortunately that's an unacceptably small subset of the meta-data that I care about.

File formats evolve at a glacial pace and suffer from immense historical baggage. No one benefits from pretending that file formats are as accessible, agile or powerful as proper web APIs.

<comment><USER7> What are you even talking about? You'd rather use a fucking web API than your local pc when dealing with FILES?!

You are everything that is wrong with modern computing. A web API is always inferior to what you can do natively.

<comment><USER8> Strike the trendy "web" qualifier, and I'd argue we still have a problem, namely that "data" tends to outlive "behavior" by many, many years, and this fact is important and useful in both computing and civilization at large. This is why, in theory at least, relational data stores are more promising "trans- filesystem" candidates than either method-based object systems or "APIs". Hierarchy is inessential; data storage is not.

To say nothing of the fact that "APIs", Web or otherwise, _aren't actually a means of storing data_ ; at least in the context of things like "pictures" and "music", we obviously can never have "turtles all the way down."

</comment></comment></comment></comment></comment><comment><USER9> It seems to me that any system or API you imagine or make up that associates a particular stream of bits with some sort of identifier is pretty much a file system.

</comment><comment><USER10> No.

</comment><comment><USER11> Files will never go away. It all depends on the abstraction level that you view the term 'file'. Humans are files, a self contained unit of information (with built in copy semantics!) they have meta data (hair color, eye color, height, age etc). My point is that there will always be a container object of a sequence of bytes of data. Whether that's an mp3 file or a hummingbird, they are still files.

A more meaningful question might be to challenge the notion of a hierarchical file system. The web has managed fine without one, so possibly search across a flat collection is a better metaphor. There are numerous others.

There are, however, interesting possibilities that make files less conspicuous, apple are experimenting with this, where there are pipes between apps, I open a photo, send it to snapseed, pipe it on to tumblr. At no point am I confronted with a file save dialog. Obviously it's a file under the covers, but that's just an abstraction. Files themselves are abstractions. There's really no such thing as an mp3 file, it's just a sequence of bytes we can interpret as one.</comment>


The low-down on home routers – how to buy, what to avoid - <AUTHOR> http://esr.ibiblio.org/?p=8330 <comment><USER2> Kind of missing any discussion of options like pfSense, or the other fancy BSD powered options. The discussed routers are the sort of options I would look at for buying for a non-techy family member, where I log in and update the firmware for them once or twice a year. But for people looking for a little more power and / or configurability, just pick up a little low power AMD x86 box and put some real firewall software on it. Add a little Ubiquiti access point and you've got a great, solid setup.

I went with one of these: [https://pcengines.ch/apu2.htm](https://pcengines.ch/apu2.htm)

<comment><USER3> I keep hearing this, but does Ubiquiti actually provide good speeds?

I got an Asus AC 5300, it works great. I can get 450 Mbps downloads and uploads easily, and get good coverage.

I've also installed the Linksys Velop mesh system for a number of people now, and I can crank out similar speeds with that.

The speed ratings I have seen for the Ubiquiti products are half that, at best.

Here's another thread which mentions this issue: [https://community.ubnt.com/t5/UniFi-Wireless/UniFi-AP-AC- LR-...](https://community.ubnt.com/t5/UniFi-Wireless/UniFi-AP-AC-LR-maximum- speed/td-p/1901054)

<comment><USER4> Here is an explanation for expected throughput of various WiFi standards [https://www.speedguide.net/faq/what-is-the-actual-real- life-...](https://www.speedguide.net/faq/what-is-the-actual-real-life-speed- of-wireless-374)

The Unifi product line works well for environments where non-network savy people are involved. I've installed them in a number of non-profits, my relative and friends homes with great success. By success, I get no questions or complaints about WiFi coverage or access. Ubiquiti has done a pretty incredible job of making multiple AP setup and management easy for a low price.

For people who want a router + APs, I recommend the USG Gateway, Unifi Cloud Key, and one or more AP-AC-Lite's. As an alternative to the USG Gateway, I use Ubiquiti Edgerouter POE's or ER-X's.

I've used a USG myself, but may switch to a pfsense router as the USG lacks some advanced features that aren't available in the USG.

Background: In the 90's I built my own firewalls, then moved to SG300's from an Australian company that eventually got purchased by McAfee (I think?), then to DD-WRT on WRT54G's, then Tomato, then Asuswrt-Merlin, and then to the USG. Why not continue on the opensource route? I just wanted a firewall that worked and was easy to maintain. The Ubiquiti Edge Router and Unifi Security Gateway met most of my requirements and I've been satisfied. I'm happy to answer any questions.

<comment><USER3> Thanks for the review of Ubiquiti in general. I'm still not sure I see a great use case, however.

If the customer can get away with a single wifi router (eg. Asus AC 5300) that will generally be easiest for them to manage (eg. easy to reset if necessary, no concern that older devices are connecting to the wrong access point). It also gives very strong download speeds (around 450Mbps for a gigabit connection).

If the customer needs multiple devices the Linksys Mesh system has worked very well. I can connect the nodes to each other wired or wirelessly, and I can get speeds in a similar range as a single router (450Mbps). The Linksys app is dead simple to setup and restart the system, and clients have even been able to apply firmware updates from their phone without issue.

I don't consider the Ubiquiti software easy to use for general consumers, so I would only install their products if I was planning to fully manage the network for them, i.e. they would have to call me in the event that the power went out and the system didn't come back up correctly or something.

Regardless of ease-of-use, I am more concerned about the speed. It seems like the Ubiquiti access point I have installed top out around 200 Mbps, so I don't even want to use them for my own house.

My guess was that the Ubiquiti devices were designed for use in an office setting, where making sure that everyone can connect is more important than enabling the fastest speed for say 5-10 devices.

</comment></comment></comment></comment><comment><USER5> >If I needed a new router today (I don't, I have a couple of cold spares) I'd trawl e-Bay for a one-generation-back commodity router on the OpenWRT support list that does have 4GB+ flash and 32GB+RAM and doesn't have a &$@*$! Broadcomm chip in it, buy it, and flash OpenWRTs latest stable release.

This is the blogpost in a nutshell. Save yourself some time.

<comment><USER6> Why does someone need 32G of Ram for home router?

Is it a typo?

<comment><USER7> The blogpost says MB, not GB.

<comment><USER8> You are both right. Based on a comment, GB was a early typo that was then corrected to MB.

</comment></comment></comment></comment><comment><USER9> I have a different recommendation. Now that WiFi standards have stopped evolving so fast, used commercial-grade WiFi access points are a fantastic deal. I replaced AirPort Extreme with a pair of used Ruckus R600s. (They're AP's so you need a separate router. I use a Linux server as an access point, which allows using the CAKE packet scheduler at > 1 gbps.) They are $150-200 on eBay. The Airport is great, but gets a bit squirrely when your internet connection can deliver packets faster than the WiFi can offload them. With the R600, same-room performance stayed the same, but off-axis performance improved dramatically. In the bedroom right above the access point, I used to get 100 Mbps or so. Swapping out the R600 raised that to 300 Mbps. (The Ruckus has some cool directional antenna technology.)

</comment><comment><USER10> I have an Ubiquiti ER-6P. I'm pretty pleased with it. The newest OS is based on Debian stretch and it has generous ram, cpu, and storage (for a router).

The web gui is pretty nice, I can ssh (openssh not dropbear) into it (even with a ssh key), and there's a command line available if I need it. The security updates come out often, Ubiquiti seem responsive to the community, and the upgrade procedure is sane.

Ubiquiti allow backing up the entire state of the router, in a human friendly configuration format that's easy to hand edit.

They offer full IPv6, radvd, and sanely handling a IPV6 /60 from Comcast and providing each router port with it's own /64\. Simple stuff I know, but often missing in home routers. Similar was quite complex or broken on DDwrt and OpenWRT, in a previous iteration of home router I actually had to steal pieces for both to get things working with IPv6. The main problem is there was an issue with a compatible IPv6 dhcp client to accept the /60 from Comcast. Additionally I had to use a binary blob to get some of the most of my previous Asus router.

I've built a router from scratch before, but the Ubiquiti hardware is silent, well done, and their debian based OS makes all the normal router stuff easy. And my favorite feature is the ability to use apt for package management.

I've never had a crash, currently it's been up only 65 days because of a power outage.

</comment><comment><USER11> Would just like to put the Orange Pi out there: wielding 2 Ethernet ports, WiFi and other creature comforts for < $20 USD [1]. It's more than adequate for running as a Pi Hole [2] as well as having enough left over to do other interesting tasks. Would recommend from personal experience some form of cooling is you plan to really push it.

[1] [http://linuxgizmos.com/tiny-hacker-board-features-dual- ether...](http://linuxgizmos.com/tiny-hacker-board-features-dual-ethernet- and-a-13-90-price/)

[2] [https://pi-hole.net/](https://pi-hole.net/)

</comment><comment><USER12> I use this router: [https://www.turris.cz/en/omnia/](https://www.turris.cz/en/omnia/) and I am quite pleased with it.

</comment><comment><USER13> Not totally relevant, but if you have AT&T Gigafiber (and you don't have TV or landline phone service), you can actually bypass AT&T's god-awful router by getting an UBNT EdgeRouter or USG and setting up eap_proxy [0].

[0] [https://github.com/jaysoffian/eap_proxy/](https://github.com/jaysoffian/eap_proxy/)

</comment><comment><USER14> One commercial alternative I can recommend are AVM products, somewhat popular in Europe (AVM is German).

Good hardware, frequently with open alternatives.

I currently use Fritz 4040 with 1Gbps fiber, with original firmware, works like a charm.

Excellent wifi.

<comment><AUTHOR> Fritz!Box 7490 here, I love it to pieces. Best router I ever owned. But I agree that the admin interface is a bit too simplified and doesn't allow for any advanced configuration.

<comment><USER15> 5490 owner here. I feel like a bit of a dangus for asking this, but have you checked that you are in fact currently using the "advanced view" option? I was disappointed with the configurability as well until I discovered that option.

</comment></comment></comment><comment><USER16> Is there any opinion here about Apple's routers (airport express, airport extreme)?

They have discontinued the product line but software updates have continued and they say they will be supported for a while.

Are they safe to use, in the context of this blog post?

<comment><USER17> I had a few Airport Extreme and Express in the past and I think they are awesome and under rated. They were rock solid. Never had an issue with them and they always performed great. I also trust Apple to do the right thing in terms of security.

</comment></comment><comment><USER18> > If I needed a new router today I'd trawl e-Bay for a one-generation-back > commodity router on the OpenWRT support list that does have 4GB+ flash and > 32GB+RAM

You'd need to look hard to find a router with such specs.

</comment><comment><USER19> Just bought a Mikrotik router. Can't wait to get it home and start tinkering.

<comment><USER10> I've heard of Mikrotik, seemed popular with SysAdmin types, at least until they were widely targeted by some malicious folks looking to compromise SysAdmins to exploit the networks they manage.

Found one of many mentions (sorry for the long URL): [https://www.trendmicro.com/vinfo/us/security/news/cybercrime...](https://www.trendmicro.com/vinfo/us/security/news/cybercrime- and-digital-threats/over-200-000-mikrotik-routers-compromised-in- cryptojacking-campaign)

I heard something about software limiting the routers, so you had to pay for license upgrades to get full functionality out of their routers. Any truth to that?

<comment><USER20> The amount of security weaknesses in Mikrotik is low and they get immediately patched. Those guys do excellent software updates and there are tons of resources to get help at.

Regarding the pay for a license to get the full functionality. There is no chance a home or ordinary office user will ever hit any limitations within a stock license. The upgrade might be needed only for the ultimate stuff in realm of BGP tunnels and stuff alike.</comment></comment></comment>


Southwest Airlines grounds flights due to computer outage - <AUTHOR> http://www.ktvu.com/news/news/national/southwest-airlines-grounds-flights-due-computer-ou/nYR3n/

<comment><USER2> I would really hate to be the developer/sysadmin who potentially struck the fatal blow to their system(s). Its one thing in a business if people can't get email/work with some crm type tool. Its another thing entirely when thousands of people are stranded at airports.

Good luck to those poor souls working triage right now. Even if it wasn't you're fault they are gonna have someones head.

<comment><USER3> If it's any consolation, often in these sort of large scale outages at least part of the cause is management pushing back on recommendations by the IT staff.

</comment></comment><comment><USER4> Man I always underestimate the reach and extent of software, especially in enterprise. It really _is_ everywhere.

As an aside, does anyone know if such things like ticketing systems are developed in house or are outsourced to places like, say, IBM?

<comment><USER5> I worked for Southwest as recently as last year.

In the industry, ALL reservation and ticketing systems are written by specialists. The major players are Sabre ( think IBM ) / Navitaire / ITA ( which was bought by Google not too long ago ). Southwest is a great company, and they pay well, but their engineering staff is made up of the neckbeard brigade . . . lots of guys in their 50s that have either retired before retiring, or finally decided to learn this new fangled "java" language and move on from C and COBOL. There is simply not the engineering skill, nor the organizational will, to develop anything that complex in house. They tried once about 5 years ago and after 4 months it exploded in a ball of flames because they couldn't solve the the throughput issue.

This outage was almost certainly a Sabre issue. The reservation system itself runs on old school IBM big iron written in C. The system is so damn old that when you go southwest.com, all the information retrieved is done via screen scraping. Not XML, not JSON, not even CORBA. The key point is when the spokesman describes the "weight" of the airplane, something that is calculated by the system according to how many people checked in, how much luggage, etc. Without the system up and running, the flight cannot be "closed" and therefore tracked properly.

Southwest hosts all of their own in house applications ( except for a few things on GCE ), but the Sabre system is run out of some nuclear proof bomb shelter in Tulsa. It goes down 1 ~ 2 a year, but typically it's only out for 10-15 minutes. For planes to be called back to the gate, the outage would have had to have been over 60 minutes, as that's how long they buffer in a separate system in case it does go down.

Finally, Southwest pays Sabre by . . . wait for it, requests executed per second.

<comment><USER6> > The reservation system itself runs on old school IBM big iron written in C. > The system is so damn old that when you go southwest.com, all the > information retrieved is done via screen scraping.

Man, say what you will about old mainframes and critical systems and C and COBOL versus racks of commodity x86 boxes and Java and Ruby and "scaling out" and load balancers and reverse proxies and ..., but those old business apps running on the AS/400s and mainframes?

They just work(TM).

I agree that these old systems need to come into the 21st century but some of the most stable, reliable systems I've seen in my career are 20- or 30-year- old applications running on that old iron.

(mmm, 5150, 3270, CICS, JCL, RJE, IBM printers as big as refrigerators... _sigh_... sometimes I miss those days.)

<comment><USER7> Can we all agree that your point (while well taken)... is really really funny in light of the subject of this article? I'd say this was a pretty spectacular instance of just _not_ working.

<comment><USER8> Well - a lot depends on what part failed - was it the backend big iron, or the front end scraping system?

</comment></comment></comment></comment></comment><comment><USER9> "Some flights were on the taxiway and diverted back to the terminal after the problem was detected"

 _Why?_ You've checked these guys in, the baggage is loaded, the pilots (presumably) know where they are flying to... why would you pull them back in?

<comment><USER10> The business is probably so computer-dependent that the business is essentially the software systems executing. Planes flying, at this point, are mere physical side effects of software systems executing. If your systems aren't executing, your business isn't running.

Add in probable regulatory requirements that are also implemented by software, and that probably makes it illegal to fly.

<comment><USER11> It may have been relating to the Pilot Operating Handbook procedures the Airlines' Air Operators Certificate requires.

They still have the means to manually calculate the weight/balance etc. Some (most?) airlines require the pilots to do a manual cross-check worksheet of the fuel, weight/balance and a few other safety of flight items, before they take-off. This helps avoids mistakes like over-rotation on takeoff etc.

One particularly amusing case was in a 767, where the Captain handed a copy of the worksheet to a young girl who loved math problems, and was travelling in first class as a VIP. The young girl found a mathematical error in the worksheet. It turned out the flight computer had the fuel CG incorrect by 2-3% in certain cases, and both were incorrect.

A quick call to Boeing, and 20 minutes later, fuel transferred and the flight proceeded.

I suspect the Southwest aircraft returning to the gate, was a procedural abort, than a safely-of-flight issue.</comment></comment></comment>


Welcome to the Google Privacy Policy - <AUTHOR> https://www.google.com/policies/privacy/ <comment><USER2> Yes, and they leak info to advertisers, as I point out here [1].

And I know it is against the rules to complain about this, but somehow that link got downvoted for mysterious reasons. I think I'm raising a valid point here.

[1] [https://news.ycombinator.com/item?id=12899160](https://news.ycombinator.com/item?id=12899160)

<comment><USER3> I think it got downvoted because it is inaccurate.

* You can opt-out entirely on interest-based advertising with google [1]. You can also just delete your cookies/only browse in incognito/etc.

* Advertisers cannot target audiences with less than 100 people (1000 for search ads)[2] so they can only get a 1% chance of identifying "you" (this will go down as the list grows above 100), and even then that is only if you click on an ad for their product which is typically way under 1% as well. So less than 1% of the time, they have a maximum of 1% chance of identifying "you".

* They do not sell your personal information [3]

[1] - [https://support.google.com/ads/answer/2662922?hl=en- GB](https://support.google.com/ads/answer/2662922?hl=en-GB)

[2] - [https://support.google.com/adwords/answer/2472738?hl=en- GB](https://support.google.com/adwords/answer/2472738?hl=en-GB)

[3] - [https://privacy.google.com/intl/en-GB/how-ads- work.html](https://privacy.google.com/intl/en-GB/how-ads-work.html)

<comment><USER2> * That is inaccurate: Google's ad controls panel says this (after fully disabling targeted advertising): "Ads you see may still be based on your general location (such as city or county) or recent searches"

* Even if advertisers can target audiences in groups of at least 100 people, advertisers can run multiple campaigns and make an intersection of the sets of people they find, to still "identify" me.

* Yes, they don't sell personal information directly. This one is correct, and there is no reason to believe otherwise.

You can argue that my points are far-fetched, but in the end I am the one who determines the value of my data, not Google.

</comment></comment></comment><comment><USER4> I like the related materials at the end, particularly the layperson's description of their facial recognition tech [https://www.google.com/policies/technologies/pattern- recogni...](https://www.google.com/policies/technologies/pattern-recognition/)

I'd like to think I'm so savvy that nothing in that Privacy document would surprise me. But I haven't really read the whole thing. It'd be a good class assignment to make students read the policies of major services and write down what they were most surprised by, just to get a sense of how technically savvy they are.

</comment><comment><USER5> The irony being that if you want to know what they hold about you have to create an account to identify yorself to them..

</comment><comment><USER6> Is there a fork of Android that strips away Google's intrusion? One that is also maintained often too.

<comment><USER7> [http://www.cyanogenmod.org/](http://www.cyanogenmod.org/)

<comment><USER8> But, as with other flavors, you'll pretty much have to use the Google Services to get your apps working (notifications etc.)

<comment><USER7> Indeed, the problem is far from solved, but there is hope. Some apps can already be replaced:

[https://prism-break.org/en/categories/android/](https://prism- break.org/en/categories/android/)

</comment></comment></comment></comment><comment><USER9> > Example Whilst we currently don't ask for a credit card during sign up, > verifying your age through a small credit card transaction is one way to > confirm that you meet our age requirements in case your account was disabled > after you have entered a birthday indicating you are not old enough to have > a Google Account.

Pay us some small amount so we can keep tracking you.

</comment><comment><USER10> Submission is "Welcome to the Google Privacy Policy", Google's privacy page.</comment>


How My Startup Spent $46,548.47 in One Month - <AUTHOR> http://inside.idonethis.com/startup-expenses/

<comment><USER2> This is interesting. Thanks for sharing this. I wish more startups would share books.

<comment><AUTHOR> I'm really glad that you found it interesting! Thanks for taking a look.</comment></comment>


How I learnt to code in one year - <AUTHOR> http://www.davidbauer.ch/2013/01/25/how-i-learnt-to-code-in-one-year/

<comment><USER2> >Learning 1: Set a goal and talk about it. You'll need the pressure.

In fact, there is compelling evidence that the opposite is true: [http://www.psych.nyu.edu/gollwitzer/09_Gollwitzer_Sheeran_Se...](http://www.psych.nyu.edu/gollwitzer/09_Gollwitzer_Sheeran_Seifert_Michalski_When_Intentions_.pdf)

The long and short of it is that if you tell other people about your intention to accomplish something in advance, you get to pat yourself on the back without actually achieving anything. This apparently _reduces_ your motivation to follow up on the commitment because you've already reaped the reward.

<comment><USER3> > _"This apparently reduces your motivation to follow up on the commitment > because you've already reaped the reward."_

That's not universally true. Also, having skimmed the paper, that's not quite what the authors state.

To quote the paper _"...participants felt closer to the identity goal of becoming a jurist when their behavioral intentions were recognized than when those intentions remained private."_ This says nothing about motivation and in fact motivation (or even actual work) was not at all examined in this study. For all we know, those students _did_ go on to do better or "... read law periodicals regularly" as they said they would.

</comment></comment><comment><USER4> When teaching first year undergrads they would always complain that they couldn't see the application of what they were learning. It's interesting that this older student had the same reaction ("things I would have done differently had I known what I know now... Worry less about the fact that most exercises have no obvious relation to journalism.")

I guess that common in learning anything -- you have to get the fundamentals down but you probably can't appreciate them till you've mastered more of the subject.

Also interesting that Treehouse didn't work for him. If I was Ryan Carson I'd be a bit worried about this. Can anyone comment on the differences between CodeAcademy and Treehouse?

<comment><USER5> First and foremost I have used both products and enjoyed them both. To be honest Team Treehouse is great it really is but yes it does feel like you could pass the quizzes without really knowing anything. That being said their content was excellent but I wish they had more advanced topics. Soon enough though they are going to start getting into command line and the advanced parts of CSS(see here <http://teamtreehouse.com/roadmap>). Codeacademy on the other hand made it impossible to move forward without really knowing the material. Problem with Codeacademy though was it's lack of material. It only covers a few things at the current time relative to Team Treehouse.

</comment></comment><comment><USER6> So you learned to "code"? Next goal: become a software developer.

<comment><USER7> And after that, try to understand some algorithms and data structures. :)</comment></comment>


Mongraph, graph database coupling Neo4j + MongoDB - <AUTHOR> https://github.com/pstaender/mongraph

<comment><AUTHOR> this is an awesome.. missing db!</comment>


Photos from Pyongyang, North Korea - <AUTHOR> http://www.m1key.me/photography/ostensibly_ordinary_pyongyang/ <comment><USER2> [https://news.ycombinator.com/item?id=11286997](https://news.ycombinator.com/item?id=11286997), submitted 18h ago, points to a different gallery about the same trip and seems to discuss both.</comment>


Why Google Built Incognito Mode - <AUTHOR> http://runofnetwork.adzerk.com/general/why-google-built-incognito-mode/

<comment><USER2> This article doesn't make sense at all. Cookies aren't even saved when you're in in cognito mode.

<comment><AUTHOR> That's the entire point. If incognito mode didn't exist, the user would clear their history and cookies instead, probably deleting cookies for 'clean' as well as 'dirty' sites.</comment></comment>


Security Considerations for a brave new (IPv6) World [pdf] - <AUTHOR> http://www.void.gr/kargig/presentations/0x375-kargig_-_Security_considerations_for_IPv6.pdf

<comment><AUTHOR> More here:

[http://www.void.gr/kargig/blog/2011/11/28/0x375-0x07-securit...](http://www.void.gr/kargig/blog/2011/11/28/0x375-0x07-security- considerations-for-a-brave-new-ipv6-world/)</comment>


LIGO Detects First Neutron Star/Black Hole Collision - <AUTHOR> <comment><USER2> I am pretty sure this is several years ago.

First measured BH-BH merger was like 2015. First measured NS-NS merger was like 2016.</comment>


China to Funnel $29B Towards Its Chip Ambitions - <AUTHOR> https://www.bloomberg.com/news/articles/2019-10-29/china-to-funnel-29-billion-towards-its-chip-ambitions <comment><USER2> What else to expect? Being left at the mercy of trade sanctions policies of other states is not the smartest move. The only question left is funds and China has those aplenty.</comment>


James Bond Movie Analysis - <AUTHOR> http://www.r-bloggers.com/james-bond-movies/ <comment><USER2> The latest Bond film is actually pretty interesting. And at risk of plugging my own writing, anyone interested in actual film analysis could do worse than check out this essay on the Skyfall, which nailed the major themes in Spectre two years in advance:

"The hostility of authoritarian political systems to individual autonomy (democratic government in aggregate) is thus one of the ongoing themes of the film...."

[https://popupchinese.com/skyfall.html](https://popupchinese.com/skyfall.html)

The short version of Spectre is that Mendes is doing the same thing he did in Skyfall, casting M16 as the villain of the film and using literary motifs and allegorical doubling (i.e. villains reflecting aspects of Bond himself) to suggest that it is the security state itself that the real villain in the film. The interesting thing is the way he engineers a happy ending by transforming the "license to kill" into a "licence not to kill", essentially changing Bond from the agent of death he is shown to be at the beginning of the film into a pro-democratic figure who abandons violence and in doing so gets the girl and what she thematically represents.

<comment><USER3> So an Assasin that takes his own initiative on who to Kill is democratic :-)

<comment><USER2> Surprising and somewhat nonsensical, I agree, but that's what the film is doing.

</comment></comment></comment><comment><USER4> This is the original link: [http://opiateforthemass.es/articles/james-bond- film-ratings/](http://opiateforthemass.es/articles/james-bond-film-ratings/)

The books were better than the films anyway!

</comment><comment><USER5> That's not a lot of analysis. Why not ask:

Which Bond actor was the most profitable per film (i.e. the average box office rating of an actor)?

Which actor was the most efficient (i.e. the average actor salary subtracted from the average box office rating)[0]?

Which actor turned the best ratings? Can we predict whether the next Bond film will be good or bad, based on data first from the Craig era films and then all the films?

The article doesn't even mention what is the _best_ Bond film, i.e. the film that performs best when _both_ rating and box office is taking into account. I find the problem interesting of how you add a box office amount together with a rating percentage to get a 'film score'.

This article seems to be more about the technical aspect and not such more about the results.

[0] Yes, I know there are five Roger Moore films where the actor salary is unknown, but then we could just skip Roger Moore or only calculate on the films we _do_ know the salary.

<comment><USER6> 538 did such an analysis [here]([http://fivethirtyeight.com/features/the- perfect-bond-movie-s...](http://fivethirtyeight.com/features/the-perfect-bond- movie-sean-connery-judi-dench-and-a-watch-that-blows-stuff-up/))

</comment></comment><comment><USER7> R-bloggers is an aggregator. Should link directly to the original.

<comment><AUTHOR> _Should link directly to the original._

Why? Is it that hard to click through on a link? I stumbled across the article on r-bloggers, found it interesting, and submitted the link. Why should I worry about putting in the work to make sure people wind up on one site instead of another?

<comment><USER7> Just seeing your comment now, and I should have explained better. R-Bloggers is a great aggregator for R-related topics and I look at it every day. But it jams all the posts into its own text-heavy format, so you should click through to the original to get the full post formatted as the author intended.

Again, R-Bloggers is great for finding blog posts of interest, but once you find something interesting, then you should go to the original.

</comment></comment></comment><comment><USER8> Is there a reason why the pictures are so small?

<comment><USER9> If you mean the graph images, they're slightly larger on the original post: [http://opiateforthemass.es/articles/james-bond-film- ratings/](http://opiateforthemass.es/articles/james-bond-film-ratings/)

The code is also much more readable there.</comment></comment>


Buffon's Needle Problem - <AUTHOR> https://en.wikipedia.org/wiki/Buffon%27s_needle_problem <comment><USER2> dupe [https://news.ycombinator.com/item?id=21101721](https://news.ycombinator.com/item?id=21101721)

<comment><USER3> Dupe of what?

You've linked to the same post.

<comment><USER4> Every post is a dupe of itself. We don't need any more posts on HN</comment></comment></comment>


The Culture War Has Finally Come for Wikipedia - <AUTHOR> https://www.buzzfeednews.com/article/josephbernstein/wikipedia-ban-editor-culture-war <comment><USER2> A culture war (or at least different conflicts) has raged in Wikipedia for a long time, there's nothing new here.

The article could have used links to the relevant discussion pages, since everything is in the open and it would have allowed reader to have an idea of the reactions, beyond the chosen quotes</comment>