rmattes

It would be triangulation if the system was measuring the arrival angles of the incoming signals. If the system relying solely on arrival time differences, it's likely doing something based on trilateration.

If you're into this stuff and ever in the Seattle area I recommend visiting the Naval Undersea Museum in Keyport. They have a good collection of torpedoes on display, including a Japanese Kaiten manned torpedo.

http://www.navalunderseamuseum.org

Why haven't I tried ROS on Windows? I never really had the need to, I primarily use Linux at home and work.

I did briefly evaluate ROS 2 (ardent) on Windows at my previous job. It seemed to work fairly well, I built it natively, ran the demos and did some latency/throughput comparisons between DDS implementations.

I've never tried it, so I don't know how easy it is, but there has been a lot of work recently to improve ROS on Windows: https://microsoft.github.io/Win-RoS-Landing-Page/

If you're not looking for a full size rack, I like the Hammond Manufacturing RCH series. They come in several heights and depths, and you can add locking doors and casters.

ROS runs on Mac, and ROS 2 adds Windows support.

The 'assertion-evidence' approach to creating slides focuses on for keeping text to a minimum and using pictures and other visual aids to support your message. They emphasized it in my engineering school, and I've been using it in workplace presentations for years.

https://www.assertion-evidence.com/

The 90s wasn't exactly the stone age, there was plenty of self-driving vehicle work taking place. For example:

https://www.smithsonianmag.com/history/the-national-automate...

Sure, but even then, I think his point is still applicable. It's urllib2 and requests, not urllib2 and requests and 20 other libraries. The fact that an inferior library is being kept alive by being in the stdlib is maybe unfortunate, but there's still only a small number of choices overall. That makes it much easier to do research and see within the first few search results that the majority of the community recommends one over the other.

I don't think he's arguing that the language designers are the ones that need to be curating crates, he just brought up Python as an example of some sort of curation happening in a similar ecosystem. It's the community at large that needs to be more active about identifying and signaling which crates should be preferred to provide particular functionality.

I don't think you even need to just pick one crate for a particular functionality - narrowing the field down from 23 to a handful with well-understood strengths and drawbacks would be a good start.

If you can't definitively prove that a class of changes won't break things, then you probably have to treat that class of changes as breaking and version accordingly, no?

That's an interesting point. If you're using a language that adds more rules to the API compatibility than the language that a module is released in, it's probably not possible to rely on semver in the general case. Unless the author is aware of those issues and versioning accordingly, any minor release could be breaking.

So it sounds like you're trying to quantify the runtime stability of a library with the risk metric: e.g. if I update this package, what are the chances that the foobaz function I'm using in that package will start giving me the wrong answer, or start crashing with the inputs I'm providing. You're right that semver does not try to solve this problem: by design it is only concerned with how to quantify changes to a public API.

If there's a risk that a package's functionality could break between releases it can be signaled through other channels. For example, you can keep unstable code in an "experimental" module, or hide unstable functionality behind a compiler flag. The binary compatibility (ABI) of a compiled package can be signaled with a SOVERSION or with symbol versioning.

I guess I would hope that the packages I use that do publish a public API don't go changing the guts of the package in possibly unstable ways, at least not without lots of testing and maybe a few alpha/beta releases to let the experimental changes stabilize with early adopters. If I was using a library where core functionality was breaking every few releases for unclear reasons, I would argue that it's probably better to just find a more stable library to use than to put the effort into quantifying instability somehow.

What do you mean by risk? How would you quantify it?

As I understand it, all semver is trying to tell you is when backwards-compatible changes happen, and when backwards-incompatible changes happen.

If the project developer wants to add some sort of indication that "this package contains changes that are alpha quality, and may not respect semver for the next few releases" then that developer can append a pre-release identifer to the version, as described in the semver spec. Once that identifier goes away, the risk that a package violates semver should be gone, and you should be free to update based on the semver relation to the previous release.

Ultimately, it's up to the project to verify that their releases don't violate the semver spec by being diligent with respect to their public API. If you find that a project isn't disciplined in documenting API changes (semver or otherwise,) then coming upw ith new rules to convey the information they're already not conveying isn't going to help anything.

I think another good example would be the craft beer industry. The brewers association directory[1] lists around 200 regional and large breweries in the US, and somewhere around 5000 microbreweries and brewpubs.

Granted, some of these are more than 20 years old, but the movement grew the most through the early 90's[2].

[1] https://www.brewersassociation.org/directories/breweries/

[2] https://www.brewersassociation.org/brewers-association/histo...

> If you do actually need to develop for Linux, I would suggest something with a rolling release model, otherwise it won't be long before you'll need to start compiling things from source because you need a more recent version of <something> than your distro is packaging.

It depends on your requirements. If you constantly find yourself needing the latest and greatest upstream software releases, then yes, use a rolling release. But if not, rolling releases can make your life much more painful. If you're not paying attention when you update your system, then each update is a roll of the dice as to whether your software will still build or run afterwards, as any update could introduce incompatible changes to packages your software depends on.

A distribution with a release model (usually) tries to maintain API and ABI compatibility for the duration of a release, so you can update with more confidence that it you won't have to re-build or port your code as a result.

There's trade-offs between stability and shininess across the spectrum of distributions with rolling releases, with frequent releases, and with long release cycles. As long as you're aware of that, you can decide for yourself how frequently you want updates, and therefore the type of distribution you should run.

> Red Hat Enterprise Beta, uh, I mean, Fedora

I really wish people would stop making comments like this. I volunteer a significant amount of my free time and effort to improve Fedora, and I see a lot of others in the Fedora community doing the same. I can't speak for anyone else, but I'm doing it to make Fedora better, not to crowd-source Red Hat development for free. Fedora is a first-class distribution in its own right, with an open, inclusive, and independent community. Reducing it to a beta distribution for Red Hat glosses over that fact, which I find very unfortunate.

> Tesla is probably well ahead on that game and Uber will either need to partner or buy an existing car company.

Tesla may have been working on it longer commercially, but Uber did poach a lot of expertise from Carnegie Mellon to get a head start:

http://www.businessinsider.com/uber-poached-a-load-of-staff-...

If Tesla is ahead, it's not by much. Uber is already demonstrating (alpha-testing?) self-driving cars in Pittsburgh.

https://techcrunch.com/2016/09/14/1386711/

I'm not sure why Uber needs to be directly working with a car company, other than for better integration of the self-driving technology with the vehicle systems. However, they are currently working with Volvo:

https://www.media.volvocars.com/global/en-gb/media/pressrele...

For additional reference, the introductory computer vision course I recently took was based around these two freely downloadable books:

http://szeliski.org/Book/ http://www.cse.usf.edu/~r1k/MachineVisionBook/