lukeqsee

Can you email me luke <at> stadiamaps.com? I would love to chat about QGIS plugins, and we may be able to sponsor you to build one.

QGIS is the swiss army knife of geospatial computing.

I use it daily, and frequently, for all sorts of work building a location API SaaS company. It's a sterling success of open source, on par with as impactful as Linux, for the geospatial world (IMO).

> Russian officials already know that any “negotiation” or treaty signed with Kiev (in fact with the US) is not even worth the paper it is written on, I had hoped the Estonian “Foreign Intelligence Service” would have been aware of that.

Can you substantiate this? Please provide to specific examples.

We've been building stadiamaps.com to help with those table-stakes--affordable, private, and independent mapping services are vital for everyone today.

That being said, projects like this will make it easier for folks to get the basics if they're comfortable with self-hosting. Overall, map tiles are losing their competitive edge and becoming commodities.

Checkout planetiler: https://github.com/onthegomap/planetiler. A super fast way to take an OSM data dump to create vector tiles.

MapLibre board member here. Really cool map! I also just love seeing MapLibre random places on the internet. :)

Thanks, Durkie! :)

Small note of clarification about MapLibre. It's a vendor-neutral, community-led project supported by a lot of different industry participants (including AWS & Meta).

https://maplibre.org

I'd love to hear your thoughts directly on this one. They're a primary competitor, and we would be happy to learn how to better serve your needs! (Email in bio.)

If it's just local--depending on the exact service--you probably wouldn't need a lot of RAM. Expect memory requirements to scale somewhat sub-linearly with diversity of regions simultaneously accessed.

For sure! There's a lot of in-between solutions (depending on what services/regions/update frequency you need).

Serving large data sets at acceptable latency typically requires some proportional amount of RAM to keep frequently accessed files and indexes in memory (especially if you're serving off of HDDs).

It depends on the service, but we frequently find geo services are RAM limited up to a certain point (at which point there's enough cached to make it CPU limited).

For businesses who don't want to self-host maps, but still want to migrate away from Google Maps (or other major cloud providers' offerings), there's quite a few options (full disclosure, I run one of them):

- https://mapbox.com

- https://stadiamaps.com

- https://maptiler.com

- https://jawg.io

- https://thunderforest.com

- https://locationiq.com

If market makers are getting liquidated with any consistency frequent enough to require exceptions, they are in deep trouble.

Market makers almost universally remain delta-neutral (that is, their goal is to be hedged against almost any market movement). Sure they sometimes get off balance and lose some money, but the margins for makers are typically so thin that liquidation is basically equivalent to total failure.

For two: BlockFi and Gemini Earn both have stopped withdrawing. This means a lot of people have a lot of crypto that they may or may not ever get back.

I suspect it will take some time, but at the ecosystem level, contagion is already here. Time will tell if it spreads beyond to the markets (but it feels inevitable at some level).

I think "Outage" as stated is a bit over-the-top. We run significant operations in most of these DCs, and we have seen zero impact. YMMV of course, but I think it's a big disingenuous to say this is a full outage.

That's not a bad one-word description. :)

I doubt what I saw will really add to what Doctor_Fegg says in his talk. However, a few examples:

https://daylightmap.org is built by Meta (Facebook) to allow their maps to meet their quality needs consistently while still pulling and encouraging OSM updates. This unlocks OSM data for a large amount of sensitive corporations.

I personally have made quite a few edits on behalf of customers who pointed out errors in the map.

The popularity of OSM-based navigation apps has made it useful for people to download editing apps to ensure their locale is as up-to-date as possible (this is getting better and better every year).

Every company starts as a "net taker" until they find their contribution niche, so I'm not concerned. Besides, the positive effect of more eyes seeing OSM and more companies caring about its quality cannot be understated. (I can point to dozens of examples of this.)

Welcome to the party, TomTom! A little more healthy competition never hurts. :)

Seriously though, the prestige of OSM and the companies building on it is only growing—a success story of epic proportions to the open source and open data communities!

Great coverage on those answers. Thanks!

One followup: have you considered handling the actual usage calculation and aggregation? One use case that comes to mind is accepting API request logs from (CloudFlare|CloudFront|Logstash), processing them, and directly deriving billing from those. That moves the entire process outside of a system your customer has to touch (in cases where complex application-layer knowledge isn't needed). One less thing for a potential customer to worry about (and removes one of the reasons to need read access to a database in many cases).

Again, all the best! Happy hacking. :)

Congrats on launching a product of this complexity! Best of luck.

I'm staring down the barrel of a potential usage pricing implementation, and I'm glad the majority of the foundational work is already done. It'd be no cakewalk to implement from scratch.

How do you generally address the risks of read access, GDPR, and other similar security and privacy concerns related to your technical model?

No one uses the plain text, though. Every tool I have used, uses the PBF. (I run a company built on OSM, so that's a lot of tools.)

ScyllaDB's obsession with performance by working closely with deep understanding of hardware and software and not simply adding more machines is really impressive.

They consistently demonstrate that we are under using our CPUs compared to potential.

HAProxy also has Lua support.

The general answer here, is no, I don't think you can do much in HAProxy that you can't do with OpenResty, but with HAProxy you generally don't have to pay the overhead of Lua (and HAProxy tends to be very well optimized, so the difference can be significant at high throughput of requests / bytes).

We built a fantastic CDN on top of HAProxy, and all these nifty tricks are only scratching the surface of its potential.

The ease with which you can make real-time reactions to threats and conditions is really second to none, and with the ability to truly "hitless" reload (reload without affecting in-flight requests and connections) it makes those have immediate impact and no customer impact.

Sometimes the capabilities make the config a bit inscrutable, but other than that, I can't recommend it enough.

Missed that. Thanks!

The article didn't seem to say how much they're raising prices, only that they're raising prices due to electricity.

Where are you pulling seeing the price change %? I may need to edit that to marginal, if it's only 10%. :)

For sure, and I agree, but that's underscoring my point.

The marginal cost of cloud computing isn't capex, it's opex. And of that opex, it's mostly electricity. We aren't paying for the hardware so much as we're paying for the cost of keeping it turned on and cool.

While the pricing is interesting, I think the fact it is driven by the input costs of electricity is even more telling.

The fact that electricity costs is the dominating (edit, correction: marginal) cost of cloud computing basically means that:

1) We're up against physical barriers to lowering the cost (and ecological impact) of our clouds.

2) Optimizing for less compute will pay multi-fold dividends over the next few years where we can expect energy prices to continue rising.

3) Building more power-efficient chips is a big deal, and I'm glad to see more general ARM deployment, given their efficiency gains.