V aktuálním příspěvku na blogu počítačové hry Factorio (Wikipedie) se vývojář s přezývkou raiguard rozepsal o podpoře Linuxu. Rozebírá problémy a výzvy jako přechod linuxových distribucí z X11 na Wayland, dekorace oken na straně klienta a GNOME, změna velikosti okna ve správci oken Sway, …
Rakudo (Wikipedie), tj. překladač programovacího jazyka Raku (Wikipedie), byl vydán ve verzi #171 (2024.04). Programovací jazyk Raku byl dříve znám pod názvem Perl 6.
Společnost Epic Games vydala verzi 5.4 svého proprietárního multiplatformního herního enginu Unreal Engine (Wikipedie). Podrobný přehled novinek v poznámkách k vydání.
Byl vydán Nextcloud Hub 8. Představení novinek tohoto open source cloudového řešení také na YouTube. Vypíchnout lze Nextcloud AI Assistant 2.0.
Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
Během posledního týdne nevyšly žádné nové verze. Začleňování do 2.6.23 stále probíhá a do hlavního repozitáře se valí další patche; vizte níže.
Já si jen moc a _moc_ přeji, abychom měli dvě stabilní verze za sebou. Mám pocit, že 2.6.22 má dobrý potenciál a nerad bych měl hned potom další 2.6.21.
Sysfs se nikdy nesnažil být ABI/API v běžném slova smyslu - některé části jsou jen trochu hezčí "kernel dump" :)
Musíte se tam řídit _velmi_ specifickými pravidly, abyste získali informace způsobem, který v další verzi jádra, nebo dokonce o vteřinu později, nepřinese neočekávané výsledky.
-- Kay Sievers
Podle mého názoru je každý hibernační systém, který nebere ohled na uvedené požadavky, odsouzen k neúspěchu. Navíc se některými z nich neřídí ani existující systémy, takže je všechny považuji za nedokončené. Z toho důvodu bych daleko více uvítal nápady, které by nám umožnily, více či méně evolučním způsobem, vylepšit stávající systémy, místo pokusů o jejich celkové nahrazení něčím úplně novým.
Od minulého týdne bylo do repozitáře hlavního jádra zařazeno dalších 2600 sad změn. Začíná být jasnější, jak bude 2.6.23 vypadat; jádro bude obsahovat:
Změny viditelné vývojáři jádra:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
char *kstrndup(const char *s, size_t max, gfp_t gfp);
Duplikuje řetězec podobně jako strndup() v uživatelském prostoru.
Za zmínku stojí i pár věcí, které v 2.6.23 nebudou. První z nich je patch s kontejnery procesů - ještě není tak docela hotový. Některé další funkce (například skupinové plánování CFS) na kontejnery procesů čekají, takže je pravděpodobné, že bude kód připraven pro začlenění v 2.6.24.
Další velká věc, na kterou se nedostane, jsou clockevents, dynamický tik a časovače s vysokým rozlišením pro x86_64. Autoři už patch považují za připravený, ale po potížích, které způsobilo začlenění verze pro i386 v 2.6.21, mají někteří vývojáři pocit, že by se tentokrát mělo postupovat opatrněji. Výsledkem byla poněkud otrávená diskuze v konferencích a rozhodnutí patche lépe rozdělit, aby mohly být pečlivě prohlédnuty v rámci dalšího vývojového cyklu.
Zařízení universal serial bus (USB) [univerzální sériová sběrnice] obyčejně nepodléhají nějakým bezpečnostním opatřením. Může-li uživatel USB zařízení strčit do počítače, předpokládá se, že je oprávněn to udělat. Existují však situace, ve kterých přidělává zapojování USB zařízení lidem vrásky; obvykle se jedná o strach z kopírování obchodních tajemství na nějaké USB zařízení, které lze z budovy snadno odnést. Většinou se takové hrozby řeší zákazem (nebo pokusem o zákaz) USB zařízení nebo prostě zapatláním USB portů lepidlem.
Bezdrátové USB situaci mění. Tento protokol umožňuje vzdálené připojení USB zařízení, takže není potřeba mít kabel, o který všichni zakopávají. Zatímco běžný uživatel notebooku by si pravděpodobně všiml, kdyby mu útočník zastrčil do USB portu kabel od svojí klávesnice, v případě využití bezdrátového USB by mohl útočník klávesnici připojit, aniž by se přiblížil. Je zřejmé, že je potřeba nějaká bezpečnostní vrstva. Specifikace bezdrátového USB tuto potřebu předvídala, takže nabízí celou řadu technik s množstvím zkratek pro zajištění 1) autentizace jak hostitele, tak zařízení a 2) dostatečného šifrování bezdrátové USB komunikace, aby nemohla být odposlouchávána.
Iñaky Perez-Gonzalez pracuje na podpoře bezdrátového USB pro Linux. Došel k závěru, že nehezké detaily autentizace bezdrátového USB patří do uživatelského prostoru; jádro nemůže (samo o sobě) udržovat přehled o tom, která zařízení se smějí k systému připojit. Je však na jádře, aby implementovalo autorizační stranu rovnice: neautorizované bezdrátové USB zařízení by nemělo mít možnost s hostitelským systémem jakkoliv komunikovat. Iñakyho odpověď na otázku autorizace je tato sada patchů pro subsystém USB.
Patche přidávají do struktury usb_device tři nové příznaky: wusb, authorized [autorizované] a authenticated [autentizované]. První značí, že se jedná o bezdrátové zařízení, a poslední (který ještě není používán) říká, že zařízení prošlo autentizací. Prostřední ukazuje, že se smí se zařízením mluvit. Dokud není zařízení autorizováno, nepřečte si jádro ani jeho konfiguraci (aby zjistilo, jaké styčné body poskytuje); v tu chvíli může dojít pouze k autentizaci. Kvůli tomu jsou různá místa v USB stacku změněna, aby kontrolovala příznak authorized, než povolí přístup.
Uživatelský prostor je do obrazu uveden pomocí obvyklého oznámení o připojení zařízení a vytvoření příslušného sysfs stromu. Sysfs adresáře jednotlivých USB zařízení mají nový atribut authorized, který odpovídá internímu příznaku; uživatelský prostor může povolit přístup k zařízení zapsáním nenulové hodnoty do atributu. Taková infrastruktura postačuje k tomu, aby si mohl nějaký uživatelský démon všimnout nového bezdrátového USB zařízení, projít databázi známých zařízení a případně uživateli předhodit dialogové okno - a rozhodnout se, jestli by mělo být zařízení povoleno se připojit nebo ne.
Iñaky posunul věci ještě o krok dál, když si uvědomil, že tento autorizační mechanismus nemusí být omezen jen na bezdrátová zařízení; ve skutečnosti může být využit k tomu, aby se nějakému správcovskému kódu umožnilo rozhodovat o kterémkoliv USB zařízení. Administrátor může nakonfigurovat sadu příznaků authorized_default; pokud se prostě nastaví výchozí hodnota na nulu, bude zamítnuto připojení všech nových zařízení, ať už bezdrátových nebo jiných.
Komplexnější implementace by mohla povolovat připojení jen některým druhům zařízení. Klávesnice a myši by mohly být přijatelné, ale cokoliv, co by mohlo ze systému brát data - třeba úložná zařízení nebo tiskárny - by bylo zakázáno. Nebo by mohla být úložná zařízení povolena, ale pouze za předpokladu, že by obsahovala nějaký řádně podepsaný certifikát, který by hostitelský systém ověřil. Existuje množství zajímavých možností. Výsledné zabezpečení nebude tak odolné jako ucpané porty nebo úplné odstranění podpory USB, ale mohlo by to být právě to, co je na některých místech potřeba.
Je to poměrně jednoduchá sada patchů, která přidává zajímavé možnosti. Zbývá ještě dodělat hodně té obtížné práce - autentizaci a šifrování - ale to je práce pro uživatelský prostor. Iñaky požádal o začlenění do 2.6.23; pro v podstatě netestovaný kód je však trošku pozdě. 2.6.24 se zdá pravděpodobnější.
V roce 2006 probíhala živá debata o budoucnosti softwarového uspávání (na disk) - a pokračuje až do dnes. Andrew Morton do toho tenkrát skočil s návrhem na jiný přístup:
Pokud chcete můj vesele neinformovaný názor, tak já myslím, že bychom je měli všechny vyhodit a implementovat suspend3, který by byl založen na infrastruktuře kexec/kdump. Máme tu tolik duplicitní práce, až to už ani není vtipné. A když jsou takhle oddělené, tak to oba přístupy zeslabuje tam, kde jsou opravdové problémy: v oblasti ovladačů.
O 18 měsíců později to vypadá, že bychom přeci jen mohli mít "suspend3" - Ying Huang poslal patch kexec jump.
Yingův patch staví na existující funkci kdump. Účelem kdump je poskytnout bezpečné a užitečné crash dumpy [výpisy informací o pádu] v situacích, kdy je stav systému nejistý. Pokud systém zpanikaří, je fajn mít možnost uložit aktuální stav pro posmrtné debugování. Je však důležité, aby chybující jádro, kterému se v tu chvíli nedá věřit, nebylo používáno k provádění nebezpečných věcí - třeba zapisování crash dumpu na disk. Aby se tomu předešlo, vloží se do rezervované oblasti paměti malé "dump jádro", kde většinu času vyčkává, aniž by si ho někdo všímal nebo bylo potřeba. Dojde-li k panice, provede se volání kexec(), které převede kontrolu na dump jádro. Dokud zůstává dump jádro v rezervované oblasti paměti, bude schopno zapsat zbytek systémového stavu na disk (nebo jinam) poměrně bezpečně.
Minulý rok si Andrew všiml, že suspend-to-disk (které se pomalu přejmenovává na hibernaci) dělá v podstatě totéž: je zastavena činnost systému a aktuální stav je zapsán na disk. Pokud by dump jádro mohlo načíst stav zpět do paměti a vrátit kontrolu původnímu jádru, mohlo by hibernovat (a probudit) systém. Implementace v tomto duchu by měla výhodu ve sjednocení většiny kódu kdump a hibernace, což by umožnilo koncentraci vývojářského úsilí a obecné zjednodušení. Navíc by pak bylo možné odstranit současný kód, který není zrovna moc oblíben - navzdory mnohaletému pobytu v jádře.
Aktuální kód zatím tohle všechno neumí; je to jen první krok: umožňuje skok na původní jádro. Kód je poměrně jednoduchý; ačkoliv spoléhá na většinu existující infrastruktury, aby mohl řádně uspat a vypnout všechna zařízení při přípravě ke skoku oběma směry. Takže pokud ovladač zařízení nespolupracuje s hibernací, problém bude přetrvávat i v implementaci pomocí kexec. Ale spousta dalšího hibernačního kódu, včetně pomlouvaného zmrazovače procesů, by už nebyla potřeba a mohla by být odstraněna.
Než se však vezme kudla na stávající hibernační kód, je potřeba dořešit několik detailů. Vypínání zařízení při přechodu mezi těmi dvěma jádry není vlastně nutné ani žádoucí; musí být pouze v tichém "hibernačním" stavu. Kdump jádro musí být umístěno v rezervované oblasti paměti od počátku; snažit se ho natáhnout v okamžiku paniky už by bylo příliš pozdě. Jádro používané pro hibernaci však nemusí být v paměti celou dobu, takže je potřeba nějaký systém, který umožnil vyžádat natažení sekundárního jádra. Vlastní ukládání a obnovování obrazu systému ještě není implementováno - to se však dá snadno udělat v uživatelském prostoru, aniž by bylo potřeba podpory ze strany jádra. Dá však práci dostatečně zrychlit proces obnovy - uživatelům by se asi nelíbilo čekat, až nabootují dvě jádra, než budou moci používat svůj systém. A tak dále.
Jinými slovy, kexec hibernaci nečekejte nijak brzy. Počáteční reakce na tento přístup byly příznivé; zdá se, že se hodně lidem líbí představa nového začátku v této oblasti. Něco z tohoto odhodlání možná vyprchá časem, až se ukáže, že i s novým přístupem je hibernace složitý a poněkud obskurní problém. Jen čas ukáže, jestli z tohoto kódu vzejde lepší implementace.
Vzhledem k tomu, že Jeremy na kerneltrap.org zjevně chytil nějaký druhý dech a rozjel vydávání článků v míře dosud (nebo alespoň za poslední dva roky) nevídané, tak už jich je pro přidávání do Jaderných novin moc. Mnohé z nich jsou sice o věcech, které už byly v LWN (a tedy i v JN) popisovány podrobněji, ale i tak zůstává v průměru skoro jeden článek na den, což už by jednotlivé díly JN neúnosně natáhlo. (Shodou okolností jsem si to uvědomil jen pár dní po té, co jsem v diskuzi prohlásil, že všechny články z kerneltrap.org do JN dávám...)
Proto vkládám do tohoto článku anketu, ve které vás nechám rozhodnout, jak s tím přívalem novinek v Jaderných novinách zacházet.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Původně jsem si myslel, že k jako kernel a proto kobjekty, ale asi to bude překlep, protože v druhé větě to nění.
2.8.2007 01:32
michich | skóre: 51
| blog: ohrivane_parky
2.8.2007 00:47
struct kobject.
nemelo by byt spise demodulátory ?
Díky, opraveno (i ostatní chybky zmíněné v komentářích).
které by nám umožnily, více či méně evolučním způsobem, vylepšit stávající systémyNejsou tam ty čárky navíc? Nevím, jak to vypadalo v anglickém originálu, ale v češtině se mi to nezdá jako vložená věta.
2.8.2007 08:58
What: ACPI hooks (X86_SPEEDSTEP_CENTRINO_ACPI) in speedstep-centrino driver
When: December 2006
Why: Speedstep-centrino driver with ACPI hooks and acpi-cpufreq driver are
functionally very much similar. They talk to ACPI in same way. Only
difference between them is the way they do frequency transitions.
One uses MSRs and the other one uses IO ports. Functionaliy of
speedstep_centrino with ACPI hooks is now merged into acpi-cpufreq.
That means one common driver will support all Intel Enhanced Speedstep
capable CPUs. That means less confusion over name of
speedstep-centrino driver (with that driver supposed to be used on
non-centrino platforms). That means less duplication of code and
less maintenance effort and no possibility of these two drivers
going out of sync.
Current users of speedstep_centrino with ACPI hooks are requested to
switch over to acpi-cpufreq driver. speedstep-centrino will continue
to work using older non-ACPI static table based scheme even after this
date.
Who: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
2.8.2007 19:37
andree | skóre: 39
| blog: andreeeeelog
ze je to ho dost... kludne by som to prekladal aj raz za par dni, to zase take hrozne nie je - ale neviem ako by ludia neslovenskej narodnosti zvladali citanie prekladov.. hadam ze poniektori by uz skor prekusli anglicku originalnu verziu
no a o tom som hovoril v blogu minuleOno to začalo dost nečekaně. Já kerneltrap sleduji se stejným odstupem, s jakým vycházejí JN - když se podíváš trošku zpátky, tak je vidět, že Jeremy vydával sotva dva články týdně. Proto jsem (tehdy) psal, že není problém je dávat do JN všechny.
neviem ako by ludia neslovenskej narodnosti zvladali citanie prekladovS tím bych si hlavu nedělal. Články ve slovenštině na abclinuxu normálně vycházejí. Pokud máš opravdu zájem s překladem pomoci, kontaktuj mě prosím emailem a dohodneme se na podrobnostech.
2.8.2007 22:10
andree | skóre: 39
| blog: andreeeeelog
co uz, shit happens... :o)
3.8.2007 11:58
andree | skóre: 39
| blog: andreeeeelog