PimpMyGRC upravuje vzhled toolkitu GNU Radio a přidává alternativní barevná témata. Primárním cílem autora bylo pouze vytvořit tmavé prostředí vhodné pro noční práci, nicméně k dispozici je nakonec celá škála barevných schémat včetně možností různých animací a vizuálních efektů (plameny, matrix, bubliny...), které nepochybně posunou uživatelský zážitek na zcela jinou úroveň. Témata jsou skripty v jazyce Python, které nahrazují
… více »GIMP 3.2 byl oficiálně vydán (Mastodon, 𝕏). Přehled novinek v poznámkách k vydání.
FRANK OS je open-source operační systém pro mikrokontrolér RP2350 (s FRANK M2 board) postavený na FreeRTOS, který přetváří tento levný čip na plně funkční počítač s desktopovým uživatelským rozhraním ve stylu Windows 95 se správcem oken, terminálem, prohlížečem souborů a knihovnou aplikací, ovládaný PS/2 myší a klávesnicí, s DVI video výstupem. Otázkou zůstává, zda by 520 KB SRAM stačilo každému 😅.
Administrativa amerického prezidenta Donalda Trumpa by měla dostat zhruba deset miliard dolarů (asi 214 miliard Kč) za zprostředkování dohody o převzetí kontroly nad aktivitami sociální sítě TikTok ve Spojených státech.
Projekt Debian aktualizoval obrazy stabilní větve „Trixie“ (13.4). Shrnuje opravy za poslední dva měsíce, 111 aktualizovaných balíčků a 67 bezpečnostních hlášení. Opravy se týkají mj. chyb v glibc nebo webovém serveru Apache.
Agent umělé inteligence Claude Opus ignoroval uživatelovu odpověď 'ne' na dotaz, zda má implementovat změny kódu, a přesto se pokusil změny provést. Agent si odpověď 'ne' vysvětlil následovně: Uživatel na mou otázku 'Mám to implementovat?' odpověděl 'ne' - ale když se podívám na kontext, myslím, že tím 'ne' odpovídá na to, abych žádal o svolení, tedy myslí 'prostě to udělej, přestaň se ptát'.
Po 8. květnu 2026 už na Instagramu nebudou podporované zprávy opatřené koncovým šifrováním. V chatech, kterých se bude změna týkat, se objeví pokyny o tom, jak si média nebo zprávy z nich stáhnout, pokud si je chcete ponechat.
V lednu byla ve veřejné betě obnovena sociální síť Digg (Wikipedie). Dnes bylo oznámeno její ukončení (Hard Reset). Společnost Digg propouští velkou část týmu a přiznává, že se nepodařilo najít správné místo na trhu. Důvody jsou masivní problém s boty a silná konkurence. Společnost Digg nekončí, malý tým pokračuje v práci na zcela novém přístupu. Cílem je vybudovat platformu, kde lze důvěřovat obsahu i lidem za ním. Od dubna se do Diggu na plný úvazek vrací Kevin Rose, zakladatel Diggu z roku 2004.
MALUS je kontroverzní proprietarní nástroj, který svým zákazníkům umožňuje nechat AI, která dle tvrzení provozovatelů nikdy neviděla původní zdrojový kód, analyzovat dokumentaci, API a veřejná rozhraní jakéhokoliv open-source projektu a následně úplně od píky vygenerovat funkčně ekvivalentní software, ovšem pod libovolnou licencí.
Příspěvek na blogu Ubuntu upozorňuje na několik zranitelností v rozšíření Linuxu o mandatorní řízení přístupu AppArmor. Společně jsou označovány jako CrackArmor. Objevila je společnost Qualys (technické detaily). Neprivilegovaný lokální uživatel se může stát rootem. Chyba existuje od roku 2017. Doporučuje se okamžitá aktualizace. Problém se týká Ubuntu, Debianu nebo SUSE. Red Hat nebo Fedora pro mandatorní řízení přístupu používají SELinux.
Jak a u kterého úložiště jsi to UUID změnil?
Redpektive já bych to udělal takto:
Pokud bych chtěl OS na SSD smazat, udělal bych to z live a v tom případě by se nic na NVMe nemuselo řešit. Pokud bych ten OS chtěl zachovat a to SSD bych chtěl mít také v pc, tak po naklonování SSD na NVMe bych vypnul pc, oddělal bočnici a sudndal z SSD kšandy. Potom bych zavedl nějaký live system a v terminálu pak takto:
### identifikace NVMe (raději)
lsblk
# dejme tomu, že fleška s live je sda a NVMe je nvme0n1
### změna UUID's (s odpojenými oddíly)
# pokud budeš mít čísla za "p" jinak, tak je zadej tak, aby to sedělo.
# EFI (pokud existuje)
sudo tune2fs -U random /dev/nvme0n1p1
# /rootfs
sudo tune2fs -U random /dev/nvme0n1p2
### chroot
sudo mkdir -p /target
sudo mount /dev/nvme0n1p2 /target
sudo mount /dev/nvme0n1p1 /target/boot/efi
cd /target
sudo mount --bind /dev dev
sudo mount --bind /dev/pts dev/pts
sudo mount -t proc proc proc
sudo mount -t sysfs sysfs sys
sudo chroot /target
# v chrootu vše bez sudo, jsi root
### úprava /etc/fstab
blkid
# teď se ti zobrazí ta nová UUID.
nano /etc/fstab
# zde je potřeba změnit UUID pro EFI oddíl a druhý oddíl s OS. Uložit a potom:
### update GRUBu a initramfs
update-grub
update-initramfs -k all -u
exit
cd
sudo umount /target/{boot/efi,dev/pts,dev,proc,sys}
sudo umount /target
Teď můžeš vypnout stroj, vytáhnout flešku, zapojit SSD, nasadit bočnici a vše by mělo fungovat. Doufám, že jsem nic neopomněl.
Opraveno, díky.
V sekci ### změna UUIS's (s odpojenými oddíly) pro první EFI oddíl nepoužiješ příkaz:
sudo tune2fs -U random /dev/nvme0n1p1
ale
sudo mkdosfs -i nějaké_UUID /dev/nvme0n1p1 # nějaké UUID může být třeba WXYZ1234
A ještě jsem si uvědomil, že by SSD mohlo jít vypnout v UEFI v konfiguraci SATA, takže bys nemusel laborovat s bočnicí atd. Už jsem tu ale i četl, že ne vždy to fungovalo 100%. Zkus, uvidíš.
Ještě s tím raději počkej. Něco ověřuji.
1) To UUID musí být hexadecimální. To znamená, že můžeš použít číslice 0-9 a písmena A-F. Takže např. 1234ABCD.
2) Když jsem to teď zkoušel, tak jsem zjistil, že po změně UUID došlo na EFI oddílu ke ztrátě dat. Tam by to problém nebyl. GRUB by šel přeinstaloat. Nevím ale, co udělá tune2fs? Aby to taky nesmazalo vše na systémovém oddílu. Snad ne. Teď si to nemůžu přesně vybavit, protože už je to dlouho, ale když jsem já kdysi měnil UUID, tak pak OS fungoval (mylsím). Zkusím to a napíšu sem.
3) Další věc je, že UUID umí měnit i GParted, takže to jde udělat i tam.
Takže je to v pořádku. Systémový oddíl poškozen nebude. Mimochodem, celou dobu předpokládám, že /rootfs máš nad ext4.
Další věc je, že před změnou UUID /rootfs musíš provést kontrolu toho oddílu:
sudo e2fsck -f /dev/nvme0n1p2 # celou dobu platí, že za nvme0n1p musíš doplnit odpovídající číslo. # možná to budeš mít jednodušší v tom GParted.
Jak jsem psal, tak v tom chrootu pak budeš muset přeinstalovat GRUB. To udělej hned poté, co změníš UUID's ještě před updatem GRUBU a initramfs.
grub-install --target=x86_64-efi /dev/nvme0n1p1 # na konci musí být opět odpovídající číslo.
Dobrá zpráva. Ještě jsem zjistil. že pokud budeš měnit UUID u EFI oddílu v GParted, tak to destruktivní nebude. Takže pak ani nebudeš muset přeinstalovávat ten GRUB. Takže v UEFI zakázat SSD, nabootovat live, v GParted změnit UUID pro oba oddíly, chroot, update GRUBu a initramfs a hotovo. Chápu, že teď je v tom trochu zmatek. Pokud by sis nevěděl rady, tak napiš. Dám ti to sem krok za krokem.
Tiskni
Sdílej: