„Solarpunk is a movement of artists, writers, and activists interested in changing the trajectory of our world for the better.

As a genre of fiction, solarpunk comprises optimistic science fiction stories that engage with issues of environmental and social injustice. Solarpunk stories don't always elaborate on the specific solutions that led to a better world, but they do always strive to show that better futures are possible. Often paired with the aesthetic of Art Nouveau—which was historically an anti-capitalist movement—solarpunk worlds strive for a balance of nature and technology, with degrowth and decentralization as core values.

A lot of climate fiction focuses on the disasters and the dystopian outcomes of climate change and ecological collapse. Solarpunk doesn’t ignore those issues, but it focuses on how we make the world better, and how we thrive and adapt in the world we’re headed into. It’s an interruption of the narrative that we are doomed and there’s nothing we can do about it. Negative messaging about climate change tends to make people feel hopeless, and the cognitive dissonance produced when blame is pointed at individual action can actually bolster denialism. So solarpunk uses different tactics to try to get people’s attention. Rather than “if this goes on, here’s the worst that can happen,” solarpunk says, “if we change direction, here’s a better version of what could happen.”

Sarena Ulibarri

via "Towards Solarpunk Futures"

https://www.tc.columbia.edu/sustainability/news/stories/2022/solarpunk/

#Solarpunk #Storytelling #Fiction #Writing #Future #SarenaUlibarri

How background workers work in littleFedi

Every littleFedi instance runs a background job queue. Jobs are split by kind, but they all share one thing in common: they sit in a database table and are executed by the "main" worker pool, whose size you control with queue.workers (default min(8, GOMAXPROCS), 1 on the low_power preset).

The kinds fall into two groups:

• Heavy, mostly CPU/DB-bound work - inbox (ActivityPub signature verification, actor fetches, home-feed fan-out) and media_cache (image decoding). These block a worker synchronously while they run.

• Light, mostly network-bound outbound work - delivery (one signed POST to one remote inbox), its delivery_fanout expander, push_notification, and send_email. These are short and often latency-sensitive: a boost that hasn't landed yet or a push that hasn't arrived is visible to real people.

By default every worker can pick up any kind of job. That is perfectly fine for most instances. The only caveat: job priority only orders queued rows, it cannot preempt a job that is already running. So if a slow inbox or media job is occupying the single (or few) workers, timely outbound delivery, push and email can end up waiting behind it.

light_workers (default 0, disabled) spins up a second, dedicated worker pool for exactly those four light outbound kinds. It is a strict either/or, not extra capacity: with light_workers > 0, delivery, delivery_fanout, push_notification and send_email run only on this pool. The main pool stops touching them, even when idle, and there is no overflow between the two. So workers=8 + light_workers=2 gives outbound federation exactly 2 workers, not 10.

The light pool also yields to interactive requests like the main one does, but with a shorter wait (3s vs 10s) when both compete for the single foreground-recovery slot - so short, people-visible outbound jobs win that one job while every other worker keeps yielding to keep the web UI responsive.

It's totally optional.

With 0 (the default) all four kinds stay on the main pool. The extra goroutine(s) cost is negligible even on constrained hardware.

It can be useful for:

• low_power devices (e.g. Raspberry Pi or similar): keep workers=1 for the heavy inbox/media work and enable light_workers=1 so outbound delivery, push and email keep flowing even while your single main worker is blocked on a slow inbox job. This is the recommended combination on a small box.

• Instances where inbox/media loads spike: a burst of incoming activity (a big follower purge, backlog of signature-verification work) can stall time-sensitive outbound delivery on a shared pool; giving the light kinds their own pool decouples them.

• Visibility matters: push notifications and federation delivery are things users notice immediately; if you care about their latency on a busy instance, the dedicated pool is a cheap way to protect it.

Running a single pool is the right default for most instances. Also note both pools share the DB connection limiter (sized from MaxOpenConns): the database is the serial resource, so worker counts beyond the connection count buy nothing, extra workers just deepens the queue in front of it. Size light_workers for your real outbound throughput.

#littleFedi

„Every Political System Is The Same Prison“

„Every time someone says »we need a better government«, what I hear is »we need more comfortable handcuffs«.

When I was a kid I lined up all the political systems in my head trying to find the one that worked. I never found it. Not because I didn't look hard enough — because the question was wrong. You can't find a working political system for the same reason you can't find a working perpetual motion machine.

Every durable large-scale system built on ruling territory has run on the same four things. Not most of them. All four, every time: violence, resource extraction, hierarchy, and artificial scarcity. Run any -ism through these four and the pattern holds. The labels are arguments about which version of the same machine to run. The machine itself is never on the table.“

https://inv.nadeko.net/watch?v=yf5_fnvrblk

(https://youtu.be/yf5_fnvrblk)

#MarinaKarlova #Maledicta #Author