qeef boosted

When websites say "use our app, it's much better", they mean better for them, not you.

qeef boosted

Did you miss any speakers from last Friday's conference?

Worry not!

Watch the Day 2 playlist of presenters from our channel: youtube.com/playlist?list=PL_Y or watch the live stream itself: youtu.be/aqQ5tbwrbTs

qeef boosted

Did you miss any of our speakers yesterday?

The day 1 playlist is now available for your convenience: youtube.com/playlist?list=PL_Y

Subscribe to our YouTube channel for updates, or watch this space for announcements.


---
RT @pistangmapa
DAY 1 DONE!

Thank you for attending Day 1 of Pista ng Mapa 2020.

See you next Friday!

You may visit …
twitter.com/PistaNgMapa/status

qeef boosted

@sir I'm starting a linux community in my hometown. I already created a mailing list on sourcehat with the intent of teaching my fellow citizens how to use it and then using it for technical support and discussions.

qeef boosted

RT @Mapbox
This month the PH🇵🇭 mapping community is gathering at the @PistaNgMapa virtual conference. Catch our Day 2 talk today with @maningsambale and @Marena_B to learn how we support mapping for positive impact: pistangmapa.github.io/2020/pro #pnm20 #PistaNgMapa

qeef boosted
qeef boosted
qeef boosted

git changing master to main by default 

The argument against the word "master" is based on the unproven assumption that the term is loaded with racist connotations, and the mandate for change is based on the fact that the possibility of the assumption's truth is nonzero and that the side-effects of the change are small.

If that were true, I would be on board with it. However, it's plainly clear that the impact of git upstream switching the default branch name to "main" is going to be huge. Many scripts with the "master" hard-coded are going to break, scripts written on the valid assumption that the name "master" was an intrinsic, unchanging property of git.

Every programmer who works with repositories before and after the change are going to constantly mis-remember which is which, and we'll have to guess at the default when working with new or unfamiliar repositories.

This event is going to establish a new epoch in git. We should take that seriously.

Which means we have to confront the fact that the assumption (that inherent racism is present in the word "master" and is causing harm to those who have suffered under racism) may not actually be true. The claims do not hold up well under scrutiny. And, as far as I can tell, the cause is championed disproportionately by white people.

The moralized nature of the question puts an external pressure on decision makers on the git project, which is normally not present for other patches. They have to consider, if they review these changes negatively, will it affect their personal reputation? Their careers? If there's even a slight chance of this, is it better not to argue the matter at all, and rubber-stamp the patches? I don't think this change is being developed under the right conditions.

On the left, we have a tendency to rubber-stamp social causes with a lesser degree of scrutiny. I think that this is a testament to how much we value empathy and solidarity, but I don't think it's a healthy way to approach our problems. Software breakage has a social cost, too.

qeef boosted

Nice @pistangmapa question about client last Friday: "What about low bandwidth connections?"

I tried to test it but not sure how to do it exactly. If you have better idea, I would be happy to know it.

I tried Chromium "Performance" with custom setting for GPRS (50 kbps download, 20 kbps upload, 500 ms latency.)

I tested two requests from the server:

- server.damn-project.org/areas (20 areas, 4.0 kB)
- server.damn-project.org/area/7 (295 commits, 44.0 kB)

which is comparable to downloaded client.

Have you seen the client
client.damn-project.org/ on mobile phone? I recommend to switch to *LIST* view though...

It may sounds stupid but the intro web page was not a priority for the project. However, I believe it's important for mapping communities.

I wanted to: (1) keep it as simple as possible and (2) allow customization in maximum scale.

The solution is to provide link to a docker git repository (must end with .git because of !@#$ docker; must export port 80) in .env file of git.sr.ht/~qeef/damn-deploy.

damn-project.org/ is run by git.sr.ht/~qeef/damn-www.git.

I am going to play with DNS tonight (UTC). Please, expect some outage of the project again...

I am going to play a bit tonight (I mean UTC evening/night) with the deploy, so it may be off a bit longer than usual.

Sooooo, after about 3 weeks (approximately?) I decided to drop off milestones, as there were few new things waiting to be released but can't because milestone is not yet closed.

I deployed these -project things now.

Also, I must note that it's not a problem of milestones planning workflow. I think that it's just that the project has currently specific development workflow. (Like that I do things when I have a bit of time :)

Show thread
qeef boosted

Jan 2019: Travis CI acquired by private equity
Feb 2019: Travis CI senior engineering staff laid off
Nov 2020: Travis CI pricing changes

SourceHut: We don't take outside investments™

qeef boosted
Show more
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!