Blogbejegyzések

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.

Új PC ami nem megy

Nemrég kikerült hostingból egy régi gép, ami kapcsán úgy döntöttem, újra hasznosítom a házát és tápegységét, kap modern belsőséget. Vettem egy Ryzen 5 5600G procit, 16GB Crucial Ballistix memóriát és kinéztem hozzá egy MSI Pro VDH Wifi alaplapot. Utóbbit megtaláltam használtan Prohardveren, gondoltam jó lesz...

Építettem már néhányszor gépet de ezt egyszerűen nem tudom feléleszteni. Bekapcsolás után nem ad képet a gép, pedig a monitor bekapcsol, a billentyűzet led is világít. Azaz hol világít, hol nem. Mintha valami boot loop lenne, de kép nélkül. Próbáltam BIOS frissítést, ez annyit javított a helyzeten hogy néha-néha már felvillant a BIOS képe 1-2 másodpercre, de aztán megint elsötétült minden. Az alaplapi diagnosztikai ledek közül a boot és a vga világít felváltva. RAM, processzor ki-be is megvolt, az összes szokásos hibakeresési lépés.

Vajon átvertek az alaplappal? Ugyan garanciális de nincs sok kedvem heteket várni rá míg kiderül mi van vele. Vagy esetleg a tápegységem rossz? Az a tapasztalatom hogy ilyen fura problémáknál mindig a tápegység a hibás. Ugyan nem volt vele soha probléma, de mégsem egy új darab...

Cherry KC 6000 UK - tapasztalatok közel 3 hét után.

Szóval pár hete feldobtam egy fórumtopicot, keresném a sokéves Genius Slimstar i222 utódját. Alapvetően megtette a dolgát, de már pár éve gondolkodtam rajta, hogy vennék valami normálisabbat, ami nem csörög-zörög-lötyög. Az meg megy egy másik helyére, amin már a takarítás sem segít a ragadáson.

Kritériumok a következőek voltak: