heipei

This 100%. I run a German limited company (GmbH) and I can't just send money somewhere without a proper invoice. I've even had issues with paid services (think VPN providers etc) that don't send out invoices, so then I'm stuck with an expense that I can't deduct as a business expense. Make sure you can issue correct invoices, and let potential customers know upfront!

We're using Elasticsearch with binary vectors and our own sub-token filtering approach, but if we were to start over again today we'd simply use the dense vectors and ANN built into Elasticsearch, just with float vectors.

The iPhone is waterproof and you can take a photo with the physical volume up/down key. I've used it underwater a couple of times, none of my other proper cameras would be able to do that. My two cents.

Hu, weird. We run 15 AX101 instances, 13 for Elasticsearch and 3 for ScyllaDB, and I haven't had one reboot yet. Though even if they did it would not impact the stability of our databases.

Big Hetzner fan, but the EX101 does not feel like a good value compared to the AX101 that they've had for a while. Yes, the i9-13900 is faster than the 5950X, but does that justify half the RAM and half the disk?

- EX101: Intel Core i9-13900 / 64 GB / 2x1.92 TB NVMe - From €84

- AX101: AMD Ryzen™ 9 5950X / 128GB / 2x3.84 TB NVMe - From €101

NSQ is a message broker that's intended to run in a distributed fashion, i.e. one broker per machine which is producing messages. Consumers then have to discover and connect to all brokers that carry messages on a given topic. NSQ persists messages to disk, but it does not have replication, so if one of the machines with the brokers dies (as in dead disk), all queued messages will be lost.

We use NSQ extensively and its a great fit for us. It's fast, lightweight, very easy to understand and work with, has great HTTP APIs for controlling the queues and publishing messages, etc. What it doesn't have is replication, so if a message must not be lost ever I'd reach for a distributed log, probably looking at Redpanda before Kafka, and possibly building my own on top of ScyllaDB since we're already running that.

Thanks for the great series of posts on this topic!

If you're into that I suggest watching the SWR documentary around Big Manni / FlowTex.

We use queues for various jobs, some of which are time-sensitive (e.g. emails), so the queue should be empty most of the time, some of which are background or re-processing (e.g. re-indexing), so queues can balloon and then take days to drain again.

The unifying aspects of using queues for us is that it allows us to load-balance jobs across workers, and allows us to monitor throughput in a centralised fashion. We can set alerts on the time-sensitive queues and then use different thresholds for the background queues, but we're using the same metric data and same alerting system.

The economies of gas stations will be interesting to watch for sure. Given that they already make only a few cents of profit per gallon sold, their main source of profit is probably all the additional things (pizza and beer at 2am or on Sundays where everything else is closed here in Germany). Couple that with the fact that EV owners will spend more time at a station due to charging times, the switch to EV might honestly drive up their profitability quite substantially. And once you can get rid of pumps you just eliminated maintenance of moving/pumping machinery, fire hazards, regular visits by fuel trucks, and probably a lot of other things I'm not even aware of.

I'm not saying I'm right on any of these, but I'm really curious to see how this plays out. There's gonna be some "wow, I didn't think that would happen" moments along the way.

No, I get that it's only new cars, but what I meant what was that the attractiveness of an ICE will rapidly diminish way before the cutoff date of 2035. As other comments have said, infrastructure might heavily favour EVs (gas stations, parking lots, residential parking, city bans, tax incentives), making ICEs much less attractive even if you can still technically own and drive them. For new cars, the models that are going to be sold over the next 12 years have already been developed, many car manufacturers have developed their last iteration ICEs, so except facelifts you can essentially just buy 12-year-old models in 2034/2035.

Put another way: Would you want to be the last guy to buy an Intel Mac if Apple had already announced their switch to ARM with all the changes that go along with it? Yes, you can still run it, yes there are still others who run it, but do you want to be the last holdout that buys that Intel machine right before the next Apple keynote finalising the switch?

It's going to be interesting to observe first hand how much earlier this will effectively take place, i.e. how much sooner folks will transition to only buying new EVs, because who wants to be the last person to buy a brand-new ICE just before 2035 except maybe some petrolheads.

It will also be interesting to see what this does to the used-car market in Europe, though I guess you can always sell used ICEs abroad minus their shipping cost.

True, that makes running these databases a bit easier since there are multiple nodes that can be restarted in any order. However the main point still stands: You could just as well run Postgres on Nomad/k8s by pinning it to a specific node and excluding that node from the general job scheduling pool. We do that for a single-node Redis instance for example. Still vastly superior to managing unique snowflakes nodes just for the DBs via ansible/systemd.

We run our databases (ScyllaDB, Elasticsearch) on our workload orchestrator (Nomad), just like any other job. The only difference is that the servers running the database workloads are not available for scheduling any other jobs, that way the database will be the only thing running on them. I can't overstate how much easier this has made database operations for us. We get to keep all of our config in our Nomad repo, use the same mechanism for secrets management, service discovery, the fleet-wide logging and auditing sidecars, etc. Plus Nomad allows rolling updates with automatic revert which makes upgrading 10+ nodes of Elasticsearch one-by-one with healthchecks a total breeze. Since we've had this setup we are able to trigger database release updates with a one-line change and a single command.

Congrats on the launch, I think the description of what MrScraper does vs what you'd have to do yourself really nails it, and that is the value prop. Having experience in that area myself I can say that this looks like a great product and great pricing as well.

I know this is a peak HN comment, but I really fail to see the appeal of using a third-party solution for something so basic. In my applications, feature flags are simply controlled via a "tags" field per user and per team. Additionally, each subscription plan has a "tags" field attached to it that is merged with the user and team tags. The logic of how the application behaves in each case is something you have to write yourself either way, so the only thing these third-party applications are doing are managing a list of flags on your behalf the way I see it. I don't see how someone would pay for that and also expose their user information to a third party for something so simple. Maybe I'm missing something?

Trigram indexing is also used by the Elasticsearch "wildcard" field type for fast arbitrary regex/infix matching: https://www.elastic.co/blog/find-strings-within-strings-fast...

As a German myself I think I can confidently say that most of my country-men don't have the slightest feeling for what "remote" actually means until they have actually been to some of these places outside of Europe. "Remote" to a German might mean that it takes more than 30 minutes to the next highway. "Remote" means that cell reception drops to 3G, or that there's only one gas station in a 20km radius. Lots of folks I knew always talked about going to the outback in Australia as their first major trip abroad, because "it's so remote". It's hard to convince them that there's "remote enough" and "way too remote". I know plenty of places, specifically in Canada and the US, where driving for ~ 60 minutes from a major city will get you somewhere remote enough that you won't spot another soul. This is hard to grasp for us Germans since there's basically no place in the whole country where you're truly by yourself. My two cents.

Look at the papers of Andrew Zhai (Pinterest) and how they do it.

Yes, though at this point I'd say this is old news and table stakes, so I expect everyone to be using this type of data already. As an example, Orbital Insights began tracking 250k parking lots across 96 retail chains at least all the way back to 2017. Same for things like monitoring gas silo levels via satellite imagery, etc. If you read it on the blog of one of the many sat image providers I would assume there to be no more competitive advantage to be had, unless you can read additional information from that data that other traders might have missed.

I'm a long-time vim user, and haven't really used anything else over the past 15-20 years. I use a nice color scheme, barely any plugins and a moderate but static vimrc. I feel like this is my happy place, it let's me write with the setup I'm used to, in any terminal, on any machine, and on any codebase (JS, Python, Go, HTML, C, etc).

Every now and then I see the magic of modern text-editors (VSCode et al), especially with code completion /intellisense and file trees. For me, I rarely feel like I need to be able to complete function parameters in my code to be more productive. Code-writing takes up such a small amount of the creative process that I'm perfectly fine looking up seldom-used functions in a web-browser. I wonder if anyone has ever attempted the jump from longtime-vim-user to these and can share their stories about why or why not.

> In fact, the German in-joke is that the reason Tesla built a factory in Germany is so that the Germans could (try to) teach them how to fix the panel gaps. :-)

As a German I can certainly say that folks here really pay attention to where cars are manufactured. Tesla Model Y's available on various platforms are boldly advertised as "Manufactured in Grünheide". At the same time people are aware that some domestic models (such as the Mercedes EQS SUV) are solely manufactured in the US and then shipped over, which are sometimes conceived as lower quality as a result.

Those are the same numbers as on the tax invoice, and in that section it just says "Fees for all charges, including card charges and other payment methods." Curious if that number already includes charges for things like Subscriptions.

Been using Stripe for years but now I realise that I don't even know what plan I'm on and can't see what Stripe is charging me. I get a monthly "tax invoice" which includes all charges done through Stripe and comes out at ~ 2.9% of the volume, but I don't see any line items for Billing or anything else. Where do I find this stuff?

Not if you download a small number of large files ;)

That's great to hear, happy Hetzner customer for many years. Now if they start offering dedicated servers in US locations with equally competitive pricing as for their Germany and Finland DCs then a lot of other players are going to feel the heat.

This is great, not having to set up Consul or Vault makes an easy deployment process even easier. Upgrades are just as easy, just replace the binary, restart the cluster one node at a time and that's it. Never had any issue with Nomad in production in the past ~ 2 years.

Thanks for the great post!

One small addition: Nomad recently implemented basic service discovery functionality into Nomad itself, so for simple use-cases you might get away with just a Nomad cluster without Consul running alongside: https://www.hashicorp.com/blog/nomad-service-discovery

I believe AWS is also using Equinix in some locations.

We Germans probably have a standard design system for the documents we send by Fax...