Not really apples to apples. iOverlay is more like a topology toolkit - things like set operations and buffering. pretty different from triangulation.

The commenter probably meant https://github.com/iShape-Rust/iTriangle, a sibling library that is indeed quite fast at triangulation, especially on bigger inputs

In the meantime, you can check out maps.earth, which has bike+transit directions for the puget sound area (also sfbay, los angeles, portland)

...though the elevation model I'm currently using is courser (~30m, from Mapzen skadi). This is a good reminder to fix that where available!

Hit me up if you want to use the iOS beta which has some nice transit features (already available on the web).

Nice! I’m always exciting to try a new non-car centric mapping/routing app.

In my experience, Google Maps too often sends me down dangerous streets - busy, wide, arterials with fast moving automobiles.

Though I do know some people who prefer them because they can be a little faster. Not worth it for me. I'd much rather go a little out of my way for a comfortable safe ride.

If you’re into this, and ever in Seattle check out the connections museum.

https://www.telcomhistory.org/ConnectionsSeattle.html

The volunteers there maintain a bunch of functioning cool vintage equipment you can see in action and even use.

Be sure to send them an email first, so that you can arrive at the proper time for them to give you a tour. It is very, very worth it. One of the best museum experiences so far.

Thanks to both of you for the info. I'm longtime Seattle and I had no idea. I'm still disappointed that the living computer museum was closed. Jody Allen is a decent person so was surprised she let that tiny line item expire from the spreadsheet, I digress.

+1 to this! If you have any interest in telephones, telephone switching, or phreaking, this place is incredible. And the people who run it are awesome.

A branch is mutable and holds only one version of history at a time.

If you never rewrite history, you could achieve something similar, but it precludes you from having a “tidy” branch.

Whether or not you’re into rewriting history is a different discussion that has been hashed out over and over again.

Another thing that becomes easier with change IDs is reviewing multiple related commits together, essentially "stacked pull requests".

If you treat a branch as your unit of review, then it becomes super difficult for someone to submit a chain of related changes. You'll be constantly rebasing your pull requests onto each other as you get feedback from dependent branches.

I heard that the github CLI recently introduced support for this, but since in git there's no concept of dependent branches (a branch isn't even an object in git, just a reference to a commit), I think this approach will always be clunkier than reviewing commits related by a change ID.

> If you treat a branch as your unit of review, then it becomes super difficult for someone to submit a chain of related changes. You'll be constantly rebasing your pull requests onto each other as you get feedback from dependent branches.

I know this isn’t a very interesting comment, but just to provide some balance to the mostly negative comments I’m seeing:

It’s interesting that you did the experiment, and I appreciate you sharing your results. It all seems reasonable, even if a bit depressing.

A lot of people in the comments are saying he did it for "likes" - that's a pretty harsh reading of the article.

What I think a lot of people are missing is that the difference between supporting corporates who spend up to millions per year on your product and supporting end-users who are literlly counting every cent they spend is a huge gulf in terms of expectations, technical ability, professionalism.... the list goes on. It's a completely different game.

I thought the article was a brilliant summary of why you simply can't help all the users all the time. It's a hard lesson to learn in the world of Tech Support. We all want to be the knight is shining armour solving customer problems, but the skill to be able to say "no" in the right way is not universal.

To those ragging on the author - there are huge numbers of people who, even if you paid them to use your software, they would still complain and swear at you. It's just life. And dealing with the competing interests of customers, time pressures, personal sanity and many more is almost exactly the job description of Tech Support.

Thanks. I'm not really understanding the likes comment. What are likes in this context? I was very explicit in the post I thought providing better support would build customer relationships and improve retention, and I learned that really isn't true. Also I wrote this a couple days ago so the blog would have content and only submitted on a whim, had I known I'd get 10K views and 100 comments I would've written it more carefully

Thanks for posting this. I have experienced similar. I have found that nasty bug reports are most effective. Good data, and the people are too cheesed off/embarrassed, to follow up, after you address it. Occasionally, it can actually be turned around, and they can become evangelists.

I have integrated a simple feedback form into the app, with the option to send anonymously. That seems to help.

> had I known I'd get 10K views and 100 comments

Is that still the case, after being frontpaged on HN (but most comments are probably here)?

All comments here yeah. Almost to 11K views and there were less than 50 before I posted, with a dozen new subscribers to the blog.

I mention the value of negative feedback, here (in my own blog): https://littlegreenviper.com/the-road-most-traveled-by/#feed...

I don’t really care whether or not I get many views (spoiler: I don’t -too many words). I write for myself.

For what it's worth, I see a lot of parallels to this and IT support. I found it genuine. Cheers.

This was also my thought! OP is going to get a lot of arrows for this article, but it's a genuinely great write up that matches a lot of my experience with mass-market products.

It's a great account for people to reflect on. I've immediately sent this article to several early-stage founders who are burning astounding amounts of time on undesirable customers.

Everybody on HN knows better than OP how to run their own business and could absolutely please 100% of customers or potential customers 100% of the time. Apparently.

Idealism doesn't survive contact with reality.

I’m a bit doubtful with this conclusion, as apparently in many cases humans will rather refute reality is meaningful if it fails to pass their idealistic proof-test.

Same here. I feel it's what every software owner thinks, but no one is willing to admit because of the backlash.

It’d be nice if they at least mentioned the existing pure rust implementation.

https://github.com/KillingSpark/zstd-rs

And better yet if they compared it explicitly in their “why” section. As it is, I’m left guessing.

The "Why" section exclusively opens with a reference to zstd-rs:

> Why though?

> Using zstd in Rust is already supported via the zstd crate, so why bother with a whole new implementation?

Separately, I'd say their end goal seems to be replacing the C library dependency in Rust's zstd-rs:

> We have our own fork of the zstd that uses libzstd-rs-sys instead of the C library. We'd like to upstream this at some point.

They seems to be referering to https://github.com/gyscos/zstd-rs which looks like a wrapper around the C library. https://github.com/KillingSpark/zstd-rs. is a pure rust implementation

What do you think is happening to the water not being utilized in the production of power? I assumed it's still being run downstream, just not through the power producing turbines.

I'd expect there's not a big effect on the ultimate amount of water being released downstream either way.

They let the reservoir fill up for when the power and/or drinking water is needed later.

The max is like a car engine’s redline. That the car can hit it doesn’t mean you should at all times.

(outside an abortion facility)

Yes, the place she thought needed her prayers.

How is that important?

What are your views on abortion?

I believe in free access. I also believe those going to get an abortion shouldn’t be impeded by protesters in the immediate vicinity when getting their healthcare.

She was standing alone, across the street, on the curb/grass next to the sidewalk, kind of doing a homer simpson into the bushes.

There were no other people visible, she made no noise.

She didn't impede anyone, and it would have been very difficult to tell she was protesting, if that's in fact what she was doing (I'm not her, so I don't know).

I don't believe in God, so those particulars (or that it was an abortion clinic) aren't important to me. She was arrested for thinking silently to herself.

> Do you believe God was listening to the prayers and influencing the people at the abortion clinic?

No, the woman was there tying to influence other women’s healthcare, something she had no right to get involved in.

Edit: The police did screw this up - the clinic was closed. She also received a payout.

Framing this as ‘thought police’ is wrong, the issue was her presence.

https://www.bbc.com/news/articles/c4gze361j7xo

(Headway maintainer here)

Indeed there is currently no incremental update in Headway, and deployments are largely an exercise left to the reader.

For maps.earth (a Headway planet deployment), I typically rebuild the world, and then do a blue/green deployment.

I guess the one exception is for transit routing. We have individual transit zones small enough to fit into memory, which can be deployed incrementally. There’s nothing really built in about it - just another level of indirection via our “travelmux” service which redirects your routing queries to a different backend depending on mode and region.

Thanks for chiming in - super helpful context.

I am trying to learn from real deployments as I design Corviont's updater for edge boxes (bandwidth caps, maintenance windows, unreliable WAN, atomic swap + rollback).

When you say transit "zones" are small enough to deploy incrementally - what is the actual artifact per zone (roughly what format), and what sizes do you typically see?

And when a transit zone dataset changes, how do you roll that out safely - do you restart/reload the backend that serves that zone, or do you bring up a new backend/version and then flip travelmux to point at it?

Transit routing is provided by OpenTripPlanner, so the deployment artifact is their OTP serialized graph format.

So it’s not really incremental with respect to the existing transit zone deployment. I just mean I can redeploy a single transit zone with the latest GTFS without having to touch the other transit zones, tileserver, geocoder, etc.

Deployment/rollback is handled by k8s config.

Thank you, that's very helpful.