Blogbejegyzések

Csökkentett mód ON

Inaktivitás detektálás, avagy mikortól nincs szükség egy erőforrásra?

Ha automatizáltok felhős erőforrásokat és megnövekedett igény esetén bekapcsoljátok, akkor azt is le kell programoznotok, hogy mikor kapcsoljátok le, ha vissza csökken az igény.

Nem triviális a kérdés. Az optimum keresés szükségességét az adja, hogy tudjuk, van egy még nem jó, és egy már nem jó határ. De vajon hol van közte a jobb döntés? Tudjuk-e közelíteni? Érdemes-e?

Regisztált fiókok

HUP web:                       18 833

HUP Twitter:                    1 358

HUP Facebook:                 1 517

HUP Reddit:                          65

HUP Hírlevél:                      405

HUP Feedburner:                189

Dolgok. Egy kis stop, és újratervezés.

Aki érti érti, aki nem az ne is értse, annyira nem vész.

Az év elején mindig van egy orvosi kivizsgálás, mánáger szűrés, mert hát ha az ember annyit idegeskedik egy hét alatt, mint más egész évben, akkor ugye ... . Szóval ennek az eredménye az lett, hogy meglátogathattam egy neves orvosi műintézményt, ami nem éppen a nagy zöld kocka utcában van.... . Tényleg nem akarom konkrétan leírni.

ASUS Xonar SE 5.1 PCIe gaming sound card with 192kHz/24-bit hi-res audio and 116dB SNR

Mivel az alaplapi erősítő kimenet 3,5" Jack aljzata már nem működött megbízhatóan az Asrock B450M Pro4-en lapon, ezért raktam bele egy ASUS hangkártyát is. Szebben szól, mint az alaplapi. :)
80%-ban Debian 11 kompatibilis.: "While the rear connectors seems to work the front header is not.". Számítottam ilyen "ASUS problémára" egy ASUS Notebook után.
Workaroundként használom az alaplapi hangkarit is aminek ez a része eddig is jól működött.
 

Hosszan futó tar processz monitorozása (pv/pipe nélkül)

A klasszikus módszer szerint átkergethetjük az adatfolyamot egy (vagy több) pv-n, és akár párhuzamosan nézhetjük a progressbarokat.

Viszont lehet olyan eset, amikor nem szeretnénk pipe-okat használni (pl. bufferelési vagy blokkméret beállítások miatt), ilyenkor egyszerűen küldhetünk a tar processznek egy SIGUSR1 szignált, akár rendszeresen, mondjuk percenként, crontab-ban időzítve:

* * * * * root pkill -SIGUSR1 tar

A tar-t pedig megkérjük arra, hogy legyen kedves ezeket a SIGUSR1-eket menet közben elkapni, és rá mindig olyan módon reagálni, hogy kiírja a pillanatnyi statisztikáit. 

lxc03:/mnt/ctdev02/sapdata # tar cf /dev/nst0 DISKD0051 --totals=USR1
Total bytes written: 14206033920 (14GiB, 354MiB/s)
Total bytes written: 39681720320 (37GiB, 376MiB/s)
Total bytes written: 65241937920 (61GiB, 394MiB/s)
Total bytes written: 87778324480 (82GiB, 384MiB/s)
Total bytes written: 115248916480 (108GiB, 396MiB/s)

Ha nem adjuk meg a --totals=USR1 kapcsolót, és mégis megkapja a SIGUSR1-et, akkor megáll 138-as returnkóddal, egyébként csak kiírja az adott pillanatban, és a végén rc0-val áll meg (vagy amivel amúgy állt volna meg).

MakePass v2.0.0 && PassHandler v1.0.0

Pár évvel ezelőtt írtam egy jelszógenerátort, ami egy bemeneti stringből (pl. 'username@domain') tudott generálni egy jó hosszú és kacifántos jelszót (egész pontosan egy Base64-kódolt SHA-1 hash-et csinált a bemenetből). Akkor volt, aki nehezményezte, hogy a cucc nem képes tárolni sem userneveket, sem adott jelszavakat, dehát ezen nincs mit csodálkozni, mert ez egy jelszógenerátor, nem jelszótár. Viszont, volt javaslat arra, hogy mire is alapulhatna egy olyan utility, ami tudná ezt. Ez pedig a dmenu.