jrallison

"Just ignore the lidar in situations where lidar and vision conflict and you have the original decision."

Then why have lidar? If it's only purpose is to agree with vision or you just discard it, then why even have it?

I have, quite often. :)

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.

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.

A few reasons off the top of my head:

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.

Multi-key transactions means coordination. Coordination is not cheap. You'll be paying a hefty cost somewhere.

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.