Curious - why write it as a function in presumably .gitconfig and not just a git-summary script in your path? Just seems like a lot of extra escapes and quotes and stuff
I was going to say, the OP's assertion that "they" are typing all these commands out by hand each time without an alias is just one of many tells that this post is AI slop. Nobody that proficient with shell commands should be typing any of those by hand more than once or twice without aliasing for reuse.
I see tons of articles like this, and I have no doubt sqlite proved to be a great piece of software in production environments, but what I rarely find discussed is that we lack tools that enable you to access and _maintain_ SQLite databases.
It's so convenient to just open Datagrip and have a look at all my PostgreSQL instances; that's not possible with sqlite AFAIK (not even SSH tunnelling?). If something goes wrong, you have to SSH into the machine and use raw SQL. I know there are some cool front-end interfaces to inspect the db but it requires more setup than you'd expect.
I think that most people give up on sqlite for this reason and not because of its performance.
> As these were not logistical flights, they were not covered by the bilateral treaty governing U.S. military bases in Italy which allow for logistical and technical use; that led Defense Minister Guido Crosetto to deny the planes the use of the Sigonella base since permission in this case would need approval from the Italian parliament.
> their flight plan was not communicated in advance to the Italian air force general staff, nor had the American aircraft received authorization to land,
Sounds like they might have gotten authorization if they had just told them in advance.
Fair point! To be clear: rari handled the traffic perfectly fine - the issue was an overly defensive rate limiter I had configured (and it was grouping proxy traffic incorrectly). The framework itself was cruising, I just had the safety rails set too tight. Adjusted now and it's handling the load as expected!
We've been self-hosting protomaps (aka pmtiles) for several years. The only thing you need server-side is a web server that can serve static files and supports range requests (so anything works; I've tried caddy and nginx). The map is one large file, it's easy to share it between however many servers you need.
Downsides? Nothing major that I can think of. You have to add another client-side dependency (support for their custom protocol); the library is pretty small and easy to audit.
Editing map styles is slightly more difficult because generic maplibre styles won't work with it: they add a bit of custom sauce on top. IIRC this editor worked fine, you can import one of protomaps styles and base your work off it:
No, the names are there in the file, streets included. Their default styles did not support the languages we needed out of the box (everything was shown in the local language or English IIRC), but it was easy to fix by patching the style. I don't remember the exact fix, but it was about as simple as replacing something like `["get", "name_en"]` with `["get", ["coalesce", "name_xx", "name_en"]]`.
Sure. You can look at their demo, it uses the exact same single-file hosting mechanism (the network requests tab in the browser dev tools confirms it — it doesn't send any other requests), and street/house addresses are visible on the map.
Have used pmtiles to self-host a “find your nearest store” map, which only needed to cover Australia. Created two sources: (1) a low-detail worldwide map to fill out the view (about 50 MB), and (2) a medium-to-high detail source for Australia only, up to zoom level 15 (about 900 MB). In this case, there’s no need for up-to-date maps, so we were able to upload these two files to S3 and forget about them. Works great!
In short: We have a script that builds a pbf of the area we are interested in (Colorado, USA) from OSM, then set up a openstreetmap-tile-server container with that data, bring in our styles, and then set up renderd.
I had to go down this path for a print-on-demand book project. If you need high-DPI assets for physical print the commercial static map APIs are prohibitively expensive or restrict usage rights for resale. Self-hosting was basically the only way to generate 300dpi rasters at scale without destroying the margins.
I do. The pros are hosting own data and have total control over stack and cloud hosting. The cons are having to code your own stack and do cloud management. I use PostGis to storage and serve vector tiles. And I use a simple backend with AWS S3 to store and serve raster data (GeoTiff COG).
Respect this commitment. I think to be honest I'd only ever consider hosting a tile server if I was actually rendering data on the tiles or there was something 'special' about them (e.g style). Using $whatever hosted tiles are likely to be faster for the user as they'll be cached, served statically.
What's the isolation level? They only mention write-write conflicts.
The reason SQLite's BEGIN CONCURRENT does not greatly increase concurrency (unless you're very careful with your schema and queries) is as much due to page level conflict detection as it is because it enforces serializable isolation.
MVCC is a non-locking algorithm for concurrent writers that the big databases like postgres use (with caveats like aborting some transactions if conflicts would exist). It's not a matter of pushing locks around but allowing multiple threads to operate on the data concurrently.
reply