Show newer
qeef boosted

Just want to say that I just published this repository github.com/karlprieb/writefree.

It's basically a way to deploy @writefreely using docker.

qeef boosted

I feel like someone at Microsoft is watching KDE Plasma a little bit too closely...

Plasma's slogan since 2017: "Simple by default, powerful when needed"

Microsoft advertising Windows 11: "Simple by default, powerful by choice"

Really? 🤔

The main visible change of the project upgrade git.sr.ht/~qeef/damn-deploy/re is the refactoring of the JavaScript client. Well, not much visible as it's refactoring. However, at least the statistics page changed and maybe a bit of performance improvement is done.

Preparing for new mapping workflow is not much visible change. (The teaser are two new scripts of git.sr.ht/~qeef/damn-client.py)

One of things I like less than JavaScript is Java, but the upgrade to the damn plugin is needed this time.

Show thread
qeef boosted
qeef boosted

Make a community presentation at an Foundation Board Meeting. Are you part of a local chapter, or a local community, putting together an organized project, or developing software? The board would love to hear from you.

openstreetmap.org/user/mikelma

Feel free to test refactored web client for the project: git.sr.ht/~qeef/damn-client.js (just clone repo & run static/index.html)

The changes are just to make the code a little bit clearer, as it's pain for me to maintain that JavaScript thing. Small performance and visual improvements included.

I will be off the net for the weekend, I would make the release just now otherwise.

qeef boosted

Junior dev: What's the best prefix for global variables?

Senior dev: //

qeef boosted

I created a library to read data files (PBF, XML, OSC) initially to scratch my own itch. But it's nice that some others are apparentlying finding it and using it and sending me patches. 🙂🙂
github.com/rory/osmio/

qeef boosted

RT @natfukue
The vaccination at Umi, a town in Fukuoka, is done smoothly and effectively with a doctor & his team moving while elderly residents sit and wait. They can give shots to 120 people in an hour, 8 times faster than before

I think that something like this helps developers getting oriented in the project. Maybe administrators, too. This graph is not meant for users/mappers.

- Solid links are docker-compose config-related.
- Dashed links are HTTP requests.
- Dotted is just-not-used-now connection.

qeef boosted

¡Divide y mapea!
El proyecto #damn (Divide and Map. Now.) ayuda a los mapeadores a dividir un área grande en cuadrados más pequeños de forma que resulten más fácil de cartografiar.
#openstreetmap #osm #mapas #maps damn-project.org/

This is forgotten I/O utilization graph for the last "average" test of 200 mappers and 2 areas.

Show thread

I did another round of "average" load testing for 200 mappers and 2 areas to maintain the compatibility with en.osm.town/web/statuses/10618 and en.osm.town/web/statuses/10618 (the same number of mappers, the same number of areas.)

The interesting time is at start 11:40 -- spawning of mappers. Next, around 12:13 to 12:18, where mapping is finished (i.e. 0 % to map). Finally, 12:45 -- upkeep script runs while server is returning 404: no square to map. (I checked it with `journalctl -u damn_upkeep.service -f`.)

Show thread

So the results looks more like the "extreme" results when changing times towards the "extreme" load times (git.sr.ht/~qeef/damn-server/tr) I will keep "extreme" and "average"clearly distinguished.

What also influence the results is locust _spawn rate_ (mappers spawned/second) I will keep it such that all the mappers are spawned within the first minute.

Also, actual database parameters are git.sr.ht/~qeef/damn-deploy/co

Show thread

First round of endurance load testing. Started at 12:00, 0% to map at 15:00, non-recoverable CPU load after 18:00.

My guess is that it's upkeep scripts.

Also, I think that I should speed up waiting of locust average mappers from 30 - 60 seconds to 2 - 5 seconds. I will let the mapping time of 30 - 60 seconds, though.

Let's see.

Show thread

I think that 200 mappers (30 s mapping, 30 s waiting) with 4 areas is the top wall for load testing. I've tested 300 mappers with 6 areas for about 10 minutes and I don't feel confident about it.

Recall that the instance of damn-project.org/ runs on $5/month VPS with 1x 2.2 GHz vCPU, 1 GB RAM, and 25 GB SSD.

Show thread

deploy v0.20.0 git.sr.ht/~qeef/damn-deploy/re includes the improvements.

The results of load testing for the server of damn-project.org/ with 4 areas and 200 mappers (all spawned in the first minute,) and "average" load scenario: 30 - 60 s mapping, 30 - 60 s waiting (git.sr.ht/~qeef/damn-server/tr) are attached.

Run for 1.5 hour approximately -- after that time there were 0 % to map for all of the areas so the results could become biased.

Server: 1x 2.2 GHz vCPU, 1 GB RAM, 25 GB SSD.

Show thread

I did some improvements to the server and the database. Testing on the localhost looks good. Next, I need to test the server of the damn-project.org/ instance.

(The images are from the "extreme" scenario of load testing git.sr.ht/~qeef/damn-server/tr run for few minutes only.)

Show thread
qeef boosted

I have encountered more image descriptions on Mastodon in 24 hours than I have in Twitter in a couple of years. Seriously. I'm not exaggerating.
As a blind person, this means a lot to me. If you read this and you describe your images, thank you so, so, so much on behalf of all of us. If you don't, now you know you'll be helping random Internet strangers make sense of your posts by typing in a few more words than usual.

Show older
En OSM Town | Mapstodon for OpenStreetMap

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!