Ostatnio zastosowałem prostą sztuczkę w standardowej inwokacji PyTesta w #Gentoo, by rzucało błąd, kiedy wykryje nieużywane funkcje async. Miało to na celu zwiększenie szansy zauważenia, jeśli w którejś paczce przypadkiem pominięto zależność od dev-python/pytest-asyncio (albo równoważnej wtyczki), albo przy wyłączonym automatycznym ładowaniu wtyczek, pominięto ładowanie takiej wtyczki.
Dziś otrzymałem pierwsze zgłoszenie, dotyczące paczki dev-python/ipython. Przeszukałem źródła, i potwierdziłem zależność — tyle, że z jakiegoś powodu przypiętą do wersji < 0.22. No cóż, nie mamy już takiej, ale warto sprawdzić, czy mimo to nie zadziała. Tak więc dodałem zależność, dodałem -p asyncio… a #PyTest dalej jej nie widzi. Podrapałem się po głowie, spróbowałem PYTEST_PLUGINS — dalej nie działa. Co do…?
Tak więc sklonowałem repozytorium git, spróbowałem ze starszą wersją wtyczki — testy działają. Zaktualizowałem do 0.23.6, przestały działać. Sprawdziłem historię, i okazało się, że starą wersję wymuszono ze względu na błąd w wydaniu 0.22.0. Tyle że ten błąd już poprawiono, wydanie usunięto, a mój problem był zupełnie inny.
Przyjrzałem się sprawie bliżej. Z jakiegoś powodu, w kodzie #IPython testy nie są bezpośrednio oznaczone markerem pytest.mark.asyncio. Zamiast tego, conftest.py automatycznie dodaje ten marker do wszystkich testów, będących współprogramami. Ze starszymi wersjami to działało, z nową przestało. Wygląda na to, że test zostaje poprawnie oznaczony, ale wówczas przestaje być rozpoznawany jako współprogram. Przygotowałem minimalny przykład i zgłosiłem problem.
Istotne w tej historii jest to: (potencjalny) problem nie został zauważony przez dłuższą chwilę, bo autorzy IPythona przedwcześnie wymusili starą wersję ze względu na chwilowy błąd, a następnie nie usunęli tego ograniczenia.
#gentoo both masked the 5.6 #xz release and additionally removed it from the repo, even though the backdoor as known so far would not get injected when running your own autofoo and also just targeted dpkg/rpm. Good.
Jak sobie to wyobrażałem: włączę #DistCC na cienkim lapku, zasypie stacjonarnego Ryzena kompilacjami, utrzymując 12 wątków z boostem na 100% obciążeniu, i skończy kompilować webkit-gtk w chwilę.
Jak wyszło w praktyce: 4 rdzenie laptopa są w 100% obciążone preprocesorem i nie wyrabiają z dostarczaniem zadań Ryzenowi, a ten je wykonuje tak szybko, że ledwie jest obciążony.
No cóż, przynajmniej preprocesor nie zużywa tak dużo pamięci jak pełna kompilacja, więc budowanie cały czas postępuje, zamiast zaciąć się na swapowaniu.
Wzdych. Pod wpływem pewnego wątku na pewnej liście mailingowej, mam potrzebę napisania jeszcze czegoś, pesymistycznie, w temacie xz/sshd.
Co nie nastąpi? Długotrwała poprawa finansowania i wsparcia twórców #OpenSource. I przez "twórców", mam na myśli prawdziwych ludzi, którzy muszą za coś kupić jedzenie i zapłacić rachunki, a nie "projekty".
Co już się dzieje? Szukanie winnych, rzucanie wspaniałych pomysłów i oczekiwań w stosunku do już wypalających się twórców.
Zdaje się, że już wszyscy i ich babcie używają exploitu w xz/sshd, by szerzyć swoją agendę, więc i ja nie będę gorszy.
#Autotools to zły system budowania. Skryptu configure są absolutnie nieczytelne, więc nikogo nie powinno dziwić, że nikt nie zauważył złośliwego kodu — wszak nie różni się niczym od całej reszty tego bełkotu.
Statyczna konsolidacja i włączanie zależności są złe. Wiecie, dlaczego tak szybko udało się rozwiązać problem z liblzma? Bo wystarczyło cofnąć systemową bibliotekę do wcześniejszej wersji. Nie trzeba było przeszukiwać, łatać i wydawać na nowo setek projektów. Z #RustLang i Cargo nie byłoby tak łatwo.
Możecie winić #OpenSource za bycie niedofinansowanym i tym samym otwartym na tego rodzaju nadużycia w kluczowych projektach. Ale tak naprawdę żaden projekt IT nie jest w stanie być odpornym na poczynania złoczyńców o dostatecznych zasobach, a że przydarzyło się to xz, to tylko przypadek. Korpoprojekty też nie są bezpieczne, a tym bardziej własnościowe oprogramowanie z zamkniętym kodem źródłowym.
Tak więc: doceńcie Mesona, doceńcie dynamiczne ładowanie bibliotek, doceńcie dostawę oprogramowania przez dystrybucje, i rzućcie grosza wie… chciałem powiedzieć, devom open source.
Visiting family away from home and this xz security issue cropped up. Thankfully I can #wireguard to my home to update my #gentoo machine from my phone.
Pewnie już to gdzieś widzieliście, ale: xz-utils w wydaniach 5.6.0 i 5.6.1 zawiera skomplikowany exploit, który wstawia backdoora w SSH. #Gentoo nie powinno być dotknięte, bo nasze OpenSSH nie używa liblzma — wygląda na to, że celowano w dystrybucje, które łatają OpenSSH, by korzystało z libsystemd, które z kolei może korzystać z liblzma. Jednakże nie ma pewności, czy exploit nie robi czegoś jeszcze, więc nowe wersje zostały zamaskowane.
Nie mogę wrzucić nowej Tuby, bo nie mamy jeszcze nowego GTK. Nie mogę wrzucić Fractala, bo nie mamy nowej Adwaity. Nie mogę wrzucić UV, bo nowy Rust czeka w kolejce do przeglądu.
A pamiętacie przycisk "turbo" w latach 90.? Ten, co przełączał stare procesory między dwoma ustawieniami zegara. Osobom nieobeznanym wyjaśniam, że nie służyło to oszczędzaniu energii, ani "podkręcaniu" procesora, lecz zachowaniu zgodności ze starszymi programami, które spodziewały się określonego zegara.
Pamiętajcie, że mówimy tu o czasach DOS-a, kiedy programy z reguły mogły przyjąć, że dostaną procesor na wyłączność. No i jak taka gra, synchronizowana zegarem procesora, dostała procesor dwa razy szybszy, to działała dwa razy szybciej. I nie chodzi o to, że płynniej — po prostu grało się w przyspieszeniu. Kilka razy szybszy procesor, i grać się nie dało. Dziś jeszcze widzimy ślady tego, chociażby w DOSBoksie.
Oczywiście, programy przestały być zależne od konkretnego zegara, i z czasem ten przycisk zaniknął. Za to rozwinęły się możliwości "podkręcania" procesorów, czy też ogólnego skalowania zegara (#CPUFreq), żeby oszczędzać energię i ograniczać hałas. No i w końcu pojawiło się #PStates, jako trochę bardziej zaawansowany sposób skalowania procesora.
Co ciekawe, jednym z parametrów PStates jest opcja "boost". Kiedy jest wyłączona, zegar procesora skalowany jest normalnie, do częstotliwości znamionowej. Natomiast po jej załączeniu, PStates może "podkręcać" poszczególne rdzenie powyżej tej częstotliwości, w ramach dostępnej mocy zasilania i możliwości odprowadzenia ciepła.
Tak właśnie historia zatoczyła koło i wrócił przycisk "turbo":
cd /sys/devices/system/cpu/cpufreq
if [ "$(cat policy0/boost)" = 0 ]; then
echo 1 > boost
else
echo 0 > boost
fi
「 Redcore Linux explores the idea of bringing the power of Gentoo Linux to the masses. Redcore is a distribution based on Gentoo's Testing branch which uses a hardened profile by default. It aims to be a very quick way to install a pure Gentoo Linux system without spending hours or days compiling from source code, and reading documentation 」
FYI if you're using OpenRC in a regular split /usr profile on #Gentoo (which is basically the default) be wary that the binary package for OpenRC itself assumes a merged /usr for the 23.0 profile. This will cause a migration from the 17.1 profile to break the boot process unless you use the source package (which works as expected).
"""
Szczerze mówiąc, uważam, że największym problemem jest to, że dystrybucja oprogramowania w Pythonie jest nieskończenie skomplikowana i nieintuicyjna, co oznacza, że każda osoba, która chce się tym zająć z którejkolwiek strony, ku swojemu zaskoczeniu odkryje bardzo wysoki próg wejścia. #Gentoo#Python Guide ma już 300 KiB plików .rst, i w żaden sposób nie jest kompletne. W tej chwili, przeciętny dev nie jest w stanie wrzucić czegokolwiek napisanego w Pythonie do dystrybucji, nie przechodząc wcześniej specjalnego szkolenia i/lub otrzymując przeglądu kodu od kogoś bardziej doświadczonego, a i owi seniorzy mają sporą trudność w nadążaniu za ciągłymi zmianami.
Jednocześnie, framework Pythona w Gentoo ma już sporo zabezpieczeń, które wykrywają najczęstsze błędy. To jednak też nie jest w żaden sposób kompletne, i dokładam kolejne, ilekroć odkrywamy kolejną nieintuicyjną pułapkę. Z tego wątku odnoszę wrażenie, że będziemy musieli dodać kolejne zabezpieczenie, które będzie upewniać się, że kiedy pyproject.toml jest modyfikowany, zajęto się również PKG-INFO.
"""
Używanie --load-average w MAKEOPTS przynosi ciekawe spostrzeżenia.
Niektóre systemy budowania (jak make i ninja) obsługują tę opcję, ale zawsze uruchamiają przynajmniej jeden proces. Przez większość czasu utrzymuje to pełną saturację wątków procesora, jednocześnie zapobiegając uruchomieniu zbyt wielu równoległych procesów, kiedy wiele paczek buduje się równocześnie. Czasem, kiedy buduje się tylko jedna paczka, zdarza się, że przez chwilę procesor nie jest optymalnie wykorzystany, wskutek chwilowego skoku obciążenia, ale to nie jest wielki problem.
Niektóre narzędzia (jak pytest) w ogóle nie obsługują --load-average. Zawsze uruchamiają pełną możliwą liczbę procesów. Skutkiem tego jest to, że narzędzia, które obsługują tę opcję, cały czas obserwują wysokie obciążenie i uruchamiają tylko jeden proces. Okazuje się to względnie wygodne, kiedy testuję nowe wersje paczek Pythona, bo testy uruchamiają się szybciej, nie będąc spowalnianymi przez inne budowane paczki.
Niektóre narzędzia (jak CTest z CMake) nie uruchamiają żadnych procesów, jeżeli wskazane obciążenie jest przekroczone. Może to być całkiem mylące — w pierwszej chwili odniosłem wrażenie, że testy się zawiesiły. Co więcej, przy wysokim obciążeniu systemu może okazać się, że testy nigdy się nie uruchomią.
No więc dostałem jakiś #spam z ofertą pracy od rekruterów firmy #Samsung, na projekt, na który definitywnie nie mam umiejętności. A potem jeszcze dwa identyczne maile.
Pierwsza myśl? Spamują przypadkowe aliasy #Gentoo, więc załapałem się na kilka kopii.
Ale nieee. Ta sama osoba wysłała trzy identyczne maile. Drugi 2 godziny po pierwszym, a trzeci — minutę później. Wygląda to bardzo profesjonalnie.
Może powinienem odpowiedzieć i poprosić o trzy odrębne oferty pracy.
I've been posting my #Gentoo generic custom kernel for a few years now because there weren't any readily available. I've always based it on the #Fedora kernel with a few modifications.
I didn't realize it immediately but now that Gentoo has a distribution kernel, the configuration is also based on the Fedora one. I guess when things work there's no point in doing things differently.