arek o sofcie

Różności na temat tworzenia oprogramowania

Kupiłem sobie kartę Arc Pro B50, żeby zastąpić starą kartę 1070 NVidii. Na razie chyba trzeba powiedzieć sobie, że w przypadku Linuxa jest trochę za wcześnie na ten sprzęt.

Problemy

Kartę wziąłem, bo ma 16GB VRAM, była tania i pobiera tylko 70W. Wydawało się OK na mój stary Dell Inc. XPS 8930.

Ale: * Przydałaby się obsługa ReBAR, żeby CPU miał większe okno dostępu pamięci karty – mam tylko 256MB, a mogłoby być 16GB, * Wygląda na to, że zderzenie PCIe 3.0 płyty z kartą PCIe 5.0 skończyło się tym, że komunikacja jest na jednej linii – LnkSta: Speed 2.5GT/s, Width x1. Trochę słabo.

Kolejny problem: libva nie działa. Ściągnąłem najnowsze biblioteki Intela z PPA, ale nawet uruchomienie vainfo kończy się crash-em. Żegnaj akceleracjo sprzętowa :)

Ciekawa sytuacja z chrome pod wayland: gdy Gnome wygasi ekran, desktop wywala się podczas ponownego włączania ekranu.

W przeglądarce widać pewne artefakty graficzne przy niektórych animacjach.

Wygląda na to, że sterownik xe w wersji 6.14.0-37-generic kernela nie jest jeszcze dopracowany.

Pozytywy

Akceleracja 3D (OpenGL, Vulkan, WebGL, WebGPU) działa. Wydajność jest całkiem przyjemna.

Dało się odpalić ollama w trybie OLLAMA_VULKAN=1. Wydajność nie jest powalająca, mimo że model w całości jest obsługiwany przez GPU. Może będzie się to poprawiać.

Pewnie i tak będę zmieniał komputer (jak ceny RAMu spadną :) ) i zobaczymy co będzie dalej.

Na Windows karta działa całkiem OK, mimo starej płyty głównej. Nawet Cyberpunka z Light Tracing odpaliłem.

Nie lubię zakupów sprzętu.

@ark_r

W teorii zrobiłem już wszystko i tag powinien działać.

Może to trochę spam, ale inaczej tego nie sprawdzę.

@ark_r

Tak, pewna niespodzianka, ale blog wiąż żyje. Chociaż nie mam czasu, żeby coś pisać.

Ale zrobiłem aktualizację i piszę posta, żeby sprawdzić, czy faktycznie nowe funkcje zadziałają.

Na pewno działają “lajki” – tj. gdy ktoś da fava np. na mastodonie, to widać to w artykule.

A teraz jeszcze kwestia taga fediverse:creator.

Ale to muszę dopiero ogarnąć. Może zadziała, a może nie.

Edit... no jakoś “creatora” nie ma.

#writefreely

@ark_r

Przy którejś aktualizacji kernela (gdzieś między 5.19, a 6.1) mój pecet nabył ciekawego problemu: wyłączanie kończyło się jak lata temu na windows, gdzie użytkownika żegnał napis “Teraz możesz wyłączyć komputer”.

Cała procedura shutdown-u przechodziła, ale na samym końcu, gdy kernel wywołuje acpi_poweroff, proces się zawieszał i musiałem wyłączać zasilanie przytrzymując kilka sekund przycisk na obudowie.

Przy okazji – usypianie (sleep/suspend) również przestało działać, ale tego akurat nie używałem zbyt często, więc przeszkadzało mi znacznie mniej.

Historia poszukiwania rozwiązania jest nudna jak flaki z olejem (ale sporo ciekawych rzeczy o ACPI można się dowiedzieć), więc od razu przejdę do rozwiązania (a przynajmniej czegoś, co u mnie to zadziałało).

Zgodnie z https://www.kernel.org/doc/Documentation/Intel-IOMMU.txt mój oparty na CPU Intela pecet może obsługiwać IOMMU dzięki stosownemu modułowi i zdaje się, że właśnie w kernelu 6.x dostarczanemu z Ubuntu ta funkcjonalność została włączona.

Pecet ma zintegrowaną grafikę Intela (której nie używam) i dodatkowo kartę NVIDIA. I chyba coś z tą nieużywaną grafiką Intela szwankowało.

We wskazanym dokumencie można przeczytać:

Graphics Problems?
------------------
If you encounter issues with graphics devices, you can try adding
option intel_iommu=igfx_off to turn off the integrated graphics engine.
If this fixes anything, please ensure you file a bug reporting the problem.

I właśnie owo intel_iommu=igfx_off rozwiązuje problem. Wartość off również, ale podobno iommu poprawia bezpieczeństwo (i przydaje się, gdy się uruchamia maszyny wirtualne).

W każdym razie – zadziałało. Po dodaniu do parametrów kernela w grub problem ustąpił i shutdown -P wyłącza zasilanie.

#linux #poweroff #iommu

@ark_r

Blog działa na komputerku z procesorem w architekturze ARM64, a writefreely ostatnio nie publikował buildów dla architektury innej niż ADM64.

Na szczęście ich problemy się rozwiązały i mogłem zrobić aktualizację.

Z większych zmian... z tego co widzę, to można już bez sztuczek obsłużyć weryfikację identyfikatora mastodon (rel="me), co niniejszym uczyniłem.

Aktualizacja sprowadza się do rozpakowania archiwum i wykonania

./writefreely db migrate

Do ogarnięcia :)

@ark_r

Z jakiś powodów zapragnąłem ustawić w Linuksie limity na użycie dysku. Pominę opis poszukiwania informacji w Internecie, ale w skrócie – z nieznanych mi powodów w zdecydowanej przewadze opisywane są jakieś starocie. W artykule pokrótce jak to wygląda w aktualnych wersjach jądra.

Czytaj dalej...

Czasami zdarza się, że zatwierdziłem jakieś zmiany, ale coś tam jednak wymaga poprawy. Pewnie skorzystam z git rebase -i, tym niemniej po takich poprawkach uporządkowanie commitów wymaga trochę pracy i tu z pomocą przychodzi opcja --fixup.

Czytaj dalej...

Albo “o co chodzi benchmarkach”.

Istnieje sobie portal benchmarksgame-team.pages.debian.net, który na przykładzie kilku algorytmów pozwala porównać wydajność wydajność implementacji w różnych językach.

W swojej historii pisałem w wielu różnych językach i niejednokrotnie mam możliwość wybrania języka dla realizowanego projektu. Takie porównania są więc interesujące, bo w sytuacji, gdy gdzieś kluczowa jest wydajność, dobrze jest wiedzieć, czy wybrałem właściwe narzędzie albo jak bardzo mój wybór jest nieoptymalny.

Z różnych powodów interesuje mnie porównanie wydajności języków Java i Go. Wchodząc pod ten adres https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go.html można się przekonać, że Go jest ogólnie porównywalny z Javą albo nawet szybszy, poza jednym przypadkiem: Binary trees!

Wydajność benchmarku binary-trees dla implementacji w Java i Go

Przypadki, gdy coś jest 10% szybsze albo wolniejsze, coś oczywiście mówią, ale w realnych programach najprawdopodobniej takie zyski rozmyją się w natłoku innych, niezbędnych i nieuniknionych elementów programu. W praktyce oprogramowanie, które piszę, co chwila coś wysyła po sieci, albo czeka na rezultaty z sieci i sekunda więcej na obliczeniach (choć ważna) nie boli tak bardzo. Zawsze można dodać CPU lub kolejną maszynę wirtualną i ogólna wydajność systemu spełni wymagania.

Ale w tym wypadku jest dramat: implementacja w Go jest 5,6 razy wolniejsza.

Czytaj dalej...

Tym razem coś o kwestii obsługi znaków i stringów. Na początek zagadka: co wypisze ten program?

RegExp

Czytaj dalej...

Prawdopodobnie każdy zainteresowany jakkolwiek tematami IT słyszał już o czymś takim jak kontenery i od razu wie, że chodzi o takie rzeczy jak docker albo kubernetes. Wiadomo, że są obrazy w repozytoriach i można je łatwo pobierać i instalować.

Kontenery przedstawiane są jako lekkie maszyny wirtualne. Taka wirtualka, która nie marnuje RAM-u na utrzymywanie całego systemu operacyjnego gościa – kilka takich “wirtualek” (kontenerów) współdzieli system operacyjny, ale zapewnia separację dla uruchamianych wewnątrz procesów.

Oprogramowanie takie jak docker (zwłaszcza z jego modułem swarm) oraz kubernetes, to całkiem spore kombajny robiące mnóstwo rzeczy, których zakres funkcjonalności przekracza znacznie sam temat uruchamiania kontenera. Do tego obrosły jeszcze w cała gamę narzędzi, które wspierają administratora (lub developera) w procesach wdrażania, monitorowania i zarządzania usługami. Powstały również rozwiązania dla systemów innych niż Linux, np. Docker Desktop dla Windows, czy też jego odpowiednik dla urządzeń Apple'a.

Internet pełen jest artykułów, poradników, prezentacji etc. opisujących zalety konteneryzacji i ogólnie są to bardzo przydatne materiały, ale przy okazji każdej technologii dobrze jest (czasem) wiedzieć czym ona naprawdę jest i jak działa. Taka wiedza przydaje się zwłaszcza, gdy coś przestanie działać i żaden “wizard” i “kreator” nie wiedzieć czemu akurat nie potrafi pomóc.

Czym zatem jest naprawdę kontener i co dzieje się pod tymi wszystkimi warstwami skądinąd bardzo przydatnych narzędzi?

Czytaj dalej...