Hacker Newsnew | past | comments | ask | show | jobs | submit | _kushagra's commentslogin

This is really good!


Looks really good but I found a visual bug — the graph overflows (on small resolutions?) http://d.pr/i/mQFV

Also, are the polls embeddable? I couldn't find any information about it on your page.


Not yet... it was built very quickly just yesterday... I will be fixing and adding (a limited amount) features over the coming weeks.


I like the idea but the execution was not great. I would've preferred a slideshow instead of this because at first, I didn't know that killing an enemy would show up specific slides. So skipping an enemy means skipping the slides associated with it.

Maybe you can port it to slid.es or something similar and it will be a much more valuable that way.


Why's it bad to store source code on Git?


Its not bad, is really nice, but Git has one problem, when you codebase is big, the process takes a long time, imagine git scanning those 8GB every time you do a commit, that is why Facebook was looking to port all their code to another VCS


I think it's worth making a distinction between the Git plumbing and the Git porcelain when talking about performance. The core functionality (the plumbing) is very fast regardless of repository size. The slowdowns people describe are almost always related to the porcelain commands, which are poorly optimized. Almost every porcelain-level command will cause Git to lstat() every file in your tree, as well as check for the presence of .gitignore files in all of the directories. It's very wasteful.

The fix for this is pretty simple: use filesystem watch hooks like inotify to update an lstat cache. I wrote something like this for an internal project and the speed difference was night and day. I remember reading that there had been progress on the inotify front on the git dev mailing list a few years ago, don't know what the current status is.


There was some testing early last year, but I think it's about time for someone to post another reminder

http://git.661346.n2.nabble.com/inotify-to-minimize-stat-cal...


This is when a centralized VCS with checkin-checkout concepts really shines. The client only has to check the checked-out files on commit.


Funny you should mention Facebook maybe having performance problems with Git: http://git.661346.n2.nabble.com/Git-performance-results-on-a... (2012)


I really can't support this claim. I have a repo of 111GB now and it works ok. Not slow at all (unless you do git gc or something like that).


" when you codebase is big, the process takes a long time"

From my experience, we can bet git is the one that takes the least amount of time

Not hitting the network to check which files changed, for a start


[deleted]


I wouldn't say Facebook and Twitter are competitors. Their models are quite different.

- Facebook's complex privacy vs Twitter's binary "public or private"

- Facebook's real names vs Twitter's @usernames

- Facebook's freeform posting length vs Twitter's 140 character limit


They store their code using the Git version-control software, not on Github as you seem to be thinking.


git is not a website...


10 seconds into the game and I won. The key is to press only three directional keys randomly and you'll win.

Hell, this is the first 2048 game in which I've won!


$ gem install json

$ scout_realtime

You're welcome.


If anyone is looking for a slow version – http://cssdeck.com/labs/hbuvchec


HN doesn't like self promotion, maybe?


I made safari crash with CSS only too! http://cssdeck.com/labs/adbir40g


IE8 is a problem.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: