Links for 2013-02-22

  • Indymedia: It’s time to move on

    Our decision to curtail publishing on the Nottingham Indymedia site and call a meeting is an attempt to create a space for new ideas. We are not interested in continuing along the slow but certain path to total irrelevance but want to draw in new people and start off in new directions whilst remaining faithful to the underlying principles of Indymedia.

    (tags: indymedia community communication web anonymity publishing left-wing)

  • How to revert a faulty merge in git

    omgwtf, this is pretty horrific.

    (tags: merging git merge omgwtf version-control branching)

  • #AltDevBlogADay » Latency Mitigation Strategies

    John Carmack on the low-latency coding techniques used to support head mounted display devices.

    Virtual reality (VR) is one of the most demanding human-in-the-loop applications from a latency standpoint. The latency between the physical movement of a user’s head and updated photons from a head mounted display reaching their eyes is one of the most critical factors in providing a high quality experience. Human sensory systems can detect very small relative delays in parts of the visual or, especially, audio fields, but when absolute delays are below approximately 20 milliseconds they are generally imperceptible. Interactive 3D systems today typically have latencies that are several times that figure, but alternate configurations of the same hardware components can allow that target to be reached. A discussion of the sources of latency throughout a system follows, along with techniques for reducing the latency in the processing done on the host system.

    (tags: head-mounted-display display ui latency vision coding john-carmack)

This entry was posted in Uncategorized. Bookmark the permalink. Both comments and trackbacks are currently closed.

One Comment

  1. Nix
    Posted February 23, 2013 at 13:37 | Permalink

    The revert-a-merge thing seems logical to me. Merges have to be history-graph-aware or you end up with the Subversion merge-track hell where you try to add history-awareness to every file to track every merge point. This is the downside of history-aware merges: you need history-aware reversion in some situations. Git doesn’t have any tools for that, or rather it does: ‘git reset HEAD^’, but it only works if that history is still mutable. If it’s not — perhaps because you’ve pushed it out so cannot edit the history that follows it to no longer descend from the merge commit — well, reverting the content, then reverting the revert, is likely the best you can do. Anything else seems likely to impose hideous performance costs (e.g. you could add a header to revert commits indicating which commit they reverted, iff it was a merge commit — but now all merges have to scan every ancestral commit for that header: not at all fast, and getting ever slower the longer the history.)

    This is a very rare situation, though, so I guess nobody’s ever put in the mental effort to figure out a proper fix, since it is thoroughly unobvious.