Po půl roce vývoje od vydání verze 48 bylo vydáno GNOME 49 s kódovým názvem Brescia (Mastodon). S přehrávačem videí Showtime místo Totemu a prohlížečem dokumentů Papers místo Evince. Podrobný přehled novinek i s náhledy v poznámkách k vydání a v novinkách pro vývojáře.
Open source softwarový stack ROCm (Wikipedie) pro vývoj AI a HPC na GPU od AMD byl vydán ve verzi 7.0.0. Přidána byla podpora AMD Instinct MI355X a MI350X.
Byla vydána nová verze 258 správce systému a služeb systemd (GitHub).
Byla vydána Java 25 / JDK 25. Nových vlastností (JEP - JDK Enhancement Proposal) je 18. Jedná se o LTS verzi.
Věra Pohlová před 26 lety: „Tyhle aféry každého jenom otravují. Já bych všechny ty internety a počítače zakázala“. Jde o odpověď na anketní otázku deníku Metro vydaného 17. září 1999 na téma zneužití údajů o sporožirových účtech klientů České spořitelny.
Byla publikována Výroční zpráva Blender Foundation za rok 2024 (pdf).
Byl vydán Mozilla Firefox 143.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Nově se Firefox při ukončování anonymního režimu zeptá, zda chcete smazat stažené soubory. Dialog pro povolení přístupu ke kameře zobrazuje náhled. Obzvláště užitečné při přepínání mezi více kamerami. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 143 bude brzy k dispozici také na Flathubu a Snapcraftu.
Byla vydána betaverze Fedora Linuxu 43 (ChangeSet), tj. poslední zastávka před vydáním finální verze, která je naplánována na úterý 21. října.
Multiplatformní emulátor terminálu Ghostty byl vydán ve verzi 1.2 (𝕏, Mastodon). Přehled novinek, vylepšení a nových efektů v poznámkách k vydání.
Byla vydána nová verze 4.5 (𝕏, Bluesky, Mastodon) multiplatformního open source herního enginu Godot (Wikipedie, GitHub). Přehled novinek i s náhledy v příspěvku na blogu.
[root@kvm ~]# lvs LV VG Attr LSize Pool Origin Data% Move Log Cpy%Sync Convert TESTOVACI data -wi-ao--- 160.00g a1 data -wi-ao--- 40.00g a2 data -wi-ao--- 10.00g swap data -wi-ao--- 4.88g system data -wi-ao--- 19.53g windows_server data owi-aos-- 120.00g windows_server_snapshot data swi-a-s-- 25.00g windows_server 1.40
# vytvořím snapshot > lvcreate -s -L 25G -n windows_server_snapshot /dev/data/windows_server # vytvořím image stejným způsobem, jakým zálohuji na server se souborovým systémem ZFS, tj. přenesu jen rozdíly mezi soubory (nebo celý pokud neexistuje cílový) > rsync -L --inplace --no-whole-file --block-size=32768 --copy-devices /dev/data/windows_server_snapshot /testovaci/windows_server.img # md5 lvm snapshotu > md5sum /dev/data/windows_server_snapshot | awk '{print $1}' > /testovaci/lvm.md5 # md5 lvm image > md5sum /testovaci/windows_server.img | awk '{print $1}' > /testovaci/file.md5 > cat /testovaci/lvm.md5 /testovaci/file.md5 65428116d1797a70949530221850cc5e 7a17be5c0e71b193b8178343d06f2208Na ostatní LVM volumy to funguje, jen s tímto je problém.
cat /dev/data/windows_server_snapshot > soubor
vytvorilo soubor, jehoz velikost neni nasobkem 32 kilo a tim padem md5sum srovnava nesrovnatelne.
btw. rsync. Prenasat len rozdiely sa moc neoplati ak zdroj aj ciel je na jednej masine. Rsync si vycita cast z oboch suborov, spravi checksum a podla toho sa rozhodne ci je potrebne prepisat ciel, alebo nie. Ak bezi rsync po pomalej linke a zmien nie je vela, tak to dost urychli synchronizovanie, no vramci jedneho stroja to ma vacsinou opacny ucinok.Ten rsync mi normálně běží na vzdálený stroj, tady jsem to jen testoval.
zároveň jsem se jinde dočetl, že čas od času je raid nekonzistentní a že je to normální, protože se to opravuje při automatických pravidelných testech. Jenže jak to pozná, na kterém disku jsou správná data při opravě a jak to pozná při normálním čtení korektní data?normalni to urcite neni, ale bohuzel se to stava (taky to je duvod proc sem z mdraid presel na ZFS, nikdy zpet) pri "oprave" se (mozna to zmenily, ale pochybuju) predpoklada ze korektni jsou data, spatne je parita (i kdyz jsou v RAID6 spatne data - pri obnove z jedny parity by ta druha sedela). co tohle znamena pro mirror si nejsem jistej, pravdepodobne ze prvni disk je "master" a predpoklada se ze ten je korektni
echo 'check' > /sys/block/mdXX/md/sync_actiona pak
cat /sys/block/mdXX/md/mismatch_countnebo i s opravou pole (asi první disk je master):
echo 'repair' > /sys/block/mdXX/md/sync_actionsledovat lze třeba pomocí:
cat /proc/mdstatPokud to chcete uspíšit a nebudete pole používat (ale můžete jej používat, ale možná pak bych dal první hodnotu jen 50000 či méně):
echo 200000 /sys/block/mdXX/md/sync_speed_min echo 500000 /sys/block/mdXX/md/sync_speed_max
mdXX
- dosaďte vlastní
mdadm --grow --bitmap=none /dev/md0
a zkusil znovu. Jinak to bude asi spíš už chyba disku…194cf9a726f086aa55b0260bf96c5e46 /dev/data/windows_server_snapshot eb6ca7d5400489cabab0b4203a1be4c4 /dev/data/windows_server_snapshot 7f2a9ef2cab1bb30091683675c279c63 /dev/data/windows_server_snapshot eb6ca7d5400489cabab0b4203a1be4c4 /dev/data/windows_server_snapshot 194cf9a726f086aa55b0260bf96c5e46 /dev/data/windows_server_snapshotJe vidět, že tolik nesynchronizovaných bloků dat tam zase nebude, protože se to občas při čtení trefí do toho samého. Nemůže to být ten samý problém (s windows paging file), který se objevuje s linux swapem na raidu 1, tj. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=405919 (i když tady moc nerozumím o co konkrétně se jedná)?
mount -t ntfs-3g /dev/mapper/data-windows_server2 /W while : ; do md5sum /W/pagefile.sys; done 6b87c2367d9936168ba79d16ccc297f7 /W/pagefile.sys ba12e00950a0459389b1e97a44602047 /W/pagefile.sys 6b87c2367d9936168ba79d16ccc297f7 /W/pagefile.sys ba12e00950a0459389b1e97a44602047 /W/pagefile.sys 6b87c2367d9936168ba79d16ccc297f7 /W/pagefile.sys 6b87c2367d9936168ba79d16ccc297f7 /W/pagefile.sysTeď je otázka - vadí to něčemu? Pokud je toto ten samý či podobný problém jako s linux swapem na raid 1, pak tento problém nemám jen já, ale všichni, kteří provozují takovou konfiguraci (raid 1, lvm, virtualizace s kvm) - mohl by mi to prosím někdo potvrdit?
Tiskni
Sdílej: