I Love Free Software Day 2026

W piątek, w ramach I Love Free Software Day 2026 odbyło się spotkanie w Poznaniu. Mimo niezbyt fortunnego terminu[1], na spotkanie przyszło kilkadziesiąt osób. Spotkanie było organizowane m.in. przez hackerspace Knyfyrtel, który organizuje też P.I.W.O., co czyni z organizacji ważny punkt na mapie wolnego oprogramowania w Poznaniu.

Chociaż teoretycznie była określona okazja i cel, to poszedłem raczej pod pretekstem. Zresztą agenda też była luźno związana, choć jeden z wykładów był typowo poświęcony tworzeniu pakietów i roli maintainerów.

Tematyka dla bardzo różnych odbiorców. Był wykład o grze OpenTTD, jaka jest historia, jak powstała, jak zacząć grać i jakie są możliwości. Nie zagram[2], ale doceniam. Na drugim biegunie były obliczenia rozproszone na klastrach (ciekawe, ale mocno pod studentów) czy bootc.

Ten ostatni wykład, oraz wykład o Fediwersum przypomniały mi, że dwie rzeczy są w IT trudne. I chyba przekłada się to na opisy czym jest dane rozwiązanie. NFM: wyjście od jak coś działa niekoniecznie ułatwia zrozumienie odbiorcy, o co chodzi. Pewnie lepiej skoncentrować uwagę odbiorcy na czymś, co już zna, pokazać różnice, zalety, wady i ew. na koniec ew. wejść w szczegóły techniczne realizacji.

Potrzebę odniesienia do znanej koncepcji było widać po pytaniach. W przypadku Fediwersum jedno z pytań, które padło z sali (z pamięci) jakiego typu serwisem jest Szmer, czy to taki Wykop? Drugie dostałem po wykładzie od kumpla[3] co to jest ten Mastodon? No nie bójmy się powiedzieć, że to taki Twitter. To oczywiście odpowiedź zła, albo raczej nieprecyzyjna, ale znowu, nazywanie rzeczy jest trudne. Szczególnie, gdy nazwa sieci i jednego z serwerów, który pozwala na korzystanie z jej są takie same[4]… A odbiorca dokładnie tego przybliżenia koncepcji potrzebował.

Organizacja spotkania bdb. Bez problemów technicznych, punktualnie. Były napoje, pizza, możliwość wysłania fizycznych kartek i okazja do spotkania znajomych. Nie żałuję, że poszedłem.

[1] Piątek 18:00 to raczej czas, kiedy jest sporo alternatyw.
[2] Robiłem kiedyś, dawno temu, przymiarkę, nie wciągnęło mnie. Ogólnie nie mój typ gier.
[3] Wie co to social media, świadomie nie używa, raz na parę m-cy zagląda na LinkedIn.
[4] No niestety, tak właśnie jest.

Mastodon a blokowanie

Mastodon chwali się, że daje możliwość kontroli widoczności. Na poziomie użytkownika posiada do tego celu dwie zbliżone opcje. Pierwsza z nich to mute, czyli wyciszenie, które, cytując komunikaty pojawiające się przy blokowaniu:

They won’t know they’ve been muted.
They can still see your posts, but you won’t see theirs.
You won’t see posts that mention them.
They can mention and follow you, but you won’t see them.

Druga z nich to block, która jest opisana jako:

They can see that they’re blocked.
They can’t see your posts and you won’t see theirs.
You won’t see posts that mention them.
They can’t mention or follow you.

Czyli w obu przypadkach nie widzimy postów w których jest wymieniane (mention) dane konto. Ma to nieco sensu, ale wykorzystując którąkolwiek z możliwości, zepsujemy sobie dostęp do treści. I to nie tylko pisanych przez zablokowane konto, ale także znikną nam wszystkie wiadomości w wątkach, w których jest wymienione to konto, niezależnie od tego, kto je napisał. Dość inwazyjne, zwłaszcza, że ludzie często zostawiają w wątkach wszystkie dotychczas wywołane osoby.

Jeśli chodzi o block, to osoba zablokowana widzi, że jest zablokowana. Przynajmniej teoretycznie, bo co prawda taka informacja jest dostępna (w API), ale nie ma żadnego miejsca, gdzie możemy sprawdzić jakie konta nas zablokowały. Nie dostajemy też informacji o blokowaniu. Co w praktyce możemy zauważyć? Zepsute wątki, zwłaszcza brakujące wiadomości. Choć wtedy może to wynikać także z wyciszenia przez nas innej wywołanej osoby, poprzez mute. Najlepszą metodą bez sięgania po API jest sprawdzenie, czy mamy możliwość obserwacji danego konta. Brak możliwości włączenia obserwacji danego konta – opcja niekatywna – oznacza, że zostaliśmy zablokowani.

Jeśli chodzi o they can’t mention to… nie działa. Jak najbardziej można zamieścić toot zawierający oznaczenie konta, które nas blokuje. Serwer podpowiada nicka i obsługuje go normalniew toocie. Zapewne wywołana osoba nie dowie się, że została oznaczona, ale to nie znaczy, że oznaczenie nie została. Co więcej, wszyscy inni użytkownicy będą widzieli to oznaczenie. Nie wiem jaki był zamysł autorów, ale wygląda na obietnicę bez pokrycia. Podobnie jak they can see that they’re blocked. Niby można się dokopać, ale czy widać? Polemizowałbym.

Jeśli chodzi o they can’t see your posts, to nie do końca jest to dowiezione. Zadziała tylko, jeśli mamy ograniczoną widoczność własnych tootów do zalogowanych kont. Co raczej nie jest popularnym ustawieniem. W przeciwnym razie wystarczy, że oni skorzystają z okna przeglądarki w trybie prywatnym.

Podsumowując, mam wrażenie, że z poziomu użytkownika blokowanie/wyciszanie na Mastodonie zrobione jest słabo. Skomplikowane (dwie różne metody), nie do końca działające zgodnie z opisem, za to bardzo inwazyjne. Wygląda, jakby ktoś projektując rozwiązanie mocno skupił się na aspektach technicznych, zapominając o „dużym obrazie” i skutkach. W efekcie użytkownicy nie dostają więcej niż na innych platformach, za to cierpi używalność platformy.

Wpis przeleżał nieco w szkicach, więc nadeszła pora na publikację…

Boty są złe

Od pewnego czasu obserwuję social media i dochodzę do wniosku, że boty są złe. Przynajmniej w social mediach. Przynajmniej niektóre.

Pisząc o botach mam na myśli rozwiązania, które cyklicznie biorą aktualny stan, zamieszczają go w formie wpisu w social mediach. Klasycznym przykładem jest aktualna pogoda czy też jej prognoza w danym mieście. Ale może to być też zużycie energii w jakimś kraju. Pomijam – przynajmniej na razie, przynajmniej w tym wpisie – boty, które informują jednorazowo o pewnych wydarzeniach, jak np. zamieszczenie wpisu na blogu.

Dlaczego to jest złe? Powodów jest kilka. Po pierwsze, zamieszczane w ten sposób dane tylko pozornie są aktualne. Być może nawet będą aktualne w momencie zamieszczania, ale to wymaga od użytkownika (bardziej: obserwatora) obserwacji non-stop. Czyli karmią FOMO. Jeśli użytkownik zajrzy na nie po jakimś czasie od zamieszczenia, dane będą nieaktualne. Lepiej by uczynił, sprawdzając je u źródła.

Po drugie, tylko pozornie tworzona jest historia. Owszem, jest to jakiś zapis, który jakoś można sprawdzić, ale… jest to skrajnie nieefektywne w porównaniu z dedykowanymi sposobami prezentacji zmian w czasie. Takim jak np. wykres. Czy dostarczania danych źródłowych, takimi jak np. plik CSV. Szczególnie prawdziwe dla większych częstotliwości zamieszczania danych.

Nieeleganckie odpytywanie i przetwarzanie przez cały czas, niezależnie od rzeczywistej potrzeby, zamiast na żądanie – czyli generowanie zbędnego ruchu – to już detal. Wspominam o tym tylko ze względów porządkowych.

Ostatecznie doszedłem do wniosku, że dane dostarczane przez boty informacje tylko zaśmiecają timeline. Przy okazji zużywając energię na przekładanie nieaktualnych danych z miejsca na miejsce.

Sprawdziłem obserwowane konta prowadzone przez boty na Mastodonie (którego aktulanie głównie używam jako platformy social media) i wśród obserwowanych 205 kont mam:
https://pl.fedimeteo.com/szczecin
https://pl.fedimeteo.com/poznan
https://fedi.stfn.pl/@energetykapolska
Czy też raczej: miałem. Dodatkowo wyciszyłem https://mastodon.social/@icm_meteo bo pojawiało mi się na timeline z powodu obserwowanych przeze mnie tagów. Jeśli dobrze liczę, razem daje to 26 zbędnych wiadomości dziennie mniej.

Piszę to z perspektywy czasu, bo kiedyś idea botów wydawała mi się fajna. Obserwowałem boty pogodowe, zużycia energii. Nawet zdarzyło mi się dołożyć cegiełkę. Tylko dotarło do mnie, że to niepotrzebne. Less is more.