Byla vydána verze 7.0 open source platformy pro správu vlastního cloudu OpenNebula (Wikipedie). Kódový název nové verze je Phoenix. Přehled novinek v poznámkách k vydání v aktualizované dokumentaci.
E-mailový klient Thunderbird byl vydán ve verzi 140.0 ESR „Eclipse“. Jde o vydání s dlouhodobou podporou, shrnující novinky v upozorněních, vzhledu, správě složek a správě účtů. Pozor, nezaměňovat s průběžným vydáním 140.0, které bylo dostupné o týden dříve.
Organizace Video Games Europe reprezentující vydavatele počítačových her publikovala prohlášení k občanské iniciativě Stop Destroying Videogames.
Společnost Raspberry Pi nově nabzí Raspberry Pi Camera Module 3 Sensor Assembly, tj. samostatné senzorové moduly z Raspberry Pi Camera Module 3.
Cathode Ray Dude v novém videu ukazuje autorádio Empeg Car (později Rio Car) z let 1999–2001. Šlo o jeden z prvních přehrávačů MP3 do auta. Běží na něm Linux. Vyrobeno bylo jen asi pět tisíc kusů, ale zůstala kolem nich živá komunita, viz např. web riocar.org.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.7.
Wayland byl vydán ve verzi 1.24.0. Jde o menší vydání po více než roce. Více funkcionality bývá přidáváno v průběžných vydáních Wayland Protocols.
Textový editor Geany byl vydán ve verzi 2.1. Jde o udržovací vydání po bezmála dvou letech. Obsahuje drobná vylepšení vyhledávání, aktualizace podpory zvýrazňování syntaxe a dále převážně opravy chyb.
Byly zveřejněny videozáznamy, dostupné také s prezentacemi přímo z programu, a také fotogalerie z open source komunitní konference DevConf.CZ 2025 konané od 12. do 14. června v Brně.
Navigace se soukromím CoMaps postavena nad OpenStreetMap je nově k dispozici v Google Play, App Store i F-Droid. Jedná se o komunitní fork aplikace Organic Maps.
Občas není od věci vyslovit něco, za co se upaluje nebo ukamenovává. Nic není totiž tak jednoduché, aby byla pravda vždy jediná a na první pohled zřejmá.
V návaznosti na diskuse ohledně chování programu mount ve vztahu k filesystému ISO 9660 jsem ho rozhodl přesvědčit se, jak to doopravdy je. A je to v podstatě tak, jak jsem si myslel.
Spustíme-li program mount
(s požadavkem připojit konkrétní FS), záleží na tom, zda existuje příslušná položka v /etc/fstab
a jaké parametry mount
dostane. Konkrétně třeba typ FS - největší prioritu má hodnota zadaná z příkazové řádky, pak následuje hodnota ze souboru, a teprve nakonec by se mount pokoušel o detekci filesystému.
Podobně je to i s volbami pro připojení. Tedy i s tím, zda se bude připojovat RO nebo R/W. Důležité je, že R/W je výchozí volba, a že detekce typu systému nemá žádný vliv na to, jak se filesystém připojí. Jinými slovy, že detekce (nebo jiné určení) filesystému ISO 9660 nezpůsobí, že by mount
automaticky přepnul na RO. Stejně tak na to nemá vliv zařízení - bylo by to nesmyslné a nesystematické, znamenalo by to mj. pořádné nabobtnání programu.
Program mount
tedy, v okamžiku kdy zná všechny potřebné parametry, volá syscall mount
, který provede (samozřejmě v jádře) samotné připojení. Jádro zjistí typ filesystému a zavolá příslušnou funkci v ovladači tohoto filesystému. A zde je to klíčové - ovladač pro ISOFS totiž bez dalšího natvrdo nastavuje režim na RO (bez ohledu na to, jaké parametry dostal). Není sám, podobně postupuje třeba ovladač NTFS, pokud nebyl zkompilován s podporou zápisu.
Po připojení se běh vrací zpět do programu mount, a ten (pokud bylo připojení úspěšné) zapíše soubor /etc/mtab
. Použije k tomu ty parametry, které posílal do jádra - nezajímá ho, jaké změny jádro provedlo (ostatně by si to musel zjistit, např. přes PROCFS, protože je přes syscall zpět nedostane).
Co z toho vyplývá? Že v /etc/mtab
(pokud je vytvářen přímo programem mount
) jsou parametry poskytnuté programu mount
, kdežto v /proc/mounts
jsou parametry, s jakými jádro filesystém připojilo. Proto ten rozpor.
Ještě zbývá vysvětlit rozpor mezi filesystémem připojeným ad hoc (na základě parametrů poskytnutých uživatelem) a systémem připojeným podle záznamů v souboru /etc/fstab
. Záznamy do tohoto souboru dnes dělá většinou démon HAL (dříve třeba program kudzu
apod.), který detekci schopností zařízení provádí (s jakou kvalitou, to nechme stranou). Proto, rozpozná-li RO zařízení, v řádku pro příslušný filesystém se objeví tato volba.
Doufám, že tento stručný přehled ukončí nesmyslné spory o to, co jaká komponenta dělá nebo má dělat. Já osobně považuji použitou koncepci za poměrně rozumnou, i když někdo může mít jiný názor.
Tiskni
Sdílej: