Blogbejegyzések

…már több, mint egy éve. Azóta saját életem van, saját döntéseim, és persze saját hibafaktorok is akadnak.

A host: Manjaro, kernel:6.12 (12 mag, 32 GB memória, kb. 4 éves gép, nem ssd-n fut)

A guest: Win 10 Pro.

Őrült lassan működik. Egy start kb. 15-25 perc. Egy shutdown 30-40 perc. Ilyenkor kiírja "getting ready" vagy valami ilyesmi. Felkészülni a shutdownra? Vicces.

A VM főbb beállításai: 4 mag, 6 GB memória, 128 MB videó memória, 50 GB lemezterület.

Frissítés:
Úgy néz ki rengeteg és köztük néhány termetes update volt az a mi a szörnyű lassulást okozta.

Egy kicsit zavart hogy a soft AVR core-s projektben ez az egyebkent elegge AVR-specifikus, 6 bit mely, 8 bit szeles I/O buszt a CPU aszinkron modon olvassa es szinkron modon irja. Azaz mig a program-memoria illetve az adatmemoria rendes szinkron ROM/RAM-kent viselkedik (igy mind az olvasasi, mind az irasi ciklus eredmenye a kovetkezo orajelre jelenik meg a CPU es/vagy a memoriak szamara), az I/O port eseten az olvasas a jelenlegi implementacioban aszinkron. Gondoltam kicsit utanajarok ennek a dolognak mit lehet itt tenni hogy egy elegansabb, jobban fenntarthato, jobban ujrafelhasznalhato cuccmany legyen ebbol az egeszbol. 

Debian 12 hiba és patkolása:

root@rpi5-killer:/etc/rear#  ldd /usr/lib/x86_64-linux-gnu/systemd/libsystemd-core-252.so
    linux-vdso.so.1 (0x00007efcccdca000)
    libsystemd-shared-252.so => not found
    libseccomp.so.2 => /lib/x86_64-linux-gnu/libseccomp.so.2 (0x00007efcccba4000)
    libpam.so.0 => /lib/x86_64-linux-gnu/libpam.so.0 (0x00007efcccb92000)
    libaudit.so.1 => /lib/x86_64-linux-gnu/libaudit.so.1 (0x00007efcccb61000)
    libkmod.so.2 => /lib/x86_64-linux-gnu/libkmod.so.2 (0x00007efcccb44000)
    libapparmor.so.1 => /lib/x86_64-linux-gnu/libapparmor.so.1 (0x00007efcccb2d000)
    libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007efcccaff000)
    libmount.so.1 => /lib/x86_64-linux-gnu/libmount.so.1 (0x00007efccca9c000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007efccc8bb000)
    libcap-ng.so.0 => /lib/x86_64-linux-gnu/libcap-ng.so.0 (0x00007efccc8b3000)
    libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x00007efccc7f7000)
    liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007efccc7c6000)
    libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007efccc200000)
    libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007efccc72c000)
    /lib64/ld-linux-x86-64.so.2 (0x00007efcccdcc000)
    libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x00007efccc6d5000)

root@rpi5-killer:/etc/rear# echo "/usr/lib/x86_64-linux-gnu/systemd" > /etc/ld.so.conf.d/libsystemd-core.conf && ldconfig

root@rpi5-killer:/etc/rear#  ldd /usr/lib/x86_64-linux-gnu/systemd/libsystemd-core-252.so
    linux-vdso.so.1 (0x00007fa2a492d000)
    libsystemd-shared-252.so => /usr/lib/x86_64-linux-gnu/systemd/libsystemd-shared-252.so (0x00007fa2a4200000)
    libseccomp.so.2 => /lib/x86_64-linux-gnu/libseccomp.so.2 (0x00007fa2a4707000)
    libpam.so.0 => /lib/x86_64-linux-gnu/libpam.so.0 (0x00007fa2a46f5000)
    libaudit.so.1 => /lib/x86_64-linux-gnu/libaudit.so.1 (0x00007fa2a46c4000)
    libkmod.so.2 => /lib/x86_64-linux-gnu/libkmod.so.2 (0x00007fa2a46a7000)
    libapparmor.so.1 => /lib/x86_64-linux-gnu/libapparmor.so.1 (0x00007fa2a4690000)
    libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fa2a4662000)
    libmount.so.1 => /lib/x86_64-linux-gnu/libmount.so.1 (0x00007fa2a45ff000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa2a401f000)
    libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x00007fa2a45f4000)
    libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x00007fa2a459d000)
    libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x00007fa2a458f000)
    libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007fa2a4553000)
    libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007fa2a3ed8000)
    libip4tc.so.2 => /lib/x86_64-linux-gnu/libip4tc.so.2 (0x00007fa2a4549000)
    liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x00007fa2a3eb2000)
    libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007fa2a3a00000)
    libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x00007fa2a3944000)
    liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007fa2a3915000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fa2a3835000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fa2a492f000)
    libcap-ng.so.0 => /lib/x86_64-linux-gnu/libcap-ng.so.0 (0x00007fa2a453f000)
    libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007fa2a379b000)
    libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007fa2a3e8a000)

rpi5-killer Debian12 DR for the OS with REAR 2.9 on the 3rd disk ... Sok szívás, van benne Debian 12-es hiba is, pl. hibás REAR 2.9, kisebb NVME SSD méret, után siker 1 Ventoy-os pendriveval ... Multi DR egy pendriveval ... Nagyon király lett ...
Sikerült a teszt szerveremen a DR. :)

root@rpi5-killer:/etc/rear# cat os.conf 
OS_VENDOR=Debian
OS_VERSION=12

root@rpi5-killer:/etc/rear#  cat local.conf
OUTPUT=ISO
BACKUP=NETFS
AUTOEXCLUDE_DISKS=no
ONLY_INCLUDE_VG=( "vg" )
BACKUP_URL=file:///media/rear
BACKUP_PROG_EXCLUDE=( '/tmp/*' )
FIRMWARE_FILES=( 'yes' )
COPY_AS_IS=( '/usr/share/file/magic' '/usr/share/rear/*' '/var/lib/rear/*' )
AUTOEXCLUDE_MULTIPATH=yes
MIGRATION_MODE='true'
AUTORESIZE_PARTITIONS=( /dev/nvme0n1p3 )
AUTOSHRINK_DISK_SIZE_LIMIT_PERCENTAGE=90

innetől kezdve REAR 2.9 mentés hiba nélkül fut.

...avagy hogyan ne tároljunk fontos anyagokat...

How the CD Master Scandal Was Exposed! It's Unbelievable - YouTube

https://searchengineland.com/ai-killing-web-business-model-455157

Elég pontos.

https://x.com/Pirat_Nation/status/1921739351563829359

ja nem:(

https://rog.asus.com/me-en/graphics-cards/graphics-cards/rog-astral/rog…

Tessék.

│11:19:09  ~Fisher | Aszondja a kolléga, hogy van egy hibás disk, küld egy képet a szerverről.                                                                                        │
│11:19:18  ~Fisher | Én vakulok rá, 32 disk, mind ződ.                                                                                                                                │
│11:19:29  ~Fisher | Aszondja... jaa, a képen nem látszik, mert villog.                                                                                                              

Elkezdtem játszani $subj-tel.

Más is kapott ilyet? Mikor felvettem, valami ázsiai nyelven dumált kb. 30 másodpercet, majd letette. Vélhetően robot volt, én direkt nem nyomtam ki, meg akartam várni, mennyit dumál.

Magyar idő szerint éjjel 11 óra körül érkeztek az első jelentések, India kilenc célpont támadásáról számolt be. Félő, hogy a helyzet villámgyorsan eszkalálódik a két atomhatalom között. .

https://index.hu/kulfold/2025/05/06/india-pakisztan-haboru-megtorlas-te…
https://index.hu/kulfold/2025/05/06/india-pakisztan-haboru-kasmir-terro…
https://www.youtube.com/shorts/__ATrdX7k3M

Jónéhány éve, még talán 2017-ben vagy 18-ban kaptam egy kiselejtezett asztali PC-t. Házi "szerver" lett belőle, proxmox és rajta konténerek.

https://github.com/cncf/sandbox/issues/81

Powerline kiegészítést használtam Bash-hez régóta. Viszont előjött egy bosszantó bug, így kerestem alternatívákat.

A powerline-go tudja jól a symlinkeket kezelni a Git repóknál, elvileg gyorsabb is, bár nekem a régi sem volt észrevehetően lassú. Aki nem használ ilyesmit, annak érdemes tenni egy próbát.

Az évek során megkerülendő az Android alkalmazások használhatósági poklát, írtam pár apróbb JS szösszenetet ami hasznos volt a mindennapi munkában és hobbizásban. Ezek közül pár erősen épített a mobiltelefon különféle beépített eszközeinek(audio, kamera, szenzor) az elérésére.
Aztán volt egy telefonváltás és hirtelen az alkalmazások fele nem ment. Nem foglalkoztam vele, mert nem kellett. Aztán úgy jött az élet, hogy mégiscsak kellettek.

Különbözőek vagyunk. Itt van a példa.

A pincérek

Az idei Revision hozott szép demókat, de szerintem ami a pálmát vitte az a BEC szkópdemója:

Pakolás közben találam régi CD-ket.
Gyorsan átnéztem és találtam pár gyöngyszemet.
Pl: 2005, screenshot, slackware.hu, stb  :-)
https://flic.kr/p/2qZSnbi

Alapértelmezett policy, semmi különös beállítás.

Ha kiküldök egy levelet, amiben bárhol szerepel a ccleaner letöltési linkje (ez), akkor a levél látszólag elmegy, de nem érkezik meg a címzetthez.
Reprodukálható megfigyelés, másik feladó címmel is próbáltuk, másik címzetthez is próbáltuk. Nincs jelzésem sem nekem, sem a címzettnek a turpisságról - ez utóbbiakat azért sérelmezem.

Más tapasztalt ilyet?

A pcforum.hu oldalán olvastam a címbeli kijelentést. Egészen pontosan ez volt leírva:

"Lehet, az az apró tény kimaradt neki, hogy a Linux kernel fejlesztésében a MS is jelentősen részt vesz. Ezen az alapon az egész Linux (+disztrók) MS. De azért mégse."

Ez a link pedig pontosan odamutat, ha valaki az eredetit szeretné látni: Forrás

Eddig azt hittem elkerül a baj.
Eddig több mint 400 kis gyümölcsfáról tudok, amit elvittek kertekből a környéken.

Egyszerűen amit ki tudnak húzni gyümölcsfát viszik. Kamera is volt ahol felvette. Más helyen csak simán leütik a kamerát.

Tőlem ma reggelre 6 kis fát vittek el.

Már elkapták őket egyszer, de mivel kis értékű lopásnak számít így ismét szabadlábon tevékenykednek. :(

Korábbi blogbejegyzés folytatása. Lásd: https://hup.hu/node/184223

Mivel az előző játékom -- Words of Yendor, egy steamgoth világban játszódó szókitalálós kalandjáték -- csúfos kudarcnak bizonyult Steamen, tanultam az esetből.

Csináltam egy Dragon Riddler című, fantasy világban játszódó szókitalálós kalandjátékot, melynek demója mától elérhető Steamen Windowsra, Macre és Linuxra egyaránt:

https://store.steampowered.com/app/3654630/Dragon_Riddler_Demo/

Azt hittem, hogy a tray-en csak 1 ikon lehet applikációnként.

Egy olasz srác kérte, hogy legyen választható a nyelv és rakjam be egy exe-be a CPU és memória monitort.

Utána néztem, meg lehetett oldani.

Így az exe mérete nem nőtt jelentősen ~50k -> ~70k.

Viszont az új exe kb. ugyanannyit eszik mint egyenként az eredeti exe fájlok. Azaz feleztük a memória használatot.

Íme az eredmény:
https://github.com/lutischan-ferenc/resource-monitor-v2/releases/tag/v2.1.0