In what way does the parent comment indicate the author did not read the article? The article discusses options as a target of trolling, the parent seems directed at bystanders.
The article specifically calls out the "ignore the trolling" tactic is specifically a losing one, as the trolls will simply turn up the volume / severity of abuse. Nearly the entire article elaborates on this theme -- that it's not something that can be ignored, nor fought easily, and that telling someone to "just ignore it" is not going to solve it.
Like I said, though, that is directed at troll targets, not bystanders. Further, "just ignore it" is an incorrect summary of what Joe suggested, which was "ignore it but support the victim". I don't know that this is the correct approach, but I know it's not what the article spoke to.
I didn't read it as being directed only as targets.
There's been a general push, among communities suffering harassment, against the notion that vocally calling out malicious actors is 'feeding the trolls' in the traditional exacerbating sense. i.e. standing aside allows further victimization.
It may deserve to be directed more broadly; reading the article, it was not my impression that it was being so directed - and skimming again seems to support my initial reading ("ignore" is mentioned thrice, and every time in the context of talking to someone who was a target of trolls).
I would note that this discussion lends significant strength to my initial complaint here - which is that a bare RTFA is poor form and one should point to why and how the source disagrees with the comment. People are quite capable of reading the same material and coming away with different things (without anyone being an idiot).
The article also mentions that there becomes a competition among the bullies to see who can find the most effective tactic. ("The more dangerous social-web-fueled gamification of trolling is the unofficial troll/hate leader-board. ....")
This adds a lot to the severity. Ignoring it is not enough.
Note that I'm not saying ignoring it is the best approach. I just don't like seeing a bare "RTFA" when the issue raised was not specifically addressed in the article. (Even if it can be arguably inferred from the article, some pointers at the steps of inference are worthwhile - things are not equally obvious to everyone).
I felt that the aside about social gamification was important conceptually.
As technologists, sometimes we build something and then like to step aside and talk about it like it's inevitable. But how it was made and how it works factors in to how it is used. So it is our responsibility.
Right, thanks, way beyond normal sane responses required I see from the article. Well, maybe there's not been anything invented yet that will solve this problem.
Guessing here: Mozilla has a location service, fed by volunteers/contributors.
One way to contribute is by installing the MozStumbler app.
It seems the author contributes and is now disappointed about the inability to download the full dataset and pouts.
I would be interested in the full dataset myself, fail to see the why Mozilla guys are evil if they don't provide me the information about wifi names around the world.
I think the author is complaining about the opposite: Mozilla is now making available GPS coordinates from volunteer's contributions, which could be used to determine where a volunteer lives.
There are editions of the book using ML and Java. Since Andrew Appel is involved with SML/NJ, the ML edition is most likely the original. (The ML one is also quite good.)
Personally, I'm never a fan of punctuation first formatting styles - though I give some exception for dot (.) first method calls in fluent interfaces for C-family languages.
I'm reminded of protothreads (http://dunkels.com/adam/pt/). I used protothreads some time ago on an embedded project to implement a (very small) HTTP server in only a few KB or RAM.
The trouble with them is they're stackless, which means you can't have arbitrary functions thoughtlessly coded by someone unaware of threading called inside many different protothreads. Coroutines are easier to combine with code not written to account for their existence (of course stack overflow is a big concern though, which can be somewhat mitigated through memory protection depending on the OS and the hardware).
Sure, if none of these C functions tries to yield, or calls a library function trying to yield. In fact, the problem isn't that they can't be plain C functions, but that they must be plain C functions :)
Why would functions called by "lightweight threads"/"coroutines"/whatever want to yield? One example is, they want to wait for an event - an I/O request completion or a computation offloaded to an accelerator or whatever - without having to return all the way back to the event loop.
I must admit that this property attracted me to protothreads, since there is a clear demarcation between coroutines (through the presence of a protothread argument) and plain C functions.