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.

Open source is weird. It’s like everyone on the entire planet is your coworker and you have no real say in their hiring, on boarding, or firing.

I can see why there is trepidation and guard rails around giving them the key to your office planner.

These folks gave an interesting talk on producing pharmaceuticals at defcon a couple years ago.

IIRC it was more about production methods than developing new treatments.

https://fourthievesvinegar.org/

If your brain was distributed as software, I think it might?

One tricky thing about maps, as they relate to privacy, is that the earth is large.

Compare that to encrypted email: if I’m sending you an encrypted message, the total data involved is minimal. To a first approximation, it’s just the message contents.

But if I want “Google Maps but private,” I first need access to an entire globe’s worth of data, on the order of terabytes. That’s a lot of storage for your (usually mobile) client, and a lot of bandwidth for whoever delivers it. And that data needs to be refreshed over time.

Typical mapping applications (like Google Maps) solve this with a combination of network services that answer your questions remotely (“Tell me what you’re searching for, and I’ll tell you where it is.”) and by tiling data so your client can request exactly what it needs, and no more, which is also a tell.

The privacy focused options I see are:

1. Pre-download all the map data, like OrganicMaps [1], to perform your calculations on the device. From a privacy perspective, you reveal only a coarse-grained notion of the area you’re interested in. As a "bonus", you get an offline maps app. You need to know a priori what areas you’ll need. For directions, that's usually fine, because I’m usually looking at local places, but sometimes I want to explore a random spot around the globe. Real-time transit and traffic-adaptive routing remain unaddressed.

2. Self-host your own mapping stack, as with Headway (I work on Headway). For the reasons above, it’s harder than hosting your own wiki, but I think it’s doable. It doesn’t currently support storing personal data (where you’ve been, favorite places, etc.), but adding that in a privacy conscious way isn’t unfathomable.

[1] https://organicmaps.app (though there are others)

[2] https://github.com/headwaymaps/headway (see a hosted demo at https://maps.earth)

The entire planet's worth reverse geocoding data is ~120gb. The map tiles file for whole planet is also ~120gb, and they both are precompiled, so you don't need hundreds of gbs of RAM to run your local planet. It's easier than you probably think nowadays. Not mobile-size, but local server-size

I'd love it if it were easier than I think, because I spend a lot of time thinking about it! I host maps.earth, which is a planet sized deployment of Headway mapping stack (which I also maintain).

To first order, you're right on about the storage size of a vector tileset and an geocoding dataset based on OpenStreetMap. But Google maps is a lot more than that!

Headway uses Valhalla for most routing. A planet wide valhalla graph is about ~100gb of storage. It doesn't produce reasonable transit directions. Transit is an even tougher cookie.

OpenTripPlanner gives good transit routing, but it doesn't scale to planet-wide coverage. We've settled on a cluster of OTP nodes for select metro areas - each one being on the order of 5-10GB of RAM.

https://about.maps.earth/posts/2023/03/adding-transit-direct...

So, I'd say we have some of the pieces of a general purposes mapping tool that could replace Google Maps usage, which you could host yourself.

But we don't have satellite imagery, real time traffic data, global transit coverage, rich POI data (like accurate opening hours, photographs, reviews).

Do all people want all these features? Probably not, but a lot of people seem to want at least some of it and it's not obvious to me that they'll be quickly solved.

This article is entirely about where displays are produced, so no need for “from the gut” stats.

According to TFA, about 95% are made in China and Taiwan.

The majority of non-Chinese fabricated displays are fabricated by basically 3 companies:

1. Samsung Displays - which primarily invests in SK and ASEAN

2. LG Displays - which primarily invests in SK and ASEAN

3. Japan Displays Inc - they are JV of Sony/Hitachi/Toshiba, and primarily Japan and ASEAN

The China related data does make sense given BOE and HKC's execution, but the Taiwanese data feels like an extrapolation of AUO and Innolux's market share. If they are including Innolux's production (which includes Pioneer in Japan), then it might be overindexing Taiwanese production.