Společnost NVIDIA vydala verzi 13.0 toolkitu CUDA (Wikipedie) umožňujícího vývoj aplikací běžících na jejich grafických kartách. Přehled novinek v poznámkách k vydání.
Byly vyhlášeni vítězové a zveřejněny vítězné zdrojové kódy (YouTube, GitHub) již 28. ročníku soutěže International Obfuscated C Code Contest (IOCCC), tj. soutěže o nejnepřehlednější (nejobfuskovanější) zdrojový kód v jazyce C.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za červenec (YouTube).
Konečně se ochladilo, možná i díky tomu přestaly na chvíli padat rakety jako přezrálé hrušky, díky čemuž se na Virtuální Bastlírně dostane i na jiná, přízemnější témata. Pokud si chcete jako každý měsíc popovídat s dalšími bastlíři, techniky, vědci a profesory u virtuálního pokecu u piva, Virtuální Bastlírna je tu pro Vás.
Ještě před ochlazením se drát na vedení V411 roztáhl o 17 metrů (přesné číslo není známé, ale drát nepřežil) a způsobil tak… více »Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
PixiEditor byl vydán ve verzi 2.0. Jedná se o multiplatformní univerzální all-in-one 2D grafický editor. Zvládne rastrovou i vektorovou grafiku, pixel art, k tomu animace a efekty pomocí uzlového grafu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí GNU LGPL 3.0.
Byly představeny novinky v Raspberry Pi Connect for Organisations. Vylepšen byl protokol auditu pro lepší zabezpečení. Raspberry Pi Connect je oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče. Verze pro organizace je placená. Cena je 0,50 dolaru za zařízení za měsíc.
CISA (Cybersecurity and Infrastructure Security Agency) oznámila veřejnou dostupnost škálovatelné a distribuované platformy Thorium pro automatizovanou analýzu malwaru. Zdrojové kódy jsou k dispozici na GitHubu.
Ubuntu nově pro testování nových verzí vydává měsíční snapshoty. Dnes vyšel 3. snapshot Ubuntu 25.10 (Questing Quokka).
Společnost Proton AG stojící za Proton Mailem a dalšími službami přidala do svého portfolia Proton Authenticator. S otevřeným zdrojovým kódem a k dispozici na všech zařízeních. Snadno a bezpečně synchronizujte a zálohujte své 2FA kódy. K používání nepotřebujete Proton Account.
Řešení dotazu:
mkdir /mnt/old mount -o bind / /mnt/old cd /mnt/old cp -av * /mnt/zaloha/Zdar Max
Jinak zálohovat můžeš tarem, nebo pokud zálohuješ na další místo s linuxovým fs, tak i jen kopií (cp -av). Pro správné kopírování bych použil bind mount, aby jsi se vyvaroval kopírování dynamických věcí v dev, proc, sys, run apod.
--one-file-system
?
Aniž bych tušil, jakou konfiguraci tazatel používá, jen upozorňuji, že tady něco nesedí:
Pokud používáš Btrfs v multidevice módu, a LUKS má to být POD Btrfs, pak to znamená, že používáš dm-crypt a do Btrfs máš integrované pseudozařízení…
Proč jedno? Co když tam má integrovaná (mnohá) pseudozařízení?
Na stroji, u kterého zrovna teď sedím, vypadá kořenový FS (Btrfs RAID1) takto:
NAME FSTYPE FSVER MODEL SIZE UUID nvme0n1 crypto_LUKS 2 Seagate FireCuda 520 SSD ZP2000GM30002 1,8T 8fbfe3ee-6721-4025-af7a-4ca577dd42c7 └─dustbin0 btrfs 1,8T 4bf8d9ff-a1b8-4fc2-927a-7764a374876a nvme1n1 crypto_LUKS 2 Seagate FireCuda 520 SSD ZP2000GM30002 1,8T 8fbfe3ee-6721-4025-af7a-4ca577dd42c8 └─dustbin1 btrfs 1,8T 4bf8d9ff-a1b8-4fc2-927a-7764a374876aDalší FS (Btrfs RAID6 data, RAID1C3 metadata) vypadá takto:
NAME FSTYPE FSVER MODEL SIZE UUID sdc crypto_LUKS 2 WDC WDS400T1R0A-68A4W0 3,6T 923968d8-4526-4521-b4a3-35dc7f8564de └─crypt5 btrfs 3,6T 9e439e61-7540-40a7-95f9-6922707389ef sdd crypto_LUKS 2 WDC WDS400T1R0A-68A4W0 3,6T daa7a9f6-50de-4e3c-a3b2-c4a77bd7f410 └─crypt4 btrfs 3,6T 9e439e61-7540-40a7-95f9-6922707389ef sde crypto_LUKS 2 WDC WDS400T1R0A-68A4W0 3,6T 28bad0e0-9328-49e8-af3a-6a5c39ab4988 └─crypt2 btrfs 3,6T 9e439e61-7540-40a7-95f9-6922707389ef sdf crypto_LUKS 2 WDC WDS400T1R0A-68A4W0 3,6T b7d31ea4-e79b-41c6-9798-cdb28d67f251 └─crypt7 btrfs 3,6T 9e439e61-7540-40a7-95f9-6922707389ef sdg crypto_LUKS 2 WDC WDS400T1R0A-68A4W0 3,6T 413861b8-262f-4c5b-839e-0d95117e1ed0 └─crypt0 btrfs 3,6T 9e439e61-7540-40a7-95f9-6922707389ef sdh crypto_LUKS 2 WDC WDS400T1R0A-68A4W0 3,6T 83183f5e-0839-49c0-b023-b34f8e187cf0 └─crypt1 btrfs 3,6T 9e439e61-7540-40a7-95f9-6922707389ef sdi crypto_LUKS 2 WDC WDS400T1R0A-68A4W0 3,6T 605f7a74-1c33-4580-8eee-c2f1b121b1c2 └─crypt3 btrfs 3,6T 9e439e61-7540-40a7-95f9-6922707389ef sdj crypto_LUKS 2 WDC WDS400T1R0A-68A4W0 3,6T 4c7375bd-51bd-4f2e-a75d-af1bac1d7eb9 └─crypt8 btrfs 3,6T 9e439e61-7540-40a7-95f9-6922707389ef
Po jednom společném zařízení tam↑ není ani stopy. UUID LUKS zařízení se liší a jde tedy o různá zařízení, zatímco UUID filesystému (4bf8d9ff-a1b8-4fc2-927a-7764a374876a
u menšího, e439e61-7540-40a7-95f9-6922707389ef
u většího) se shodují, přesně dle očekávání.
Výhody multi-device Btrfs výše uvedená konfigurace rozhodně nepostrádá:
Label: 'dustbin' uuid: 4bf8d9ff-a1b8-4fc2-927a-7764a374876a Total devices 2 FS bytes used 1.05TiB devid 1 size 1.82TiB used 1.62TiB path /dev/mapper/dustbin0 devid 2 size 1.82TiB used 1.62TiB path /dev/mapper/dustbin1 |
Label: 'crypt' uuid: 9e439e61-7540-40a7-95f9-6922707389ef Total devices 8 FS bytes used 8.41TiB devid 1 size 3.64TiB used 1.44TiB path /dev/mapper/crypt8 devid 2 size 3.64TiB used 1.44TiB path /dev/mapper/crypt1 devid 3 size 3.64TiB used 1.44TiB path /dev/mapper/crypt2 devid 4 size 3.64TiB used 1.44TiB path /dev/mapper/crypt7 devid 5 size 3.64TiB used 1.44TiB path /dev/mapper/crypt4 devid 6 size 3.64TiB used 1.44TiB path /dev/mapper/crypt5 devid 7 size 3.64TiB used 1.44TiB path /dev/mapper/crypt0 devid 8 size 3.64TiB used 1.44TiB path /dev/mapper/crypt3 |
|
Data, RAID1: total=1.58TiB, used=1.05TiB System, RAID1: total=32.00MiB, used=320.00KiB Metadata, RAID1: total=43.00GiB, used=7.12GiB GlobalReserve, single: total=512.00MiB, used=0.00B |
Data, RAID6: total=8.57TiB, used=8.38TiB System, RAID1C3: total=32.00MiB, used=528.00KiB Metadata, RAID1C3: total=23.00GiB, used=20.55GiB GlobalReserve, single: total=512.00MiB, used=0.00B |
(Pravda je, že total=
je v tomto výpisu celkem odjakživa nesmysl; ve skutečnosti i podle df -h
je to 1,9T a 30T.)
Jen pro doplnění, tar tam a zpět provedl správně, co měl.
Možná… Téměř…
Jistota správného přenosu je jen a pouze u btrfs send ... | btrfs receive ...
.
V případě utilit typu tar
je potřeba myslet na --xattrs
, --acls
a --selinux
, což bývá implicitně vypnuté, tj. implicitně se všechna tahle data ztratí, pokud existují. (To třeba rsync
je na tom ještě hůř: podporuje jen první dva uvedené argumenty, zatímco SELinux data potichu zahodí.)
Já bych volil btrfs send
místo tar; tím je zaručeno, že se přenesou fakt všechna metadata, i taková, o kterých rsync
nebo tar
na své úrovni abstrakce vůbec nemusí vědět.
A pak z těch serializovaných dat udělat na novém FS btrfs receive
, vzniklý subvolume prohlásit za hlavní a je vymalováno.
Tiskni
Sdílej: