But let's say you want anonymous contributions for a large project, yet prevent people from knowing where your server is located

There are two issues at play here.

1. you want others to have at least read access to (clones of) your repository;
2. you want others to be able to contribute, somehow.

The real problem with #1 is how to verify the authenticity of the clones. How does everybody not in the team know that the repositories are mirrors of the team's own? AFAIK the best that can be done is signed tags.

The second issue, which is what worry the most about, is actually the least risky, since —unless the repository consists chiefly of an unwieldy number of binary blobs— contributions can be provided in a variety of efficient ways, since they are plain text: from emails to pastebins you can spread over your work in all kinds of ways which is basically impossible to bottle up. EDIT: to clarify, I'm talking about exchanging commits in the form of patches (see git format-patch and its counterpart git am), which is how development is handled in a lot of projects (forget “pull requests” and that kind of crapola).

Again, larger patchsets might be more cumbersome to exchange, but still pretty much doable. Worst case, you can always put online some text-encoded git bundle. But heck, even in the old newsgroups days the exchange of binaries was a solved probem.

Also, without supporting mailing lists, the patch review process might be annoying. Again, Usenet could be a solution.

Um what makes it centralized in any sense of the word? The choice to Bless a one instance of the repository (usually server) as the source of truth is usually an arbitrary choice.

This is something that needs to be stressed out more. A lot of people are used to think/work with Git as some sort of centralized VCS with an offline mode, but the truth is that it is completely decentralized. You can have a small team cooperate by just adding each other's repository as remote, and exchange patches and commits by pulling from each other. It becomes somewhat unwieldy as the team grows larger, but it's a perfectly valid M.O.

In what way Mercurial is more decentralized than Git?

I'm watching a series called "handmade hero" and he used the term in passing. I was compelled to look it up.

That looks like something a handmade hero would do, yes. I think I'll look that series up.

Also, for love of god, please never tell anybody about that mistake. I beg of you. On my knees with tears in my eyes. You don't have to forgive me, just never speak of it again.

mrburns.jpg

I'm sure that's true. I suppose I tend to be one of those people for whom correctness is more important than timeliness, but I certainly see the point you're making.

You don't necessarily need to sacrifice correctness to achieve timeliness. There's plenty of systems where both are just as important. This is why I stressed that not getting the result in time would be just as useless as not getting any result or getting the wrong one.

It's also worth noting that I'm much less worried about inefficiencies than most people.

That's probably because you don't work in a field where efficiency is one of the preconditions for actually being useful (in the sense that it's not enough to actually have the correct result, it's also important to have it as soon as possible, and even earlier if possible). Think for example of things such as navigation control, emergency systems, or any other system where you have hard deadlines on when the result must be delivered, or it'd be just as useless as not having delivered it at all or delivering the wrong result.

That was what prompted my search.

You came across something actually using frobnicate?

Also, my deepest apologies for "TIL I learned".

Apology refused, I don't think you're groveling enough.

I knew the difference between tweak and twiddle, I didn't even know frob(nicate) existed as an actual word.

I'm not so sure about this. For me, the great strength of Haskell/functional-programming-in-general is that it mirrors mathematics and/or mathematical logic much more clearly, and I tend to feel that many of the problems with programming arise from not specifying the initial problem with adequate mathematical or logical clarity. (This may be because I work mostly on technically interesting areas with, generally, clear mathematical or logical solutions. For what I would consider "uninteresting" areas - games, web programming, etc. - you may be right, though.)

As a mathematician and a programmer, I'm honestly not that big a fan of functional programming outside of the areas where it makes sense in a “natural” way (basically anywhere that can be trivially construed in terms of symbolic manipulation of entities). Outside of that, “pure” functional programming tends to be monstrously inefficient, both in terms of coding efforts and in terms of achievable performance. There are however many principles of functional programming that are extremely useful in general, and those tend to be exactly the ones that sooner or later get assimilated in unsafe(r) languages.

[Edited to match the bracket parity in the original 8-)]

Agreed. Personally I'd prefer to see more movement from Haskell towards the "top right" of his diagram, but I recognise that there is a lot of movement from the "top left" families of languages.

I think “left-to-right” motion is considerably easier than “bottom to top”, which is why we see more of the former and less of the latter. And honestly I don't think it's such a bad thing: it's good to have stuff on the “bottom right” to act as beacon, in a sense.

I knew what video this was even before I clicked the link. It's very interesting because a lot of people get annoyed by the initial presentation and completely miss the point, which is about language (and hardware!) evolution to find the optimal balance between safety and practicality.

FWIW, I've just created /v/gpgpu (for GPGPU and massively parallel programming in general).

Oh, I absolutely agree that the introduction was necessary. And I loved the trick. But let's say that I might have ended up not finding out about it if I didn't have the patience to go through the whole article. Maybe a small hint at the beginning that it's not just a presentation of Newton's method at the beginning might be a little more enticing.

Ah yes, the famous “fast inverse square root” and its magic numbers.

Not the most original thing to read (especially for someone like me with a math background), but I did like the idea about how to get the initial guess _a lot_. It's a very useful idea that can be used for other functions as well, as long as you can get a general idea of the order of magnitude of the solution (which is what it does here).

For local hosting you can also look into gitolite. It's somewhat barebone, and it only does hosting with relatively fine-grained permissions, though, so for anything else (issue tracking and whatnot) you'll have to rely on something else. For issue tracking you might want to look into Bugs Everywhere, which integrates the feature with the main code repository.