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.

Debian Trixie

Wczoraj została nowa wersja Debiana, o nazwie kodowej Trixie. Podobnie jak przy okazji Bookworm, wrażenia z instalacji.

Na pierwszy rzut, jeszcze wczoraj, poszedł kontener LXC w którym działa nowy certstream[1]. Nie bardzo miało co pójść nie tak i… nie poszło. Aktualizacja w zasadzie nudna, jedyne o czym warto pamiętać, to zmiana formatu w jakim podawane są źródła apt. Nie była to nowość, bo w końcu na desktopie mam od dawna Debiana Sid.

Rozochociło mnie to i jako drugi zacząłem aktualizować kontener z Linuksem na Chromebooku. No nie polecam. Będę przywracał z backupu. Ale to raczej nie wina Debiana, raczej coś przeoczyłem, lub – co najbardziej prawdopodobne – po prostu są dodatkowe elementy wymagane przy interakcji. Komunikaty niezbyt pomocne, w zasadzie naprowadzają jedynie na zbyt małą ilość przydzielonej pamięci ale… nie wygląda na używaną.

Potem zaktualizowałem jeszcze kontenery LXC w których działają blogi. Wymagane były drobne poprawki związane ze zmianami w składni nginx oraz wersją PHP. Dość standardowo.

Więcej roboty było ze skryptami Pythona i virtual environments. Musiałem wszystkie utworzyć, przy okazji wyszły drobne zmiany w bibliotekach. Problemem jest ilość i konieczność ręcznej roboty, nie stopień komplikacji.

Szybka ściągawka z poleceń, oczywiście polecam lekturę instrukcji:

apt update
apt upgrade
# Zmiana wpisów w sources (sed -i "s/bookworm/trixie/" /etc/apt/sources.list)
apt update
apt upgrade --without-new-pkgs
apt full-upgrade
apt autoremove
apt modernize-sources
# Opcjonalnie
apt list '~o'
apt purge '~o'
apt list '~c'
apt purge '~c'

Jeśli coś ciekawego wyniknie na pozostałych systemach, dam znać.

[1] Notka w trakcie tworzenia, nie ma chronologii, oj, nie ma…

abcc3.py

Wieki po projekciku, który robiłem w ramach projektu DSP2017, po którym chyba już nic w sieci nie zostało, doznałem natchnienia. Stwierdziłem, że teraz jest łatwo, można popytać LLMa, więc może łatwiej będzie znaleźć bibliotekę do ping pod Pythonem. Ostatnio opornie to szło…

Nie zawiodłem się, podał od ręki, wraz z kodem. Oczywiście przerobiłem, by bardziej pasowało. Przy okazji przy testowaniu (w zasadzie: testach uruchamiania) wynikło trochę błędów, które poprawiłem.

Po co to zrobiłem? Nie wiem. Chyba dla porządku. Drażnił mnie ten Python 2 w wymaganiach. A wyrzucić szkoda było. Chociaż raczej nikt nie używa. Choć IIRC ktoś się przymierzał, ale nie chciał poświęcić czasu, tylko „zrób mi”. Oczywiście za darmo. Trochę nie miałem czasu, weny i… to tak nie działa.

Warto po latach przypomnieć czym jest abcc? Na dzień dzisiejszy to rzeźbiarstwo figurowe – program do wybierania najlepszego łącza z kilku dostępny z wykorzystaniem zadanych wag, na podstawie strat i opóźnień. W sumie kiedyś, w czasach routerów na Linuksie miało to sens. Chociaż nic nie stoi na przeszkodzie by i dziś podpiąć dowolny skrypt i sterować np. przy pomocy SNMP routerem operatorskim. Istniało komercyjne rozwiązanie, które mniej więcej robiło to samo. Oczywiście z ładnym inferfejsem i opakowaniem.

Albo można użyć na jakimś OpenWrt do balansowania łącza czy też raczej wyboru lepszej ścieżki do danej sieci. Bez BGP, na podstawie wyżej wspomnianych metryk. Przy LTE itp. może być użyteczne.