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í
×
dnes 02:00 | Nová verze

Australská společnost Blackmagic Design oznámila vydání verze 15 svého proprietárního softwaru pro editování videa a korekci barev DaVinci Resolve běžícího také na Linuxu. Představení nových vlastností na YouTube. Základní verze DaVinci Resolve je k dispozici zdarma. Plnou verzi DaVinci Resolve Studio lze koupit za 299 dolarů. Před rokem to bylo 995 dolarů.

Ladislav Hagara | Komentářů: 0
včera 21:00 | Zajímavý projekt

Cílem projektu DXVK bylo vytvořit vrstvu kompatibility mezi Direct3D 11 a Vulkanem a začlenění této vrstvy do Wine. Direct3D 10 nad Vulkanem bylo možné řešit mezikrokem pomocí vrstvy DXUP překládající Direct3D 10 na Direct3D 11. Vývojáři DXVK se rozhodli přímo podporovat Direct3D 10. Podpora byla začleněna do hlavní větve na GitHubu.

Ladislav Hagara | Komentářů: 3
včera 16:00 | Nová verze

Vyšla verze 3.10 přehrávače Audacious. Přináší oprav chyb a drobná vylepšení seznamů skladeb, vyhledávání či ikonek. Zároveň pokračují práce na novém uživatelském rozhraní využívajícím Qt namísto GTK+ – nejsou však hotovy, proto je vydání 3.10 pojmenováno „Not Quite There Yet“; až bude proces u konce, vyjde Audacious 4.

Fluttershy, yay! | Komentářů: 12
včera 02:00 | Nová verze

Linus Torvalds vydal Linux 4.18. Více o vývojovém cyklu v Jaderných novinách: začleňovací okno [1] a [2], statistiky. Finální přehled změn je k mání na webu Linux Kernel Newbies.

Fluttershy, yay! | Komentářů: 5
včera 01:00 | Pozvánky

Srpnový pražský sraz spolku OpenAlt se koná ve čtvrtek 16. 8. 2018 od 19:00 v Kavárně Ideál (Sázavská 30), kde máme rezervovaný salonek. Tentokrát jsou tématem srazu databáze. Prezentaci svého projektu si pro nás připravil Standa Dzik. Dále bude prostor, abychom probrali nápady na využití IoT a sítě The Things Network, případně další témata.

xkucf03 | Komentářů: 0
11.8. 22:22 | Komunita

Vývojáři svobodného softwaru pro 3D grafiku Blender představili Blender Benchmark. Uživatelé Blenderu si pomocí něj mohou otestovat své počítače a výsledky volitelně odeslat vývojářům. Z odeslaných výsledků lze například zjistit, na kterých operačních systémech byl benchmark spuštěn. Aktuálně vede Linux s cca 83 % (2032 z 2448). Získaná data budou anonymizovaná a uvolněna jako otevřená data. Představení Blender Benchmarku také na YouTube.

Ladislav Hagara | Komentářů: 5
11.8. 03:00 | Komunita

Některým uživatelům Dropboxu na Linuxu se začalo objevovat upozornění, že v listopadu přestanou být jejich soubory synchronizovány. Vývojáři Dropboxu to v oficiálním fóru potvrdili. Po 7. listopadu budou synchronizovány pouze soubory uloženy na souborovém systému ext4 [reddit].

Ladislav Hagara | Komentářů: 54
11.8. 02:00 | Komunita

Akademie filmového umění a věd každoročně udělující Oscary a Linux Foundation společně představily Academy Software Foundation (ASWF) s cílem poskytnou neutrální půdu vývojářům open source softwaru využívaného ve filmovém průmyslu. Vedle Akademie filmového umění a věd a Linux Foundation jsou zakládajícími členy Animal Logic, Autodesk, Blue Sky Studios, Cisco, DNEG, DreamWorks Animation, Epic Games, Foundry, Google Cloud, Intel, SideFX, The Walt Disney Studios a Weta Digital.

Ladislav Hagara | Komentářů: 2
11.8. 01:00 | IT novinky

Christopher Domas (@xoreaxeaxeax) se ve své přednášce na konferenci Black Hat USA 2018 věnoval možným hardwarovým backdoorům v procesorech x86. Prakticky demonstroval "božský mód" aneb alternativní instrukci pro přechod z ringu 3 na ring 0 v některých procesorech VIA C3. Zveřejněné zdrojové kódy jsou k dispozici na GitHubu jako projekt rosenbridge.

Ladislav Hagara | Komentářů: 10
10.8. 12:00 | Zajímavý článek

Soudní dvůr Evropské unie rozhodl (tisková zpráva) ve věci C-161/17: Zpřístupnění na internetových stránkách fotografie, která je se svolením autora volně dostupná na jiných internetových stránkách, vyžaduje nové svolení tohoto autora. Takové zpřístupnění na internetu je totiž zpřístupněním nové veřejnosti.

Ladislav Hagara | Komentářů: 248
Používáte zařízení („chromebook“, „chromebox“ či tablet) s ChromeOS?
 (6%)
 (3%)
 (12%)
 (79%)
Celkem 159 hlasů
 Komentářů: 7, poslední 10.8. 22:37
    Rozcestník

    Jaderné noviny - 27. 6. 2007

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

    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.