Migracja, której nie było

Obwąchiwałem się z serwisem Codeberg od jakiegoś czasu. Nie miałem może silnego postanowienia migracji z GitHub i motywacji do niej[1], ale gdzieś tam taka opcja istniała. Nawet zrobiłem skrypt do backupu repozytoriów z GH i pisałem o Codeberg, na którym założyłem konto.

Jednak pozmieniało się. Codeberg zmienił warunki korzystania z usług. Najpierw pojawił się zakaz utrzymywania repozytoriów, w których kod pisał głównie LLM. Bo rzekomo pojawiają się niejasności związane z copyright i nie ma gwarancji, że nie będzie szkodliwego kodu. Chwilę później dołączył zakaz projektów związanych z kryptowalutami gdyż szkodzą reputacji serwisu. I opcja migracji przestała dla mnie istnieć.

Dlaczego? Powodów jest wiele, ale najważniejszy jest chyba niesmak. Nie wiem, czy bardziej spowodowany pokazową deklaracją światopoglądową, czy podawaniem pretekstowych uzasadnień czy wypaczaniem idei FOSS. Pierwszego tłumaczyć chyba nie trzeba – manifestacja antyAI i antykryptowalutowa i chęć jej „zaistnienia” w warunkach usługi jest czytelna. A przy tym zbędna – istniejące punkty jak najbardziej już zabraniały hostowania projektów naruszających zasady. Nic nowego się nie pojawiło, po prostu zakazy są z góry, tematycznie, bez zastanawiania się.

Uzasadnienia uważam za pretekstowe, gdyż… po krótkim zastanowieniu łatwo dostrzec, że nie mają sensu. Zabronione są projekty pisane głównie przez LLMy[2]. Kluczowe słowo to oczywiście głównie. Bo czy w projekcie, gdzie tylko trochę kodu jest pisane przez LLM mogłoby dojść do naruszenia copyright lub pojawić się szkodliwy kod? Oczywiście przy założeniu, że takie rzeczy w ogóle występują, ale tę część można wyłączyć przed nawias jako nieistotną dla dalszych rozważań. Otóż mógłby, bo nie zależy to od udziału kodu generowanego przez LLM.

Kolejna sprawa to brak możliwości stwierdzenia, jak powstał kod – ręcznie czy z użyciem LLM. I w jakim stopniu. Czyli pozostaje ocena po deklaracji autora lub owocach. A zapisy dotyczące copyrightu oraz szkodliwego kodu już przecież istniały.

Podobnie jest z nieprecyzyjnym słowem powiązany (z kryptowalutami). Czy jeśli zrobiłem skrypt, który pobiera dane m.in. o kursach kryptowalut i robi analizę statystyczną/korelację z kursem walut i akcji spółek giełdowych, to już szkodzi reputacji?

Zresztą przy krótkiej rozmowie z jedną z osób, które współpodejmowały decyzję, usłyszałem „nie chce też żeby moje składki szły na bandwidth i storage dla ludków co se robią 5 projektów i puszczają armię botów w samopas”. No rozumiem, że ktoś nie chce[3]. Ale nie uzasadniajmy tego copyrightem czy szkodliwym kodem. Wystarczy napisać wprost, że takie projekty zużywają więcej zasobów.

Zostało wypaczanie idei FOSS. Chodzi o cztery wolności, których Codeberg zresztą wymaga w warunkach usługi. Dokładnie o możliwość dowolnej modyfikacji oraz o możliwość rozpowszechniania ulepszeń. Wyobraźmy sobie, że jest projekt open source, który tworzy plugin zabezpieczający przed botami przez zastosowanie PoW (proof of work). Ot, np. policzenie czegoś stosunkowo złożonego w JS. Ktoś wpada na pomysł, żeby zamiast zużywać prąd zupełnie bez sensu, dać użytkownikowi możliwość spędzenia chwili czasu na kopaniu kryptowalut[4] na rzecz właściciela strony. Obecnie taka zmiana nie ma możliwości znalezienia się w kodzie projektu rozwijanego na Codebergu, ponieważ jej zaakceptowanie rzekomo szkodziłoby reputacji serwisu.

Oczywiście można dyskutować, czy to faktycznie ograniczenie tej wolności, bo przecież można sobie modyfikować i publikować gdzie indziej. Tylko wg mnie taka możliwość jest raczej teoretyczna – community i rozwój jest w konkretnym miejscu, nikt raczej nie będzie z powodu jednego ficzera chciał zmienić platformy, prędzej odrzuci zmianę. To nie jest hosting, że zmieniamy dostawcę, przepinamy domenę na nowe IP i już.

Rozmawiałem na ten temat ze znajomym. Pojawiło się stwierdzenie, że potem jest zdziwienie i narzekanie, że (przez tego typu akcje) ludzie nie korzystają z europejskich rozwiązań, tylko uzależniamy się od rozwiązań zza oceanu. To smutne, ale skoro lokalnie dostępna jest jedynie wolność z gwiazdką…

[1] No bo to trochę taka sztuka dla sztuki by była – mało się tam dzieje, a backup mogę przywrócić gdziekolwiek.
[2] You must not share projects that mostly consist of code written by „generative AI”-tools.
[3] Co prawda pewnie wystarczyłby tu rate limiter, no ale…
[4] To nie jest nowa idea, był plugin/serwis do kopania Monero, zamiast reklam na stronie. Z różnych powodów upadło.

Optymalizacja strony

Kolejny wpis, który przeleżał wiele czasu jako szkic. Nie znalazłem na niego czasu, a teraz sprawdziłem i dobrze się zestarzał, więc opublikuję to, co mam, choć nie pociągnąłem do końca tematu, którym jest optymalizacja stron WWW, tym razem bardziej od strony serwera, niż WordPressa, o którym wtedy napisałem.

Na początek polecam wpis Yzoji o optymalizacji bloga. I komentarze do niego. Tak, wpis jest sprzed trzech lat. Tak, jest aktualny, a wszystko co tu znajdziesz powstało właśnie wtedy. Raczej postaram się napisać uzupełnienie, niż powtarzać rady z tamtego wpisu.

Efekty

Nie mam niestety porównania sprzed wprowadzania zmian, ale żeby było wiadomo o czym rozmawiamy. Efekty optymalizacji strony bloga, wg PageSpeed Insights, przedstawiają się następująco:

Wynik optymalizacji strony wg PageSpeed dla desktop - performance 100%
Wynik dla desktop
Wynik optymalizacji strony wg PageSpeed wynik dla mobile - performance 9%
Wynik dla mobile

Kompresja

Na przyspieszenie działania bloga pomogło zmniejszenie poziomu kompresji w nginx. Tak, dobrze czytacie, zmniejszenie, nie zwiększenie. Dlaczego? Otóż tekst kompresuje się dobrze tak czy inaczej. A różnice w szybkości działania kompresji gzip są znaczne. Czyli mamy mininalnie większą ilość przesyłanych danych, ale odpowiedź jest wysyłana znacznie szybciej! Być może to kwestia relatywnie słabego VPSa, ale skoro nie widać różnicy, po co przepłacać? W każdym razie w konfiguracji nginx mam:

gzip_comp_level 1;

Lazy loading

Kolejną rzeczą, która przyspieszyła działanie tego bloga było wyłączenie lazy loading. Było o tym u Yzoji, ale warto powtórzyć, bo znowu, jest to nieintuicyjne. W dodatku wszyscy mantrują, że włączenie lazy loadingu jest dobre dla szybkości ładowania. No i teoretycznie mają rację. Ale nie jest to prawdą na stronach, gdzie ilość załączanych grafik jest niewielka. Więc jak mam jedną czy w porywach dwie skromne grafiki na wpis, to lazy loading tylko spowolni ładowanie. Gdyby grafik było więcej lub były większe – pewnie włączenie lazy loadingu mógłoby pomagać.

Google

Wyłączenie zabawek Google. Firma ta prezentuje pewną dwumyślność. Z jednej strony chce, by strona działała szybko. Z drugiej strony, sama dostarcza rozwiązania, które fatalnie wpływają na wydajność strony i stwarzają problemy w ich własnym scoringu! Google Analytics – wydajnościowe zło. Fonty Google – kolejne wydajnościowe zło. Google AdSense też drastycznie pogorszy szybkość działania strony.

Rozwiązanie, jeśli nie chcemy całkiem pozbywać się Google? W przypadku AdSense można zrezygnować z wyświetlania reklam wszędzie i ograniczyć ich obecność do wpisów, na których jest największy ruch. Taki kompromis – strony z reklamami będą ładować się dłużej, ale większość stron będzie działać szybko. Oczywiście wiąże się to z rezygnacją z reklam na głównej. Nieco upierdliwe, bo oznacza to ręczne zarządzanie kodem JS odpowiedzialnym za wyświetlanie reklam na poziomie konkretnych wpisów, ale dla mnie OK. Zamiast Google Analytics polecam Matomo. Z fontów Google zrezygnowałem, zamiast tego pewnie można serwować je lokalnie.

Klucz RSA

Kolejna nieoczywista sprawa – rozmiar klucza wykorzystywanego przy SSL/TLS. Miałem podejście security is our priority i klucz RSA o długości 4096 bitów. Tyle tylko, że póki co 2048 bity są także uznawane za bezpieczne. No i na tym blogu nie ma nic wrażliwego. Najbardziej wrażliwe jest hasło, które przesyłam przy logowaniu, więc zmniejszyłem rozmiar klucza i… Pomogło to skrócić czas nawiązywania połączenia z serwerem. Znowu, może kwestia stosunkowo słabego VPSa. Przy tej okazji polecę jeszcze wpis o tym jak zrobić sobie certyfikat SSL/TLS z oceną A+ na nginx.

Jak widać, optymalizacja stron WWW nie jest oczywista i warto do tematu podejść kompleksowo.

Pretekst

Od jakiegoś czasu szukałem pretekstu, żeby pobawić się maszynkami z Ampere A1 od Oracle. Poza tym, w zadaniach przetestowanie Cloudflare na blogu wisiało… prawie 5 lat. I jeszcze na dodatek gorącym tematem jest AI, często reprezentowana ostatnio przez ChatGPT. Ale jakoś na nic nie było czasu i potrzeby.

Zatem wpadłem na pomysł, żeby postawić bloga, który będzie WordPressem, stojącym na VMce z arm64, za Cloudflare, a treść dostarczać będzie głównie AI. Trzy pieczenie na jednym ogniu. W sumie cztery, bo jeszcze sprawdzę indeksowanie tego tworu i zarobię miliony na reklamach. Poznajcie blog everything about coffee.

Przyznam, że było trudniej, niż się spodziewałem. Najpierw był problem z wyborem domeny. Stwierdziłem bowiem, że taki eksperyment wymaga stosownej separacji. W domenach raczej nie siedzę, więc znalezienie czegoś sensownego w niewielkich pieniądzach było trudne. Stanęło na tym, że analogicznie jak na głównej domenie niech się składa w jedno słowo. I tak powstał coffee express. Bez es. W sumie także bez e w środku, bo byłyby aż trzy kolejno, ale to już wybór, nie ograniczenie techniczne.

Domena

Wydawać by się mogło, że kupno domeny w 2023 jest proste, szybkie i przyjemne. Sprostuję, nie jest. A przynajmniej nie jest, jeśli korzysta się z TLD .es a kupuje w OVH. Rejestrator ma teraz dziwne wymagania, panel OVH ma dziwne pola i komunikaty. Ostatecznie udało się, po kontakcie z supportem OVH. Dwukrotnym.

Hosting

Jeśli chodzi o Ampere A1, to ostatecznie odpuściłem instalację Debiana, którego Oracle nie dostarcza i użyłem gotowca w postaci Ubuntu. Przynajmniej na podstawce AKA hypervisorze, bo sam blog stoi już w kontenerze LXC z Debianem. Za wiele się tam nie dzieje, ale – po krótkim obcowaniu – maszynka wygląda na wydajną i generalnie śmiga.

Cloudflare

Przepięcie domeny na Cloudflare – szybkie, łatwe i przyjemne. Podpowiadają co mają podpowiadać, autouzupełnianie działa. Panel przejrzysty, ustawienia domyślne sensowne. Opcji w wersji darmowej niewiele, ale wystarczają.

Oczywiście jest tricky part związana z certyfikatami SSL czy ustawieniami DNS, jeśli chce się mieć coś dostępne bezpośrednio, ale da się. No i wypada zablokować ruch HTTP(S) do serwera spoza Cloudflare. Jest wiele sposobów, wybrałem prawdopodobnie najprostszy i najgorszy, czyli iptables z wyjątkami na klasy adresowe Cloudflare na maszynie. Może kiedyś zmienię.

WordPress

Stawianie WordPressa także okazało się pewnym wyzwaniem. Może nie tyle samo postawienie, co doprowadzenie do działania. W każdym jakby ktoś wybrał wariant z ruchem nieszyfrowanym między blogiem a Cloudflare, czyli teoretycznie najprostszą opcję, to może się naciąć. W praktyce chyba prościej uruchomić to jako szyfrowane, z certyfikatem self signed. Nie obyło się bez grzebania w wp-config.php. Poza tym, raczej było prosto. Najwięcej czasu zeszło na wybór grafiki i ręczną instalację i konfigurację wszystkich wtyczek do WordPressa, których używam.

ChatGPT

No i na koniec część związana z AI. Jak łatwo można się domyślić, bawiłem się chatGPT przy porannej kawie i wtedy powstał pomysł na bloga generowanego przy pomocy AI. No właśnie nie przez AI, a przy pomocy. Co to znaczy? Ano to, że może się zdarzyć, że ingeruję w odpowiedzi zwrócone przez chatGPT. Łączę je, przycinam, albo dodaję coś od siebie. Ale nie jest to regułą i zwykle po prostu przeklejam wprost. Bez korekty, sprawdzania faktów itd. Błędy się zdarzają, o czym można przeczytać choćby w komentarzach do tego wpisu. Poza tym, nie podaję prompta i sam, ręcznie wybieram tytuł. Ot, powiedzmy taki asystent leniwego copywrightera w postaci AI. Co do zasady muszę zmieścić się z utworzeniem wpisu od początku do końca przy paru łykach porannej kawy.

Projekt nie jest skończony. Marzy mi się dorzucanie powiązanych obrazków do każdego wpisu. Najchętniej automatyczne. Brakuje detali typu favicona czy optymalizacja szybkości. Choć ten w zasadzie goły WordPress za Cloudflare działa wg GTmetrix podobnie szybko, co ten blog. Nad wyświetlaniem reklam nadal pracuję – chwilę to trwa już po stronie Google No i oczywiście wpisów na razie jest mało, a chciałbym dodawać około dwóch tygodniowo, przynajmniej przez najbliższych parę miesięcy.

DeepL

UPDATE: Do gromady dołączył jeszcze DeepL, a dokładnie Write. Coraz częściej zdarza mi się dodać coś od siebie, poza tym ChatGPT pisze dość sucho i encyklopedycznie. Nie używam domyślnie, raczej sporadycznie póki co. I uwzględniam tylko niektóre sugestie, ale warto wspomnieć i o tym narzędziu.