I've always gotten the answer from officials "if you aren't competing with local workers, you're fine". As always, depends on the country. Further down the source I just cited:
"Examples of activities for which a person would not normally be remunerated or which would not compete directly with Canadian citizens or Permanent Residents in the Canadian labour market and which would normally be part-time or incidental to the reason that the person is in Canada include, but are not limited to:
long distance (by telephone or internet) work done by a temporary resident whose employer is outside Canada and who is remunerated from outside Canada;"
It's the definition of "work", whether you're competing with locals, and whether you're being paid by a Canadian company.
Many countries don't have this clearly documented, as until very recently (last 10-15 years), the only real "work" was competitive with local citizens/residents. All work visa documentation is written with this implied definition. Many countries are starting to call this out as an exception (like Canada above, Thailand recently, etc, etc).
Until it's clear for a particular country, it's best to talk to an official.
"What kind of activities are not considered to be “work”?
An activity which does not really ‘take away’ from opportunities for Canadians or permanent residents to gain employment or experience in the workplace is not “work” for the purposes of the definition."
Working for my own US company isn't competitive to local workers.
Every country I've visited has a similar definition, though I can't say for sure if every country does, so it's best to check before attempting to go.
Mostly Airbnb's, an occasional hostel/hotel if I didn't plan ahead.
My routine when arriving in a new country would be to quickly find a place to stay and a coworking space, then explore the city/country when I wasn't working.
Did almost exactly this for all of 2014 (part of 2015). With a US citizenship, and visited 10 countries for a month+.
Working remotely for a foreign corporation generally isn't against the terms of a tourist visa (consult the specific country you're visiting). All officials I asked had no problem with it, from South America/Asia/Europe (Germany will actually let you stay longer, up to 2 years, if you're a remote worker/freelancer). You do need a work visa if you're planning to do work for a company that exists locally (competing with the locals, etc).
It was hugely income tax advantageous. There's a huge US tax credit if you aren't living in the US (your first $95-120k tax free), and I wasn't staying long enough in any country to meet their reporting requirements.
It's not guaranteed to be atomic in failure conditions. Also, the biggest difference between Redis and Geode would be the "distributed" part, which involves maintaining these guarantees across a cluster of machines (which Redis demonstratingly doesn't do).
Sometimes, just maybe, the priority isn't to build something from scratch (however simple), but rather press a few buttons and move onto something more important.
That was my interpretation of your comment, but I'm still not sure I follow. In my understanding, by using RAID 0, any single disk failure will brick a node. Each node would then have 3 disks that are ticking time bombs (multiplying the failure rate by 3). How is that more reliable?
In RAID 5, I can have 1 disk failure on a node with no problem. 2 disk failures on the same node, and I only lose 1 node of my 12 node cluster (I.E. cluster is fine). I can also theoretically lose 12 (1 on each node) + 2*(RF-1) disks, and gracefully repair the situation with 0 interruption.
What's the benefit of RAID 0 other than increased usable disk space and perhaps write performance? It seems you're decreasing reliability significantly for those gains.
1) We're still interested in the nodes being as reliable as they can be. With RAID 5, we need two simultaneous disk failures to brick a node. With RAID 0 (to increase usable disk space), any of the 3 disks can brick the node.
Even with 12 nodes and RF of 2, an order of magnitude more node failures would be more likely to disrupt our service. Perhaps this makes more sense in a larger cluster with a higher RF factor?
2) We're using commodity hardware from a dedicated server provider, which uses RAID 1 or 5 configurations exclusively by default. We haven't reached the point where we felt that was enough of an issue or gain to investigate changing it.
3) Having more CPUs/disks in the cluster (12 nodes rather than cramming all data on 6) can be a good thing... as FDB scales fairly linearly.
With a replication factor of 2 (for fault tolerance), it's ~4.5 TB.
FoundationDB requires SSD drives, which the best we can get efficiently in our data center is ~670 GB of usable space (3x480GB raided).
12x670 = 8040 GB
We try to keep extra space available for node failures (FDB will immediately start replicating addition data if it notices data with less than the configured number of replicas).
Our dataset currently grows at a decent pace, so we over provision a bit as well.
Don't know much about RAMCloud, but from the description:
"Many more issues remain, such as whether we can provide higher-level features such as secondary indexes and multiple-object transactions without sacrificing the latency or scalability of the system. We are currently exploring several of these issues."
Sounds it doesn't provide multi-key ACID transactions at the very least.
Absolutely. Choosing the proper data model based on your access patterns is one of the best ways of keeping FDB performance high by reducing the likelihood of contention.
It's not hypothetical. Twitter has significant revenue. When revenue is generated from eyeballs (ads), then yes, number of users and engagement is a valuable metric (yet not the only one).
You're discounting the "very large scale" portion of your statement.
What may seem fairly low value from the outside or consumer perspective is likely of huge value internally to ensure you can always watch Netflix without even thinking about everything that has to happen to deliver as much video as they do to their customer's browsers.
async != an incorrect system. Cash machines are a good example of an asynchronous, eventually consistent system that works. As is any well built eventually consistent data store.
Redis/Mysql has it's problems, as does all databases. However, as a practitioner it's important I know the shortcomings of each, so that I can know exactly what a certain database is offering in terms of safety and whether it's a good fit for my use-case. Antirez being open about them is a huge +1 in my book.
Data drift or loss of acknowledged writes isn't correct for a wide range of use-cases. If you know the limits, you can choose the incorrect system, and deal with the fallout when that "rare" event does happen.
It won't do well, but at least Antirez is up front about the shortcomings.
The article itself states that Redis Cluster will lose acknowledged writes during partitions (no P), will be eventually consistent (no C), and won't be available during partitions (no A).
Then why have lidar? If it's only purpose is to agree with vision or you just discard it, then why even have it?