Sesja Linuksowa, połowa

Wahałem się czy wybrać się na Sesję Linuksową. Bo to jednak wyprawa do innego miasta. Skoro jednak jest w weekend, a pociągi IC jeżdżą teraz szybciej, to dwa razy godzina z groszem na dojazd wydała się akceptowalna w stosunku do kilku godzin na miejscu. Stwierdziłem, że wariant przyjazd w sobotę rano, wyjazd wieczorem jest wykonalny, a tytuły wykładów[1] brzmią do posłuchania.

Wyjazd z Poznania o 7:30, przyjazd przed 9:00. Teoretycznie kwadrans tramwajem i jestem na miejscu, planowy start wykładów jest o 9:05, czasem jest poślizg, więc prawie powinienem zdążyć… Co może pójść źle? Wiele rzeczy… Ale udało się i zdążyłem na wykład o SSH niemal w całości. Myślałem, że temat nie będzie mnie w stanie specjalnie zaskoczyć, tymczasem sporo ciekawych zastosowań i możliwości. I to już na pierwszym wykładzie. A teraz kilka słów o wybranych[2] wykładach.

Dziwnostki rozwoju kernela – ciekawe, trochę znałem, trochę nie. Fajnie pokazuje, jak jednak[3] duże rzeczy działają, choć działają… dziwnie. Bo przysyłanie patchy mailem, zamiast pull requstów w systemie kontroli wersji, wygląda na spore utrudnienie.

Ciekawy wykład o Velvet OS, czyli instalacji Linuksa (Debiana) na chromebookach i nie tylko. Fajnie, że takie rzeczy się dzieją. Choć sam na chromebooku korzystam z ChromeOS. Zaskoczyło mnie, ile jest różnic, ograniczeń i problemów.

Wykład Ile tritów ma trajt – dość luźny, ale ciekawy, sporo historii komputerów – przypomniał mi niedawną dyskusję o tym, jak reprezentacja binarna wpływa na pojmowanie świata. I okazuje się – o czym nie wiedziałem – że może logika trójwartościowa być może wróci, bo jest przyjazna sieciom neuronowym i LLMom.

Ukryte koszty wolności – bardzo ciekawy, nietechniczny wykład o modelach rozwoju open source, problemach z finansowaniem i tym, że kiedyś były czasy… A teraz to fundacje, federacje, rządzą nimi korporacje. Celnie, choć pesymistycznie.

Tyle połowy. I połowy SL, i połowy opisu, bo na drugi dzień Sesji Linuksowej się nie wybieram w tym roku[4]. Ale Wy możecie, wg mnie warto, więc szybko ten wpis, może ktoś się zdecyduje, a druga część… wkrótce.

A gdyby ktoś nie chciał jechać lub miał daleko, to jest streaming live. O którym nie wiedziałem, ale nie żałuję wycieczki. Tym bardziej, że osobiście nie przepadam za słuchaniem streamingów.

C.D.N.

[1] Były też warsztaty, ale zupełnie nie miałem na nie weny. To jednak w założeniu miał być relaks i miłe spędzenie czasu, bez większego wysiłku intelektualnego.
[2] Nie najlepszych, nie najciekawszych, wybranych. Wszystkie inne też prowadzone przynajmniej dobrze i ciekawe.
[3] A może właśnie dlatego?
[4] Niestety; wyłącznie logistyka i plany, nie jakość konferencji.

HumanRank

Dziś przeczytałem wpis o human.json i stwierdziłem, że temat jest godny pełnowymiarowego wpisu. Nie dlatego, że jest ciekawy, ale dlatego, jak bardzo nieprzemyślany i słabo wykonany jest to pomysł. Uprzedzam, że będzie stronniczo i trochę mi się uleje.

W skrócie, LLMosceptycy wpadli na pomysł, żeby ludzie zaczęli dodawać plik JSON, w którym będą wskazywać URLe do innych treści (stron) tworzonych przez ludzi. Do tego dodatek do przeglądarki, który pokaże ilu ludzi wskazało odwiedzaną stronę na tworzoną przez człowieka i jaka jest odległość (ilu pośredników) względem naszej strony.

Czyli – cytując wytłuszczenia ze strony projektu – autor strony deklaruje się jako człowiek i umieszcza plik. Następnie poręcza za inne strony. I rozszerza scope poręczeń.

Jeśli komuś się z czymś to kojarzy, to – jeśli jeszcze nie zorientował się na podstawie tytułu wpisu – jest to w założeniu bardzo podobne do PageRank stworzonego przez Google. Może i Google stwierdziło, że to nie działa dobrze, jest podatne na manipulacje SEO i wycofało się z projektu, ale tym razem się uda. OK, jest różnica, bo aktualnie human.json nie uwzględnia wag. Ale to wczesna wersja, więc możliwe, że wszystko przed nami.

Wersja Google była o tyle lepsza/prostsza, że nie wymagała osobnego pliku i używała po prostu linków ze strony. Ale to nic, wiadomo, że wszyscy ludzie są techniczni, tu sobie nagłówek dopiszą, tam plik wygenerują. Na ironię zakłada wybór formatu JSON, który jest pomyślany jako przetwarzalny przez automaty i niezbyt przyjazny ludziom.

Dalsze wady pomysłu? Ależ proszę bardzo. Rozwiązanie jest podatne na manipulację. Nie ma żadnego problemu, żeby kupić kilka(-naście, -set) stron, umieścić na nich human.json, który będzie linkować do pozostałych. Zapewne będą miały wyższą ilość potwierdzeń, niż wiele stron tworzonych przez ludzi.

Kolejny problem to założenie, że wszyscy pieczołowicie będą utrzymywać swoje pliki. O ile z dodaniem pliku nie ma większego problemu, to z czasem domeny wygasają, zmieniają właścicieli. Po kilku latach może być na nich zupełnie inna treść. Znam to doskonale i z linków na blogu, i z czytnika RSS. W przypadku PageRank był jeden opiekun, który dbał o jakość wskaźnika.

Czy to koniec problemów? Na pewno nie. Na pewno znajdą się chętni do „wymiany linków” tj. wzajemnego potwierdzenia swojego człowieczeństwa. Pamiętacie sprzedaż linków? Gdyby pomysł jakimś cudem się przyjął (w co nie wierzę) to handel linkami powróci w wielkim stylu. Tym razem linkami w human.json.

Czym więc jest human.json, albo jakie widzę jego niezamierzone skutki? Przede wszystkim jest deklaracją nie lubię LLM. Do tego oczywiście każdy ma prawo. Ale czy człowiek musi polegać na automatycznym, algorytmicznym wskaźniku z przeglądarki, żeby ocenić czy treść jest wartościowa? Wydaje mi się to dziwne.

Ostatni niezamierzony skutek, który widzę, to tworzenie kolejnego bąbelka. Bo czy strony ludzi, z których poglądami się nie zgadzamy, trafią do human.json równie często, jak tych, z którymi się zgadzamy? Szczerze w to wątpię.

Strzeż się Tahoe

Apple jest nachalne do niemożliwości. Nie gonię za najnowszymi wersjami macOS, raczej jestem oczko z tyłu. Tak naprawdę jeśli chodzi o funkcjonalności, to rzadko widzę różnicę, a mój support techniczny zwykle ostrzega przed problemami i raczej zaleca poczekać z aktualizacją. W takiej sytuacji nie ma się co spieszyć. W końcu nawet Sonoma jest jeszcze normalnie wspierana.

Tymczasem korzystam z wersji Sequoia. O aktualizacji nie pisałem, bo nudna i niczego nie wniosła wg mnie. Z godnych pamięci szczegółów – długie pobieranie (jakieś 2h na 100 Mbps), za to krótki downtime – obrócił poniżej 30 minut ze wszystkim.

Chciałbym nadal korzystać z Sequoia, ale Apple uparło się, że wciśnie mi Tahoe. Nie drzwiami, to oknem. Po pierwsze, popup, że jest nowa wersja. Co mogę wybrać? Albo aktualizację do Tahoe w nocy, albo że przypomni później[1]. Opcji sam zadecyduję, kiedy zechcę zaktualizować, nie przypominaj więcej nie ma. Liczą na missclick?

Daleko idący wniosek z tym missclickiem? No nie wiem, bo jak wejdę w Software Update to mam u góry aktualizację do Tahoe, a poniżej inne aktualizacje (Also available), które wyglądają tak:

Zrzut ekranu pokazujący Also Available, a tam dwukrotnie "Command Line Tools for Xcode and 1 more..."

Bezpiecznie? No nie wiem, bo kliknięcie znaczka z informacją pokazuje:

Zrzut ekranu, widoczne macOS Tahoe, Command Line Tools for Xcode oraz Safari.

Znaczy znowu wciskają Tahoe. Zapewne można odznaczyć, ale jeśli jesteście przywiązani do Sequoi i chcecie uniknąć aktualizacji do Tahoe, bądźcie czujni.

Oczywiście nie jest to nic nowego, Microsoft robił podobnie wymuszając przejście z Windows 7 na 10.

Dla jasności, co do zasady uważam, że przypominanie o aktualizacjach jest dobre, aktualizacje automatyczne też. Ale niekoniecznie podoba mi się takie nachalne wciskanie nowej wersji systemu. Szczególnie, gdy stary jest wspieramy. To jednak grubsza i potencjalnie inwazyjna zmiana.

[1] Nie jest określane, kiedy nastąpi później. W zasadzie mogłoby wyskakiwać co godzinę.