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.
Git není efektivní při verzování velkých binárních souborů – změna bitu znamená jeho uložení v novém souboru, nebo náročné výpočty rozdílů souborů. Tuto slabinu řeší nástroj Bup pomocí metody „rolling checksums“ a adresování obsahu souboru. Bup tak de facto dělí soubory na osmikilobytové úseky, takže se při změně jednoho bitu nově ukládá pouze příslušný úsek, jeho následník a seznam úseků.
Tiskni
Sdílej:
Neni? Ja myslel, ze Git uklada kazdou novou verzi jako cely soubor, a ne jako rozdil, jak to delaji nektere jine VS.To je právě jenom konceptuální pohled. V reálu ty celé soubory komprimuje pomocí binárních rozdílů. Git je v tomhle zprvu o něco složitější na pochopení, jak už jednoduché a elegantní věci bývají :). Optimalizace se v něm řeší opravdu... jako optimalizace a ne jako jádro problému (což není), jako se to dělá jinde.
average size of 8192 bytesKdyby to mělo 8MB chunky, tak by to moc k použití nebylo, osobně tak 10x8MB binárky snad ani nemám (flight-gear má sice asi 250MB komprimovanou instalačky, ale to jsou vše textury). Jinak imho by bylo efektivnější oba soubory od sebe odečíst a na místech rozdílu získat tímto nenulové hodnoty. Nulové by se jednoduše odřízly nebo zkomprimovaly něčím triviálním jako RLE. Osobně se mi ale zdá, že binárka se bude blbě diffovat, protože se i drobnou změnou mění celé adresy skoků dále v souboru. Lepší je imho gitovat zdrojáky
.
.
V takovém případě si dokážu docela dobře představit využití 8MB chunků.
PS: Ale mám takové podezření, že ten kdo pracuje s gigabajtovými obrázky, tak velikost disku nejspíš neřeší.
PS: Ale mám takové podezření, že ten kdo pracuje s gigabajtovými obrázky, tak velikost disku nejspíš neřeší.Tak to pozoor. ono se to dlouho přetahuje po síti, a hrozně blbě se to ve velkých kvantech zálohuje.