syp @syp@freeradical.zone

Hi, I have strong interests in free software and anti-authoritarian leftist politics. So self-organized communities & their histories, infrastructure & reproductive labor. Used identi.ca years ago & left centralized social networks long ago. Glad to see a new generation of federated online communities. #introduction

So dear #lazyweb whats your favorite online communication tools for *internal* communications in #activist communities?

Ideally long-term, archival functions and short-term discussions would fit into one and the same thing. So think wiki + forum + calendar.

Crabgrass (we.riseup.net) is used quite a lot in my circles but it's showing its age and still lacks a calendar for example. mailing lists have a low barrier of entry but are unfit for calendaric or more permanent information.

Is there a way to customize the columns displayed in the #mastodon web client?

https://github.com/NixOS/nixpkgs/issues/24288 for example illustrates the issue. Maybe I am overlooking something, but the only workaround I am aware of is to create a wrapper script which injects secrets into the configuration file at service-start-up-time? That does not sound right to me...

Tried #nixos, for the first time since a few years ago, for a appliance I had to set up. Quite surprised in negative way that *everything* in the nix store - including passwords and private keys - is world-readable which makes it almost unusable at least for multi user systems.

For the moment, I am writing simple user-space programs, but I can't wait until my day-job leaves me with a bit more head-room to look a bit more into the #mirageos world during the evenings.

Coming back to #ocaml is a very pleasant experience so far. jbuilder is *much* nicer than the other build systems I remember and utop is really polished and tooling in general seems to be ready for my 'daily' usage.
And thanks to the #mirageos people, there's even stuff like a TLS implementation in a safe language which can be trivially used with the(?) major http client (cohttp). I am impressed! :)

@tek Maybe that would be a good topic for mastodons issue tracker? Because it does not only affect tor but all other alternative networks/DNS. Not sure if that's to much to ask from you. I could do it too, but I'd take a while because I would have to setup a local setup and try it myself ;)

I guess the do not really need to care for the few #android users who use #fdroid exclusively, but do amazons android devices include 'google play services' nowadays or are their users also unable to use all those apps?

#duolingo only works with 'google play services' on your phone, even if you install it using #yalpstore or something similar.Which is sad, it would have been a welcome variation to the fantastic #anki for vocabulary training.

@tek See https://www.torproject.org/docs/tor-onion-service for setup instructions . In this case you might even want to use a single-hop onion service as described in https://blog.torproject.org/whats-new-tor-0298 and https://www.torproject.org/docs/tor-manual.html.en . The choice if it is worthwhile is yours of course. ;)

@tek Regarding the onion service: I don't think it's needed quickly or even that it's necessary, seeing that you don't seem to block Tor exit nodes or so. It would just make it easier for Tor users to configure their clients correctly (because you don't need extra proxy configuration or so, just connect to the onion url while running Tor) and they are not too complicated to run if server anonymity is not needed.

@tek How long are users IP addresses kept on freeradical.zone / when are the rotated out of logs and backups? And what are you thoughts about a onion service for freeradical.zone?

Mostly because #Kubernetes combined with a storage layer like #Ceph and a software defined network like #Calico has a lot of conceptual overhead which is expensive in terms of resources, especially for unpaid projects and hobbyists in the team. Especially if we have to debug those things.

I mean, much of #Kubernetes benefit lies in the management of services which are already containerized to the point of being 'commodified'. Quite a lot of the stuff I am working on still runs on debian/libvirt/kvm like 10 years ago and it works okay. I guess a slow migration towards services in containers managed by puppet is the way to go for the year to come.