bramcohen

The whole point of using a proper CRDT is that it's easy to reason about what it does. It took me a while to figure out the details of how to build one.

The endgame of effectiveness of stego with this framework of published techniques versus customized detectors for those techniques specifically is going to be much, much more difficult for the detector than it is today, if not outright losing. As for your claim that it isn't easy to stego techniques: Seriously, go read through the docs before making claims. You're just plain wrong, and obviously so.

To clarify: There is not, and cannot be, a universal DissidentX encoding detector. It will always, always, be possible to iterate arbitrarily on the encoding technique, and this iterating is easy to do.

This tool allows for the specifics of how the encoding is done to be changed without the decoding algorithm needing to be changed ever, so yes in fact it is ready to be used, although better encoders are both easy to write and welcome.

There was a CIA contractor who outright defrauded them claiming that he had tools which were detecting steganographic messages used by terrorists on the internet. He didn't get prosecuted because they were too embarrassed to admit that they'd been completely bamboozled.

This is a framework for steganographic schemes, not a specific steganographic scheme. The specific ones thrown in are just for demonstration purposes. The versatility of this approach is a major step forward in defeating statistical detection schemes. You of course don't know this, because you haven't read through the page and figured out what the code does.

In San Francisco at BitTorrent Inc. we're hiring a number of developer positions, most heavily web front end engineers. https://angel.co/bittorrent

Low enforcement might start issuing warrants to hand over your customer list as a list of potential suspects. If I were you I'd start that rumor myself.

The traditional overlay approach involves a bunch of full trees, and uses multiple trees as a way around dealing with leaf nodes being unutilized. My approach uses multiple groupings, which do not overlay, screams within them, and does something completely different for the last hop. They're completely different architectures. I have trouble taking seriously any paper which says that it makes heavy use of multiple description coding. If you have congestion control, skips should be an extreme and bad event.

Those other technologies have latencies measured in dozens of seconds or minutes, while mine is measured in seconds.

Over time I've made interview challenge problems progressively easier, as I've found that the trickier ones don't give any more information than the easier ones. My challenge now basically amounts to 'read this doubly nested for loop and tell me what it does', equivalent in difficulty to fizzbuzz.

If you can't solve that, even in the pressure of an interview, then I'm sorry, but you have no business working as a programmer, and I'm offended that you even applied.

And yes, people flunk it all the time.

You should probably make your code robust to this sort of data corruption in the future.

Looking at the correlation in students between year to year makes clear what's going on - http://garyrubinstein.teachforus.org/2012/03/06/analyzing-re...

There's such a high correlation between an individual student's score from one year to the next, and the number of data points is so small, that trying to tweeze out the teacher's contribution in a statistically meaningful way is fairly hopeless.

What I'd like to see are correlates with a teacher's own scores on the tests of the material they're supposed to be teaching (oh you think they all can get perfect scores easily? Hah!) and whether teachers banned from giving homework do any worse, and whether dumping the enforced curriculum in favor of letting students study at their own pace makes any difference. Given how little what the teachers actually do seems to make, it would be logical to at least dump the things which make school dull and unpleasant.

In regards to the question of 'Is it legal to fire this person for this?' at least in California it's a slam dunk - the answer is yes. One of the questions on the harassment training I had to take was for a related scenario, where a boss cut off an affair with an employee and later on fired her because his wife found out and wanted him to, and the whole point of the question was that the firing was legal. If it's legal to fire under that circumstance, it's definitely legal to fire under this one.

A number of things have changed since I made that post. Streaming downloads are long since supported. Peoples's net connections are much faster than they used to be. Flash can be relied on to do playback. And I've just plain figured out a whole bunch of new techniques, reworking from the ground up, to actually get latency under control.

From my sketchy understanding of your description of the algorithm, it seems like a 2d version of the patterns in gaps you see when you look at cornrows.

Did you read the article or just the headline?

Did you even read the article?

That's what you would do IF you were going to be serious about making the router drop packets in a way which actually helps. I don't expect it to happen any time soon.

There's some detailed writeups of the algorithms in the LEDBAT documentation. As for commentary, that's distinctly lacking, and my post is filling in some of the gap.

BitTorrent is using uTP just fine, which is only, you know, most of the upload from consumer internet connections, and we're working on getting the same things crammed into TCP with LEDBAT, but that's a slow process.

I wasn't complaining about RED dropping packets, just describing how it works.

As for the tension, my point is that my solution works and the other one doesn't. If you want to know why the person I quoted was being such a dismissive jerk, you'll have to ask him.

uTP carries the bulk of all BitTorrent transfers at this point. This would seem to imply a certain level of success.

They can have their throughput without running a denial of service on their net connection. If you assume that they'll DOS themselves for the fun of it anyway, then I can't help you.

uTP isn't based on CurveCP, and CurveCP is nowhere near as mature as uTP is.

Who do you think made the development he's referring to happen?

While other languages claim they can be used for such things, I have yet to hear of it being done in a real deployed piece of commercial software, despite the obvious security benefits. I'd be interested in hearing any success stories.

I still own bitconjurer.org, there's a misconfiguration of some kind which needs to be tracked down.

Some of us had to learn to not be like this.

http://stuffaspergerpeoplelike.com/2008/11/30/28-brutal-hone...

The problem is not the intelligence of the merge algorithm. The problem is that in this case there is no right answer.

For some context, Git follows the same architecture as Codeville, so Linus didn't invent the idea (although he ripped it off from Monotone, not Codeville) and the argument was essentially about whether a simple three-way merge can be used in all cases, and the answer is no, because of criss-cross cases, and solutions for that have since been put into Git. It is the case that semantics which more closely resemble three way merge are preferred though, as explained in my post which this thread is about, but for reasons which nobody in the flame war you link to appreciated at the time.