The article mentions an `append` operation which is obviously not commutative; does that imply memcached needs a separate "appendable" string type? Of course not. Memcached only guarantees that the individual operations are atomic, it's the client's responsibility to avoid race conditions between multiple operations.
Now to in order to multiply a sequence of numbers correctly in a "high performance" shared store, you have external process synchronization. Just awesome. Thank you for the lesson. I had no idea concurrent processing could be so easy.
Threatening to "go kill ni**ers for a high score" is likely illegal.
That shits on /pol/ right now, and is the root of supporting extremism to the point of violence and murder. And last I checked, making death threats is explicitly not protected speech.
However, "go kill ni*ers for a high score" is not only not a true threat, it's the kind of speech that Brandenburg v Ohio, which established the current incitement-to-imminent-lawless-action test, explicitly said was 100% protected free speech.
Pretty much anything less than leading a mob and telling them who is their next lynching target will be ruled protected speech.
Your test sentence fails the Brandenburg test: it is not "directed to inciting or producing imminent lawless action", nor "likely to incite or produce such action."
Yes, bytes from a *logical* stream need to be delivered in order. But in HTTP2 (3) multiple logical streams are multiplexed on top of one physical TCP (QUIC) connection. In the HTTP2 case this means that a dropped segment from logical stream A will block delivery of subsequent segments from an different logical stream B (which is bad for obvious reasons). QUIC doesn't have this problem, which is a large part of its value proposition.
Except it doesn't work in practice and real world data proves it. Multiplexing streams inside of a single TCP connection don't magically make your data link less prone to dropped packets or high latency.
> The point is that in some cases the name of the project might itself be considered sensitive in some way
probably better to solve that problem by just giving projects easy-to-remember codenames. that's what intelligence agencies and militaries have been doing for years after all
I agree. Actually everyone I don't like should be classified as a terrorist and denied any sort of due process or civil rights. It's fine as long as we only do it to really really bad people who make us very very mad.
it's irrelevant whether they're "cryptographically" random, all that matters is that account IDs are not controlled by the user and therefore have no logical relation to any access-control policies the user may wish to implement
Yes we all know it's possible to lie with statistics. What are your criticisms of this article in particular? If you don't have any then you're just baselessly casting aspersions.
I don't have access to the article - my comment was about the figures specifically, as they were posted on Twitter (where I can see them. I don't have an FT subscription).
I'm critical/suspicious whenever a complex topic is presented as if it is apparently very simple, e.g. when people's political opinions apparently clearly follow a general rule across different countries and cultures (as in this case).
Without any evidence to back it up, I can imagine a different set if questions leading to different outcomes. Ideally, there would be a different newspaper who would set out to show that Women are more conservative (or some other different finding to the FT's), and the we'd be able to decide which method we find more compelling.
Having different opinions published by outlets that have the same readership is how scientific findings are disseminated and judged (e.g. two different theories both published by Nature, and read by Nature readers). In the case of newspapers, people of one opinion tend to read one subset of newspapers, and people of another opinion the other, which means that the kind of weighing up of evidence doesn't happen in the same way.
Anyway, my comments were made in good faith, in the spirit of someone just saying what they think, as is the way with HN. I didn't mean to offend anyone.
No? You don't need parallelism to guarantee global progress as long as the scheduler has the ability to preempt tasks. Of course coroutines (as opposed to e.g. userspace threads) can't really be preempted, which is the issue here.
> parallelism to guarantee global progress as long as the scheduler has the ability to preempt task
Preempting tasks is a single-core simulation of parallelism. I suspect there is confusion about what parallelism and concurrency are here: the terms are often used interchangeably (especially saying "concurrency" instead of "parallelism"), but they are definitely not interchangeable - or even, arguably, related at all. Concurrency, by definition, is concerned with continuations. If you remove continuations (async/await and/or futures/promises - depending on the language choices) then you aren't talking about concurrency any more.
Either way, you can use parallelism is Rust today - just use blocking APIs, locking, and threads. I don't get what the big deal is. You can even use concurrency and parallelism together, just use await/async across multiple threads.
I agree with the premise of the article, but the reasoning in this comment chain is something along the lines of "cats are horrible, because 5." The criticism is foreign to the entire subject matter.
Preemption simulates localized concurrency (running multiple distinct things logically at the same time) not parallelism (running them physically at the same time). You can have concurrency outside continuations. OS threads for example are not continuations, but still express concurrency to the kernel so that it can (not guaranteed) express concurrency to the physical CPU cores which hopefully execute the concurrent code in parallel (not guaranteed again, due to hyperthreading).
