abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

včera 19:33 | Zajímavý článek Marek Stopka | Komentářů: 2
včera 17:55 | Nová verze

Bylo oznámeno vydání nové verze 3.0.0 a krátce na to opravných verzí 3.0.1 a 3.0.2 nástroje mitmproxy určeného pro vytváření interaktivních MITM proxy pro HTTP a HTTPS komunikaci. Přehled novinek v příspěvku na blogu. Přispělo 56 vývojářů. Aktualizována byla také dokumentace [Hacker News].

Ladislav Hagara | Komentářů: 0
včera 01:11 | Nová verze

Byla vydána nová major verze 3.0 svobodného multiplatformního geografického informačního systému QGIS (Wikipedie). Její kódové jméno je Girona, dle názvu města, ve kterém proběhlo 15. setkání vývojářů QGISu. Přehled novinek i s náhledy a animacemi v poznámkách k vydání.

Ladislav Hagara | Komentářů: 0
23.2. 20:33 | Zajímavý článek

Nadace Raspberry Pi vydala sedmašedesáté číslo (pdf) anglicky psaného časopisu MagPi věnovanému Raspberry Pi a projektům postaveným na tomto jednodeskovém počítači a čtvrté číslo (pdf) časopisu pro kutily HackSpace věnovanému navíc 3D tisku, pájení, řezání nebo i elektronice a IoT.

Ladislav Hagara | Komentářů: 0
23.2. 18:33 | Komunita

Morevna Project, který stojí za řadou svobodného softwaru pro animátory (např. Synfig Studio, RenderChan nebo Papagayo-NG) a svobodnými (CC-BY-SA) animovanými filmy/komiksy Morevna (3. díl) a Pepper&Carrot: The Potion Contest (6. díl), sbírá do 1. března příspěvky na 4. díl svého animovaného filmu Morevna. Mezi odměnami přispěvatelům lze najít např. i videokurzy animace v Synfigu či Blenderu.

xHire | Komentářů: 0
23.2. 12:22 | Bezpečnostní upozornění

Ve středu vydaná "npm@next" verze 5.7.0 správce balíčků pro JavaScript npm (Wikipedie, Node Package Manager) přinesla řadě uživatelů Linuxu nečekanou nepříjemnost. V závislosti na způsobu instalace a ve spojení s příkazem sudo mohlo dojít ke změně vlastníka u systémových souborů, také například /. Chyba je opravena v před několika hodinami vydané verzi npm 5.7.1 [reddit].

Ladislav Hagara | Komentářů: 12
23.2. 10:00 | Nová verze

Byla vydána verze 10.5 open source alternativy GitHubu, tj. softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech, GitLab (Wikipedie). Představení nových vlastností v příspěvku na blogu. Zdůraznit lze integrovanou podporu Let's Encrypt.

Ladislav Hagara | Komentářů: 0
22.2. 12:33 | Komunita

Příspěvek na blogu Signalu (Wikipedie) informuje o založení neziskové nadace Signal Foundation, jež bude zastřešovat další vývoj tohoto svobodného bezpečného komunikátoru běžícího také na Linuxu (Signal Desktop). Brian Acton, spoluzakladatel WhatsAppu, věnoval nadaci 50 milionů dolarů [Hacker News].

Ladislav Hagara | Komentářů: 1
22.2. 05:55 | Zajímavý článek

Článek na Fedora Magazine krátce představuje programovací jazyk Rust a několik zajímavých v Rustu naprogramovaných terminálových aplikací. Jedná se o alternativu k příkazu grep ripgrep, moderní barevnou alternativu k příkazu ls exa, příkazem cloc inspirovaný tokei a zvířátko v terminálu ternimal.

Ladislav Hagara | Komentářů: 0
21.2. 23:55 | Zajímavý projekt

Byl spuštěn Humble Classics Return Bundle. Za vlastní cenu lze koupit hry Broken Sword 5 - The Serpent's Curse, Shadowrun Returns a Shadowrun: Dragonfall - Director's Cut. Při nadprůměrné platbě (aktuálně 8,48 $) také Shadowrun: Hong Kong - Extended Edition, Wasteland 2: Director's Cut - Standard Edition, Age of Wonders III a Xenonauts. Při platbě 15 $ a více lze získat navíc Torment: Tides of Numenera a Dreamfall Chapters: The Final Cut Edition.

Ladislav Hagara | Komentářů: 0
Který webový vyhledávač používáte nejčastěji?
 (2%)
 (28%)
 (62%)
 (2%)
 (3%)
 (0%)
 (1%)
 (1%)
Celkem 450 hlasů
 Komentářů: 35, poslední 21.2. 19:51
    Rozcestník

    Jaderné noviny - 27. 6. 2007

    18. 7. 2007 | Robert Krátký | Jaderné noviny | 4308×

    Aktuální verze jádra: 2.6.22-rc6. Citáty týdne: Linus Torvalds, Randy Dunlap. Odstranění taskletů. Linuxové bezpečnostní ne-moduly a AppArmor. Shrnutí změn v interním API v jádře 2.6.22.

    Obsah

    Aktuální verze jádra: 2.6.22-rc6

    link

    Aktuální předverze je (27. 6. 2007) 2.6.22-rc6, vydaná 24. června. Těší mě, že se po vydání -rc5 věci zklidnily, takže tu máme skutečně jen opravy chyb a zvláště regresí. Vypadá to, že tento vývojový cyklus už se blíží ke konci; seznam známých regresí se zkracuje. Jako vždy najdete spoustu podrobností v dlouhém changelogu.

    Od vydání 2.6.22-rc6 bylo do hlavního git repozitáře začleněno asi 30 patchů; jsou to všechno opravy, většinou v kódu USB pro jednotlivé architektury.

    Minulý týden nevyšly žádné nové -mm verze ani starší jádra.

    Citáty týdne: Linus Torvalds, Randy Dunlap

    link

    Upřímně řečeno, osobně uvažuji o odstranění "checkpatch.pl". Je to jen náckovské snění. Třeba ten natvrdo vyžadovaný 80znakový limit, to prostě není správné.

    -- Linus Torvalds

    Potíž je podle mne v tom, že jsou patche čím dál tím méně kontrolovány, ačkoliv by bylo potřeba je kontrolovat více a více. Andrew je jeden z mála, kdo kontroluje spousty patchů. Neměl by to však mít na krku jen on. Takže pokud by Andrewovi pomohlo trochu automatizace, bylo by to fajn. Tedy, dokud se lidé nevzbouří.

    -- Randy Dunlap

    Odstranění taskletů

    link

    Tasklety jsou metodou pro pozdržené spouštění úloh v jádře; byly přidány během vývojové řady 2.3, aby mohly zpracovávače přerušení [interrupt handlers] plánovat práci, která má být provedena v blízké budoucnosti. Tasklet je v podstatě funkce, která má být zavolána (s datovým ukazatelem) v softwarovém přerušení, jakmile je to možné. V praxi bude naplánovaný tasklet (pravděpodobně) spuštěn, když jádro 1) dokončí běh zpracovávače přerušení nebo 2) přepne zpět do uživatelského prostoru. Protože tasklety běží v režimu softwarového přerušení, musí být atomické - žádné spaní nebo reference na uživatelské prostředí atd. Práce, kterou lze provádět v taskletech, je tedy dost omezena, ale i tak jsou v jádře velmi používány.

    A s tasklety je ještě jeden problém: protože běží jako softwarová přerušení, mají vyšší prioritu než kterýkoliv jiný proces v systému. Tasklety tedy vytvářejí neomezené latence, což se vývojáři, kteří se snaží latence snižovat, už dlouho pokoušejí odstranit. Objevily se pokusy, jak problém zmírnit; pokud jádro se softwarovými přerušeními neudrží krok, vyhodí je nakonec do procesu ksoftirqd a nechá je, ať se porvou v plánovači. Specifické tasklety, u kterých bylo zjištěno, že způsobují latenční problémy - například zpracovávač zpětného volání RCU - byly trochu umravněny. A realtimový strom tlačí veškeré zpracovávání softwarových přerušení do samostatných procesů, které lze plánovat (a využít na ně preempci) jako všechno ostatní.

    Steven Rostedt nedávno navrhl jiný přístup: proč se těch taskletů nezbavit úplně? Od doby, kdy byly tasklety vyvíjeny, už jádro získalo jiné a pružnější způsoby odkládání práce; konkrétně pracovní fronty fungují velmi podobně jako tasklety, ale bez mnoha nevýhod, které jsou s tasklety spojeny. Protože pracovní fronty používají dedikované pracovní procesy, může na ně být uplatněna preempce a nemají stejné latenční problémy jako tasklety; jako bonus poskytují kontext procesů, který pracovním funkcím umožňuje (v případě potřeby) spát. Steven tvrdí, že pracovní fronty jsou natolik schopné, že tasklety už nejsou potřeba.

    Stevenův patch tedy rozhraní pročišťuje a z RCU taskletu dělá samostatné softwarové přerušení nezávislé na mechanismu taskletů. Pak je vyhozen kód taskletů a nahrazen obalovým rozhraním [wrapper interface], které pod sebou schovává pracovní fronty. Výsledkem je jádro bez taskletů, aniž by bylo nutné přepisovat všechen kód, který tasklety používá.

    Proti odstranění taskletů se nikdo moc nebouří, i když je jasné, že před zařazením takové změny bude nutné provést hodně výkonnostních testů. Skoro nikomu se však nelíbí obalové rozhraní; je to přesně takový způsob poslepování věcí kvůli kompatibilitě, kterému se snaží zabránit pravidlo "žádné stabilní interní API". Je tedy vyvíjen tlak na zahození obalu a převedení všech uživatelů taskletů na pracovní fronty. Není třeba říkat, že jde o velký kus práce; a není také žádné překvapení, že by se mohl najít někdo, kdo by byl v pokušení se tomu vyhnout. Ať tak či tak, současnou podobu patche je možné testovat; pokud by nahrazení taskletů způsobovalo problémy, tento patch je odhalí, než si někdo dá tu práci a převede všechny uživatele taskletů.

    Další otázka, na kterou je nutné mít odpověď, zní: přinese převod taskletů na pracovní fronty lepší zpracovávání přerušení, nebo by se mělo uvažovat o širších změnách? Místo přepínání kontextu do procesu pracovní fronty by možná systém vytěžil lepší výkon, kdyby prostě zpracovávač přerušení spustil jako vlákno. Realtimový strom to přesně takhle dělá už dlouho: všechny (OK, skoro všechny) zpracovávače přerušení běží ve vlastních vláknech. Vývojáři realtime plánují tento kód začlenit během následujících několika vývojových cyklů.

    Podle současných plánů by vláknové zpracovávače přerušení pravděpodobně byly konfigurovatelné při kompilaci. Ale kdyby vývojáři věděli, že zpracovávače přerušení poběží v kontextu procesů, mohli by prostě potřebné zpracování provést v rámci zpracovávače a mechanismu pro pozdržení práce se zbavit úplně. Takový přístup by nemusel fungovat s každým ovladačem - u některých zařízení by bylo riziko příliš velké latence při reakci na přerušení - ale v mnoha případech se nabízí možnost situaci výrazně zjednodušit a zpřehlednit. Kód by nebyl jen jednodušší, ale dokonce i výkonnější.

    Zdá se tedy, že na odstranění taskletů se skutečně pracuje. V rámci příprav se Ingo Molnar zaměřil na možné výkonnostní problémy:

    Takže k tomu následujícímu odlišnému přístupu: všichni, kdo máte tasklet v kódu, u kterého je důležitý výkon, se prosím ozvěte. Sami taková místa budeme aktivně hledat. Můžeme je buď převést na softwarová přerušení, nebo je přesunout zpátky do kontextu hardwarových přerušení. Jakmile to bude hotovo - a pochybuji, že to bude více než 1 - 2 místa - tak můžeme najednou převést všech těch dalších 110 míst na nudné, ale kompatibilní řešení, při kterém jsou prováděny v globálním kontextu vláken.

    To je docela jasná výzva k činu pro každého, komu záleží na možných výkonnostních dopadech této změny na nějakou konkrétní část jádra. Pokud myslíte, že nějaký kód potřebuje rychlejší reakci na pozdrženou práci, než může poskytnout mechanismus založený na pracovních frontách, teď je ta pravá chvíle neodkládat odpověď na Ingovu žádost.

    Linuxové bezpečnostní ne-moduly a AppArmor

    link

    Pokud již dění kolem vývoje jádra nějakou chvíli sledujete, budete vědět, že LSM API (Linux security module API - rozhraní pro linuxové bezpečnostní moduly) je přinejmenším kontroverzní. Mnozí si myslí, že nesplnilo svůj úkol - umožnit vývoj konkurenčních přístupů k zabezpečení linuxového systému; jediný významný bezpečnostní modul v jádře je SELinux. Přitom však lze rozhraní LSM snadno zneužívat; protože umožňuje vložení háčků [hooks] do téměř libovolné systémové operace, může být jinými moduly využíváno k poskytování funkcí, které s bezpečností nesouvisejí. LSM symboly jsou většinou exportovány jako pouze-GPL, ale i tak je možné, aby binární moduly LSM operace zneužívaly - a zjevně už to některé dělají.

    SELinux hacker James Morris o tomto problému přemýšlel a také si všiml, že bezpečnostní moduly, které jsou součástí jádra (SELinux a ten malý modul, který implementuje kvalifikace [capabilities]), není možné z běžícího jádra vyjmout. Takže položil otázku, proč mít vůbec modulární rozhraní? Poslal patch, který z LSM dělá statické API, jež neexportuje žádné symboly. Je-li tento patch aplikován, musejí být potřebné bezpečnostní "moduly" zakompilovány přímo do jádra; už neexistuje způsob, jak je přidat za běhu.

    Objevilo se pár nesouhlasných názorů, ale nevypadá to, že by někdo přišel s opravdu vážným důvodem, proč by mělo být možné bezpečnostní moduly odstraňovat za běhu. Naopak někdo poukázal na to, že snažit se udržovat rozumnou bezpečnost na systému, kde jdou odstraňovat moduly, je skoro nemožné. Tento patch má tedy slušnou šanci se do jádra dostat. Jedinou otázkou tak je, jestli mají vývojáři pocit, že je nutné poskytnout dlouhou dobu před začleněním jako varování vývojářům a uživatelům bezpečnostních modulů, jež nejsou součástí jádra.

    Jeden takový modul je AppArmor - bezpečnostní mechanismus licencovaný GPL, který je distribuován Novellem. AppArmor zůstává mimo jádro, zatímco se jeho vývojáři snaží reagovat na připomínky, které byly během let vzneseny. Byl představen nový AppArmor patch; v němž byla spousta věcí opravena, ale jeden ze zásadních bodů zůstává: AppArmor pro prosazování pravidel stále používá mechanismus založený na názvech cest. Takový přístup se vývojářům nelíbí - hlavně těm z tábora SELinuxu - protože jsou přesvědčeni, že názvy cest jsou ze své podstaty nebezpečná metoda. Z jejich pohledu je jediný bezpečný způsob kontroly přístupu k objektům přidání značek přímo na objekty.

    Už to vypadalo, že byl tento spor vyřešen na jaderném summitu v roce 2006, kde bylo rozhodnuto, že používání názvů cest není dostatečný důvod pro odmítání AppArmor. To však lidem nezabránilo ve stěžování, když se nedávno objevil nový přístup založený na názvech cest (TOMOYO Linux). Pokud se AppArmor do hlavního jádra dostane, bude to přes námitky vývojářů, kteří tvrdí, že uživatelům poskytuje falešný pocit bezpečí.

    Andrew Morton by tuto záležitost chtěl dohodnout mimo konferenci; napadají ho dvě alternativy:

    a) nechat stranou technické otázky a překousnout začlenění jako službu SUSE a jejich uživatelům (obě skupiny jsou pro nás důležité); nechali bychom to jako konkrétní lekci z kapitoly "jak nevyvíjet jaderné funkce" [...]

    b) nechat to venku a vyžadovat od SUSE, ať nese nákladové a kvalitativní důsledky správy mimo jádro. I tak to bude dobrá lekce o tom, "jak nevyvíjet jaderné funkce".

    Andrew však pravděpodobně nechce dávat konkrétní lekce k vývoji jaderného kódu žádným z těchto způsobů; uzavřel tedy žádostí:

    Ach jo. Nestavte nás už prosím do této situace. Než něco začnete prodávat zákazníkům, dostaňte to nejdřív do jádra, OK? Není to žádná velká věda.

    Na summitu v roce 2006 se Linus jasně vyjádřil, že používání názvů cest mu připadá rozumné. To, společně s faktem, že je AppArmor široce distribuován, napovídá, že dříve či později si tento modul cestu do jádra najde - i kdyby už to nebylo ve formě modulu.

    Shrnutí změn v interním API v jádře 2.6.22

    link

    Vývojový cyklus 2.6.22 se pomalu blíží ke svému závěru, což znamená, že už by mělo být bezpečné se pokusit vyjmenovat významné změny interního API.

    • Byl začleněn bezdrátový stack mac80211 (dříve "Devicescape"), takže je k dispozici kompletně nové API pro vytváření bezdrátových ovladačů - především těch, které vyžadují podporu MAC.

    • Funkce eth_type_trans() teď nastavuje pole skb->dev, což je stejný postup, jaký používají podobné funkce pro jiné typy linků. Kvůli tomu byla změněna spousta ethernetových ovladačů - bylo odstraněno (teď již) zbytečné přiřazení.

    • Hlavičková pole ve struktuře sk_buff byla přejmenována a už nejsou typu union. Síťovací kód a ovladače teď mohou používat skb->transport_header, skb->network_header a skb->skb_mac_header. Pro vyhledání specifických hlaviček v paketech jsou k dispozici nové funkce: tcp_hdr(), udp_hdr(), ipip_hdr() a ipipv6_hdr().

    • Ještě z oblasti síťování: paketový plánovač byl přepracován, aby používal hodnoty ktime místo jiffies.

    • SLUB alokátor byl začleněn jako experimentální (prozatím) alternativa ke kódu slab. SLUB API obecně odpovídá slabu, ale trochu se změnil způsob řešení nulových alokací.

    • Další změny již byly uvedeny v souhrnu, který se objevil v článku Jaderné noviny - 9. 5. 2007.
           

    Hodnocení: 100 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    18.7.2007 01:25 Kyosuke | skóre: 28 | blog: nalady_v_modre
    Rozbalit Rozbalit vše Re: Jaderné noviny - 27. 6. 2007
    zpracovávače přerušení [interrupt handlers]
    Ehm, rutiny {obsluhy|pro obsluhu} přerušení? Případně jen obsluha přerušení, tam, kde není kladen důraz na konkrétní kus kódu.
    18.7.2007 12:35 Robert Krátký | skóre: 94 | blog: Robertův bloček
    Rozbalit Rozbalit vše Re: Jaderné noviny - 27. 6. 2007
    Ehm, rutiny {obsluhy|pro obsluhu} přerušení? Případně jen obsluha přerušení, tam, kde není kladen důraz na konkrétní kus kódu.
    No jo, mně se ty zpracovávače také moc nelíbí, ale používám je v JN už poměrně dlouho a nikdo zatím nekřičel, tak jsem se nechal ukolébat... Díky za nápady.
    18.7.2007 13:16 Kyosuke | skóre: 28 | blog: nalady_v_modre
    Rozbalit Rozbalit vše Re: Jaderné noviny - 27. 6. 2007
    Já to taky zas tak poctivě neprocházím, tak jsem si toho zatím nevšiml. ;-)
    18.7.2007 03:04 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Jaderné noviny - 27. 6. 2007
    Dvoje jaderné noviny během tří dnů? Děkujeme velice.
    Quando omni flunkus moritati
    18.7.2007 08:33 cronin | skóre: 49
    Rozbalit Rozbalit vše Re: Jaderné noviny - 27. 6. 2007
    Njn, konecne to spravne tempo. :-D
    18.7.2007 12:36 Robert Krátký | skóre: 94 | blog: Robertův bloček
    Rozbalit Rozbalit vše Re: Jaderné noviny - 27. 6. 2007
    Snažím se jen dohánět zpoždění :-)
    18.7.2007 20:41 Creator of Myths
    Rozbalit Rozbalit vše Re: Jaderné noviny - 27. 6. 2007
    To jako ze si budu moct precist v ceskych Jadernych novinach aktualni veci misto toho, co se delo pred mesicem? To by bylo opravdu skvele! :-)
    18.7.2007 21:24 Robert Krátký | skóre: 94 | blog: Robertův bloček
    Rozbalit Rozbalit vše Re: Jaderné noviny - 27. 6. 2007
    Úplně aktuální věci to nebudou nikdy, protože bych to jednak nestíhal, ale také jsem se s provozovatelem LWN dohodl, že vždy počkám alespoň týden, protože bych jinak zpřístupňoval překlad obsahu, který by v tu chvíli byl na LWN dostupný pouze pro předplatitele.
    19.7.2007 09:26 Creator of Myths
    Rozbalit Rozbalit vše Re: Jaderné noviny - 27. 6. 2007
    Rozdil jednoho tydne beru jako v podstate aktualni. Rozhodne je to neco jineho nez mesic, behem ktereho jsou vyvojari schopni udelat spoustu zmen.
    18.7.2007 22:42 Messa | skóre: 39 | blog: Messa
    Rozbalit Rozbalit vše Re: Jaderné noviny - 27. 6. 2007
    Ale takhle mám alespoň dobrý pocit z toho, že na problémech v kernelu zmíněných v českých Jaderných novinách se už nejméně měsíc pracuje :-)
    Petr (DotaZ) Jakubec avatar 20.7.2007 13:27 Petr (DotaZ) Jakubec | skóre: 5
    Rozbalit Rozbalit vše Re: Jaderné noviny - 27. 6. 2007
    taky mi mesicni zpozdeni nijak nebrani v klidnem spanku :-)

    3 mesicni by uz mi prislo jako zastarale ale mesic je jeste OK.

    ja ta aktualni povazuji 14dnu i mesic zpozdeny preklad uplne bez problemu.

    jo a DIKY za nej!
    21.7.2007 12:39 Martin Doucha | skóre: 23 | blog: Yet another blog
    Rozbalit Rozbalit vše Jedna drobnost v překladu
    Větu "That thing is just a nazi dream." bych přeložil spíš jako "Ta věc [checkpatch.pl] je sen všech nácků.", Linus komentuje kvalitu toho skriptu a ne svoje představy.
    21.7.2007 14:59 Robert Krátký | skóre: 94 | blog: Robertův bloček
    Rozbalit Rozbalit vše Re: Jedna drobnost v překladu
    Linus komentuje kvalitu toho skriptu a ne svoje představy.
    Nemyslel jsem to tak, že jde o jeho představy. IMHO "náckovské snění" znamená to, o čem snívají náckové.
    21.7.2007 20:29 Martin Doucha | skóre: 23 | blog: Yet another blog
    Rozbalit Rozbalit vše Re: Jedna drobnost v překladu
    Ale věta "Je to jen náckovské snění." se tak dá pochopit.

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.