gregcoombe

He'll probably be relegated to some minor role like "Husband of Board Member #6"

"It's one flag, Michael. How much could it cost, $44B?"

Side story: the haptic feedback for the NanoManipulator was through a hydraulic system (kinda like this? https://www.sarcos.com/wp-content/uploads/history_5-339x280....). There were hydraulic lines that were piped through the building down to the machine room (where the SGI Infinite Reality Engine was!). Someone read through the manual and realized that the force that the arm was capable of could easily break someone's arm, and since it was usually grad students working late at night programming it, they decided it would be safest to just decommission that. I think I got one of the last demos during a UNC grad school recruiting event.

Tolstoy also has a lot to share about programming. "Happy families are all alike; every unhappy family is unhappy in its own way" is a clear recommendation to use status codes as return values instead of boolean success/fail.

H3 has the significant downside that children nodes do not fit within parent nodes. So one needs to be very careful working within any sort of multi-resolution algorithm (the most effective uses I've seen are with a fixed resolution). S2 does not suffer from this.

It's the office of the future! https://www.cs.unc.edu/Research/stc/. The challenge in 2000 was that bandwidth and 3d reconstruction needed several leaps forward in quality.

The Wikipedia page dedicates an entire section to explaining that comment, under "Appointment to CEO, controversy and resignation". He was forced out of the CEO position for this political view. It was a pretty significant news story, and I think they are right for including this as part of what he is known for (particularly outside the HN community).

Yeah, it was a significant infrastructure cost. I heard at one time that the single largest computer at Google was the Perforce server. They ended up completely re-writing it (called "Piper") for scaling. This is sort of what I was alluding to with my comment about Google having different concerns than many other companies. They can afford to dedicate a number of engineers to maintaining a monorepo system and then re-writing when it doesn't scale. That said, I personally believe that there are a lot of benefits to monorepos, and I think those tradeoffs are worth it for other companies too.

Google posted a paper detailing their reasons for choosing monorepo: https://research.google/pubs/pub45424/

Caveat: your company probably isn't Google, so your challenges may be different.

You can get a saliva test today, it's just a bit expensive: https://www.vaulthealth.com/covid

We did this this morning, and it was not bad. They ship the tubes to your house, and you get in a Zoom call to verify ID and do the procedure. They haven't worked out all the kinks (it took much too long to do all of us) but it was pretty convenient. The biggest issue? It's surprisingly hard to fill up an entire test tube with spit.

"Hey, should I put this on my personal card?" "No, just Brex-it!"

Talented jerks can absolutely destroy a team. In my experience, the actual degree of coding prowess turns out to be significantly less important than the ability to collaborate.

They observed keys being transmitted to Chinese servers, which makes them to suspect that Zoom is distributing keys via these servers. They have worded this very carefully to avoid claiming something that they cannot confirm (distribution to multiple users).

It's possible it comes from a corporate culture that is focused on ease-of-use over security. This is not the first time that they've done some questionable things to reduce friction. See for example https://www.theverge.com/2019/7/9/20688113/zoom-apple-mac-pa..., where they installed a secret webserver to save Mac users a single click.

This is exactly the opening argument of the article, and the writer's response (in part) is, "Nevertheless the Nobel continues to exceed the Booker, the Pulitzer, and all other literary awards in its prestige, global impact, and ability to tip the scales toward immortality."

From the article: "[White Noise]... represents better than any other literary text just how apocalyptic dread has become the inescapable ground note of everyday life."

Aurora Innovation | Software and Hardware Engineering, Machine Learning, Perception, Robotics, EE | ONSITE (WFH for now) | Full-time, Interns | https://aurora.tech/careers | SF, Palo Alto, Pittsburgh, Bozeman

If you're passionate about self-driving, Aurora is hiring! We have openings for engineers at all levels for all of our teams. Here's a link to our careers page: https://aurora.tech/careers

Founded in 2017 by the leading experts in self-driving, Aurora is committed to delivering the benefits of self-driving technology safely, quickly, and broadly. Through rigorous engineering and applied machine learning, the company is building the Aurora Driver, a platform that brings together software, hardware and data services to fully operate any passenger or commercial vehicle.

To add to this: it's not just computational complexity, but it's also about safety. There is a human review process for every element of the map, which enforces a level of quality and safety that is extremely difficult to ensure from a fully on-the-fly system.

I think that there is grey-area between data that is sufficiently static to represent in a map (buildings, lane lines) and data that is dynamic and must be handled by on-board perception systems (pedestrians, road debris). A good way to think of this is that the map is encoding priors about the environment for use by the perception system. It may be possible in the future to do all of this on-board (like humans do!) but the computational constraints would be quite high.

I think you've hit upon one of the most challenging aspects of mapping, which is that the real world is incredibly dynamic. And it's not just the things that we think of as dynamic (bicyclists, pedestrians, other vehicles), it's also the geometry itself (lane lines, vegetation, building construction). So this requires some form of updating (either semantic, geometric, or both). And as you pointed out this is not uniform: dense city maps can change from week-to-week, whereas rural maps require less frequent updates. So first you need to build an on-board/offline system that can first detect these changes, then configure the pipeline so that the proper data is collected and updates can be compact and fast. As mentioned in the article, we have a git-like structure for Atlas updates which allows us to track small changes. And the fact that the Atlas is only locally consistent means that any update is contained just to the detected area.

Hi all! I'm Greg and I work on the Mapping Team at Aurora. I'd be happy to answer any questions about the article and mapping for self-driving.

It's been my experience that engineers are quite poor at judging the "patentability" of ideas. I'm not saying that you're wrong, just that the patent field is quite opaque and difficult to understand, which is why patent lawyers do quite well.