Is Redlock Safe? Reply to Redlock Analysis - <AUTHOR> http://antirez.com/news/101 <comment><USER3> This response is incorrect at a very fundamental level.

First, Antirez claims that requiring the "materialization" store to be able to tie break with a monotonically increasing token requires linearization? This is completely false. The monotonically increasing token allows for eventual consistency. That's the entire point of it. It's monotonically increasing.

For anyone who claims that once you have coordination (locking) in your system you already lost is completely ignoring the research coming out of BOOM (Berkeley Orders of Magnitude). You can design your system to push the coordination out to the edge and way from your "choke points" and use these monotonically increasing tokens to keep your bottlenecks coordination free.

Secondly, Antirez's argument that you can use a compare & swap in a transactional storage layer is also wrong. This is not possible to write safely.

I'm not even going to touch his argument that using system clocks in a distributed locking algorithm is safe...

<comment><USER4> > I'm not even going to touch his argument that using system clocks in a > distributed locking algorithm is safe...

Please do

<comment><USER5> Clock drift is a real thing in distributed systems.

If I have a 5 second lock that expires at 12:01:00 and my clock is off by 1 second I could write at 12:01:01 potentially after someone else has a lock, or worse, after someone else has written.

<comment><USER4> but the expiration time is relative to the redis server's time, and the time measurement on the client side is done relative to the client's time. Other clients don't care about your clock and you don't care about redis' clock AFAIK. From TFM:

> The client computes how much time elapsed in order to acquire the lock, by > subtracting from the current time the timestamp obtained in step 1. If and > only if the client was able to acquire the lock in the majority of the > instances (at least 3), and the total time elapsed to acquire the lock is > less than lock validity time, the lock is considered to be acquired.

<comment><USER6> What is the effect on the client of a VM live migration "pause"?

or daylight savings change?

or ntp updates which change the time?

Since the system clock can change relative to itself at any time, what effect does that have on the algorithm?

<comment><USER7> Distributed time is tricky, but it depends on what the intended use is. Under normal operation it will only move forward, for example.

> VM live migration "pause"?

System clock will take a larger step than usual. It won't go backwards.

> daylight savings change?

None. System clock is UTC for a reason.

> ntp updates which change the time?

NTP only drifts the clock (under normal operation).

<comment><USER6> Not that I think it effects your point, but just off the top of my head:

 _System clock will take a larger step than usual. It won 't go backwards._

Assumes that checkpoint and restore to a previous time won't happen.

 _NTP only drifts the clock (under normal operation)._

Unless it's a system like this. Note that this was pulled at about 1pm EST.

      Waiting for clock tick...
      ...got clock tick
      Time read from Hardware Clock: 2016/02/09 22:36:50
      Hw clock time : 2016/02/09 22:36:50 = 1455057410 seconds since 1969
      Tue 09 Feb 2016 02:36:50 PM PST  -1.038948 seconds

_Under normal operation it will only move forward_

'Under normal operation' is not really a high bar for distributed systems. After all, the network is reliable 'under normal operation' too.

<comment><USER8> Use CLOCK_MONOTONIC. Or you could make your client abort when the clock goes backwards.

If someone forks a VM from a running snapshot, you're screwed whether they mess with the clock or not.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> Whoah, whoah, whoah, no:

 _1\. Most of the times when you need a distributed lock system that can guarantee mutual exclusivity, when this property is violated you already lost. Distributed locks are very useful exactly when we have no other control in the shared resource._

In context, Sanfilippo seems to be arguing that providing monotonic logical timestamps or sequence numbers is futile, since a system that relies on locks that break is going to fail one way or another.

That is probably true, but wildly misses the point: when a sound system that relies on distributed locks fails, _it doesn 't silently corrupt data_. But that's exactly what happens in the "unfenced" lock-breaking scenario Kleppmann describes.

There are worse things than crashing, is the point.

 _slightly later_

The argument about storage servers taking fencing tokens being "linearizable" also seems flimsy: aren't they "linearizable" (in whatever sense Sanfillippo means) in the case Kleppmann because _because the lock service arranges for them to be_? That's functionality Kleppmann says is missing from Redlock.

<comment><AUTHOR> Maybe you missed the point ;-) I said this and later showed how the Redlock unique token per lock can be used to guarantee the same. So it's equivalent, but yet _very non credible model_ in production. When you have a way to avoid a mess when a race condition happens, it's better to avoid a distributed lock at all, to start with.

<comment><USER9> Can you further explain your "check" and "set" storage example? I feel like you might be begging the question. "check" and "set" seem like they describe _another lock_. How does that lock time out?

<comment><AUTHOR> Whatever you can mount with a random token is always simpler than checking if Token_ID_A < Token_ID_B which needs a linearizable store. But basically this is how it works:

You want to modify locked resource X. You set X.currlock = token. Then you read, do whatever you want, and when you write, you "write-if-currlock == token". If another client did X.currlock = somethingelse, the transaction fails.

Edit: note that I noticed some confusion about this. Any other client is free to replace X.currlock even if set to a past value.

<comment><USER10> The problem with this solution is that if A writes Token_A to resource, and then A dies, then the resource can never be written to again. How do you avoid not needing to time out the 'curr_lock'

<comment><USER11> No, when you acquire a lock, you are allowed to write to currlock immediately. It's AFTER you've done whatever processing you need to do that you do a compare-and-set transactional write that verifies no one else has written to currlock between your acquisition and the completion of your task.

</comment></comment></comment></comment></comment></comment><comment><USER12> A lot of the back-and-forth here reminds me of:

"Note that, with careful optimization, only 14 gajillion messages are necessary. This is still too many messages; however, if the system sends fewer than 14 gajillion messages, it will be vulnerable to accusations that it only handles reasonable failure cases, and not the demented ones that previous researchers spitefully introduced in earlier papers in a desperate attempt to distinguish themselves from even more prior (yet similarly demented) work."

from James Mickens' "The Saddest Moment" \- [https://www.usenix.org/system/files/login- logout_1305_micken...](https://www.usenix.org/system/files/login- logout_1305_mickens.pdf)

<comment><USER13> This is such an elegant way to phrase my general sense of frustration I felt reading certain exchanges here. Thanks =)

</comment></comment><comment><USER14> As with all distributed systems algorithms, we should assume Redlock is unsafe until proven otherwise. A proof looks like [http://ramcloud.stanford.edu/raft.pdf](http://ramcloud.stanford.edu/raft.pdf) (Raft), [http://research.microsoft.com/en- us/um/people/lamport/pubs/p...](http://research.microsoft.com/en- us/um/people/lamport/pubs/paxos-simple.pdf) (Paxos) or [http://www.tcs.hut.fi/Studies/T-79.5001/reports/2012-deSouza...](http://www.tcs.hut.fi/Studies/T-79.5001/reports/2012-deSouzaMedeiros.pdf) (Zookeeper).

Personally I'd prefer stronger proofs than even those, but I think those papers get us to the point where implementation issues are as important as theoretical issues.

In my personal opinion, Redlock is not at the point where we even need to consider the implementation.

<comment><USER15> A good starting point. But those proofs are notoriously based on fairy tales such as reliable networking, Fail/Stop, and other white lies.

The fact that a protocol (e.g. Raft) has been proven correct sets the floor but it is certainly not sufficient to assume correctness of an _implementation_.

<comment><USER16> It should always be a prerequisite to have a proof before one begins an implementation. If one cannot construct such a proof then they have no business trying to design new distributed algorithms. Fortunately there are a few algorithms for proofs of replicated state machines available as previously noted.

Proofs will typically show the limitations of an algorithm, for instance the original paxos paper notes that the contained algorithm does not provide liveliness.

A system based on an algorithm with a proof has some chance of being correct, while a system based on an algorithm with no proof while technically it may have a non-zero probability of being correct that probability approaches zero.

Having worked on such systems and having talked to some people who have worked on debugging issues with paxos implementations at extreme scale while it is virtually impossible to to ensure that the system will be able to make forward progress it is possible to ensure that the state of the state machine remains correct.

When I look at an implementation of such an algorithm to evaluate it I pay very careful attention to the test suites. The more bizarre the tests they contain the more likely the implementation is to handle very weird network edge cases.

</comment></comment></comment><comment><USER17> If you need a global lock in your distributed system, then you're already in trouble. In _most_ cases, the best solution is to rewrite your software so that you don't need the lock. I don't want to say all, because I'm sure there are use cases where it would be impossible to do so. However, for my own research, I'm having trouble finding examples where a global lock is absolutely necessary. If anyone has any examples, please send them to me.

For example, a lot of people say, "updating a bank balance". But even that can easily be eventually consistent. You send increments and decrements and settle up at the end. Yes, your balance might go negative, but that's what ATM limits are for -- the most you could go negative is that limit. Most other systems can be written the same way. And for non-numeric values, there are always vector clocks or timestamps or quorum to determine which update came next, or you could send a client a list of all recent updates and let the client "do the right thing".

<comment><USER18> Is leader election somehow a usage of a global lock? I do agree it should be avoided actively though.

<comment><USER19> It's related.

Leader election generally[1] requires consensus among distributed processes, and global locks generally[1] require consensus as well. The benefit of this is that both problems can be solved on top of a common consensus implementation which is what [http://atomix.io](http://atomix.io) does.

1: I say _generally_ because you can do fancy things with fancy clocks to avoid running operations through a quorum under certain circumstances, but these carry caveats that preclude them from being reliable enough to use in many use cases.

</comment></comment></comment><comment><USER20> Another potential issue with antirez's argument:

""" If you read the Redlock specification, that I hadn't touched for months, you can see the steps to acquire the lock are:

1\. Get the current time.

2\. … All the steps needed to acquire the lock …

3\. Get the current time, again.

4\. Check if we are already out of time, or if we acquired the lock fast enough.

5\. Do some work with your lock.

...

The above also addresses "process pauses" concern number 3. Pauses during the process of acquiring the lock don't have effects on the algorithm's correctness. """

What if the process GCs for 2 minutes between 4 and 5? Then the lock times out, but the process still does its work with the lock, even though another process may think it has the lock as well.

This is a specific example of the criticism that you cannot rely on clock checks for correctness that has been made elsewhere.

<comment><AUTHOR> This is clearly addressed in the blog post. A GC pauae after step 3 is equivalent to any other pause after the lock is acquired. For example it's not different than a lock server replying OK to a lock request but the client only reads it after two minutes.

<comment><USER21> Yes, but you can't predict how long it would take so you can't be sure the lock you acquired you still hold while operating on a shared resource.

</comment></comment></comment><comment><USER22> I recently had to help some developer that was stuck trying to have mongodb lock a resource and started using redis+redshift to prevent multiple webserver from updating a document in parallel (mongodb basic locking features weren't enough in his case).

As a RDBMS aficionado, that whole stack made me puke, BUT, to all the really smart people here having a PHD in distributed systems, please : try to help antirez build something that works. Many developers are trying to reach the shore of consistent systems after having been lost in the ocean of "NoSQL is great for everything".

Note : and i'm not saying redis is to blame here. It's obviously a great software. It's mostly the users that are to blame in this case.

<comment><USER23> Redlock, not Redshift, I assume?

<comment><USER22> Yeap, typo

</comment></comment></comment><comment><USER24> I'll take one point here. Antirez's point that clients _have_ to timeout on locks, otherwise the resource will be deadlocked is not correct. We implemented an alternative model based on distributed shared memory. Clients take a lock on the root of a subtree (of potentially millions of inodes in our version of HDFS) and persist the lock to shared memory and look for existing locks on the subtree in shared memory. If the client dies while processing the subtree, its lock is still persisted in shared memory alongs with the clientID. If another client tries to take the lock and it notices the client holding the lock has died, it takes the lock. We used heartbeats to shared memroy to implement the failure detector for clients (based again on shared memory [http://www.jimdowling.info/sites/default/files/leader_electi...](http://www.jimdowling.info/sites/default/files/leader_election_using_newsql_db.pdf) ). Importantly, timeouts for heartbeats expand when the system is congested.

<comment><AUTHOR> There may be systems where you can reliably detect if a client has a lock at all, and if it's still alive or is failing. In most systems this is not possible, so your locks need to have an auto release feature. Distributed locks with auto release are like a huge needed evil: you avoid using it at all costs if you can, but there are problems when they are needed.

<comment><USER24> In this case, we transformed the problem from detecting if the client has the lock or not, to one of detecting if the client is dead or not - for which there are many more protocols (with different levels of accuracy). The point stands that auto-releasing distributed locks is not the only possible solution.

<comment><AUTHOR> It is impossible to write a reliable distributed failure detector in this use case, in a practical system model.

<comment><USER24> You mean in the asynchronous systems model, in the presence of failures, it is impossible to write a reliable failure detector: [http://the-paper- trail.org/blog/a-brief-tour-of-flp-impossib...](http://the-paper- trail.org/blog/a-brief-tour-of-flp-impossibility/) However, you can write a failure detector for a practical system with the help of omega (weakest failure detector): [http://www.cs.utexas.edu/~lorenzo/corsi/cs380d/papers/p685-c...](http://www.cs.utexas.edu/~lorenzo/corsi/cs380d/papers/p685-chandra.pdf)

In practice, failure detectors mean timeouts. What I am arguing is that you can have systems that adapt their timeouts for failure (such as our one), based on the current level of network congestion or load or whatever. The setting/changing of the timeout is averaged over a period of time, to ensure it is high enough to not give false positives. You could do the same approach at the per message level, but for all possible messages, it may be prohibitive. If you have a small number of messages, it may work. The problem with messages, compared to failure detection, however, is the following: how do you figure out you have had a false positive? For failure detection it's easy: the timeout expired, butre i'm still alive and my heartbeat arrives late, so we increase the timeout for that node. Vector clocks (fencing tokens) make it easier to reliably find out if messages arrive very late (identify false positives).

</comment></comment></comment></comment></comment><comment><USER25> I feel a bit like how a juror must feel when two expert witnesses are making opposing arguments...

<comment><USER26> No kidding. Unfortunately, it seems people sometimes get kind of snarky with these discussions, which I don't like. It starts to remind me of the Comic Book Guy.

I would encourage everyone to be civil and patient, and if you have the time, expand on what you're writing so that those of us who are not experts can learn something.

</comment></comment><comment><USER27> Short answer: no.

Longer answer: provided that things never go wrong it works. But the assumption that things never go wrong is false. In particular the whole basis of the original point is that there is no true universal time, and this post (essentially) says "provided that there is universal time then I can't see what you are complaining about"

Swing and a miss.

</comment><comment><USER28> I'm actually exploring the usage of Redlock in one my projects and the first question I've is - How can you count on a program to end in a given time? That feels similar to Halting problem. The only option I've is to use an external program to kill the program that's using the lock after the lock's expiration period.

<comment><AUTHOR> Note: you have the same issue with all the other dist locks with auto-release. If you have a mission critical use case you could:

1\. Try real time kernel extensions.

2\. Try a time bomb or watchdog process as you suggested.

3\. Put monitoring systems to avoid load to go over a certain level.

4\. Tune the Linux scheduler params.

5\. Use TTLs that are comparatively very large compared to the work you need to do with the lock hold.

</comment></comment><comment><USER29> I'm not distributed systems expert, but I don't see any attempt at responding to:

> 1\. Distributed locks with an auto-release feature (the mutually exclusive > lock property is only valid for a fixed amount of time after the lock is > acquired) require a way to avoid issues when clients use a lock after the > expire time, violating the mutual exclusion while accessing a shared > resource. Martin says that Redlock does not have such a mechanism.

The section "Distributed locks, auto release, and tokens" talks about why Martin's solution isn't right (I'm not well-read enough to tell if that argument is correct), but never actually argues that Redlock has a mechanism to avoid violation of mutual exclusion due to timeouts.

Perhaps I'm missing some background here: does such a mechanism exist?

<comment> squeaky-clean (tl;dr, I don't think he does)

I'm also not a distributed systems expert, but this is how I interpreted the arguments. AntiRez is responding to the scenario where a client acquires a lock, hangs, a new client acquires a lock, and the old client comes back and tries to write something based off of a now stale lock. As demonstrated in this image [0]

So the random token ensures that even though many clients may "think" they have a lock, only up to a single client can ever actually have one. The write in the diagram which corrupts the database shouldn't happen, because you'll need to check that your lock token matches the service. [1] (excuse the terrible MSPaint modifications).

Which covers the common cases of lock timeout. But the clients aren't the only part of the system that can violate the mutex. Martin seems to have already thought of this rebuttal:

        You cannot fix this problem by inserting a check on the lock expiry just before writing back to storage. Remember that GC can pause a running thread at any point, including the point that is maximally inconvenient for you (between the last check and the write operation).
        [ ... ]
        If you still don't believe me about process pauses, then consider instead that the file-writing request may get delayed in the network before reaching the storage service. Packet networks such as Ethernet and IP may delay packets arbitrarily

And I don't believe AntiRez answers this (or I'm not understanding when they do :P ). Even if a client makes a write-request at a perfectly valid point in time, when they own the lock, how do I know that by the time the write-request reaches storage, that the lock is still valid? The difference boils down to "redlock guarantees requests are sent during a valid lock", but not "redlock guarantees requests transact during a valid lock"

Martin's fix [2] is similar to the token method suggested, except: A) the write-if-token-matches logic is handled directly by the storage layer. B) It uses an auto-incrementing token.

He spends a few paragraphs making the point that redlock cannot generate good fencing tokens, because it has no good auto-increment consensus. But I don't see how a random token is any worse than an incrementing one if you're just going to straight up reject requests where the token doesn't match. Antirez addresses this, without addressing A.

I would also really like someone to correct me if I'm missing something. The Redlock implementations are very bare-bones with tests or examples of how to actually use them. The Ruby library has a more "advanced" example, which says this at the point where they try writing to the file system:

                    # Note: we assume we can do it in 500 milliseconds. If this
                    # assumption is not correct, the program output will not be
                    # correct.

Which doesn't give me good faith in this...

[0] [http://martin.kleppmann.com/2016/02/unsafe- lock.png](http://martin.kleppmann.com/2016/02/unsafe-lock.png)

[1] [http://i.imgur.com/8rezAaX.png](http://i.imgur.com/8rezAaX.png)

[2] [http://martin.kleppmann.com/2016/02/fencing- tokens.png](http://martin.kleppmann.com/2016/02/fencing-tokens.png)

[3] [https://github.com/antirez/redlock- rb/blob/master/example2.r...](https://github.com/antirez/redlock- rb/blob/master/example2.rb)

<comment><USER30> > But I don't see how a random token is any worse than an incrementing one if > you're just going to straight up reject requests where the token doesn't > match.

No, random tokens are not worse per se, they just have no place in the algorithm Martin described. It's a completely different system. In that system incremental tokens presume a mechanism that gives you a way to have some order of events. And one can rely on that order to decide which requests with which tokens to reject.

</comment></comment></comment><comment><USER31> > All the time Martin says that "the system clock jumps" I assume that we > covered this by not poking with the system time in a way that is a problem > for the algorithm, or for the sake of simplicity by using the monotonic time > API. So:

> About claim 1: This is not an issue, we assumed that we can count time > approximately at the same speed, unless there is any actual argument against > it.

[https://aphyr.com/posts/299-the-trouble-with- timestamps](https://aphyr.com/posts/299-the-trouble-with-timestamps)

> Timestamps, as implemented in Riak, Cassandra, et al, are fundamentally > unsafe ordering constructs. In order to guarantee consistency you, the user, > must ensure locally monotonic and, to some extent, globally monotonic > clocks. This is a hard problem, and NTP does not solve it for you. When wall > clocks are not properly coupled to the operations in the system, causal > constraints can be violated. To ensure safety properties hold all the time, > rather than probabilistically, you need logical clocks.

> A somewhat less safe but reasonable option is to use NTP rigorously on your > machines, and sync it to TAI or GPS instead of POSIX time or UTC. Make sure > you measure your clock skew: everyone I know who says they run NTP has > discovered, at one point or another, that a node was way out of sync. If you > want rough correspondence to POSIX time, you can still ensure monotonicity > by running your own NTP pool and slurring leap seconds over longer time > frames.

Clock skew is a very real problem and virtually impossible to avoid 100% of the time. Particularly when you have things like leap seconds where the fundamental concept of how many seconds in a day get changed.

[https://en.wikipedia.org/wiki/Leap_second](https://en.wikipedia.org/wiki/Leap_second)

 __System clocks are fundamentally unsafe if you just use NTP. __That isn 't to say you can never do it. Some use cases it is "safe enough" [e.g. Analytics, Metrics] where the occasional fuck up isn't substantial but Antirez isn't making that argument with Redlock as far as I can tell.

> "Okay, so maybe you think that a clock jump is unrealistic, because you're > very confident in having correctly configured NTP to only ever slew the > clock." (Yep we agree here ;-) he continues and says…)

That still isn't reliably safe because there is no guarantee all nodes will perform the slew identically.

</comment><comment><USER32> This entire debate reminds me quite strongly of Peter Bailis's talk at MesosCon last year on designing distributed systems to avoid coordination where possible. It is a really excellent talk for anyone into this sort of thing:

[https://www.youtube.com/watch?v=EYJnWttrC9k](https://www.youtube.com/watch?v=EYJnWttrC9k)

[https://mesoscon2015.sched.org/event/3Aot/keynote-silence- is...](https://mesoscon2015.sched.org/event/3Aot/keynote-silence-is-golden- coordination-avoiding-systems-design-peter-bailis)

</comment><comment><USER19> The article calls on someone(?) to Jepsen test Redlock, which is a good idea, but I think that the author(s) of such systems should release their own Jepsen test suite along with the software they're purporting to be safe (as others have done [1][2][3]). I would suspect that operations on Redlock, when subjected to nemesis that partition, kill and skew-clocks on various nodes, would not be found linearizable.

In general, I don't understand why one would build a system that attempts to approximate consensus without just using one of the proven consensus algorithms. Redlock is not the only one here, there are other systems that do this as well.

[1] [https://github.com/atomix/atomix- jepsen](https://github.com/atomix/atomix-jepsen)

[2] [https://www.datastax.com/dev/blog/testing-apache- cassandra-w...](https://www.datastax.com/dev/blog/testing-apache-cassandra- with-jepsen)

[3] [https://foundationdb.com/blog/call-me-maybe-foundationdb- vs-...](https://foundationdb.com/blog/call-me-maybe-foundationdb-vs-jepsen)

<comment><USER33> The problem with Jepsen is that it can prove that systems are unsafe, but it can't be used to prove that systems are safe.

For example Consul did their own Jepsen testing[1] in which they passed them, but Kyle pointed out [2] that they passed them only because they changed timeouts from 1 s to 300 ms effectively making the race condition window smaller.

[1] [https://www.consul.io/docs/internals/jepsen.html](https://www.consul.io/docs/internals/jepsen.html) [2] [https://aphyr.com/posts/316-call-me-maybe-etcd-and- consul](https://aphyr.com/posts/316-call-me-maybe-etcd-and-consul)

<comment><USER34> It's typicaly not tractable to prove that a system is safe. For example, RethinkDB used the raft consensus algorithm, which on its own is proven correct, but due to a bug could in some cases break linearization. Jepsen was able to uncover this.

The best method we currently have for demonstrating that large systems are safe is to try really hard to prove that they are unsafe and fail.

</comment></comment></comment><comment><USER35> For problem 1, you'd use a distributed lock to update more than one resource. A single resource could very well implement its own lock in which case you don't need a distributed lock. But once you have more than one resource to update, you do.

A lock should result in linearized access (all resources updated while holding the lock should be updated in the same order based on the time when the lease was granted). A counter is enough to put the updates in order. Giving leases a unique id doesn't do that - the network could reorder writes seen by two different resources. Fencing ensures that if the network does reorder writes, one of them fails.

The lock is acting sort of like a clock that ticks whenever it hands out a lease. The resources effectively update their local clock whenever they see an update with a new token from the central clock, and use this local clock to detect stale writes.

Note that fencing doesn't guarantee that writes don't happen late - <USER2> updates could be delayed by 10 seconds and it wouldn't catch it. But it isn't feasible to prevent this on systems with bad clocks connected by a flaky network.

</comment><comment><USER21> I don't understand many of the leaps you make in your argument. From what I can see, you're defending that Redlock is "good enough" in cases where you don't care about your computers hating you. This is not a good environment for distributed systems when you need strong correctness properties.

Reading through the original description of Redlock[1] and your "rebuttal" is interesting. The algorithm described in the spec isn't safe if a GC pause or process pause happens between <checking how long it took to acquire a majority> and <doing work and releasing the lock>. You don't even touch this argument (pretending to not understand which step is the problem and defending that everything before the gap I just described is safe).

You claim that fenced tokens require linearizablity. I don't know if this is true, but even if it is all you've proven is that the solution offered isn't good enough. The fact that something that tries to fix your system doesn't fix it properly doesn't mean that your system isn't broken.

</comment><comment><USER15> Have you read this Salvatore? [http://research.microsoft.com/en- us/um/people/lamport/tla/fo...](http://research.microsoft.com/en- us/um/people/lamport/tla/formal-methods-amazon.pdf)

> ... The good thing is that distributed systems are, unlike other fields of > programming, pretty mathematically exact, or they are not, so a given set of > properties can be guaranteed by an algorithm or the algorithm may fail to > guarantee them under certain assumptions. In this analysis I'll analyze ..

Saw no mathematics in your article.

<comment><AUTHOR> Unfortunately to test Redlock with a formal method is pretty useless. The algorithm is so trivial, for the part you can mathematically model it, that is a wasted effort to model it: even with a proof of the lock acquisition process it all boils down to "is the system model credible"? And that's what we are debating. Note that similarly Martin don't even try to address the problem of _how_ the lock is acquired for the same reason I guess. Also note that if you try to model the problem adding unbound processes pauses, and put as a requirement mutual exclusivity with auto-release, I don't think there is a way the model will ever be validated, _whatever_ system you model implementing this.

<comment><USER36> I'm still relatively new to formal specification but it seems that some form of weak/strong fairness would suffice for the correctness of your invariant and then it's a matter of testing your liveness properties while holding the invariant with a model checker.

TLA+ seems pretty good at this. Why would this be a waste of effort?

</comment></comment></comment><comment><USER37> I don't see a distributed lock implementation being both 100% correct without any support of the resources guarded by the lock and actually feasible.

For data which absolutely must never violate the lock then the underlying data storage has to be involved. The vast majority of times where a distributed lock is used is where the underlying storage doesn't provide any support and the distributed lock is good enough, failures are exceptional and not disastrous.

If you want perfect correctness then you can just not have auto-release but practically this will cause more problems than it solves.

</comment><comment><USER38> I understand how a fencing token can prevent out of order writes when 2 clients get the same lock. But what happens when those writes happen to arrive in order and you are doing a value modification? Don't you still need to rely on some kind of value versioning or optimistic locking? Wouldn't this make the use of a distributed lock unnecessary?

<comment><USER39> > But what happens when those writes happen to arrive in order and you are > doing a value modification?

I believe the "first" write fails, because the token being passed in is no longer "the lastest", which indicates their lock was already released or expired.

</comment></comment><comment><USER40> Would something like Google TrueTime help in this scenario. My takeaway being accurate with time...

</comment><comment><USER36> Neither the specification nor the analysis contain a formal, verifiable specification. How can one test an invariant and properties and make real conclusions about the safety/liveness of Redlock without it?

Is it not useful to do so?

</comment><comment><USER41> I don't understand how the migration to a monotomic clock source is treated as a trivial move. In practice, using a monotomic clocks source makes coordinating lease time records correctly even more complicated.

</comment><comment><USER41> I don't understand how the migration to a monotomic clock source is treated as a trivial move. In practice, using a monotomic clocks source makes coordinating lease time records correctly.

</comment><comment><USER42> What does "linearizable" means in this context?

<comment><USER43> there's a formal definition but informally it means every participant agrees on an order of events in a system. if a system is linearizable you can safely compare-and-set to mutate state without introducing conflicts

</comment></comment><comment><USER44> The first step to getting out of the hole is to stop digging. The author of this article clearly hasn't learned this lesson yet.

</comment><comment><USER45> There's no salty like antirez salty. I have mad respect for the guy as a programmer, but he needs to take things a bit less personally IMO.

<comment><AUTHOR> Sorry I did not meant to be rude.

<comment><USER46> Fwiw, I didn't perceive your piece to be rude. I'm not sure who's right, but it seems like everyone is being civil.</comment></comment></comment>


Chuck Moore's Creations - <AUTHOR> http://blogs.msdn.com/b/ashleyf/archive/2013/09/21/chuck-moores-creations.aspx <comment><USER2> If you want to play around with the F18A instruction set, I wrote an emulator for it[1]. This also comes with a system to synthesize F18A code with MCMC, using the basic technique from the Stochastic Superoptimization[2] paper.

Additionally, there is an interesting project I worked on with several other people to make writing code for GreenArrays more accessible[3]. This includes a system for synthesizing and verifying F18A code using two different solvers (Z3 and Sketch[4]) as well as a system for automatically partitioning and laying out code over the different cores. It's a work in progress, but well worth a look.

[1]: [http://hackage.haskell.org/package/array- forth](http://hackage.haskell.org/package/array-forth), [https://github.com/TikhonJelvis/array- forth](https://github.com/TikhonJelvis/array-forth)

[2]: [http://cs.stanford.edu/people/eschkufz/research/asplos291-sc...](http://cs.stanford.edu/people/eschkufz/research/asplos291-schkufza.pdf)

[3]: [http://www.forth.org/svfig/kk/11-2012-Bodik.pdf](http://www.forth.org/svfig/kk/11-2012-Bodik.pdf)

[4]: [https://github.com/TikhonJelvis/array-forth- sketch](https://github.com/TikhonJelvis/array-forth-sketch), [https://bitbucket.org/gatoatigrado/sketch- frontend/wiki/Home](https://bitbucket.org/gatoatigrado/sketch- frontend/wiki/Home)

</comment><comment><USER3> Amazing architecture; I remember reading about it and colorforth several years ago when I was researching parallel architectures. I almost want to buy a chip and mount it on a schmartboard, but I've got so much going on right now that I know it would probably sit there after that.

The real reason for my comment, however, is a question: is that idiomatic F#? If so, I like it! It's got a lot of Haskell's succinctness, power, and functional goodness without becoming a tangled mess of indecipherable symbols. Yes, you can write Haskell this way, but in my experience, almost no one does. If this is typical for F#, it deserves a (very close) look.

Add to that the fact that I was impressed with the readability and power of a bit of C# code the other day. I really got to give these MS languages another chance. It's too bad I can't stand the OS (and yes, I've tried Windows 8 -- even worse). How's Mono these days?

<comment><USER4> Well F# is basically ML.net so why not check out OCaml? Same language, and no windows required.

<comment><USER5> Basically, yes.

But in detail, "F# is basicall ML.net" is about as useful a language summary as "Objective-C is basically C++.mac". Despite the common heritage, the two feel quite different once you sit down and spend some time with them.

And seriously, this "the Common Language Runtime is only available on Windows" trope needs to die. Mono's been around for. . . what, a decade now? Something like that.

<comment><USER6> I agree that the underlying runtime and ecosystem affect the "feel" of programming in a given language a lot, but the comment above was specifically referring to the snippet of F# in the blog post, which could be trivially translated into OCaml.

AFAIK the main differences around the runtime are that the CLR has true concurrency and access to more libraries without using FFI, while OCaml is able to produce very tiny executables (~200kb) if you use the native compiler.

<comment><USER5> Sounds like the differences go rather farther than you know:

The object model's really quite very different - F# uses CLR objects instead of OCaml-style ones.

F# has computation expressions, which are a rather nice riff on monads.

F# doesn't have functors. Since it uses CLR objects it does have .NET generics, but it's just not the same

Active patterns and type providers are neat, too. Though I believe there are Caml macros that implement both.

<comment><USER3> From my research, it looks like F# does not have structural typing (since it uses the .net type system). Does this mean you can't use constraints on types, like make a type with a range (0.0-1.0) or a type from an enum (man|woman|child)?

These kinds of type constraints are one of my favorite things about Haskell, and one of the reasons I'm really interested (in another language category) in Ada -- you can actually model real-life things using the type system.

<comment><USER5> F# uses nominal typing - that's another difference between it and Caml.

That said, F# will let you do the things you listed - one can be handled with traditional OOP techniques, and the other is handled by discriminated unions. Structural typing is a bit different from what you're describing - it's more a kind of compile-time duck typing.

I actually think F#'s switch to nominative typing is a big improvement over its Caml roots. When I'm trying to build out a type system that's meant to use type checks to enforce sanity, I want to have explicit control over when and where types are considered to be equivalent. Just because the types foo and bar implement members with similar signatures does not mean that they carry the same semantics.

Therefore, IMO having the language try to be clever and jump to the conclusion that anything that looks like a duck must be a duck is a hindrance to type safety. It's also a bit of a maintainability hassle: Having a formal type definition for each equivalence class makes it easier to find which types need to be modified accordingly when an equivalence class's definition changes.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> As someone with little interest or knowledge in low level hardware, what are the advantages of this? What would you use it for?

edit: Just to clarify, with little interest I mean little interest in acquiring in-depth knowledge about it. I'm still interested in hearing about advances like this and their uses.

<comment><USER2> The main advantage is that it's _exceptionally_ power-efficient. Take a look at the chart on these slides[1] for more details. It gets this efficiency despite being manufactured with relatively outdated methods--if I'm not mistaken, it has 150nm transitors!

[1]: [http://www.greenarraychips.com/home/news/docs/GreenArrays- Fo...](http://www.greenarraychips.com/home/news/docs/GreenArrays-Forth- Day-2012.pdf)

My understanding is that it's power efficient because the stack-based design allows you to transfer very little data in and out of registers. Additionally, the chip is very simple, has very few transistors and no clock. All this helps save power. Also, the cores can power down very quickly when they're not used, meaning you only pay the energy cost of the ones you _are_ using at the moment. Of course, you shouldn't take my word for it: I'm desperately not a hardware person.

I've heard several compelling ideas for using these chips. They're a good fit for small, simple devices that need a long battery life: things like sensors in everyday goods and such, think "internet of things". Another possibility is using them in phones so that the main, power-hungry chip could go to sleep leaving a chip like this to monitor inputs and awaken the phone if needed.

<comment><USER8> This is not exceptionally power efficient. It does around 90 gigaops/sec(probably 5bit ops) and programmable only in forth. Parallela has a chip that does 90 gflops/watt and is programmable in c/open-cl/r and maybe other tools. That's much more usefulland power efficient.

But what about better manufacturing technologies for the F18A chip ? first, it negates some of the advantages of working asynchronously , because the much higher leakage current. Second, the processors game was always about software tools and ecosystems, which is the weak point of the F18A, and without solving this , we won't see it in more advanced manufacturing processes.

<comment><USER9> Actual power efficiency depends on the application of the CPU. If you have a use case that mostly leaves the CPU in an idle state only to react on occasional events, the F18A would probably be more efficient than the Parallela chip.

</comment></comment></comment></comment><comment><USER10> I live in Northern California near Chuck Moore. He came and spoke at our office last week and showed off the new GreenArrays architecture. Afterwards we were trying to come up with things to disrupt with a super low power / massively parallel chip like that. The problem he brought up is that in products like smart phones the power usage is in the display and the radio. So there isn't much savings in a lower power processor.

But... After the discussion several of us wondered about electronic ink signage. With the Green Arrays stuff you could definitely be completely solar powered.

It would also make an interesting Personal Area Network central control unit for Quantified Self stuff using harvested energy.

I would support a kickstarter for either of those, but I'm not going to pursue them myself right now.

Green Arrays: [http://www.greenarraychips.com/](http://www.greenarraychips.com/)

</comment><comment><USER11> So, I'm actually looking right now for a microcontroller to run a bunch of real-time I/O that may involve a certain amount of fairly timing dependent bit-banging. I'm planning on building a pinball machine, and so need something that can take input from a couple of buttons, a bunch of switches and some sensors, and drive a bunch of solenoids, LEDs, and the like.

Since I will need to do a bunch of PWM or possibly bit-banged serial protocols to drive all of the LEDs, and I want to have good real-time guarantees on input from the buttons and driving the solenoids, I'm trying to figure out what microcontroller I should use; something like a Propeller, or an FPGA, or maybe one of these, or something else entirely.

Anyone have any experience with these kinds of issues? Will the GA144 be able to do some fairly timing-dependent bit-banging reliably? I notice in the docs that they say the time it takes for each instruction to execute is not fixed. How would you go about doing a timing dependent protocol on these? Is there a high-resolution timer you can poll to ensure that your transitions occur in a timely manner? Or should I bite the bullet and start learning FPGA programming?

<comment><USER12> Your solenoid response time is likely to be much, much slower than the bit- banging rate of any modern uC. A standard PIC or similar would do fine (assuming it has the I/Os you need).

<comment><USER11> For solenoids, sure, though some of them (the flipper solenoids) need to be PWMed to vary their strength; you do a full-strength pulse at the beginning to drive the flipper with a good amount of force to hit the ball, but when you hit the end of the stroke, there's a switch that tells you to switch to PWM with a low duty cycle so you avoid overheating the solenoid but can still hold the flipper up to trap the ball. So you need at least the ability to PWM that. Sure, I could probably build a little timer circuit to do that, but it would be convenient if I could just bit-bang a GPIO pin instead of building more hardware.

For driving a few dozen RGB LEDs with PWM to control brightness on each of the three channels, you're very quickly going to reach the limits of what you can do with a standard PIC. Or even if not driving the LEDs directly but using something like these: [http://www.adafruit.com/datasheets/WS2812.pdf](http://www.adafruit.com/datasheets/WS2812.pdf) you need to be able to produce a fairly high precision 800 khz serial signal with no clock.

Between the number of inputs and outputs needed (lots of switches and sensors on the playfield, lots of solenoids to kick out balls and control various toys, lots of LEDs), and the high-speed output needed to drive the LEDs, I'm not sure a standard PIC is going to cut it, though I haven't actually sat down to calculate out the precise number of I/Os and speed that I'll need so I may be wrong. I'm more looking for a ballpark of what I should get a dev board for and start playing around with, I may wind up changing my mind and switching to something else later.

<comment><USER12> For the LEDs and solenoids I'm guessing the PWM frequency is in the sub 1 kHz range, so you should be able to bit-bang perfectly well with even a low- powered uC. Timing precision for those shouldn't be very strict.

As for the WS2812, that's annoying :) It would be nice if it could use SPI or a UART. I see the NeoPixel library uses bit-banging with interrupts disabled and relies on instruction timing, yuck. But hey, it might work. I've seen single-wire stuff work on Windows CE, for crying out loud. AFAIK you don't need a continuous 800 kHz signal, you can just send it when you want to update.

<comment><USER11> Yeah, the WS2812 does have a fairly unique interface, but at 45¢ for an RGB LED with a built in constant current driver, it's pretty much the cheapest option per LED. Other options I've seen like the A6281 are $2 for just the driver itself, without the LED.

Since there are probably going to be at least a few dozen LEDs, the per LED cost can add up quickly, so I'm fine with spending a bit more on a more powerful microcontroller or FPGA and learning a new system. And of course, part of the goal is to learn new things and have fun with the project, so some of these new highly parallel microcontrollers like the GA144, Propeller, XMOS, or even an FPGA would be more interesting to work with than a standard PIC, even if they may technically be overkill.

This is the first time I've done hardware hacking in a while; the last time I did it I used a 68008 as my microcontroller. So I'm hoping to find something that will be interesting to learn, not too hard to use, and capable of everything I'm going to throw at it, so I don't have to go through several iterations of buying expensive development boards only to discover that I can't drive my dot matrix display or I can only drive half of the playfield LEDs that I need or that interrupts from the flipper buttons cause my LED color fades to flicker since they screwed up the timing of my signal to the driver or something of the sort.

One of the problems is that since there are so many choices, and I haven't done hardware hacking in a while, I don't have a good sense of what I'll be able to do yet. Maybe I should start small, with an Arduino or a PIC or something of the sort, and move up if I discover that that can't do something that I want.

<comment><USER13> Coming back into the hardware world after being away for several years, I find the ARM Cortexen pretty damn compelling for the possibility to do the high level programming in something besides C. And a STM32F4 Discovery board is only ~$15.

(And yeah, I feel dirty for blowing up a GreenArrays thread with a suggestion for a more traditional microcontroller, especially not having really studied the GA chip.)

</comment></comment></comment></comment></comment></comment><comment><USER14> If you are interested in a more "conventional" Forth chip, check out the J1[1]. It's 200 lines of verilog, so you can put it on an FPGA pretty easily.

But it's even easier than that because the J1 is the basis of the Gameduino[2]. The Gameduino is a shield for Arduino that gives you a VGA interface, sprites, and graphics.

[1]: [http://www.excamera.com/sphinx/fpga-j1.html](http://www.excamera.com/sphinx/fpga-j1.html)

[2]: [http://excamera.com/sphinx/gameduino/](http://excamera.com/sphinx/gameduino/)

</comment><comment><USER15> I was at Chuck Moore's talk at Strangeloop, it was... esoteric. From what I gather, it's not really something you'd want to write a full application in - Forth came across to me as a very low-level language, much like assembler. Which makes sense given how the chip executes it natively.

also the dude did not wear shoes.

<comment><USER16> Forth is actually pretty high level. You just have to get there first by building up the abstractions. You can end up with an almost Ruby/Python like language on top of it if you want. But you probably won't want that after using Forth for a bit and will end up writing DSL's for your programming concerns.

The use case I had for Forth was a PLC-like controller. You ended up describing the configuration in Forth by the time the abstraction was built. Example for a simple "virtual relay" controlled light switch taht turns two separate circuits on and off in a ladder:

       bob relays
       0 switch inports
       1 light1 2 light2 outports
       switch inport
          bob coil
          ladder
       bob contact
          begin
             light1 outport
             light2 outport
          logical-and
          ladder
       plc

Was awesome. Unfortunately I don't have rights to the source. It ran on a Z80 board.

<comment><USER17> Forth is quite interesting, and cool in its own way, but: how can anything where you have to remember what is supposed to be on the stack 'high level'?

<comment><USER18> As I understand it, the ideal in Forth is to build up a base that hides those complexities in a domain appropriate API. You don't throw 3 numbers onto a stack and leave them on the stack to represent a vector, you wrap that up with a call to 'make-vector', and from there on you're dealing with 'vectors' as a unit rather than '3 points on the stack'. Or if you don't, you develop an API that deals with them sensibly so that every routine that operates on vectors doesn't have to get into the nitty-gritty. Write a routine that represents the common operations (add-vectors, multiply-by-scalar, dot-product, etc) and build your complex routines on those, so that vector projection could be:

        : project-a-onto-b (a b -- c) swap rot dot-product swap scalar-mult;

Ok, 3 stack manipulations but someone who's done more than just toy programs in RPL and Forth might be able to come up with some other routines that can hide those as well. EDIT: And once written, the user of the routine needs to know, "put the two vectors onto the stack, the first one is what I'm projecting, and the second is what I'm projecting onto".

Another point to consider, dynamically typed languages suffer a similar 'failing' if they're to be considered 'high level'. How can they be 'high level' if you can add 1+"b"? (in code, won't work in runtime unless it's weakly typed, similar to having too few items on the data stack). How can any language be considered 'high level' if you have to remember how many parameters, their types and in what order for every function call?

<comment><USER16> Nice to see a mention of RPL. Still use an RPL machine daily (HP50g)

<comment><USER18> Tragically, my HP48G+ (?? I know this model exists, may have been mine, sounds right) bit the dust a few years back (water damage, think it happened while stuff was in storage between residences). It wouldn't be particularly useful in my day-to-day stuff, but RPL is probably the main reason Forth seemed so natural to me when I played around with it a few years back.

</comment></comment></comment></comment></comment></comment><comment><USER19> What to do with 144 cores? I just watched a video last week about a guy doing SDR to monitor wireless tire pressure transmitters. Every car sold since 2010-ish has at least four of them, each with a unique 32 bit ID, for police tracking purposes, err, to "save the children" or whatever BS.

Anyway the complaint was there are 127 or 121 or some prime number of different algorithms from different mfgrs so you need to run 120-something decoders to completely decode each protocol. This is a pain with a single core laptop. But with a 144 core forth chip I think giving each precisely one protocol to decode in parallel would be fine.

</comment><comment><USER20> Sounds like the future if just for the low-power. « 144-core asynchronous chip that needs little energy (7 pJ/inst). Idle cores use no power (100 nW). Active ones (4 mW) run fast (666 Mips), then wait for communication (idle).»

<comment><USER21> You're right -- it sounds like the future for several reasons. I can't wait to get my hands on an eval board.

Why is it that if I have to list the three or four people doing the most to break new ground in our industry, they're all over 60? Chuck Moore is _75_ and he's doing this.

<comment><USER22> Here is a sample application note detailing an integration with the TI SensorTag:

[http://www.greenarraychips.com/home/documents/greg/AN012-130...](http://www.greenarraychips.com/home/documents/greg/AN012-130606-SENSORTAG.pdf)

</comment></comment></comment><comment><USER23> I saw a RMBP installed Windows while using the native resolution (2880x1800).

Maybe he needs more area instead of neater display. Screen area is extremely important for an electronic engineer.

</comment><comment><USER24> The fun thing is that you can buy a 10 pack of chips off the GreenArrays website for $200.

</comment><comment><USER25> I would love to see this video. The only link I could find [1], unfortunately, was behind an auth wall restricted only to attendees of the event. Does anyone know where it might be found?

1\. [http://www.infoq.com/presentations/power-144-chip?utm_source...](http://www.infoq.com/presentations/power-144-chip?utm_source=infoq&utm_medium=QCon_EarlyAccessVideos&utm_campaign=StrangeLoop2013)

<comment><USER26> There's some on youtube in the manufacturer's channel, Greenarray.

[https://www.youtube.com/watch?v=NK1zlz67MjU](https://www.youtube.com/watch?v=NK1zlz67MjU)

Also maybe try the designer's site, Chuck Moore. Google Colorforth.

</comment></comment><comment><USER27> I'd really like to see a Verilog/VHDL design of this chip to see how it works. Does anyone know if I can get that?

<comment><USER10> It doesn't work that way.

This isn't a Verilog/VHDL implementation, but instead a physical chip.

Also he implemented the chip design tool in FORTH as well.

<comment><USER27> Okay, so how did he design the physical chip? Physical design starts with some kind of RTL, usually. Unless he mapped out the chip on a transistor level by hand, he used some kind of software to aid him in the design. If he didn't use Verilog/VHDL, I'd like to see whatever logic-level design he did make.

<comment><USER28> He did design the physical chip, gates and all. He wrote the design software himself (supposedly, 500 lines of forth called OKAD). He uses a simpler model that is accurate enough for the process he is using.

[http://www.colorforth.com/vlsi.html](http://www.colorforth.com/vlsi.html)

Everything he does is fascinating, but don't expect any of it to be useful unless you are, in fact, Chuck Moore (perhaps Chuck Norris also gets a pass...)

</comment></comment></comment></comment><comment><USER12> The F18A reference doc is amazingly concise; all you need to know about the architecture in about 10 pages.

[http://www.greenarraychips.com/home/documents/greg/DB001-110...](http://www.greenarraychips.com/home/documents/greg/DB001-110412-F18A.pdf) (PDF)

</comment><comment><USER29> I've had two separate people tell me about forth and green arrays this past week. My interest in piqued. Someone please point me in the direction of a good introduction to the language and its merits.

<comment><USER10> This is a nice, concise overview: [http://cs.earlham.edu/~stoneda/cs71/](http://cs.earlham.edu/~stoneda/cs71/)

Why Forth: [http://bernd-paysan.de/why-forth.html](http://bernd-paysan.de/why- forth.html)

</comment></comment><comment><USER30> Why the change to an uninformative title from 'A CPU with 144 "tiny" computers, without clock and 5-bit instructions'?

</comment><comment><USER31> How is this different from CUDA?</comment>


Photography in Space - <AUTHOR> http://www.luminous-landscape.com/locations/photography_in_space.shtml

<comment><USER2> What should be an interesting blog is, sadly, ruined by terrible image quality.</comment>


Study reveals the Great Pyramid of Giza can focus electromagnetic energy - <AUTHOR> https://www.eurekalert.org/pub_releases/2018-07/iu-srt073018.php <comment><AUTHOR> Link to the actual study: [https://aip.scitation.org/doi/10.1063/1.5026556](https://aip.scitation.org/doi/10.1063/1.5026556)

<comment><USER2> Since it's paywalled, can you tell me the actual point?

That is, does it mean that every pyramid has these properties? Or does it suggest that there's something specific about the Great Pyramid of Giza which isn't true of any other pyramid?

For that matter, doesn't any building have the ability to focus radio waves, to at least some extent?

</comment></comment><comment><USER3> I read that already in the 60ies. Some Czech inventors then even sold products using that interesting feature.</comment>


Robinhood rockets to a $5.6B valuation with a massive new funding round - <AUTHOR> https://techcrunch.com/2018/05/10/robinhood-rockets-to-a-5-6b-valuation-with-a-massive-new-funding-round/ <comment><USER2> Gambling closely ties into a fundamental human interest.

A legal gambling app is definitely hugely valuable.

I truly mean to say this in the most positive angle possible. I think they are providing a valuable service and a great app, but it is a very nice business as well due to the above.

Kudos to the team.

<comment><USER3> I've yet to see any indication that people "gamble" (day trade) more when it's free versus fee. Is this a fair criticism to level on Robinhood?

Besides, they have day-trading limits built into the app. It's really just a mobile-first brokerage with extremely low net fees. And I'm grateful for it.

<comment><USER2> It was not aimed to be critical at all, just a comment on the attractiveness of the business.

Anecdotally, it definitely feels like it has broadened the base of the retail investor audience (which I think is a great thing) and if you have seen the options and crypto currency UIs it strikes similarities with fantasy football and makes those objects shinier.

</comment></comment></comment><comment><USER4> I'm not a Robinhood user, so correct me if I'm wrong. But as someone who's used ~5 different online brokerages, I'm having a hard time understanding what innovation they brought to the table. Buying/selling stocks online is already pretty damn simple, and takes 1-2 minutes tops. Where exactly is the innovation here? _" We're going to undercut the competition and save users a couple clicks"_ is now a $5B business idea? Kudos to the founders, but this hardly seems like the stuff movies are made of.

<comment><USER5> No commissions on any stocks or ETFs. No commissions is huge when you want to create a diversified portfolio, buying only a few shares of each at a time. No other brokerage has even come close to trying to provide this. Robinhood earned a lot of brand reputation with this move.

UX. Try out a few other brokerage experiences, and then try Robinhood, and you'll see that the market was ripe for the taking for a team with design sensibilities.

<comment><USER6> Using a broker because they have $0 commissions seems to me like going to a car dealer because they don't charge a $50 doc fee when you buy a car.

</comment></comment></comment><comment><USER7> The thing about Robinhood is that it doesn't feel like a financial services company.

Their advantage is an ineffable quality.

The closest I can come to describing that feeling of using the service is it's like someone in your family made it for you.

This may sound strange, but there's a lot of love there. That level of attention to detail and quality is rare and apple-like.

<comment><USER6> I found it amusing that Baiju Bhatt compared ill-informed investing encouraged by Robinhood to dropping your iPhone in the toilet.[1]

[1] [http://fortune.com/2015/03/12/robinhood-investing- app/](http://fortune.com/2015/03/12/robinhood-investing-app/)

</comment></comment><comment><USER8> Oh, that's nice. Can it land on a barge?</comment>


Ask HN: Companies with open vacation policies - <AUTHOR>

How do you see it working in practice? <comment><USER2> I was an early employee in a start-up that had this policy. It felt very ambiguous. There is what people say and what they do. Even though it sounds great, in terms of flexibility and lack of HR stuff to deal with. In practice people tended to take off less time than they would have taken in a larger corporation because there was only one of every role. If you are gone there is really no one to effectively step in for you.

In the future if I go back to being an employee, I would rather have a generous but clear vacation policy.

It has the possibility for over-abuse by some and under-utilization through fear or tendencies to overwork by others.

If I were joining a company that was pitching this as a strong benefit I would want to ask around informally and see whether people were actually supported in taking 2 or 3 week block vacations. If not, then it is a benefit that is actually being taken away under the guise of freedom and generosity,</comment>


ScummVM ported to HTML5 - play old games in your browser - <AUTHOR> http://clb.demon.fi/html5scummvm/ <comment><USER2> Awesome! The future rolls on. Thanks!

This message for anyone who frantically dug through the box for Disk 22, confusedly hoping to find it among the ~6 installation disks [1]:

I excitedly clicked through, hoping, jonesing, for the Monkey Island theme. Alas, sound doesn't seem to work for me (Chromium 26, Debian).

If you needed the same fix, you can find it here: [http://www.youtube.com/watch?v=1IOL4q5tDDQ](http://www.youtube.com/watch?v=1IOL4q5tDDQ)

[1]: [http://www.miwiki.net/The_Stump_Joke](http://www.miwiki.net/The_Stump_Joke)

<comment><USER3> Sound missing for me too, Chrome Version 27.0.1453.93 on OSX

<comment><USER4> Sound is working fine on Firefox 21 on Linux (Fedora 19 x86_64)

</comment></comment></comment><comment><USER5> I'd love to see Beneath a Steel Sky in HTML5 form.

[http://en.wikipedia.org/wiki/Beneath_a_Steel_Sky](http://en.wikipedia.org/wiki/Beneath_a_Steel_Sky)

[http://www.gog.com/gamecard/beneath_a_steel_sky](http://www.gog.com/gamecard/beneath_a_steel_sky)

<comment><USER6> It's supported by ScummVM (name is deceptive, supports far, far more than just SCUMM), so the module for that game could surely be compiled.

<comment><USER5> Note: [http://www.revolution.co.uk/](http://www.revolution.co.uk/) made a remastered edition, so I'm not sure of the legal status of the game (i.e. if any demo or full versions are available for projects like this).

<comment><USER7> The original PC versions can be downloaded legally from the ScummVM web site, along with _Lure of the Temptress_.

You can also download _Flight of the Amazon Queen_ , _Dreamweb_ , _Drascula_ and _Slotys_ (from other editors).

At least one Revolution programmer is also a ScummVM contributor, BTW.

[http://www.scummvm.org/downloads/#extras](http://www.scummvm.org/downloads/#extras)

<comment><USER8> Actually, Broken Sword I & II aren't free downloads; the downloads on ScummVM's pages contain the games' cutscenes transcoded from Bink Video to MPEG2.

It turns out that unlike many of the technologies ScummVM reverse-engineers and reimplements, the Bink video codec is still commercially available, and the Bink people refused to let ScummVM release their reverse-enigneered decoder. So, if you want cutscenes in Broken Sword games, you need to download them in a format that ScummVM can decode.

<comment><USER7> My bad. Corrected.

</comment></comment></comment></comment></comment></comment><comment><USER7> It is off course down.

From the little I could see through the Google cache, the port is based on Emscripten. The site provides the demo versions of a few SCUMM games.

</comment><comment><USER9> I've been wondering when some old games would be ported to JS via Emscripten. Now ScummVM is in the browser!

What I'd love to see next is OpenTTD!

<comment><USER10> Not too surprisingly, that's already been done. [http://play- ttd.com/](http://play-ttd.com/) Additionally I think this has been around for about a year at this point :)

<comment><USER9> Woah! That's super awesome! Thanks!

</comment></comment></comment><comment><USER11> So much is converted to Javascript with Emscripten now. I used it for [http://www.fabfabbers.com/openscad/](http://www.fabfabbers.com/openscad/) too.

Just hoping asm.js support catches on.

</comment><comment><USER12> Old Sierra games are availble with HTML5 at [http://sarien.net/](http://sarien.net/) \- is the html5 ScrummVM really new?

[http://mikeconley.ca/blog/2012/01/08/monkey-island-1-the- sec...](http://mikeconley.ca/blog/2012/01/08/monkey-island-1-the-secret-of- monkey-island-running-via-javascript/)

<comment><AUTHOR> I truly hope this does not become the highest voted post on this thread.

I sometimes feel like HN is chock full of people that tend to become absorbed with minutia and details that most would not normally consider important.

So it's not completely, wholly, and totally new... big deal. For my edification could you explain to me why this gets your goat?

<comment><USER13> No no no, the GP was absolutely the question I was thinking -- and I'm sure others too, because a HtML5 JS port has been done before and was well-voted on by HN. But the GP's question brought out the real answer of how this is new, and the detail is interesting to web devs

<comment><AUTHOR> "No no no" \-- great start.

"the GP was absolutely the question I was thinking -- and I'm sure others too" \-- which was my point; chock full.

"the GP's question brought out the real answer of how this is new" \-- and the person that elucidated you found out his information how? Yes, that's right... he looked at the site.

Could we quit it with the knee jerk negativism? Please and thanks.

<comment><USER14> danso's comment didn't seem negative to me ("no no no" is just colloquial). This comment does, though.

</comment></comment></comment></comment></comment><comment><USER15> Cool! I think the day is not far when we will see DosBox ported to HTML5 as well.

</comment><comment><USER16> It should add an option to add your own game. Also would be interesting to make it a Firefox OS application.

</comment><comment><USER17> Monkey Island 2: Lechuck's Revenge had a great demo as well. I might recommend adding that.

</comment><comment><USER18> is there a link to a source?

<comment><USER19> [https://github.com/juj/emscripten-scummvm](https://github.com/juj/emscripten- scummvm)

</comment></comment><comment><USER6> ScummVM supports Myst. Now that would be interesting in a browser.

</comment><comment><USER20> Excellent project!

Graphics for Monkey Island in Safari on a Mac seem to be corrupted.

<comment><USER11> It's corrupted on Safari on iPad too. Works really well in Firefox nightly.

</comment></comment><comment><USER21> Uhhhhh this is excellent. Love me some adventure games.

</comment><comment><USER22> Power switch doesn't work plz fix.</comment>


Using JS to detect exit page? - <AUTHOR>

<comment><AUTHOR> I was going to post this at Dev Shed, but I figured out that we probably have a lot of really smart people here, too.

Does anybody have a clue on how to figure out where a user went to after they left your site; basically a way to figure out the user's exit page?</comment>


The Anti-Store: How Price Club and Costco Made Shopping Harder [audio] - <AUTHOR> http://www.npr.org/sections/money/2015/09/25/443519599/episode-653-the-anti-store <comment><USER2> Transcript: [http://www.npr.org/templates/transcript/transcript.php?story...](http://www.npr.org/templates/transcript/transcript.php?storyId=443519599)

This is fascinating for me because I just shopped at Costco for the first time yesterday.

It was completely overwhelming. I was lost in a huge store with no signage. The large packages of merchandise meant my usual heuristics for whether something was a good price went out the window. Everything was utilitarian, streamlined, and huge.

Now I understand that it was deliberately designed this way.

<comment><USER3> Costco prints the unit cost on every price tag. That's not enough for your heuristics?

</comment></comment><comment><USER4> I'm not familiar with planet money, but I'm fascinated by how they never challenged the assumption that warehouse stores & buying in bulk save you money. The closest they come is when one of the hosts admits he impulse- purchased 12 gallons of carrot juice and the interviewee laughs.

Then the story goes into how Jet.com and Costco are cheaper than Amazon, gets a couple other types of digs in on Amazon, and proceeds to expound on the wonders of how Jet.com gives you 24¢ off for each box you buy that ships from the same warehouse.

It really made the whole thing come off like a native advertisement, to my ears.

<comment><USER5> I don't go to Costco primarily to save money. (Most of the time.) Of course, if you're able to plan your meals out enough to use 100% of what you buy from Costco it's impossible to beat them. (Exception: if you're an extreme couponer who has the time and energy to watch grocery store sales, which are rarely on items I actually want to buy.)

I go to Costco because I know I will get something good for a decent price. At the grocery store, it will (probably) cost more and very likely be mediocre if not strikingly bad.

For example, the lowest grade of steak Costco stocks is Choice. Until recently, Costco was the only place in my town you could get choice ribeye for under $17/lb (Costco was $8 or 9 at the time.) Recently, the groceries have started stocking that grade - according to the packaging, but the meat is visibly inferior and it's still more expensive.

I'm not saying everything there is great, but I can buy a product off the shelf because it looks tasty and it will almost invariably be good.

</comment></comment><comment><USER3> > Today, Costco alone sells more stuff every year than Amazon by far.

Perspective</comment>


Site Tests Whether You Can Spot AI-Generated Faces - <AUTHOR> https://futurism.com/the-byte/site-tests-spot-ai-generated-faces <comment><USER2> So far this technology has still flaws and if you know what to look for, you'll spot the generated image; once these will be eliminated, it won't be possible to tell the difference.</comment>


Neuroscience Can't Explain How a Microprocessor Works - <AUTHOR> http://www.economist.com/news/science-and-technology/21714978-cautionary-tale-about-promises-modern-brain-science-testing-methods?cid1=cust/ednew/n/bl/n/20170119n/owned/n/n/nwl/n/n/NA/8643534/n <comment><USER2> This article reminds me this reflexion at the end of a paper I wrote a few monts ago in [http://epsilonwiki.free.fr/lambdaway/?view=lambda_calculus](http://epsilonwiki.free.fr/lambdaway/?view=lambda_calculus) :

« Church numbers could be seen as tiny CPUs, small primitive engines ready to iterate. Not dead datas stored in a memory and sequentially given to some CPU iterating on them, but an arborescent structure of CPUs interacting in a de facto parallel process. Maybe it's how Google's data centers work. Maybe it's how our brain works, full of Church neurons. Why not ? [...]. »

Don't blame me if it is out the topic, but I wonder what some smart person could think about that? Thanks.

</comment><comment><USER3> > The researchers found, for instance, that disabling one particular group of > transistors prevented the chip from running the boot-up sequence of "Donkey > Kong"—the Nintendo game that introduced Mario the plumber to the world—while > preserving its ability to run other games. But it would be a mistake, Dr > Jonas points out, to conclude that those transistors were thus uniquely > responsible for "Donkey Kong". The truth is more subtle. They are instead > part of a circuit which implements a much more basic computing function that > is crucial for loading one piece of software, but not some others.

This is blindingly obvious in hindsight, but not something I had ever considered before. Really cool article.</comment>


Startups and Babies - <AUTHOR> https://www.omniref.com/blog/blog/2015/03/04/startups-and-babies/ <comment><USER2> Wow, today I learned I've nursed a lot of 4th Trimester startups. Great imagery.</comment>


Pulsar: Concurrent framework for Python - <AUTHOR> http://quantmind.github.io/pulsar/

<comment><USER2> I really want to use Python in a distributed computation project of mine, but I've been running into serious performance bottlenecks with regards to object serialization. Like many concurrent Python frameworks, Pulsar uses `pickle` to serialize data across processes, and for all but the smallest data structures, workers end up spending 95+% of their time (de)serializing data.

I work with video data, so I just ran these rough benchmarks on my MacBook Pro:

        import cPickle as pickle  # yes, I'm on Python 2.7.  Sue me.
        import numpy as np

        a = np.random.rand(800, 600, 3)  # 800x600 px, RGB channel

        %timeit pickle.dumps(a)  // %timeit magic from IPython
        1 loops, best of 3: 855 ms per loop

It takes nearly a second to serialize a not-so-huge `numpy` array, which makes it very difficult to do any sort of soft real-time analysis.

This is a huge pain, and (very sadly for this Python aficionado) suggests that Python might be the wrong language for this kind of work.

Any suggestions?

<comment><USER3> You should use highest protocol of pickle, here are the numbers in my machine:

        In [5]: %timeit pickle.dumps(a)
        1 loops, best of 3: 724 ms per loop

        In [6]: %timeit pickle.dumps(a, protocol=pickle.HIGHEST_PROTOCOL)
        100 loops, best of 3: 12.4 ms per loop

<comment><USER4> What's the trade off here?

<comment><USER5> Backwards compatibility. Anything pickled with HIGHEST_PROTOCOL will be unreadable in anything below Python 2.3.

<comment><USER6> So my Ford Model T won't be able to read it?

(That is my humorous way of saying that Python 2.3 is rather old and therefore HIGHEST_PROTOCOL seems like it would be a desirable trade off for most.)

<comment><USER7> Yeah, what the hell? Even 2.5 is way too old, I generally only support 2.6+ nowadays. If something breaks compatibility with 2.5, no problem there. Hell, Python 3 has been out for _years_!

<comment><USER5> Hey, I'm with you. I use 3.4 on almost everything, and 2.7 at worst anywhere else. I weep for those stuck using Python 2.2.

<comment><USER7> No, I'm agreeing with you. I want to transition to 3.4 completely (mypy looks amazing), but there are some small Django libraries (third-party libs) that aren't yet compatible :(

<comment><USER5> Mypy is indeed amazing, I can't get enough of it. Throw in asyncio and pathlib and you get the reason why I could never go back.

You might look into trying to port the django libs by yourself if you have the skill to do so. 2to3 often gets you really far. If you don't, I'd definitely recommend opening a ticket on the project page. I've done that with a few libs I use, and for a couple of them the maintainers just totally forgot about them and got around to doing the conversion just because I asked.

<comment><USER7> I did that already, I just have to find some time to do the conversion. The maintainer was kind enough to assist.

How do you use MyPy? I'm particularly worried about two things:

1) If I'm building a library, I can't have MyPy as a requirement, but would still like to use it for the types checks. Is there a way to omit the import when distributing your library?

2) Can it only check parts of an application? Maybe I have a big Django app and don't want it to static-check Django and all the other imports every time, for example.

<comment><USER5> Sorry it took so long for me to get back to you; I only check HN from time to time.

1\. No, afaik there's no way to omit the import. Sadly there's little in the way of macros or preprocessors in the python world at this point.

2\. I'm fairly sure there's ways to use module stubs, but all my mypy work has dealt with the stdlib which presents no issue.

<comment><USER7> Thanks for your reply! There aren't preprocessors, that's true, but I think the way MyPy does things is a bit unnecessary. They could have avoided the typing module and just used bare annotations, and made MyPy a static type checker. Still, this just avoids the dependency, which isn't such a big deal.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> Pulsar is 100% written on top of asyncio. In this respect is not dissimilar to Tornado or Twisted, which also use an event loop for their asynchronous implementation (with their own event loop and Future classes).

However, pulsar is built on top of the standard lib with all the benefits that that brings, especially in view of the changes in python 3.5 ([https://www.python.org/dev/peps/pep-0492/](https://www.python.org/dev/peps/pep-0492/)).

The actor model in pulsar refers to the parallel side of the asynchronous framework. This is where pulsar differs from twisted for example. In pulsar each actor (think of a specialised thread or process) has its own event loop. In this way any actor can run its own asynchronous server for example.

Tornado is an asynchronous web framework, pulsar is not, you can use any web framework and run it on pulsar wsgi application. You can use pulsar to create any other socket application, not just HTTP.

</comment><comment><USER9> I am not sure whether Pulsar would anywhere achieve the speed / throughout of a truly concurrent system like JVM, Go, Haskell, and Erlang. I don't see benchmarks posted on Pulsar's website, but I came across this discussion [1] where aphyr and KiranDave discuss about why Clojure/Erlang's model of explicit concurrency (which enabled parallelism) is superior to NodeJs' (implicit concurrency via libuv, and multi-process parallelism via clusters).

From reading the "design" section on the website, to me it looks like Pulsar is an attempt to replicate NodeJs (?) and by extension cannot compete with languages with truly concurrent runtimes?

[1] [https://news.ycombinator.com/item?id=4306241](https://news.ycombinator.com/item?id=4306241)

<comment><USER10> Great link - thanks for posting!

Pulsar can be configured to use either processes or threads. If you use processes, you pay the IPC penalty, just like NodeJS does. If you use threads, you pay the GIL penalty.

So yeah, it won't be as fast as BEAM or the JVM either way.

</comment></comment><comment><USER11> Is this related to the fibers/channels/actor framework by the same name for Clojure?

[https://github.com/puniverse/pulsar](https://github.com/puniverse/pulsar)

<comment><USER12> Good question. The name is the same and goals of both projects are similar. Implementation is very different, though.

</comment></comment><comment><USER13> Oh, another one. Doesn't the fact that there is a new concurrent framework for Python nearly every single month point to the existence of a rather large pachyderm in the room?

</comment><comment><USER14> Previously: [https://news.ycombinator.com/item?id=6543266](https://news.ycombinator.com/item?id=6543266)

</comment><comment><USER15> How does it compare/contrast with Tornado?

<comment><USER16> Looks like an actor framework, built directly on top of stdlib asyncio, and is designed to use multiprocessing first instead of tornado's cooperative multitasking.</comment></comment>


Garmin received decryptor for WastedLocker ransomware - <AUTHOR> https://www.bleepingcomputer.com/news/security/confirmed-garmin-received-decryptor-for-wastedlocker-ransomware/ <comment><USER2> I'm still hopeful that Garmin is prosecuted for paying the random. The us is actually sanctioning evil Corp. [https://slate.com/technology/2020/07/garmin- cyberattack-rans...](https://slate.com/technology/2020/07/garmin-cyberattack- ransomware-payment.html)

I even have a Garmin device affected by this. I still want ransomware stopped.

<comment><USER3> Ransomware that is a result of users clicking on update notices they should not click is very hard to protect against. Even Stuxnet was successful in crossing over to a separate network through the use of USB sticks. Source: [https://en.m.wikipedia.org/wiki/Stuxnet](https://en.m.wikipedia.org/wiki/Stuxnet)

I get the sentiment that Garmin should suffer due to paying the ransom, but I bet a lot of american companies would act the same way if it was their company on the line.

At least this incident should serve as a warning to other companies that Ransomware is very real and there has to be a plan for recovery without paying the ransom.

<comment><USER2> Those companies should have backups. If this was say a mafia type org that was going to kill people if they didn't pay up, it would be clearly wrong. If someone said they'd cut your internet links if you don't pay, it might be more obvious this extortion payment is wrong. And this can be defeated by having backups.

</comment></comment></comment><comment><USER4> Since GARMIN is a publicly traded company, couldn't an investor demand to know if the money was paid, and if they don't get an answer, they could go to the SEC? Could they sue?

<comment><USER5> Interesting question. The dynamics surrounding which questions get proper answers in shareholder meetings is always interesting to me. There is no right way and bullshitting certain questions is an art. On grounds of material impact this question is hard to skip an answer to. Perhaps the payoff wasn't that material in the end, but the hack was. So even a small fry shareholder could ask this in the shareholder meeting and expect an answer. Skipping to answer good questions often leads to more in the future, so that's the balance the CEO and investor relations face. One could always reach out to analysts to try and get some critical mass going.

<comment><USER6> I would think that it will be duly included in the company's financial statements, so that the material impact of this _overall_ is duly reported. But obviously there will be no reference to any ransom.

I would also suspect that they never paid any ransom. They probably only paid consulting fees to security/ransomware experts (wink wink).

</comment></comment></comment><comment><USER7> I'm curious if the average company even bothers planning/testing their ability to recover from a ransom ware attack wo paying.

Like do they even bother planning for that or are they unaware of the risk or did they decide it's more cost effective to purely rely on prevention and plan to pay any ransom.

I feel like there should be a regulation, where if they pay the ransom then they get a penalty of 2-5x the ransom charged.

</comment><comment><USER8> I bet they'll start investing in backup solutions right about now.

<comment><USER9> I recall a story here on HN, some days ago. A company was attacked, then the attackers waited some months to make sure that all backups had been contaminated, then they struck.

So victims can only make sure that they have a malware checker that finds the culprit, then do fresh installs, then check each file before it's restored from backup. Sounds like a crazy amount of work.

<comment><USER10> Immutable append-only backups would protect against this, right? Nuke the OS to make sure you're running on good software, then pull in data that's as good as it was when it was backed up.

<comment><USER11> Only to the degree that attackers can't figure out a way around them (given months of planning with access to internal systems & documentation).

For instance: I have backups going to an append-only s3 bucket in a separate AWS account, but I don't have monitoring in place to ensure that bucket hasn't been wiped. An email would get generated, but it'd go to the root account holder, who may not notice in time.

<comment><USER12> Kinda makes me wish for the good old days when you could just store a pile of tape

<comment><USER13> Good old Days? There is a reason Financial Institutes still uses WORM tapes, and they are great!

</comment></comment></comment></comment></comment></comment><comment><USER14> To me the fascinating part is that with the ransom payment they received the decrypt key as well as the security system patches needed to protect the system. However I would be very nervous that the hacker didn't leave something behind but perhaps they would rather a good reputation and not risk losing payment for the next attack.

<comment><USER15> Given the references the author found to apparently reputable ransomware recovery firms, my reading is that the decryptor was built by one of those companies using the key provided by the intruder.

</comment></comment><comment><USER16> Is Evil Corp their actual name, or just what the US law enforcement called them? [https://home.treasury.gov/news/press- releases/sm845](https://home.treasury.gov/news/press-releases/sm845)

<comment><USER17> It looks like that's just the name of a group - like anonymous, lulzsec, equation, shadow brokers, etc.

It's likely a nod to Mr. Robot, where the company that the hackers are infiltrating is called Evil Corp.

<comment><USER18> Its E Corp, Elliot call's them Evil Corp (He says in episode 1 iirc, that he basically replaced E Corp with Evil Corp in his own internal dialogue)

</comment></comment></comment><comment><USER19> This would never have happened, if only they used a proper Operating System from a respectable software company.

<comment><USER18> Name that tune!</comment></comment>


Indian Scientist Helps Make Revolutionary Discovery That Could End Malaria - <AUTHOR> http://www.thebetterindia.com/28236/indian-scientist-discovery-in-ending-malaria/

<comment><USER2> Very nice:) as I had malaria once, I am very happy if there was a cheaper and better cure! Too bad the article is very ambiguous about such cure.</comment>


Germany plans to fingerprint children, spy on personal messaging - <AUTHOR> http://uk.reuters.com/article/uk-germany-security-encryption-idUKKBN1951VG <comment><USER2> The headline is misleading. They are not planning to fingerprint all children. They are lowering the age at which refugee children are being fingerprinted (from 14 to 6). This is part of the EU process of making sure that refugees are handled properly.

<comment><USER3> The problem is that the fingerprint data will not be used exclusively for immigration purposes but also for general crime fighting.

I oppose that - because it is the first step to extend the surveillance state. Next to no one cares if refugees are forced to give up their fingerprints (except maybe the radical left), most people will actually silently approve of this, but who guarantees that in four years this won't be extended to every German?

And yes, there's precedence for politicians doing this - the Maut data, as well as the Vorratsdatenspeicherung (internet provider data), were once thought to be only for serious crimes but there are already plans to use the data also to fight "common lowlevel crime"...

We may trust our current governments but we cannot trust what future governments will do.

<comment><USER4> Given the high rate of incidents that Europe is having with immigrants, the alternative is to _close the borders_. So at this point, pick your poison: let tens or hundreds of thousands die of war or starvation, or take away freedoms that they wouldn't have without having crossed those borders anyway.

I'm a libertarian at heart, I've been very sympathetic towards refugees, however seeing lots of immigrants misbehave in my trips to the UK and Germany, I'm beginning to understand nationalism and why people have a periodic tendency towards populism (e.g. Trump, Brexit, etc).

The whole purpose of fingerprinting is crime fighting. Nothing else. There's no such thing as "immigration purposes". And when you're going into somebody's house, you obey their rules, otherwise you're free to go elsewhere.

<comment><USER3> > Given the high rate of incidents that Europe is having with immigrants, the > alternative is to close the borders.

"high rate of incidents"? Next to all recent terrorist attacks in the last years involved people who were born in Europe. According to Sascha Lobo and other media reports, all of them were known to police for being violent and dangerous, one of the London terrorists actually was on a TV show "the jihadist next door".

And the (real) problems, e.g. overcrowding refugee camps, could be solved by solidarity in Europe, but right now it's Italy and Greece picking up the brunt of the load, then Germany - and then, with a vast distance, every other country in Europe. Despite especially the Eastern European (Visegrad) countries having profited massively by financial solidarity from the rest of Europe (which is mainly DE, FR, UK).

> however seeing lots of immigrants misbehave in my trips to the UK and > Germany, I'm beginning to understand nationalism and why people have a > periodic tendency towards populism (e.g. Trump, Brexit, etc).

They have a tendency to nationalism/populism because populism does not work with evidence and facts but rather with emotions and propaganda.

> The whole purpose of fingerprinting is crime fighting. Nothing else.

Well, let's take the immigration discussion out of the view for one moment: for now, for example, protests are legal. But what prevents a future government from using fingerprint data or especially biometric photo data to prosecute people for protesting against government?

Nothing. And this is why such movements must be stopped before a future government turns against its citizens.

</comment></comment></comment></comment><comment><USER5> considering at least two islamist attacks in germany by a refugee have been carried by a minor[1][2], i don't think that fingerprinting refugee minors should be out of the question -- though obviously the details should be carefully deliberated.

there is absolutely no way that mandatory government spyware on phones will guarantee effectiveness, though -- the bataclan attackers for instance used ordinary sms to coordinate[3]. besides that, the potential for abuse is unfathomable.

[1] [http://www.telegraph.co.uk/news/2016/12/16/boy-12-attempted-...](http://www.telegraph.co.uk/news/2016/12/16/boy-12-attempted- blow-nail-bomb-german-christmas-market/)

[2] [http://www.telegraph.co.uk/news/2016/07/18/german-train- axe-...](http://www.telegraph.co.uk/news/2016/07/18/german-train-axe-attack- many-injured/)

[3] [https://www.schneier.com/blog/archives/2015/11/paris_terrori...](https://www.schneier.com/blog/archives/2015/11/paris_terrorist.html)

<comment><USER6> The first attack was not carried out by a refugee, at least, not per the text of the article.

</comment></comment><comment><USER7> The odds of being killed in a terrorist attack in Europe or the US are essentially zero. But the odds of being killed in a car crash, by a hospital mistake, falling in the shower, are very real.

This is a classic, and irrational, disproportionate response.

Besides, is there any evidence that monitoring 100% of message traffic will reduce terrorist attacks? Are terrorists really so dumb they're going to plan their attacks via a monitored channel? Do governments really have any problem catching and convicting criminals?

<comment><USER8> > Are terrorists really so dumb they're going to plan their attacks via a > monitored channel?

Actually yes! The Paris attack was coordinated via sms. I know other attacks have been coordinated via monitored channels.

The real problem is that even with all this monitoring, nothing is being done to stop terrorist attacks. Turns out, stopping terrorist attacks was never the point in the first place, who woulda though!?!

[https://theintercept.com/2015/11/18/signs-point-to- unencrypt...](https://theintercept.com/2015/11/18/signs-point-to-unencrypted- communications-between-terror-suspects/)

*edit: It's probably not fair to say "nothing" is being done. But we're definitely putting our efforts into the wrong direction, and I stand by the statement that the point is not to stop the attacks.

<comment><USER7> > The Paris attack was coordinated via sms.

Coordinated, yes, but I seriously doubt they texted their intentions and purpose.

</comment></comment></comment><comment><USER9> this is happening by the backdoor - at the last school we used we got a letter saying a US defence manufacturer was providing a library system for the UK school that used biometrics "let us know if you have a problem with this" \- I suspect it was provided at little or no cost

the new door entry system at the current school (I don't know the vendor yet) is using biometrics "let us know if you have a problem with this"

1.28M (2015) UK school children have given biometrics:

[http://www.independent.co.uk/news/education/education- news/p...](http://www.independent.co.uk/news/education/education-news/privacy- concerns-raised-as-more-than-one-million-pupils-are-fingerprinted-in- schools-9034897.html)

</comment><comment><USER10> Wow Germany, mandatoory backdoors? And I had my hopes in you

</comment><comment><USER11> The title is false. Has nothing to do with IT. Admins?

<comment><USER10> Germany wants to backdoor cellphones, how is that not related to IT?

</comment></comment><comment><USER12> My next startup will offer a carrier pigeon service.</comment>


At This Startup, Everyone Can Read Each Other's Email - <AUTHOR> http://www.wired.com/2014/12/startup-everyone-can-read-others-email/ <comment><USER2> "IF EVERYONE ALREADY KNOWS EVERYTHING THAT'S GOING ON, THEY WON'T HAVE TO WAIT FOR SOMEONE ELSE TO TELL THEM WHAT TO DO."

This isn't very efficient. At any one point in time, there could be many, many projects that need to be completed. How do I know what to work on? I've worked at many companies and things usually change quickly, which I don't think can be reflected in just an email list.

I'm curious, do all of the upper management use this system too? So if an employee named Frank is going to be let go, will they post this to the mailing list? If not, they aren't being very honest and it's just a system to further control their employees and presented like some sort of great, new, process.

I also can't see people not changing their habits. Today, you can get fired over saying the wrong thing and being "offensive". Why would I want to take the chance and send it to the list?

Even something as simple as "Merry Christmas". I might have a co-worker that thinks it's fine (so I send it to them). But, it offends people on the list because I'm not saying "Happy Holidays".</comment>


Ask HN: Future CoronaVirus Vaccine Safety - <AUTHOR> Quick question: a Covid vaccine might be ready in 12-18 months, obviously way faster than the normal 5-10-15 year average. My question is, could a a future corona virus vaccine do more harm than being infected by the virus would have done?
There is no way you can check how it effects people long term, offspring, etc in 12-18 months.
I'm not anti-vax, I have all required vaccines plus all that I could find at a private clinic. But I also know that some vaccines have caused problems in the past. <comment> core-questions It does seem like something that a cautious and prudent person might let other people try out first...

</comment><comment><USER2> > could a a future corona virus vaccine do more harm than being infected by > the virus would have done?

Possibly. However, consider that tons of really smart and well motivated people are working on it. And that even if a vaccine is determined to work and be ready for rolling out to the general populace that doesn't mean that work on it entirely ceases.</comment>