I'm not going to comment on the Assange case itself since I don't know the details, I'm not a lawyer, and there's so much misinformation out there that it must be almost impossible even for the prosecutors to keep track of what "the case" actually is, but... indeed, the swedish justice system is in many ways archaic. I guess unjust is the best word to describe it. Basically, it's a system that has evolved over time in a country with such low crime rates that simply being charged for a crime in itself is enough to make you guilty in the eyes of the court. If I'm not mistaken, I think Japan has a similar situation, and Japanese and Swedish culture seem strangely similar in other ways too. At least to this swede.
> Sweden has one of the EU's most restrictive drug policies, with zero tolerance for drug use and possession. At the same time, the rate of drug-induced deaths is among the highest in the union, and they are on the rise.
> [...] Only six out of Sweden's 290 municipalities offer needle exchange [...]
> "We always look at Sweden as a very advanced country with the most progressive policies, and I was surprised to see that it lags behind a number of other countries in terms of its policies on drugs," deputy high commissioner for human rights Flavia Pansieri told SVT.
Sweeden has many "peculiarities", the one that tremendously impresses me is that voting is effectively not secret.
From what was described to me, when you vote you ask for a sheet of paper. You can ask for several but you'll get weird looks from people. The end result is that anyone that votes in fringe options is effectively identified because no one else asks for those options.
The person that told me this was competely oblivious to any problem with it. When I mentioned that this makes voting "de facto" not secret he mentioned that next time he would ask for all options.
For those curious, the process is described here . As a voter, you go to a table and pick a ballot that represents your choice. You can pick a pre-printed ballot with your party's name on it, or you can take a blank ballot and write it manually. If you want to keep your choice secret, you can pick a bunch of random ballots, but submit just one of them.
For comparison, in Sweden's neighbouring country of Norway, the voting booth where you pick and fill out the ballot is covered with a curtain. You fill out the ballot (they're all printed on the same type of paper), which you fill out and fold so that it hides the contents. You then go over to an election worker, who confirms your identity and gives you an envelope to put the ballot in, which you then seal and put in the drop box.
It varies, usually you have all the papers laid out in a room. You're then free to pick just the ones you'll vote on or you can do like some and take one of each.
Parties will often also send voting blankets in the mail so you can somewhat secretly bring your own papers from home. The only issue there is that some places sets up the voting stands in such a poor way that people almost can see what you're doing anyway.
Another issue that has occurred during the past couple of elections is that the RF/AFA frat boys decided to stand guard at the entrance of some voting places, trying to stop people who intended to vote for SD.
"You can install a Zulip server on a system with 2G of RAM, but for production use we recommend a system with 4GB of RAM or more."
Something has gone horribly wrong when a chat server can barely run on 2G.
edit: As a frame of reference, here's what Inspire IRCd needs:
> A network with 3000-4000 locally connected clients and 10000 open channels experiences a constant 1-4% CPU use with 70MB of RAM use. This won't go up drastically, but it will go up. Around 40000 local clients means you'll be expecting some 500MB of RAM. 
To me, the takeaway lesson is this: Never work under unclear conditions. Make sure you have a contract that spells out the conditions you work under and the salary you will be paid. The second you start giving your labor away for free, you've lost the only leverage you have.
For anyone interested in learning more about Tracing JITs and the problems involved in implementing them should read the paper "Trace-based Just-in-time Compilation for Haskell" by Thomas Schilling .
In it, he explains the details of implementing a basic VM and tracing JIT based on LuaJIT, and deals with a lot of the issues involved. For example, the choice of where to begin a trace and for how long to trace is crucial for performance. Traces that are too long will rarely complete, and selecting poorly and tracing something that won't actually be on the hot path has significant cost. With poor trace selection, a tracing JIT can even be slower than an optimized interpreter. Interestingly, the language itself also influences the viability of tracing: A language with explicit loop instructions is easier to trace since any loop instruction is an intuitive starting point, whereas a language which relies on recursion and TCO is less cooperative in this regard. One possibility is rewriting recursive constructions to imperative loops in a pass prior to trace selection.
Personally, after reading the paper I think that there is the possibility for amazing performance from tracing JITs, but the unpredictability and reliance on heuristics makes the practical value over method JITs or static compilation questionable. It is similar to the complexities of GC implementation: As performance gains are made, complexity shoots through the roof while predictability suffers. There's no easy answer to that problem.
The Schilling paper is mostly a re-rendering of the original paper
Dynamo: A Transparent Dynamic Optimization System 
by Bala et al, which invented (or better reinvented and popularised) tracing JIT compilation. It might be worth reading the original. In addition, Haskell is not such a great target for JITing, as it's statically typed, leaving less scope for optimisation at run-time.
> Haskell is not such a great target for JITing, as it's statically typed, leaving less scope for optimisation at run-time
I'd refute this. Types are just one thing that you can speculatively optimise for at runtime which may not be practical to do at compile time. Other things include value ranges, tighter types than there are in the source code, branches taken/not-taken, contended/non-contended shared resources such as MVars and TVars, whether an Integer fits into a word or not, etc etc.
In my group we're looking at using a JIT for C, where we can do things such as inline through a function pointer by speculating that it is stable.
I agree that there is scope for JITing in Haskell.
If you are using C in a way that requires frequent invocation through a function pointer in hot code, you are probably using an OO-idiom, so casting, so circumventing C's typing.
My comment should have added something about the trace not having access to type information in the language. During luajit and v8 traces the VM has access to a higher level form than what Dynamo was dealing with.
You were specifically talking about tracing a static vs dynamic language. I agree, the opportunities for a speed up under dynamic languages is larger because there is more code bloat to dispatch on object type, where in Haskell that should have been elided during compilation, the Haskell code is much tighter to begin with. So the speedups seen for tracing Haskell should be similar to the gains seen by the Dynamo team when they traced native executables (most were generated from C afaik). Dynamo didn't have type information other than what it could extract from the assembly.
I don't know the innards of the Haskell compiler well enough, but, as chrisseaton writes above, tracing Haskell could lead to speedups better than Dynamo. For example data for generic functions in hot code could be unboxed, maybe laziness could be 'switched off' locally etc. But the easy gains that you see for dynamically typed languages, as we agree, are unlikely to be achievable. Nevertheless SPJ has suggested to the PyPy/RPython people to write a meta-tracer for Haskell, just to be able to measure what's possible.
As to Dynamo, I think some of the key gains came from the ability to shortcut jumps to jumps to jumps to ... that could arise from linking separately compiled code. However, modern CPUs diminish the penalty such frivolous jumping incurs, so Dynamo became less and less competitive with tracing on higher-level languages. (BTW, Dynamo can trace everything, not just C executables.)
Thanks! As someone who hasn't worked on any JIT compiler, the Schilling paper was very easy to read and comprehend. I'll definitely check out the Dynamo paper too.
Haskell seems like an interesting language to implement, being both statically typed and lazy. Static typing provides some optimization avenues but having to evaluate thunks at runtime complicates many common optimization strategies.
I had a short conversation at ECOOP with Ben Titzer (who works on V8 at Google, and I think used to work on HotSpot at Sun), who said simply: tracing JITs are good for short programs; for large programs you need a partial-evaluation method JIT. Partial evaluation also produces better results for a larger class of programs.
There is great progress in partial evaluation JITs going on in the Graal/Truffle project (Graal is the compiler; Truffle is a framework to write language frontends for Graal), which will be available as a pluggable compiler for HotSpot in Java 9.
As far as I'm aware partial evaluation JITs like Graal/Truffle have atrociously bad warmup times. Warmup is the phase before the optimised code is ready to be executed. This is already a problem for tracing JITs, but is supposedly worse for partial evaluation JITs. All papers I have seen measure JIT performance post warmup.
Right, and this is why people say that the JVM is slow to start. It actually starts up pretty fast (a hello world program starts the JVM, reads the class file from a JAR archive, runs it and terminates in under 80ms), but it takes a while to achieve max performance.
HotSpot has recently moved to a tiered-compilation scheme, where a fast compiler produces unoptimized code quickly, which continues to collect metrics for the profile-guided optimization, and the optimizing compiler kicks in later, once enough profiling information has been collected.
The JVM is not a tracing JIT compiler. Tracing is a very slow operation. Hence the warmup problem is substantially worse for tracing JITs.
I saw figures for warmup in tracing JITs that were so hillariously bad, that I thought they must be a typo.
People I know are currently writing a paper on this subject. I hope it will come out in the next 2 or 3 months. That should put our discussion, and the warmup performance of tracing JITs, on a firmer basis.
I said, or was trying to say that DPE and tracing have bad warmup.
Tracing JITs like LuaJIT and PyPY as fast to warm up compared to method JITs and PEs.
I have heard the opposite about PyPy, which is meta-tracing.
I'm a bit uncomfortable with saying "I have heard ..." As far as I'm aware there is no actual published research on this question. But there will soon be, so I would like to withdraw from this debate until I have read that research.
There is a parallel, but it is shallow. The author keeps pointing out the differences between the fantasy of Tolkien and the mythology within ISIS, and the more you think about it, the less the comparison holds. Religion, from the outside, is no different than any other romantic fiction. Does that mean that all romantic fiction and religion is essentially the same? I think that is a very shallow analysis.
You could draw similar parallels to any narrative which inspires actions that seem mad from the outside. The christian right of the US has the apocalyptic narrative of the Rapture, just waiting for the right circumstances to blow into the same kind of fanatic destruction as that of ISIS.
There is an allure in pointing to the mythology as the inspiration for some misdeed as if that may provide some insight, but I don't think so. The simple fact is that it doesn't take much to inspire us humans into doing things that seem unthinkable to others. Just about any fiction can inspire just about any deed. Mark Chapman shot Lennon after reading The Catcher in the Rye. Yes, perhaps it says something about the nature of humanity. But then what?
From the outside, any of these narratives seem like cosplay, like play acting. Just look at Manson or Waco, for example. The fiction is always ridiculous. The acts are real, though.
"A lot of people like cosplay." Everyone, apparently.
I think the author is talking more 'meta' than this, about the dark side of the deep human desires and archetypes that these stories tap into. It goes far beyond the near-universal story template of the 'return of the king.' That's just one permutation. What it's really all about is the need for meaning and significance to one's life.
There's a light side too. The human need for transcendent, powerful, meaningful motives can inspire amazing achievements.
One of my favorite modern crusades-in-the-making is the colonize Mars crowd. I could see it drawing its appeal from much the same psychological basis as ISIS, but channeling that energy in a much more interesting and productive route. I can also imagine the soul searching articles of future Bourgeois critics: "why would upper middle class young people with promising futures give it all up to go try to settle a desolate, airless, radiation-bathed desert and likely die in the process?" Yet I predict they would, and in far greater numbers than we see joining ISIS.
The need for meaning and significance can drive people to do the near-impossible and inspire us all, or it can drive them to take a gun and shoot up a school or go join a death cult. I personally suspect we'll see the latter in proportion to the absence of the former. One thing this author doesn't really address is how the appeal of ISIS (and other smaller-scale episodes of apocalyptic-nihilistic violence) is rooted in the banality of our culture, and what we might do about that. We spend an amazing amount of time and energy on worthless bullshit, and an equally amazing amount of energy convincing ourselves it's important.
Well, I think your thoughts on the dark side of human desire and how it relates to fiction are very close to my own. I don't think the article is even close to probing those questions. The article is just drawing a very lazy comparison but not digging any deeper than that, insinuating that there's something specifically about this kind of "return of the king"-narrative that can inspire something like ISIS. I think that's turning the cause and effect backwards, and it's shallow. It's the "dark side of the deep human desires" as you say that inspires these fictions, not vice versa.
If you are insinuating that the radical Christian right is waiting for a moment to commit the same actions as ISIS, then I believe your are completely incorrect.
They're crazy, and they expect more violence and chaos to break out, but being familiar as I am with some people who have the Rapture belief you allude to, I guarantee you there isn't a desire to commit violence against masses of innocent people. They /THINK/ violence will be committed, by Satan, against non-believers, but they will not act on it. Which means it won't happen.
No, that is not what I am insinuating. Your reading of my comment is as shallow as the article. I am insinuating that this ability to absorb a narrative and act on it, disregarding the well-being of other human beings, is innate in all humans. The Rapture narrative is only one example. I gave others. I can give another that may appeal more to someone who identifies as right-wing: Communism is a narrative, a romantic fiction, that led to horrible outcomes for innumerable people.
To believe that "they will not act on it" is a factual statement is horribly naive. People "act on it" all the time!
It was equivalent to marriage in Sweden which is an important difference, civil partnerships are inconsistent and not necessarily transferrable across borders.
You're right that just listing the dates for same-sex marriage doesn't tell the whole picture, but adding civil partnerships and their details would necessarily expand the comment to something closer to a book.
 for instance in France civil unions are quite literally a marriage lite, open to all and very commonly used as a legally recognised engagement by heterosexual couples (>90% of civil unions are heterosexual)