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

There are. It was mentioned that they are available in the 'commit comments' on 'banned.h', but you can find them by blaming down to the original commit which introduced each line.

Here are some of them:

  - strcpy()'s rationale: https://github.com/git/git/commit/c8af66ab8ad7cd78557f0f9f5ef6a52fd46ee6dd

  - strcat()'s rationale: https://github.com/git/git/commit/1b11b64b815db62f93a04242e4aed5687a448748

  - strncat()'s rationale: https://github.com/git/git/commit/ace5707a803eda0f1dde3d776dc3729d3bc7759a

  - sprintf()'s rationale: https://github.com/git/git/commit/cc8fdaee1eeaf05d8dd55ff11f111b815f673c58


I submitted a patch to fix this typo from my fork (which you can see at https://public-inbox.org/git/cab687db8315dd4245e1703402a8c76...).


This seems interesting. I use a Makefile to bootstrap my machine and manage my dotfiles.

I understand the appeal of Ansible, but I think it's more robust features are most useful in more complex environments than a personal laptop. My Makefile seems to do the trick.


Do you have your makefile on github?



Yuck. What's the point of a Makefile if every single rule is phony?


i use a bash script not a makefile, but it's (mostly) idempotent:

https://gist.github.com/talentdeficit/253fd1eaf25cb41e5c24a4...


I don't see what's wrong here.


Short answer: it's great.

I don't mean to echo the already loud voices of people championing React, but they're right: it's just awesome to write.

I think React has the right abstractions for today's web development: I am frequently able to express complex UI with very little SLOC. It's easy to see what a component does, and it's easy to jump into a project with little to no experience.

On that last point: I write software on a team with a lot of Angular.js fans. I've been trying to use React in more places, so I frequently start internal tools that have UI associated with them by using React.

It's going pretty well.


I think repeating some of the already mentioned answers is good - it shows common things that developers like.


It's interesting that an organization like the L.A. Dodgers has interest in something like this. It's also worth noting how startlingly similar this is to the YC-model of funding: $120k, 3 months, demo-day...


This Dodgers accelerator is "Powered by TechStars". See http://rgaaccelerator.com/. The terms are exactly the same as all other TechStars programs. $20k for 6% equity + an optional $100k as a convertible note.


I don't know if there is a good answer to this question simply because I don't think we're looking at it the right way.

In my mind, a product/business/whathaveyou should be a collaboration between two or three individuals, who, should the project grow, become cofounders.

I don't think the process should be:

  1) create idea
  2) idea becomes business
  3) "oh shit who will help me cofound this co.?"
  4) find cofounder through means described in this thread
  5) run successful business
...rather, the process should be:

  1) with friends, create idea
  2) develop idea
  3) create profitable business, with the aforementioned friends as cofounders.
In my mind, the later described process works with a high success rate since you have essentially "vetted" your friends in step 1. However, I don't know if you really can vet your friends against the challenges described in step 3, but perhaps that is what dooms a large percentage of startups.

Who knows.


Arq backs up my OS X machine and dumps the files into an S3 Glacier instance. Arq is inexpensive, and so is the S3 instance, so this setup works for me.

Arq has failed a few times without telling me, so I am not going to maintain a solely Arq-based setup in the longterm, but it's fine for now.

In the future, I'd like to add some redundancy, and backup to a location that I have physical control over. For now, however, I am pretty confident in this setup.


I'm confused why people see this as "revolutionary". At the core of it, this is just an abstraction around DOM-hacking. Anyone could have done this, and it is foolish to call such an "innovation" revolutionary.


It's a well maintained schlep of a DOM hacking API that makes complex interaction in a hugely important installed base of 1 billion users (previously nearly impossible) possible. Just because you understand the mechanism doesn't mean you should demean the herculean efforts of other good hackers.

Also innovation isn't the idea. Innovation is actually implementing it.


I have a hard time following this reasoning. Of course almost anything new could have been done by anyone. The nature of invention and innovation is that someone figured something out. People could have (and did) say the same thing about Facebook, Dropbox, and a number of other "revolutionary" companies/products. What matters is that someone did it and is packaging it in a way to solve problems and improve the lives of others.

Perhaps "revolutionary" is just marketing fluff, but why get hung up on subjective semantics?


Seems like you could set this up yourself using just Vim and Git(Hub).


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

Search: