Owszem, formularz się nie pokazywał, ale api POST /auth/signup było cały czas dostępne.

Na szczęście wersja 0.17.0 już to poprawia.

Swoją drogą... trochę żenujący błąd.

Tak czy inaczej, zrobiłem aktualizację.

@ark_r

https://copy.fail/

Z przykrych rzeczy – spodziewałem się, że Debian będzie miał jakiegoś patcha do kernela. A tu nic. Trzeba sobie zablokować podatny moduł:

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf

Za to Ubuntu dostarczył aktualizację.

Swoją drogą – ciekawe, czy to odkrycie w kernelu to efekt AI.

EDIT Zwracam honor Debianowi – kilka godzin później poprawka do kernela się pojawiła.

@ark_r

Mój pecet nie ma obsługi ReBAR, co znaczy, że CPU miał okno komunikacji z VRAM ograniczone do 256MB.

Okazuje się jednak, że kernel 6.17 potrafi zignorować braki informacji z UEFI i samodzielnie odgadnąć potrzebę przemapowania zasobów na PCI. dmesg pokazuje serię powtarzających się komunikatów o alokacji zasobów PCI poprzetykana wpisami typu

[    0.356844] PCI: No. 4 try to assign unassigned res

I czwarta próba zakończyła się powodzeniem.

LM Studio bez problemu obsłużyło model gtp-oss:20b.

Dodatkowo libva zaczęło funkcjonować poprawnie i w końcu mam sprzętowe dekodowanie video av1.

Jak się okazuje, Linux naprawdę pozwala przywrócić do użycia stare pecety.

#linux

@ark_r

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

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

@ark_r

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

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

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

Kiedyś

Kiedyś było tak: poza filesystemem XFS, informacje o użyciu dysku i inodach był zapisywany w aplikach quota.user i quota.group. Potem coś poprawiono i nowe pliki nazywają się aquota.user i aquota.group.

Żeby limitowanie działało, dysk należy zamontować z opcjami usrquota i grpquota. Kolejna nowość wprowadziła usprawnienie dotyczące sposobu rejestrowania aktualnego użycia dysku dla użytkownika. Opcje montowania zmieniły się na usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv1 i dzięki temu pliki ze zużyciem dysku aktualizowane razem ze zmianami w plikach i przechodzą przez journal.

Potem trzeba uruchomić

sudo quotacheck -cugv /mnt/   

i po

sudo quotaon -ug /mnt

możliwość limitowania dysku jest włączona.

Ale quotacheck wypisało mi komunikat:

quotacheck: Your kernel probably supports ext4 quota feature but you are using external quota files. Please switch your filesystem to use ext4 quota feature as external quota files on ext4 are deprecated.

I tak dowiedziałem się, że ext4 wspiera pliki limitów jako ukryte inody, tylko trzeba tę opcję włączyć.

A tak to wygląda teraz

Zatem, jak to wygląda w na nowym jądrze.

Założenia: mam dysk... np. /dev/loop30, montuję go na /mnt.

Kernel został zbudowany z opcjami * CONFIGQUOTA=y * CONFIGQUOTA_TREE=m

Mamy narzędzia do obsługi limitów (np. apt install quota na Ubuntu)

Mamy niezbędne moduły kernela (sudo modprobe quota_v2 działa).

Procedura jest następująca:

Tworzę filesystem (ext4):

sudo mkfs.ext4 /dev/loop30

Włączam wewnętrzną obsługę limitów (to jest ta najnowsza nowość)

sudo tune2fs -O quota /dev/loop30

Feature quota oznacza: “Enable internal file system quota inodes”

A teraz jeszcze jedno: można mieć nie tylko limity per user i per grupa ale również limit per projekt. Nie mam pojęcia jak działa to ostatnie, ale można je wszystkie niezależnie włączać i wyłączać (patrz man tune2fs):

sudo tune2fs -Q usrquota,grpquota,prjquota /dev/loop30

Można sprawdzić, że limity zostały włączone wywołując:

sudo tune2fs -l /dev/loop30 | grep "Filesystem features"

Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize quota metadata_csum project

Obecność słowa “quota” oznacza, że feature jest włączony.

Kolejny krok: montowanie filesystemu:

sudo mount -o usrquota,grpquota,prjquota /dev/loop30 /mnt

Pewnie dobrze jest sobie ten mountpoint wpisać do /etc/fstab, ale chodzi po prostu o to, żeby włączyć dla tego dysku odpowiednie zliczanie limitów.

Żadnych plików limitów w /mnt nie widać, ale możemy uruchomić

sudo repquota /mnt

I zobaczymy zużycie tego dysku przez użytkownika root (bo tylko jego obiekty są na razie w tym katalogu). Przy okazji, repquota z parametrem -g pokaże limity dla grup, a -P limity dla projektów (jak ustalę jak zrobić taki projekt, to na pewno to opiszę).

Limity można ustawić poleceniami setquota i edquota (ale to już standard – każdy manual opisuje jak to zrobić).

Wygląda na to, że jeśli użyliśmy podczas montowania opcji usrquota, grpquta etc, to limity są od razu egzekwowane (bez konieczności włączania ich za pomocą quotaon), co można sprawdzić używając opcji -p:

sudo quotaon -p /mnt
Limity grupy na /mnt (/dev/loop30) są włączone
Limity użytkownika na /mnt (/dev/loop30) są włączone
Limity project na /mnt (/dev/loop30) są włączone

I działa.

Linki:

• (trochę stare już) https://wiki.archlinux.org/title/disk_quota
• (trochę nowsze) https://www.digitalocean.com/community/tutorials/how-to-set-filesystem-quotas-on-ubuntu-20-04
• (magiczny feature, o którym tak niewiele) https://ext4.wiki.kernel.org/index.php/Quota

#linux #quota #administration

@ark_r

Załóżmy, że mam jakieś repozytorium git:

$ git log --oneline
63594c0 (HEAD -> master) Initial

W przykładzie jest tylko jeden commit, ale to nie istotne.

Zaczynam więc standardowo:

$ git switch -c feature-1
$ nano README.md       # Tu wpisuję treść mojego README
$ git add README.md
$ git commit -m "Dodano README.md"

W wyniku tych działań mam coś takiego:

$ git log --oneline 
87aeca8 (HEAD -> feature-1) Dodano README.md
63594c0 (master) Initial

Powiedzmy, że jednak odkrywam, że w README zrobiłem paskudny błąd ortograficzny:

$ nano README.md     # poprawiam wstydliwy błąd
$ git add README.md
$ git commit --amend

Ponowne sprawdzenie logu:

$ git log --oneline 
6f3d411 (HEAD -> feature-1) Dodano README.md
63594c0 (master) Initial

Jak widać ostatni commit został przepisany (87aeca8 został zastąpiony przez 6f3d411). Efekt w postaci poprawionego błędu i czystej historii commitów został osiągnięty.

To jest ten prostszy przypadek ale co, jeśli błąd w README.md uświadomię sobie dopiero po jakimś czasie, gdy już zdążyłem dodać inne commity. Np mam taką historię:

$ git log --oneline 
6e8a8dd (HEAD -> feature-1) Dodano main.c
6f3d411 Dodano README.md
63594c0 (master) Initial

I dopiero teraz stwierdzam konieczność poprawienia pliku README.md. Opcja --amend już nie zadziała i trzeba skorzystać z dobrodziejstw git rebase -i. “Rebase” pozwoli ponownie przeedytować istniejące commity, choć każdy kto to robił wie, że będzie trochę zabawy. I tu wracam do wspomnianej opcji --fixup operacji commit.

Mogę zrobić następującą rzecz:

$ nano README.md     # poprawiam (kolejny pewnie) błąd ortograficzny
$ git add README.md
$ git commit --fixup=6f3d411   # wskazuję poprawiany commit

Poprawiany commit, to ten z opisem “Dodano README.md”. Polecenie nie pyta mnie nawet o komentarz i mam następującą historię:

$ git log --oneline 
9fadf75 (HEAD -> feature-1) fixup! Dodano README.md
6e8a8dd Dodano main.c
6f3d411 Dodano README.md
63594c0 (master) Initial

I teraz ta fajna część:

$ git rebase -i --autosquash master

Otwiera się edytor umożliwiający ustawienie poleceń odnośnie commitów następujących po master (commity pojawiają się od najstarszego do najnowszego):

pick 6f3d411 Dodano README.md
fixup 9fadf75 fixup! Dodano README.md
pick 6e8a8dd Dodano main.c

Widać, że “fixup! Dodano README.md” zostało umieszczone zaraz po “Dodano README.md” i ma automatycznie (dzięki opcji --autosquash) wybrane polecenie fixup. Po zamknięciu edytora powstaje taka oto historia commitów:

$ git log --oneline 
8abcc8e (HEAD -> feature-1) Dodano main.c
3c9672d Dodano README.md
63594c0 (master) Initial

Commity powyżej “63594c0” zostały przepisane, w tym “Dodano README.md” zebrał zmiany, które dodałem w “fixup! Dodano README.md”.

Błędy poprawione, historia czysta. Można robić git merge.

@ark_r