Serious, non-acusatory question. Your writing looks human. Do you use any writing assistants?

Where else, other than HN, do you post?

Is love to hear more about subtitle generation. Specifically, can you label different speakers? I'd be using this for meeting transcription. Thank you.

Yeah, that's in faster-whisper-xxl via the --diarize parameter with additional options to tweak how it works:

https://github.com/Purfview/whisper-standalone-win/discussio...

I haven't used it when subtitling, though, so I don't know much more.

Terrific, thank you.

... for any purpose.

Yes. Or you can license it for specific purposes. But in general open data refers to data that is open to use by anyone, for any purpose, without restrictions except in some cases attribution.

A license only means something if you can enforce it. This means you can catch violations, and get courts to enforce it in a way that means something. If you can't catch a violation it is de facto allowed. What a license can restrict is limited by law, and so depending on the terms the court may say "you are not allowed to restrict that: they are allowed, go away". Or the court may impose a fine that is small enough everyone considers it a cost of doing business. How this plays out depends on the violation as well: if the violator can show they did their best to not violate that is very different from intentional violation. (I'm convinced the GPL will be broken - when a company shows they have lots of process to prevent the misuse, but a "rogue employee" hid their actions - the company will pay a fine but won't have to give their source code.)

With attribution

I wonder how many of these drones deliver a .txt copy of the GPL along with their payload.

Only if you publish something.

I'm in the same boat as you. Today I generally use Laravel for new projects.

  > I'm just saying its ok to ignore overly enthusiastic contributors and tell them to just fork your project.

I propose the phrasing "fork off".

A maintainer recently told me to “Fork baby, fork!” in response to a large patch set.

I was delighted.

  > BYD can be lighter because they skip on safety gear and proper structural elements - in my experience.

I'd love to hear more about your experience with BYD. The ex just bought one and my kids ride in it daily. I helped negotiate the sale - I drive a Tesla and I'm very happy with the BYD.

Brazilians got a bunch of them and they are super common in Brazil. Also common - broken suspension parts from driving them in Brazil.

Also, the only cars I’ve ever ridden on that the top of my head literally touches the headliner while sitting in the back seat. Other than that, they seem good?

Great to know, thanks. Israeli roads are typically well maintained, but I'll keep an eye out for suspension damage.

In this Atto 3, I've ridden in the back a few times and my head does not touch the headliner. I'm 170cm.

Yeah, I’m 182+ cm, so a bit bigger. It still surprised me. BYD Dolphin if I remember was the worse.

The suspension issues seem like a common theme though, they aren’t built as sturdily as most cars on that front.

Reducing the motor mass by 200 kg means you've just removed 10% of the weight of the vehicle. You could theoretically now reduce the battery pack by 10% as well.

Not true. The CdA (coefficient of drag multiplied by frontal area) matters far more for range than the weight for range. That is a smaller EV, which may very well be heavier can have a higher range and efficiency.

The Cd matters for highway driving, but weight is the dominating factor for city driving.

As efficiency improves across motors and inverters, wouldn't regen make CoD matter more, possibly tilting it to the dominant factor again?

Regen recoups about 80% of the kinetic energy, and it is already up close to the theoretical physical limit without switching to exotic materials.

Cd will never be the dominating factor at speeds which do not produce significant aerodynamic drag.

> Cd will never be the dominating factor at speeds which do not produce significant aerodynamic drag

That helped it sink in, thank you

Remember also that tires (deformation) and the like sap energy too

I don’t think there’s a whole lot of room for improvement there.

  > Why would I build my little web-apps and backends in the cloud when I can run things faster locally?

Because the company that designed and built your Chromebook made that the easy path.

And one interesting aspect is the number of children getting these types of neutered machines as their first learning tool. I read another thread comment saying people that started with react actually feel that using straight html is more complicated. My professors say that the best textbook is the one you've read. The next generation is being indoctrinated into this way of thinking

Up until they stop subsidizing things and you have to pay what things actually cost.

Amazon does 20k peak, or 20k average? Website visitor peaks could easily be two orders of magnitude higher traffic than average for a few minutes.

I worked at a company that had billions of views per year on a single big Postgres instance. Extremely read heavy with many queries needed for a page load. You can cache a lot of things.

Yes, but that's not a shopping cart, or a checkout workflow, nor a web store with heavy analytics.

It was one of the top real estate portals in the world. A lot of geolocation searches. New search every time someone moves the map. A ton of data sent to the client. Analytics in every page view.

No clue how a shopping cart or checkout flow would drastically increase database load. It should just be basic CRUD. Building a shopping cart is something every student makes. Pages in a web store can be cached relatively easily since items won't change often.

A primary DB with a few replicas and caching can go a really long way.

The composition of the average transaction will be different in a shopping cart (lots of writes and updates) compared to your use case which sounds like it skewed read heavy. With Postgres it’s generally easier to scale reads because it doesn’t really matter which replica the query hits, as long as it contains the data it needs. Whereas write-heavy workloads route through a single-writer bottleneck.

There’s challenges scaling read-heavy workloads, for sure — but they’re generally more straight forward than scaling write-heavy workloads. You can get away with more dumb horizontal scaling than with writes.

You don't see how adding functionality that requires writing to the database rather than just reading from a cache could "drastically increase database load"?

Even if it's writing to the DB, I doubt basic queries like adding an item to a cart is going to need DB sharding.

I think one piece that someone else mentioned could require DB sharding and that is all the live data needed for tracking deliveries.

The actual website/app should not need more than one beefy Postgres instance.

Scaling (asynchronous) reads is much easier than scaling writes.

What happens when the load balancer fails?

HA has to be all the way through, in which case you might not need a load balancer because each client already connects to a separate server. If you do, then you can have one load balancer per client machine.