Byl publikován aktuální přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie).
V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Forgejo byla vydána ve verzi 12.0 (Mastodon). Forgejo je fork Gitei.
Nová čísla časopisů od nakladatelství Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 155 (pdf) a Hello World 27 (pdf).
Hyprland, tj. kompozitor pro Wayland zaměřený na dláždění okny a zároveň grafické efekty, byl vydán ve verzi 0.50.0. Podrobný přehled novinek na GitHubu.
Patrick Volkerding oznámil před dvaatřiceti lety vydání Slackware Linuxu 1.00. Slackware Linux byl tenkrát k dispozici na 3,5 palcových disketách. Základní systém byl na 13 disketách. Kdo chtěl grafiku, potřeboval dalších 11 disket. Slackware Linux 1.00 byl postaven na Linuxu .99pl11 Alpha, libc 4.4.1, g++ 2.4.5 a XFree86 1.3.
Ministerstvo pro místní rozvoj (MMR) jako první orgán státní správy v Česku spustilo takzvaný „bug bounty“ program pro odhalování bezpečnostních rizik a zranitelných míst ve svých informačních systémech. Za nalezení kritické zranitelnosti nabízí veřejnosti odměnu 1000 eur, v případě vysoké závažnosti je to 500 eur. Program se inspiruje přístupy běžnými v komerčním sektoru nebo ve veřejné sféře v zahraničí.
Vláda dne 16. července 2025 schválila návrh nového jednotného vizuálního stylu státní správy. Vytvořilo jej na základě veřejné soutěže studio Najbrt. Náklady na přípravu návrhu a metodiky činily tři miliony korun. Modernizovaný dvouocasý lev vychází z malého státního znaku. Vizuální styl doprovází originální písmo Czechia Sans.
Vyhledávač DuckDuckGo je podle webu DownDetector od 2:15 SELČ nedostupný. Opět fungovat začal na několik minut zhruba v 15:15. Další služby nesouvisející přímo s vyhledáváním, jako mapy a AI asistent jsou dostupné. Pro některé dotazy během výpadku stále funguje zobrazování například textu z Wikipedie.
Více než 600 aplikací postavených na PHP frameworku Laravel je zranitelných vůči vzdálenému spuštění libovolného kódu. Útočníci mohou zneužít veřejně uniklé konfigurační klíče APP_KEY (např. z GitHubu). Z více než 260 000 APP_KEY získaných z GitHubu bylo ověřeno, že přes 600 aplikací je zranitelných. Zhruba 63 % úniků pochází z .env souborů, které často obsahují i další citlivé údaje (např. přístupové údaje k databázím nebo cloudovým službám).
Open source modální textový editor Helix, inspirovaný editory Vim, Neovim či Kakoune, byl vydán ve verzi 25.07. Přehled novinek se záznamy terminálových sezení v asciinema v oznámení na webu. Detailně v CHANGELOGu na GitHubu.
Zdravím,
rád bych zkusil btrfs. Navzdory subvolumes bych určitě chtěl 500 GB SSD rozdělit na / a /data. /data bude zvlášť oddíl, na kterém budou data a nejedná se o oddělené /home. Oboje by mělo být šifrováno pomocí luks. Něco jsem o tom načetl, ale pořád mám pár nejasností:
Díky za nasměrování
Řešení dotazu:
Díky, podívám se na to.
Tak jsem si dal openSUSE do virtuálu a docela mě překvapilo, kolik subvolumes instalátor vytvořil. Také vytvořil zvlášť oddíl pro swap. To jsem právě předpokládal, že udělá jako subvolume, ale vytvořil pro něj oddělený oddíl. Pokud bych tedy chtěl používat swap a mít /rootfs i swap šifrované, tak abych nemusel heslo zadávat 2x, musel bých mezi LUKS a btrfs dát ještě LVM, že?
Díky za odpověď.
Já to teď mám podle tohoto. Jak už jsem psal výše, používám ext4 a mám vytvořeno více oddílů. Díky LVM zadám heslo jen jednou. Myslím, že kdybych neměl LVM, tak bych musel každý oddíl odemykat zvlášť. Rozhodl jsem se, že swap dělat nebudu, takže LVM potřeba nebude. Instalátor v / defaultně vytvoří @ a @home. Já asi ještě nějaké pododdíly taky vytvořím viz. instalace openSUSE, ale vše bude na jednom fyzickém oddílu, takže heslo pro odemčení LUKS budu zadávat jen jednou a hotovo.
Ještě bych potřeboval nasměrovat:
Musím prosím tě všechny pododdíly a kvóty pořešit při instalaci, nebo stačí základní instalace s @ a @home a zbytek dodělat až v nainstalovaném systému?
Nevadí, i tak díky :)
Já teď řeším, jestli vůbec btrfs budu moci použít. Hrál jsem si dnes s Qubes(em) a uvažuji o tom, že na něj přejdu. Instalátor mi ale btrfs vůbec nenabídl, tak nevím, jestli to půjde předpřipravit. Zatím jsem se na netu nedíval.
Ještě jednou díky. Ať se ti daří.
btrfs-convert
. Samozřejmě když disk není připojen. Pak musíte ještě pohlídat to, aby jádro podporovalo btrfs (nebo se zprovoznil aspoň už v initramfs).
Použil jsem to u ext4 oddílu pod LVM, ale raději jsem si předem udělal LVM snapshot (abych nepřišel o data kdyby se náhodou něco stalo – nebyl to jen čerstvý systém). Po připojení oddílu (teď už btrfs) se ale něco zbláznilo a neukazovalo to žádné soubory. Pomohl restart, funguje.
No k tomu převodu jsem právě trochu skeptický. k3dAR tu psal, že s tím moc dobrou zkušenost nemá. Spíše to předem připravit, ne?
btrfs-convert
. Je lepší si nechat na začátku disku nealokované místo, kde po instalaci vytvoříš ten správný filesystém. Původní oddíl pak můžeš odstranit a nový zvětšit na celý disk (proto to místo na začátku).
install_items+=" /.root.key " add_dracutmodules+="resume" add_devices+=" /dev/mapper/by-label/SWAP "Pripadne swap partitionu popisat podla /dev/disk/by-uuid/... alebo hocijak inak.
Díky, podívám se na to.
To odemykání by bylo možná lepší pořešit podle Andreje.
/dev/urandom
. (Takhle to má ve „výchozím“ nastavení Gentoo.)
Já osobně kdybych dělal swap, tak jen kvůli uspávání na disk. Kvůli ničemu jinému.
Toto je cca 10. iterace téhož / podobného dotazu, že jo. Odpověď je pořád stejná:
Nedělit, nedělit, nedělit. Dělení je vždycky špatně. Když si uživatel myslí, že chce dělit, pak je na návrhu celého „úložiště“ něco špatně.
Kdyžtak násobit (Btrfs RAID a spol.), ale rozhodně nedělit.
Jak to zašifrovat a neoddělovat /boot
? To už se tu přece řešilo nekonečno-krát: GRUB umí bootovat z LUKS bez problému už asi 5+ let.
LUKS má víc slotů na klíče nebo hesla. Tím se dá zařídit, že se heslo zadá jenom jednou — pro GRUB — a pak už se vše odemkne automaticky, když bootuje kernel a chce šifrovaný root připojit. Stačí mít v initramfs / initcpio soubor s klíčem pro ten LUKS a patřičně nastavit /etc/crypttab
. To je celé. Protože initramfs je na šifrovaném /boot
, klíč je v něm v bezpečí a načte ho společně s initramfs GRUB — na základě uživatelova hesla (jiný key slot).
Pro každé distro je na tohle^^^ několik howto.
Když jsem tento dotaz pokládal, tak jsem chtěl na jeho konec napsat:
@Andrej:
Já vím, nedělit, nedělit, nedělit!
Řeknu ti, co mě k dělení vede a třeba mi to vyvrátíš. Chci disk rozdělit proto, protože chci dát data na sólo oddíl, abych při přeinstalaci systému nemusel znovu překopírovávat všecha svoje data na ten disk. Prostě by tam byl šifrovaný oddíl, kterého bych se ani nedotkl a jen bych na volné místo znovu nainstaloval systém (LUKS+btrfs).
Včera jsem zkoušel Qubes. Zkoušel jsem jej na plotnovém disku. Bylo to hrozně pomalé. Na webu Qubes důrazně doporučují použít SSD. To sice mám, ale co se týká rychlostí, tak asi jen ~ 540/520 MB/s. To na klasické distro bohatě stačí, ale pro ten Qubes uvažuji o 256 GB NVMe disku ~ 3500/1300 MB/s. Tam by se data nevešla, ale mohl bych je dát na ten SSD a pak je připojovat do /data. Takže by nešlo o oddělené /home. No a teď mi vysvětli, co je na tom špatného?
Uvažoval jsem totiž tak, že kdybych ten SSD měl jako subvolume pro /home (@home), tak bych nevěděl co si počít při přeinstalaci? Nevěděl bych (pokud to lze), jak pak k systému @home přiřadit a taky by v @home byla data programů, které by ještě ani nebyly nainstalovány a nejsem si jist, jestli bych to uměl nějak solidně pořešit?
Jak to zašifrovat a neoddělovat /boot? To už se tu přece řešilo nekonečno-krát: GRUB umí bootovat z LUKS bez problému už asi 5+ let.Tu sa skôr natíska otázka, ako pohodlne zabezpečiť že ten GRUB nebude kompromitovaný, a neodchytí prvé heslo. Už sú hotové nástroje ktoré vygenerujú kľúč, napchajú ho do TPM, podpíšu ním GRUB, zapnú SecureBoot a vyhodia cudzie kľúče ktoré tam nemajú čo hľadať? Rád by som si také hotové nástroje pozrel.
Myslíš tohel? Akorát nevím, zda je to "pohodlné".
Jsem zapomněl, že to vyžaduje oddělený /boot. Pokud to ale lze obejít pouhým nadzvednutím baterie na desce, tak je to z mého pohledu na nic.
Jo, a nebo bych mohl komp zazdít neznámo kam a husím krkem jen přivést kabely k napájení, netu a monitoru, ne? A kdyby to doma po příchodu vypadalo jako na staveništi, tak by bylo jasné, že komp někdo zkompromitoval
Ahoj Aleši,
jen se tě chci zeptat. Když bych měl systém v pc i nb na ext4 a data bych měl na jiných oddílech naformátovaných na Btrfs, takže by ta data nebyla v /home na ext4 a zálohy těch dat bych měl na dalších discích, které by taky byly naformátovány na Btrfs. Bylo by to tak pro ta data OK? Jde mi teď pouze o cow. Vyhnul bych se tak silent data corruption?
Díky oběma
Díky
/dev/disk/by-partlabel
.
Takže jsem se rozhodl, že zatím na Btrfs naformátuji pouze disky a oddíly s daty a systémové ponechám na ext4, protože zatím je pro mne nedosažitelné nainstalovat systém s neodděleným /boot nad LUKS+Btrfs. Budu s tím zatím experimentovat a až se to vystříbří, tak pak, pokud budu s Btrfs spokojen, jej použiju i pro OS's.
Takže vyřešeno/nevyřešeno.
EFI oddíl dělám. Respektive ten skript, co pro mě laskavě napsal k3dAR. Ale funguje mi právě jen s ext4. Když jsem v něm změnil ext4 na btrfs, tak po instalaci, právě při samostatné instalaci GRUBu to vytuhlo. Budu si s tím teď prostě "hrát" a až to poladím, tak pak přijde na řadu Sicherboot. Chce to postupně, no.
No s tím jsem tě právě nechtěl obtěžovat. Ale kdybys to udělal, tak to bys byl borec :) A úplně nejlepší by bylo, kdybys tam udělal volitelné LVM.
BTW: na nějakém fóru Mintu jsem taky našel nějaký skript, ale ten byl mnohem delší než ten tvůj a vůbec jsem se v něm neorientoval. Když jej najdu, odkážu.
A ještě jedna věc. Pokud se tedy do toho opravdu pustíš, tak by bylo asi dobré tam zakomponovat vytváření subvolumes a nastavení quotas. Když jsem si informativně nainstaloval to openSUSE, tak to instalátor vytvořil takto:
Akorát jsem se nepodíval na nastavení quotas. Pokud bys ale chtěl, tak to znovu nainstaluji na 100 GiB oddíl, protože takový bych v reálu použil a můžu ti sem hodnoty quotas dát??
Ještě mě napadlo:
Instaluji si Mint i na flešku, která má kapacitu 32 GB, USB 3.0. Nic bych nedělil. Udělal bych pouze EFI 256 MB(?) a zbytek místa by byl pro systém. Je vhodné použít Btrfs? Ptám se kvůli snapshotům.
To jsem si myslel. Dík
As another example, the widely used USB flash or SD cards use a translation layer between the logical and physical view of the device. The data lifetime may be affected by frequent plugging. The memory cells could get damaged, hopefully not destroying both copies of particular data in case of DUP.
A pokud vím, tak každá buňka má pouze omezený počet přepsání, kdežto pouhé čtení je v pohodě.
To má i SSD.
No to mám právě já, flešku s MLC :)
... ale v pripade USB donglu se prepisujou porad stejny bunky ...
Tady Aleš píše:
... jelikož neustále převaluje datové bloky z jedné strany na druhou.
Nebylo by tedy řešením použít právě Btrfs?
In practice, flash file systems are used only for Memory Technology Devices (MTDs), which are embedded flash memories that do not have a controller. Removable flash memory cards and USB flash drives have built-in controllers to manage MTD with dedicated algorithms, like wear leveling, bad block recovery, power loss recovery, garbage collection and error correction, so use of a flash file system has limited benefit.
A další věc je, že když už by sis chtěl nějaký ten Flash file system zkusit, tak tvůj hw jej nemusí plně podporovat. Což mě v souvislosti s tím, co jsem uvedl výše (citace v angličtině) vede k tomu, že lze klidně na takovouto flešku použít ext4.
~$ sudo mkfs.f2fs -f -l WEDOS /dev/sdb F2FS-tools: mkfs.f2fs Ver: 1.11.0 (2018-07-10) Info: Disable heap-based policy Info: Debug level = 0 Info: Label = WEDOS Info: Trim is enabled Info: [/dev/sdb] Disk Model: DISK 1.001.00?? Info: Segments per section = 1 Info: Sections per zone = 1 Info: sector size = 512 Info: total sectors = 30752848 (15016 MB) Info: zone aligned segment0 blkaddr: 512 Info: format version with "Linux version 5.3.0-26-generic (buildd@lgw01-amd64-039) (gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04.1)) #28~18.04.1-Ubuntu SMP Wed Dec 18 16:40:14 UTC 2019" Info: [/dev/sdb] Discarding device Info: This device doesn't support BLKSECDISCARD Info: This device doesn't support BLKDISCARD Info: Overprovision ratio = 1.640% Info: Overprovision segments = 249 (GC reserved = 129) Info: format successful
Tiskni
Sdílej: