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.
Today we have a fun one we have Luna from the Xenia Linux project on the show, immutable #Gentoo, a project that started as a meme because of the other #Linux mascot
#Logo I created some time ago, for @xgqt for some #Gentoo project, made with #krita.
Actually it wasn't created as vector art in most part, even if finally converted.