Společnost comma.ai po třech letech od vydání verze 0.9 vydala novou verzi 0.10 open source pokročilého asistenčního systému pro řidiče openpilot (Wikipedie). Zdrojové kódy jsou k dispozici na GitHubu.
Ubuntu nově pro testování nových verzí vydává měsíční snapshoty. Dnes vyšel 4. snapshot Ubuntu 25.10 (Questing Quokka).
Řada vestavěných počítačových desek a vývojových platforem NVIDIA Jetson se rozrostla o NVIDIA Jetson Thor. Ve srovnání se svým předchůdcem NVIDIA Jetson Orin nabízí 7,5krát vyšší výpočetní výkon umělé inteligence a 3,5krát vyšší energetickou účinnost. Softwarový stack NVIDIA JetPack 7 je založen na Ubuntu 24.04 LTS.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) spolu s NSA a dalšími americkými úřady upozorňuje (en) na čínského aktéra Salt Typhoon, který kompromituje sítě po celém světě.
Společnost Framework Computer představila (YouTube) nový výkonnější Framework Laptop 16. Rozhodnou se lze například pro procesor Ryzen AI 9 HX 370 a grafickou kartu NVIDIA GeForce RTX 5070.
Google oznamuje, že na „certifikovaných“ zařízeních s Androidem omezí instalaci aplikací (včetně „sideloadingu“) tak, že bude vyžadovat, aby aplikace byly podepsány centrálně registrovanými vývojáři s ověřenou identitou. Tato politika bude implementována během roku 2026 ve vybraných zemích (jihovýchodní Asie, Brazílie) a od roku 2027 celosvětově.
Byla vydána nová verze 21.1.0, tj. první stabilní verze z nové řady 21.1.x, překladačové infrastruktury LLVM (Wikipedie). Přehled novinek v poznámkách k vydání: LLVM, Clang, LLD, Extra Clang Tools a Libc++.
Alyssa Anne Rosenzweig v příspěvku na svém blogu oznámila, že opustila Asahi Linux a nastoupila do Intelu. Místo Apple M1 a M2 se bude věnovat architektuře Intel Xe-HPG.
EU chce (pořád) skenovat soukromé zprávy a fotografie. Návrh "Chat Control" by nařídil skenování všech soukromých digitálních komunikací, včetně šifrovaných zpráv a fotografií.
Byly publikovány fotografie a všechny videozáznamy z Python konference PyCon US 2025 proběhlé v květnu.
V testech výkonu souborových systémů si ve srovnání s Ext4 a Btrfs překvapivě dobře vedl Reiser4, který ještě ani není začleněn do hlavního jádra. Podrobnosti na Phoronixu.
Tiskni
Sdílej:
There are many more file-system / disk tests that we normally run in such articles, but these other tests were unable to successfully run on the Reiser4 file-system without crashing.Takže na vině bude asi opravdu Reiser4.
Dostal 25 rokov na tvrdo, takže jedine čo by ho dostalo z väzenia je NASA, alebo CIA, škoda génia, ten by to dotiahol fakt ďaleko.A co este jeho zeny...
Coz se o reiser3.6 rici neda, ten funguje opravdu spolehlive.To teda rozhodně ne vždycky...
Na kupu malých souboru je ReiserFS fakt dobrý a ext3 docela nevhodné.To hodně záleží na tom, co s těmi soubory chcete dělat. Často to vyjde tak, že ReiserFS sice hezky šetří prostorem, ale operace jsou pomalejší. Také se často liší chování v syntetických benchmarcích a v reálném provozu. Svého času jsem docela důkladně měřil výkon filesystemů, když jsem vymýšlel, jak by měl Sherlock ukládat na disk stovky milionů malých objektů, a Reiser3 v tomto testu prohrál kalhoty.
Na stovky milionů malých objektů by má inženýrská intuice favorizovala nějakou databázi. Jak to dopadlo u Sherlocka?Na Sherločí poměry jsou databáze také příliš pomalé. Dopadlo to tak, že se všechny objekty appendují do jednoho velikánského souboru a ten se čas od času setřepe. Je to v podstatě jediný způsob, jak zařídit, aby šlo rychle procházet všechny objekty (což Sherlock dost často potřebuje).
Mám podezření, že určitých okolností se "ztratí" obsah adresáře. Nepomůže ani sync ani remount. Teprve po fyzickém odpojení, resp. vypnutí a zapnutí disku, se data opět objeví.Co se stane, když se vysypou všechny buffery a cache zapsáním 3 do
/proc/sys/vm/drop_caches
? Tím by se zjistilo, jestli data na disku opravdu jsou nebo nejsou.
Jedním z možných (a velmi pravděpodobných) vysvětlení, proč některé testy neběžely, je prostě fakt, že žádný Reiser4 patch pro kernel 2.6.33 neexistuje. (Mluvím o situaci k tomuto datu, tedy 3. 3. 2010.)
Zen kernel je ruská ruleta pro otrlé. Autoři tohoto projektu klidně vydali neoficiální a nebezpečný patch pro kernel 2.6.32. Tím přímo ohrozili data spousty důvěřivých uživatelů v době, kdy ještě žádný oficiální patch (od Edwarda Shishkina) pro 2.6.32 neexistoval. Málokoho by v tu chvíli napadlo, že v tom je nějaká levárna a že vlastně používá kód pochybného původu.
Nechápu, proč někdo používá Zen patchset pro benchmark Reiser4, navíc ještě s nepodporovanou verzí kernelu. Může tohle dopadnout jinak, než že to bude nestabilní? Mám dojem, že Phoronix i Zen patchset dělají jinak skvělému souborovému systému medvědí službu tím, že ho šíří a testují v nepoužitelné zmrzačené podobě.
Testování souborového systému pouze na SSD je tak trochu sci-fi nápad, který se většiny uživatelů zatím příliš netýká. (Až bude SSD tak spolehlivé jako klasický disk a až nebude stát desetinásobek, určitě bude všechno jinak. Ale dnes to nebude.) Testy na klasických discích by rozhodně nebyly k zahození. Mě Reiser4 příjemně překvapil nejen na pevném disku, ale i na DVD-RAM. Ve srovnání s často používaným UDF má nesrovnatelně rychlejší mount/unmount a i zápis je mnohem rychlejší, zejména při přepisování souborů.
Ve srovnání s často používaným UDF má nesrovnatelně rychlejší mount/unmount a i zápis je mnohem rychlejší, zejména při přepisování souborů.Platí možná tak cca do 80% zaplnění disku. Pak výkon reiser4 rapidně padá.
Pokud pouze přidávám soubory, není absolužně žádný důvod, aby při víc než 80% zaplnění významně klesal výkon. (A opravdu neklesá.)
Pokud mám například 90% zaplnění a intenzivně čtu, mažu, přidávám a přepisuji spousty souborů na různých místech, znamená to, že dělám něco, na co příslušná technologie není navržená. Řekl bych, že v takové situaci UDF padá ještě rapidněji než Reiser4. Neznám souborový systém, který by se s tímhle porval zcela bez problémů. Bavíme se tady o seek time řádově 100 milisekund a víc.
Možná, že NILFS2 by takovou situaci zvládl lépe než Reiser4, ale ještě jsem to nezkoušel. Ani to příliš zkoušet nehodlám, protože opotřebení média i mechaniky postupuje v takových situacích příliš rychlým tempem. Takové experimenty už pak se zálohováním nemají v podstatě nic společného.
UDF nemá ani wear leveling, ani log structured zápis. Paradoxně je tedy pro přepisovatelná média naprosto nevhodný, i když lidové pověry tvrdí opak. V porovnání s Reiser4 nemá žádnou výhodu, nemluvě o NILFS2, který implementuje obě zmíněné důležité vlastnosti.
Narážka se týkala jak Phoronixu, tak i Zen patchsetu.
Pokud by autoři Zen patchsetu prostě vzali Reiser4 a další patche v jejich oficiální (dá-li se to tak nazvat) podobě a přidali je do svého patchsetu, je to naprosto v pořádku. Každý uživatel ví, že jsou to experimentální patche. Většina lidí některé z nich zná a má jasno v tom, co se dá očekávat.
Záležitost, která se stala u 2.6.32, rozhodně korektní nebyla. Zen kernel měl Reiser4 patch víc než o měsíc dříve, než Edward Shishkin vydal svůj oficiální patch. Že je Reiser4 v Zen kernelu poškozený a amatérsky přiohnutý, jen aby se s kernelem 2.6.32 zkompiloval, bez ohledu na funkčnost, to se vědělo prakticky ihned po vydání příslušného Zen patchsetu. A co udělal projekt Zen? Nic. Autoři se ani neobtěžovali napsat na své stránky varování ohledně Reiser4, aby uživatelé s upgradem počkali a zůstali u 2.6.31, dokud nebude oficiální patch k dispozici.
Samozřejmě, že autor free software nemá v tomto směru absolutně žádné povinnosti. Ale nějaká ta základní slušnost by neuškodila.
Ano. Rozhodně a jednoznačně. Vystavit uživatele riziku ztráty dat, které se dalo snadno předvídat, je neomluvitelné. Odložit upgrade kernelu o měsíc je proti tomu zcela nepodstatný problém.
Nepochybuji o tom, že read-only přístup fungoval. V takovém případě tam mělo být od začátku velké tučné varování, případně hack, který R/W přístup zakáže.
Jeff Bonwick, vývojář Solarisu a gatekeeper verze 2.5, kdysi poznamenal velmi trefně „mistakes will happen; negligence cannot“.
Distribuce amatérsky poškozené verze souborového systému není mistake, ale negligence.
Nebýt těch benchmarků na Phoronixu, nikdy bych o tomhle nepsal. Je to minulost, stalo se. Věřím, že se z toho všechny zúčastněné strany poučily. Tlustá čára, hotovo... Jenže pak přijde Phoronix, vezme Reiser4 z téhož pochybného zdroje, provede jakýsi benchmark a diví se, že (jaké to překvapení!) některé části benchmarku nefungují. To mi připadá jako dost nekorektní přístup k věci, který dělá špičkovému souborovému systému medvědí službu. Vytváří totiž FUD.
V okamžiku, kdy má někdo pochybnosti o spolehlivosti souborového systému, je mu zoufale jedno, jestli je o 10% rychlejší nebo dvojnásobně rychlejší. Prostě ho nepoužije. Tím začíná Quality Death Spiral, o které píše Jeff Bonwick. Bylo by smutné, kdyby v té spirále skončil Reiser4.
Možná to bude jen další z amatérských zásahů ze strany autorů Zen patchsetu.
Tuxonice i BFS mi fungují. Nepoužívám ovšem žádný Zen patchset. Nejspíš i tyto patche dokázali autoři Zen patchsetu nějak poškodit. Jiné vysvětlení mě nenapadá.
Myslím si, že mezi nefunkčním BFS, kvůli kterému „popuze“ zatuhne systém, a nefunkčním Reiser4, který může (hypoteticky) poslat celý uživatelův oddíl do kytek, je propastný rozdíl.
s/popuze/pouze/
"Spad" is abbreviation for Czech Systém pro Psychopaty A Debily (System for psychopaths and idiots).Co jiného taky čekat od BLEKa