V Amsterdamu probíhá Open Source Summit Europe. Organizace Linux Foundation představuje novinky. Pod svá křídla převzala open source dokumentovou databázi DocumentDB.
Přesně před 34 lety, 25. srpna 1991, oznámil Linus Benedict Torvalds v diskusní skupině comp.os.minix, že vyvíjí (svobodný) operační systém (jako koníček, nebude tak velký a profesionální jako GNU) pro klony 386 (486), že začal v dubnu a během několika měsíců by mohl mít něco použitelného.
86Box, tj. emulátor retro počítačů založených na x86, byl vydán ve verzi 5.0. S integrovaným správcem VM. Na GitHubu jsou vedle zdrojových kódů ke stažení také připravené balíčky ve formátu AppImage.
Vláda Spojených států získala desetiprocentní podíl v americkém výrobci čipů Intel. Oznámili to podle agentur americký prezident Donald Trump a ministr obchodu Howard Lutnick. Společnost Intel uvedla, že výměnou za desetiprocentní podíl obdrží státní dotace v hodnotě 8,9 miliardy dolarů (zhruba 186 miliard Kč). Částka podle Intelu zahrnuje dříve přislíbené subvence 5,7 miliardy dolarů z programu CHIPS na podporu výroby čipů v USA,
… více »Organizace Apache Software Foundation (ASF) vydala verzi 27 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
Knihovna FFmpeg byla vydána ve verzi 8.0 „Huffman“. Přibyla mj. podpora hardwarově akcelerovaného kódování s využitím API Vulcan, viz seznam změn.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) vydal Zprávu o stavu kybernetické bezpečnosti ČR za rok 2024 (pdf). V loňském roce NÚKIB evidoval dosud nejvíce kybernetických bezpečnostních incidentů s celkovým počtem 268. Oproti roku 2023 se však jedná pouze o drobný nárůst a závažnost dopadů evidovaných incidentů klesá již třetím rokem v řadě. V minulém roce NÚKIB evidoval pouze jeden velmi významný incident a významných incidentů bylo zaznamenáno 18, což oproti roku 2023 představuje pokles o více než polovinu.
Byl publikován aktuální přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie). Servo mimo jiné nově zvládne animované obrázky APNG a WebP.
Na chytré telefony a počítačové tablety v Rusku bude od začátku příštího měsíce povinné předinstalovávat státem podporovanou komunikační aplikaci MAX, která konkuruje aplikaci WhatsApp americké společnosti Meta Platforms. Oznámila to dnes ruská vláda. Ta by podle kritiků mohla aplikaci MAX používat ke sledování uživatelů. Ruská státní média obvinění ze špehování pomocí aplikace MAX popírají. Tvrdí, že MAX má méně oprávnění k přístupu k údajům o uživatelích než konkurenční aplikace WhatsApp a Telegram.
Společnost PINE64 stojící za telefony PinePhone nebo notebooky Pinebook publikovala na svém blogu srpnový souhrn novinek. Kvůli nedostatečnému zájmu byla ukončena výroba telefonů PinePhone Pro.
Ř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: