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 09:22 | Pozvánky

V Praze dnes probíhá Konference e-infrastruktury CESNET. Na programu je řada zajímavých přednášek. Sledovat je lze i online na stránce konference.

Ladislav Hagara | Komentářů: 0
9.12. 20:11 | Nová verze

Byl vydán Debian 9.3, tj. třetí opravná verze Debianu 9 s kódovým názvem Stretch a Debian 8.10, tj. desátá opravná verze Debianu 8 s kódovým názvem Jessie. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 9 a Debianu 8 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.

Ladislav Hagara | Komentářů: 0
9.12. 00:44 | Nová verze

Po 6 měsících vývoje od vydání verze 0.13.0 byla vydána verze 0.14.0 správce balíčků GNU Guix a na něm postavené systémové distribuce GuixSD (Guix System Distribution). Na vývoji se podílelo 88 vývojářů. Přibylo 1 211 nových balíčků. Jejich aktuální počet je 6 668. Aktualizována byla také dokumentace.

Ladislav Hagara | Komentářů: 3
8.12. 21:33 | Nová verze

Po půl roce vývoje od vydání verze 5.9 byla vydána nová stabilní verze 5.10 toolkitu Qt. Přehled novinek na wiki stránce. Současně byla vydána nová verze 4.5.0 integrovaného vývojového prostředí (IDE) Qt Creator nebo verze 1.10 nástroje pro překlad a sestavení programů ze zdrojových kódů Qbs.

Ladislav Hagara | Komentářů: 0
7.12. 11:11 | Komunita

Naprostá většina příjmů Mozilly pochází od výchozích webových vyhledávačů ve Firefoxu. Do konce listopadu 2014 měla Mozilla globální smlouvu se společností Google. Následně bylo místo jedné globální smlouvy uzavřeno několik smluv s konkrétními vyhledávači pro jednotlivé země. V USA byla podepsána pětiletá smlouva s vyhledávačem Yahoo. Dle příspěvku na blogu Mozilly podala společnost Yahoo na Mozillu žalobu ohledně porušení této

… více »
Ladislav Hagara | Komentářů: 0
7.12. 05:55 | Zajímavý článek

V Londýně probíhá konference věnovaná počítačové bezpečnosti Black Hat Europe 2017. Průběžně jsou zveřejňovány prezentace. Videozáznamy budou na YouTube zveřejněny o několik měsíců. Zveřejněna byla například prezentace (pdf) k přednášce "Jak se nabourat do vypnutého počítače, a nebo jak v Intel Management Engine spustit vlastní nepodepsaný kód". Dle oznámení na Twitteru, aktualizace vydaná společností Intel nevylučuje možnost útoku.

Ladislav Hagara | Komentářů: 5
7.12. 04:44 | Komunita

Virtualizační nástroj GNOME Boxy ve Fedoře 27 umožňuje jednoduše stáhnout a nainstalovat Red Hat Enterprise Linux, který je pro vývojáře zdarma. Vývojová verze GNOME Boxy již umožňuje jednoduše stáhnout a nainstalovat další linuxové distribuce. Ukázka na YouTube. Seznam distribucí a jejich verze, nastavení a cesty k ISO obrazům je udržován v knihovně a databázi libosinfo (GitLab).

Ladislav Hagara | Komentářů: 0
7.12. 03:33 | Nová verze

Google Chrome 63 byl prohlášen za stabilní (YouTube). Nejnovější stabilní verze 63.0.3239.84 tohoto webového prohlížeče přináší řadu oprav a vylepšení. Vylepšeny byly také nástroje pro vývojáře. Opraveno bylo 37 bezpečnostních chyb.

Ladislav Hagara | Komentářů: 10
6.12. 22:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených technologií a otevřeného přístupu na 147. brněnský sraz, který proběhne v pátek 15. prosince od 18:00 hodin v restauraci Severka na rohu Tučkové a Zahradníkové.

Ladislav Hagara | Komentářů: 0
6.12. 22:33 | Komunita

V roce 2013 byl představen projekt Debsources, jehož cílem bylo a je poskytnout webové rozhraní ke zdrojovým kódům balíčků obsažených v Debianu. Projekt doteď běžel na doméně debian.net. Dnes bylo oznámeno, že projekt byl přesunut na oficiální infrastrukturu Debianu. Služba Debian Sources nově běží na doméně debian.org. V plánů je řada vylepšení. Již dnes je ke službě k dispozici API a procházet lze také patche a licence.

Ladislav Hagara | Komentářů: 0
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (8%)
 (1%)
 (1%)
 (1%)
 (75%)
 (14%)
Celkem 949 hlasů
 Komentářů: 45, poslední 1.12. 19:00
    Rozcestník

    Jaderné noviny - 27. 6. 2007

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

    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.