5 ms·

I would even go so far as to disagree with one of your sibling comments in saying that this reading list is important because it isn’t about “arcana”. Arcana is

by zwkrt 7y ago

I would even go so far as to disagree with one of your sibling comments in saying that this reading list is important because it isn’t about “arcana”. Arcana is what usually gets you the last 10%* of the way to a working solution, even if your high level approach is beautiful and pure. An old-style hacker reads man pages, RFCs, specs, and programming books not to immediately know how to solve problems at hand, but to know what solutions are possible for future problems. It isn’t useful to know that the HTTP spec doesn’t specify a max header length or that the default setting on Apache is to only accept 8kb of headers, until it is suddenly extremely useful to know both things at once :) * some would say “the other 90%”

acqq 7y ago
> reads man pages Good luck with that, especially, but not only, with git man pages. I tend to avoid reading these “just to know” but only when I need something specific. They are mostly torture. They could have been more useful to read but they presently aren’t.
- dllthomas 7y ago
  I read through the bash man page in a reading group with some co-workers. Good times.
- alephnil 7y ago
  The git man pages is famously inaccessible if you don't already know the concepts and jargon of git. The following auto generated satire is both hilarious and sad if you have read the actual git man pages: https://git-man-page-generator.lokaltog.net/ https://git-man-page-generator.lokaltog.net/
  - acqq 7y ago
    To compare, a real small part from "man git checkout": "git checkout --detach [<branch>] git checkout [--detach] <commit> Prepare to work on top of <commit>, by detaching HEAD at it (see "DETACHED HEAD" section), and updating the index and the files in the working tree. Local modifications to the files in the working tree are kept, so that the resulting working tree will be the state recorded in the commit plus the local modifications. When the <commit> argument is a branch name, the --detach option can be used to detach HEAD at the tip of the branch (git checkout <branch> would check out that branch without detaching HEAD). Omitting <branch> detaches HEAD at the tip of the current branch. git checkout [<tree-ish>] [--] <pathspec>… Overwrite paths in the working tree by replacing with the contents in the index or in the <tree-ish> (most often a commit). When a <tree-ish> is given, the paths that match the <pathspec> are updated both in the index and in the working tree. The index may contain unmerged entries because of a previous failed merge. By default, if you try to check out such an entry from the index, the checkout operation will fail and nothing will be checked out. Using -f will ignore these unmerged entries. The contents from a specific side of the merge can be checked out of the index by using --ours or --theirs. With -m, changes made to the working tree file can be discarded to re-create the original conflicted merge result." Well yes of course.

by zwkrt 7y ago

acqq 7y ago

> reads man pages Good luck with that, especially, but not only, with git man pages. I tend to avoid reading these “just to know” but only when I need something specific. They are mostly torture. They could have been more useful to read but they presently aren’t.

dllthomas 7y ago
I read through the bash man page in a reading group with some co-workers. Good times.
alephnil 7y ago
The git man pages is famously inaccessible if you don't already know the concepts and jargon of git. The following auto generated satire is both hilarious and sad if you have read the actual git man pages: https://git-man-page-generator.lokaltog.net/ https://git-man-page-generator.lokaltog.net/
- acqq 7y ago
  To compare, a real small part from "man git checkout": "git checkout --detach [<branch>] git checkout [--detach] <commit> Prepare to work on top of <commit>, by detaching HEAD at it (see "DETACHED HEAD" section), and updating the index and the files in the working tree. Local modifications to the files in the working tree are kept, so that the resulting working tree will be the state recorded in the commit plus the local modifications. When the <commit> argument is a branch name, the --detach option can be used to detach HEAD at the tip of the branch (git checkout <branch> would check out that branch without detaching HEAD). Omitting <branch> detaches HEAD at the tip of the current branch. git checkout [<tree-ish>] [--] <pathspec>… Overwrite paths in the working tree by replacing with the contents in the index or in the <tree-ish> (most often a commit). When a <tree-ish> is given, the paths that match the <pathspec> are updated both in the index and in the working tree. The index may contain unmerged entries because of a previous failed merge. By default, if you try to check out such an entry from the index, the checkout operation will fail and nothing will be checked out. Using -f will ignore these unmerged entries. The contents from a specific side of the merge can be checked out of the index by using --ours or --theirs. With -m, changes made to the working tree file can be discarded to re-create the original conflicted merge result." Well yes of course.