Hacker News Reader

This doesn't mention one of my favorite bash gotchas, which is using `set -e` with `pipefail` at all. Try this:

    set -euo pipefail
    yes | head

That will consistently exit because `yes` gets sigpipe and quits. Which is expected, but triggers a script exit. But more exciting is that something like:

    generate_data | head

only _sometimes_ fail. It's a race that depends on whether generate_data is able to stuff all of its data into the pipe buffer before head calls close().

EDIT: I seemed to remember sharing this bug not too long ago, and indeed I did. pixelbeat responded with some interesting links: https://news.ycombinator.com/item?id=13940628

peffon Git 2.13

It's essentially the same except for the arguments. `save` took the whole command-line to be the stash message, which was confusingly unlike the rest of Git (and needed to be addressed before pathspec support could be added).

peffon Git 2.13

Yes, you're right. The `push` command was added because of backwards compatibility issues with `save` (and essentially replaces it).

peffon Better Git configuration

I'm not sure what you mean by this last sentence. But Git always computes the SHA1 of incoming objects (that's how it knows that the SHA1 is; the other side doesn't send it). And it likewise confirms that it has every object which is referenced by the newly fetched history.

The fsckObjects settings are entirely separate from the SHA. They are about syntactic and semantic rules in the objects themselves (e.g., well-formatted committer name/dates, tree filenames that don't contain "/", etc).

peffon Diaspora-common: does 'rm -rf /' on purge

Using "set -e" with pipefail is racy because of SIGPIPE. For example, if you do this:

    some_command | head

Then depending on timing, `some_command` _may_ generate all of its output and stuff it into the pipe, exiting successfully. Or `head` may get the lines it needs and close the pipe, causing `some_command` to exit with SIGPIPE. Using pipefail makes the whole pipeline fail, and then `-e` terminates the script.

And it only happens sometimes.

peffon SHA-1 Collision Detection on GitHub.com

You can already play with this using Git's "grafts" and "replace refs" features. Most of Git's graph algorithms are OK with this because they traverse the graph while setting one or more "SEEN" bits on each node. If you find one that loops infinitely, it would be worth making a bug report.

peffon SHA-1 Collision Detection on GitHub.com

No, it's better than that. It detects evidence of the cryptanalytic tricks that were used to generate that collision. So it will find any collision generated using their attack technique (which is ~2^63 operations, as opposed to 2^80 for brute force).

There may be new disturbance vectors discovered as the attack matures, but they can be added to the detector.

peffon SHA-1 Collision Detection on GitHub.com

It is possible; the researchers estimate the likelihood of a false positive at 2^-90 (which puts us back in "Sun engulfs the Earth" territory).

There are metrics that will alert GitHub's infrastructure team if a collision is found (to confirm that we aren't seeing any false positives). Those metrics were quietly shipped (without the matching "die") for a week before flipping the final switch.

If you want to know more about the patterns, see the sha1collisiondetection project:

https://github.com/cr-marcstevens/sha1collisiondetection

There's a research paper linked in the README.

peffon 14 Character Random Number Generator in C

https://en.wikipedia.org/wiki/Linear_congruential_generator

peffon A Git catastrophe cleaned up

The simplest solution is:

    # try the merge; you'll get conflicts on those files
    git merge topic

    # discard the versions from the topic branch;
    # you know you already merged those changes in
    # the funny "git checkout commit", so any differences
    # are due to changes on master.
    git checkout --ours new-file-{1,18}

    # now you are free to fix up any real conflicts
    # and resolve the merge
    git commit

This has the advantage of representing the true history. You had two lines of development (the original topic, and the "squashed" history created for deployment), and the merge shows them coming together and choosing the deployment-side content.

peffon Git 2.11 has been released

The counter never resets, it just keeps going up and we only look at the low bits. So eventually it will need to wrap. It's doubtful that ever happened in practice, even on a 32-bit system (you'd need to print 2 billion SHA-1s in a single process, and even the largest repos have on the order of millions).

So the key difference between the old and the new is that the counter resets to zero every fourth call.

peffon Git 2.11 has been released

Right, I am so used to the square approximation being used for hash collisions that I forgot it was an approximation. Thanks for setting me straight.

peffon Git 2.11 has been released

That is a nice writeup. One of the interesting things for me was to see which topics you decided to cover and which to omit. For instance, I noted `clone --reference --recurse-submodules` as a potential topic of interest, but I am afraid to point anybody to the `--reference` option due to its hidden dangers.

I'm also curious how you came up with 19,290 for a birthday paradox on a 7-hex hash. I think it's 16,384, but probability can sometimes be tricky. :)

peffon Git 2.11 has been released

A nice side effect of hex is that you can pick it out of a text commit message with higher accuracy (e.g., to turn it into a hyperlink). Tools like `gitk` and sites like GitHub do this using a regex.

peffon Git 2.11 has been released

As others have noted, there's not always an unambiguous date for some object types (the best you can do for blobs is to find the first commit in which they appeared, and use its date).

However, there'a more complicated issue with timestamps, with is that you care about what was in the repository of the person who generated the sha1, at the time of generation. So you could merge in history that includes older commits, and invalidate your sha1s with "older" objects.

So the timestamp of interest is not the one in the objects themselves, but when they entered some particular repository (and not even some well-known repository; the local clone of whoever happened to generate the sha1). That being said, those two things correlate a lot in practice, and auto-picking the oldest commit might be a useful heuristic.

It would be a fun project to implement as an option for `core.disambiguate`.

peffon Git 2.11 has been released

Oh, you're right. I misread the chart (and just fixed the blog post).

There are a lot of other caveats, too. Such as the idea of each year being an independent probability.

peffon An idea for encrypted, verifiable voting

There's a lot of academic work in this area, some of it going back 20 years. The keyword to look for when searching for papers is "receipt-free" voting.

peffon Dictionary of Algorithms and Data Structures (1998)

You can store the values in a trie (e.g., with one node per character in the string). Exact lookup in the trie is O(string_length), like a hash table. Inexact lookup can similarly walk the tree, but explore side branches within a certain budget.

So if your string is "abc", you'd follow the node for "a", then the one for "b", but _also_ the one for "c", at a cost of 1 (because dropping the "b" incurs an edit distance of 1).

peffon How to make Slack less bad for you

Err...isn't the "... is typing" message configurable and can be disabled if you don't like it?

peffon Can Facebook really make ads unblockable?

It sounds like you are reinventing CAPTCHAs.

peffon Drowning in a Sea of Information

https://en.wikipedia.org/wiki/Inverted_pyramid

I actually agree with your list; I think the inverted pyramid is really about prose construction in an age where print space was at a premium. We can be a lot more free with formatting or redundant information (if it is clearly marked as such) on the web.

I mostly wanted to point out that the concept is not new, but as far as I can tell, it has been pretty much forgotten in most modern web journalism.

peffon Git 2.9 released

I hope to one day push the highlighting inside of git itself. That should make it more efficient, and we can do a true LCS diff to find the common parts, rather than the front/back heuristic it currently does (see the diff-highlight README for the gory details).

It's just a little complicated because of the way it interacts with existing internal diff features (in particular the whitespace-error highlighting).

peffon Git 2.9 released

It doesn't. It's just more convenient to use, and we took the opportunity to make people aware of the existing `--exec` feature.

peffon 25-year-old lived for more than a year without a heart

That continuous flow is new(-ish). My father had an LVAD in 2002, and it was the older type that actually pumps rhythmically, so that was his pulse. At the time continuous-flow models were in research, and I do remember there were concerns with thrombosis (basically, the shifting force of the pulse helps break up clots).

I don't know the current state of the art, but there are definitely studies (the keyword is "pulsatile"). For example:

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4250555/

For comparison, here's a picture of some LVADs. The one I've seen in person (after it had been taken back out!) is the one on the far left. Flow issues aside, I can imagine the smaller ones are easier on the patient in general, just from the perspective of surgery trauma.

http://reliantheart.com/wp-content/uploads/2013/04/VAD_Size_...

peffon Remote code execution, git, and OS X

Minor nit: this post mentions v2.7.1 as safe from these vulnerabilities, but it is not. v2.7.4 is the first safe version (this mistake was inherited from the bogus oss-security post that is linked in the article).

peffon Remote code execution, git, and OS X

This is being worked on: https://github.com/git/git-scm.com/pull/741

peffon Git 2.8.0 released

From the very first section (Backward compatibility note):

    The rsync:// transport has been removed.

peffon Move Fast and Fix Things

I think it is a combination of two things:

- the mod-256 conflict bug is exceedingly rare. Keep in mind that this is mod-256 individual hunk conflicts in a _single file_. Most files in a merge with conflicts have a handful of hunks. Over all of the testing at GitHub, only a single merge triggered this bug, and it was on a long repetitive file with automated changes.

- the failure case was to quietly accept the merge. The result was obviously bogus, but didn't look any different than a user accidentally checking in the merge conflict markers. So if it was happening, I'd suspect that it went undiscovered either because the merge results were never used (e.g., it was a test-merge to feed the PR "Merge" button status) or the users simply scratched their head and fixed it.

peffon Counting Objects

The fork-aware packfiles are bigger, but not as much as you might think. We give up the "best" delta that git can find, but usually there is another one in the same group that is almost as good.

I didn't have any numbers on hand, so I just repacked our git/git network.git with and without the delta-aware code. A stock repack is about 300MB, and the delta-aware one is 400MB.

That sounds like a lot, but the real alternative is not sharing objects at all, which is more like 350GB.