Na YouTube lze zhlédnout nový celovečerní dokumentární film The Story of VS Code | Official Documentary věnovaný Visual Studio Code.
Farid Abdelnour se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 26.08.0 editoru videa Kdenlive (Wikipedie). Ke stažení také na Flathubu.
Byla vydána nová stabilní verze 8.2 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 152. Přehled novinek i s náhledy v příspěvku na blogu.
Byla vydána nová stabilní verze 4.0 svobodného multiplatformního softwaru pro editování a nahrávání zvukových souborů Audacity (Wikipedie). S rozhraním přepsaným do Qt. Přehled novinek také na YouTube. Ke stažení je oficiální AppImage. Zatím starší verze Audacity lze instalovat také z Flathubu a Snapcraftu.
NVIDIA kupuje Hugging Face za 12,93 miliardy dolarů.
Předobjednat si lze nový jednodeskový počítač Arduino VENTUNO Q s předinstalovaným Ubuntu. S 16 GB LPDDR5 a 64 GB eMMC. Pro lokální LLM, agentní AI, počítačové vidění, robotiku…
Hexpair není nejlepší HEX editor na světě a ani se o to nesnaží. Zato je k dispozici kdykoliv a kdekoliv – všude tam, kde máte svůj Vim. Vznikl jako hobby projekt před pár měsíci a dospěl do stavu, kdy by mohl být užitečný širší komunitě. Přepnout do HEX režimu se dá i uprostřed rozdělané práce: Soubor, který už máte otevřený běžným vim file.md, jedním příkazem přepnete do HEX editoru a dalším příkazem ho můžete vrátit zpět do textu. Kurzor přitom
CERN dlouhodobě používal vlastní sestavení RHEL, ze kterého přešel na CentOS Stream. Federico Vaga a Nikos Tsipinakis ale nyní v přednášce na MiniDebConf Winterthur 2026 popisují plán probíhajícího přechodu na Debian pro řízení akcelerátorů. Důvodem k opuštění CentOS Stream jsou zachování zpětné kompatibility se starším hardwarem, kterou Red Hat narušuje, když tlačí sestavení balíčků pro novější verze architektury (x86-64), a nedostatečné nástroje pro sestavování vlastních balíčků a repozitářů.
UZDoom (Wikipedie), tj. fork GZDoom, byl vydán ve verzi 5.0.0. Videopředstavení na YouTube. Podrobný přehled novinek v Changelogu.
bios_grub).
| MBR | ....... | oddíl 1 | oddíl 2 | ... každý oddíl by měl být: |BOOT_RECORD;SOUBOROVÝ SYSTÉM|
Co se zarovnavani tyce, sam vidis, ze se jako boot sektor nepouziva pouze prvni sektor, ale rovnou se zarezervuje neco kulateho. Odjakziva.No jo, ale je to kulaté 4 MiB? Protože SSDčka mají klidně takhle velké erase bloky.
Když jsem si kupoval poslední desktop, tak tam byl disk s fyzickými 4KB sektory, navíc jsem si chtěl vyzkoušet UEFI, takže jsem se tímto tématem zabýval více, než mi bylo milé. Obzvláště proto, že různé nástroje se chovají různě a všelijaké návody opisují bezostyšně mezi sebou, aniž by uvedly původní zdroj, takže člověk má problém zjistit, co je pravda a co je neznalost autora.
Ale zpět k MBR. Bootování z MBR je silně zvyková záležitost bez formální specifikace. Takže jestli na počátku každého oddílu musí být sektor vyhrazený pro zavaděč, není definováno. Je to ale zvyk, který vychází z reálií PC/AT se souborovým systémem FAT a operačním systémem DOS. Přečtěte si o Volume Boot Record.
Například ext2 rezervuje prvních 1024 B. Obecně se většina postarších souborových systémů snaží nesahat na prvních 512 B.
Co jsem si ze svého průzkumu odnes, je, že na magnetických pevných discích dnes nemá smysl zarovnání řešit, protože zařízení mají bloky maximálně do 4 KB a souborové systémy naopak ne této velikosti začínají.
Samozřejmě na SSD s erase bloky ve stovkách kilobajtů a regiony i v jednotkách megabajtů to už problém je, ale to je třeba se podívat na každý souborový systém zvlášť. Například u LVM i ext lze v tomto směru nastavit skrze násobky původně určené pro RAID 5, jak popisuje ve starším zápisku Ted Tso. Poslední dobou je snaha toto zautomatizovat, ale protože žádné SSD nemám, tak jsem se o to nezajímal.
Například ext2 rezervuje prvních 1024 B. Obecně se většina postarších souborových systémů snaží nesahat na prvních 512 B.To je přesně to, co řeším - proč se zarovnávají oddíly, když souborový systém stejně nezačíná na začátku oddílu. Podle té dokumentace ext2 to vypadá, že souborový systém začíná od začátku oddílu, ale první bajty nechává být => fs má disk rozdělený po blocích od začátku oddílu, jen první blok či dva nechává být.
tj. není to takto: |512 B boot record|blok1|blok2|... ale takto: |blok1|blok2|blok3|..., 512 B boot record je uvnitř bloku 1Tím pádem bude stejné chování i u oddílů GPT, protože to místo na začátku je vlastnost souborového systému (pokud se takto souborový systém chová). Tak doufám, že jsem to správně pochopil. Děkuju všem za vysvětlení.
proč se doporučuje mít první oddíl na 2048. sektoru?A kdo to doporucuje? To je jen svevolne rozhodnuti autoru fdisk od verze 2.17.2, kdyz pridali podporu pro 4k AF disky, oni si proste mysli, ze je to pro vas dobre. Defautni nastaveni ale nemusite pouzit. Castecne to ma asi oporu v HW reseni, disky to urcite interne adresuji ve vetsich blocich, az ten 1M by me neprekvapil.
Tiskni
Sdílej: