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 14:00 | Zajímavý projekt

Byl spuštěn Humble Down Under Bundle. Za vlastní cenu lze koupit multiplatformní hry The Warlock of Firetop Mountain, Screencheat, Hand of Fate a Satellite Reign. Při nadprůměrné platbě (aktuálně 3,63 $) také Hacknet, Hacknet Labyrinths, Crawl a Hurtworld. Při platbě 12 $ a více lze získat navíc Armello.

Ladislav Hagara | Komentářů: 0
dnes 13:00 | Nová verze

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

Ladislav Hagara | Komentářů: 1
dnes 11:00 | Zajímavý článek

Článek (en) na Mozilla.cz je věnován vykreslování stránek ve Firefoxu. V průběhu roku 2018 by se ve Firefoxu měl objevit WebRender, jenž by měl vykreslování stránek urychlit díky využití GPU.

Ladislav Hagara | Komentářů: 0
dnes 08:22 | Bezpečnostní upozornění

NÚKIB (Národní úřad pro kybernetickou a informační bezpečnost) informuje o zranitelnosti ROCA v procesu generování RSA klíčů, který se odehrává v softwarové knihovně implementované například v kryptografických čipových kartách, bezpečnostních tokenech a dalších hardwarových čipech vyrobených společností Infineon Technologies AG. Zranitelnost umožňuje praktický faktorizační útok, při kterém útočník dokáže vypočítat

… více »
Ladislav Hagara | Komentářů: 1
dnes 01:23 | Zajímavý software

Příspěvek na blogu otevřené certifikační autority Let's Encrypt informuje o začlenění podpory protokolu ACME (Automatic Certificate Management Environment) přímo do webového serveru Apache. Klienty ACME lze nahradit novým modulem Apache mod_md. Na vývoj tohoto modulu bylo uvolněno 70 tisíc dolarů z programu Mozilla Open Source Support (MOSS). K rozchození HTTPS na Apache stačí nově přidat do konfiguračního souboru řádek s ManagedDomain. Minutový videonávod na YouTube [reddit].

Ladislav Hagara | Komentářů: 1
včera 14:15 | Komunita

Daniel Stenberg, autor nástroje curl, na svém blogu oznámil, že obdržel letošní Polhemovu cenu, kterou uděluje Švédská inženýrská asociace za „technologickou inovaci nebo důvtipné řešení technického problému“.

marbu | Komentářů: 9
včera 13:40 | Pozvánky

Cílem Social Good Hackathonu, který se uskuteční 21. a 22. října v Brně, je vymyslet a zrealizovat projekty, které pomůžou zlepšit svět kolem nás. Je to unikátní příležitost, jak představit nejrůznější sociální projekty a zrealizovat je, propojit aktivní lidi, zástupce a zástupkyně nevládních organizací a lidi z prostředí IT a designu. Hackathon pořádá brněnská neziskovka Nesehnutí.

… více »
Barbora | Komentářů: 1
včera 00:44 | Pozvánky

V sobotu 21. října 2017 se na půdě Elektrotechnické fakulty ČVUT v Praze uskuteční RT-Summit – setkání vývojářů linuxového jádra a uživatelů jeho real-time verze označované jako preempt-rt.

… více »
Pavel Píša | Komentářů: 8
16.10. 23:44 | Bezpečnostní upozornění

V Linuxu byla nalezena bezpečnostní chyba CVE-2017-15265 zneužitelná k lokální eskalaci práv. Jedná se o chybu v části ALSA (Advanced Linux Sound Architecture).

Ladislav Hagara | Komentářů: 1
16.10. 22:44 | Komunita

Greg Kroah-Hartman informuje na svém blogu, že do zdrojových kódu linuxového jádra bylo přidáno (commit) prohlášení Linux Kernel Enforcement Statement. Zdrojové kódy Linuxu jsou k dispozici pod licencí GPL-2.0. Prohlášení přidává ustanovení z GPL-3.0. Cílem je chránit Linux před patentovými trolly, viz například problém s bývalým vedoucím týmu Netfilter Patrickem McHardym. Více v často kladených otázkách (FAQ).

Ladislav Hagara | Komentářů: 4
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (18%)
 (0%)
 (0%)
 (3%)
 (71%)
 (8%)
Celkem 38 hlasů
 Komentářů: 1, poslední dnes 11:21
    Rozcestník

    Jaderné noviny – 3. 6. 2011: Proč neforkovat jádro kvůli ARM

    13. 6. 2011 | Jirka Bourek | Jaderné noviny | 4341×

    Aktuální verze jádra: 3.0-rc1. Citáty týdne: Casey Schaufler, Ingo Molnár. Garret: Rebootování. Začleňovací okno 3.0, část druhá. Fork ARM jádra?

    Obsah

    Aktuální verze jádra: 3.0-rc1

    link

    Současné vývojové jádro je 3.0-rc1 vydané 29. května. Linus řekl:

    Tak jaké jsou velké změny? ŽÁDNÉ. Absolutně žádné. Jasně, jako obvykle jsou dvě třetiny změny ovladačů, pak je tu spousta náhodných věcí, ale klíčové je, že 3.0 je jenom přečíslování, rozhodně tu nebudeme dělat KDE-4 nebo GNOME-3. Žádné rozbíjení, žádné děsivé nové vlastnosti, nic takového. Mnoho let vydáváme v intervalech, takže to rozhodně o vlastnostech není. Jestli chcete výmluvu pro přečíslování, měli byste se se rozhodně podívat po nějakém založeném na čase ('20 let').

    V samostatném článku níže vizte shrnutí změn začleněných v druhé polovině začleňovacího okna 3.0.

    Stabilní aktualizace: 2. června vyšla jádra 2.6.38.8 a 2.6.39.1. Tato verze 2.6.38 bude poslední, takže uživatelé by měli přejít na 2.6.39.

    Citáty týdne: Casey Schaufler, Ingo Molnár

    link

    Uživatelé jsou opravdu hrozným zdrojem specifikace rozhraní. „Hackeři“ často nejsou o moc lepší, ale přinejmenším, když je rozhraní mizerné, je u vývojáře potenciál pro to, že za něj a za jeho vývoj ponese zodpovědnost.

    -- Casey Schaufler

    IMHO je klíčovou návrhovou chybou LSM to, že to odděluje bezpečnostní politiku od aplikací: k načtení politiky musíte být admin, k použití/konfiguraci LSM musíte být root. K čertu, root musíte být i když chcete přidat značky [labels] k souborům. Nejenom že jsou kvůli tomu LSM politiky specifické pro distra (a zbytečně forkované a oddělené od skutečného zabezpečení), ale také to hlásá:

    'abyste se mohli zabezpečit, musíte být privilegovaní'

    což IMO jde proti konceptu dobrého zabezpečení.

    -- Ingo Molnár

    Garret: Rebootování

    link

    Matthew Garret se podle všeho „baví“ hledáním způsobu, jak rebootovat x86. Vyjmenovává pět různých mechanismů, jak rebootovat 64bitový x86 hardware včetně: kbd – reboot pomocí řadiče klávesnice. Původní IBM PC mělo resetovací linku CPU spojenou s řadičem klávesnice. Zápisem správných magických pulsů se stroj vyresetoval. To je velmi přímočaré až na to, že moderní stroje nemají řadič klávesnice (ty jsou ve skutečnosti součástí zabudovaného [embedded] řadiče) a ještě modernější stroje ani nepředstírají, že by nějaký řadič klávesnice měly. A teď – v zabudovaných řadičích běží software. A jak všichni víme, software je hrůza. A je to ještě horší, protože software v zabudovaném řadiči napsali autoři BIOSů. Takže je jasné, že jakékoliv předstírání, že by tohle někdy mohlo fungovat, je jenom dobře propracovaná fikce. Některé stroje jsou velmi vybíravé, hardware musí být v přesném stavu, do jakého ho přepnou Windows. Jiné stroje fungují v devíti případech z deseti a pak se zaseknou kvůli nějaké podivné záležitosti s časováním. A jiné jednoduše nefungují vůbec. Hurá!

    Začleňovací okno 3.0, část druhá

    link

    napsal Jonathan Corbet, 1. června 2011

    Nakonec bylo do hlavní řady předtím, než Linus začleňovací okno uzavřel, přetaženo 7333 neslučovacích sad změn. Linus pak rozhodl, že příští verze se bude jmenovat „3.0“. Od shrnutí z minulého týdne nebylo mnoho vzrušujících změn, ale pár se jich najde. Mezi nejvýznamnější změny viditelné pro uživatele patří:

    • Byl začleněn patch pro jmenný prostor popisovačů souborů, který obsahuje i systémové volání setns(). Tato vlastnost zjednodušuje správu kontejnerů, které běží v různých jmenných prostorech.

    • Souborový systém XFS má nyní podporu pro zahazování za běhu [online discard]

    • Byla začleněna funkcionalita Cleancache. Ta umožňuje vytvořit mezisklad stránek, které byly vytlačeny z cache stránek, ale v budoucnu by stále mohly být užitečné. Cleancache je zezačátku podporována v ext3, ext4 a ocfs2.

    • Infrastruktura založená na netlink umožňuje správu RDMA klientů

    • Nyní je možné naráz přesunout všechna vlákna ve skupině do řídící skupiny pomocí řídícího souboru cgroup.procs

    • Architektura Blackfin získala podporu pro události výkonnosti

    • Souborový systém btrfs získal podporu pro operaci „kontroly“ [scrub], kterou spouští administrátor a která přečte bloky souborového systému a ověří kontrolní součty. Když je to možné, špatné kopie dat se nahradí správnými z jiného úložného zařízení. Btrfs také podporuje připojovací volbu auto_defrag, která zajistí, že si souborový systém bude všímat náhodných zápisů do souborů a u těch pak naplánuje defragmentaci.

    • Bootovací parametr no-hlt byl označen za zastaralý: v tomto tisíciletí ho nepotřebuje žádný stroj. Pokud by se přece jenom našel nějaký stroj, na kterém běží současné jádro a nefunguje na něm instrukce HLT, lze ho nabootovat pomocí idle=poll.

    • Byla přidána podpora pro protokol pNFS v případech, že jako úložné zařízení slouží úložiště ukládající objekty [object storage devices]

    Mezi změny viditelné pro jaderné vývojáře patří:

    • Nový modul pro základní podporu GPIO modulů založených na paměťově mapovaném I/O.

    • Nová atomická operace atomic_or, která provede operaci logického součtu na hodnotě atomic_t.

    S vydáním -rc1 Linus označil jádro jako „3.0.0“ (a pojmenoval ho „Sneaky Weasel“). Prohlásil, že hodlá poslední číslo zahodit během stabilizace, takže výsledné jádro bude pouze „3.0“, to ale bude záviset na opravě různých skriptů běžících v uživatelském prostoru. Tak jako tak stabilní aktualizace, které budou lidé používat, budou začínat 3.0.1.

    Linus tentokrát zjevně doufá v relativně hladký vývojový cyklus; naznačil, že tentokrát možná bude vybíravější, co se týče oprav, které přetáhne. 3.0 má podle všeho být nudné, aby se zajistilo, že změna čísla verze nebude moc znamenat. Finální verzi, ať už bude nudná nebo ne, lze očekávat někdy v první polovině července.

    Fork ARM jádra?

    link

    originál tohoto článku pro LWN.net napsal Thomas Gleixner, 1. června 2011

    Za posledních několik měsíců lidé několikrát navrhli forknout jádro pro ARM a udržovat ho jako oddělený projekt. I když se důvody pro něco takového mohou zdát atraktivní, ukazuje se, že to ve skutečnosti nedává velký smysl ani pro komunitu ARM, ani pro jádro jako celek.

    Tady jsou nejčastější důvody pro tento návrh:

    • Čas do uvedení na trh [time to market]

    • Odpovídá to povaze jednorázových výstřelků [one-off] spotřební elektroniky

    • Lépe se to hodí ve světě diverzity systémů na čipu (SoC)

    • Vyhýbá se to úzkému hrdlu, které představují správci, a také zbytečné práci navíc kvůli reakcím na revize

    Na tyto důvody se podívejme.

    Čas do uvedení na trh

    link

    Čas do uvedení na trh je odůvodňován tím, že zabere méně času nahackovat nový ovladač, než ho nechat začlenit do hlavní řady. Chápu, že jsem ze staré školy a že už nechápu rapidně se měnící svět a nové výzvy polovodičového průmyslu. I tak mám ale dost znalostí a zdravého rozumu na to, abych věděl, že v průmyslu žádný koncept naprosto „nových“ věcí oddělených od předchůdců neexistuje. Většina IP bloků (funkcionalita licencovaná pro začlenění na SoC) není nová. Co se tedy stane s časem do uvedení na trh, když se stejný IP blok použije podruhé? Pokud je ovladač v upstreamu, jednoduše ho lze použít znova. Příliš často jsou ale ovladače napsány od nuly, jsou úplně nové a nové jsou i chyby, které je potřeba opravit. Opravdu výrobci získají lepší čas do uvedení na trh tím, že pokaždé pro staré IP bloky píší nové ovladače u každého SoC, který prodávají?

    Navíc skutečný čas do uvedení na trh pro úplně novou generaci čipů se obvykle neměří v týdnech – obvyklé časové rozmezí od marketingového oznámení ke skutečnému křemíku použitém v zařízení se blíží k jednomu roku. To by mělo být více než dost času na to, aby se nový ovladač dostal do upstreamu. A navíc, k marketingovému oznámení rozhodně nedojde den poté, co se návrhářské oddělení večer sešlo v hospodě na pivo a nějaký génius tam namaloval nový návrh na ubrousek u baru, takže projekty mají na začlenění do upstreamu ještě více času.

    Jednorázová povaha embedded zařízení

    link

    Není pochyb o tom, že embedded projekty, obzvláště ty určené na spotřebitelský trh, mívají povahu jednorázových výstřelků, ale také je fakt, že různé variace dané rodiny SoC mají mnoho společného a liší se jenom v malých detailech. A navíc variace daného typu hardware – například rodina smartphonů, které se liší v určitých aspektech funkcionality – sdílí většinu infrastruktury. I novější generace SoC často obsahuje mnoho součástí z předcházející generace, takže není žádný přesvědčivý důvod nahradit již fungující stavební bloky, když je jejich funkcionalita dostačující. Opakované používání částí, o kterých se ví, že fungují, není nový koncept; není překvapením, že je to zásadní při dodržení cílů, co se doby do uvedení na trh týče.

    Nedávno jsme narazili na následující klenot. SoC s perfektní podporou pro téměř všechny periferní komponenty v hlavní řadě prošel zásadní renovací. Ta nahradila CPU, ale periferní IP bloky zůstaly stejné s výjimkou lehce se lišící VHDL spojovací vrstvy, která byla nutná kvůli propojení s CPU. Technik ve mě by očekával, že podpora výsledné generace SoC bude pouhou otázkou úpravy existujících ovladačů. Realita nás naučila, že výrobce se rozhodl sestavit tým, který měl vytvořit podporu pro „nový“ SoC a všechny ovladače byly napsány znova. Některé z nich jsme při revizích zachytili, další se dostaly do hlavní řady, takže teď máme pro stejný křemík dva ovladače, které nejsou kompatibilní ani co se týče vlastností, ani co se týče chyb.

    Opravdu nemůžu uvěřit tomu, že by přepsání tuctu ovladačů od začátku bylo rychlejší než sednout si, identifikovat existující ovladače – o kterých se ví, že fungují – a modifikovat je pro nový návrh SoC. Průmysl často používá hardware opakovaně. Proč tak nepoužít i software?

    Diverzita SoC

    link

    Každý výrobce SoC bude samozřejmě tvrdit, že jeho čip je ve všech aspektech unikátní a tak odlišný od konkurence, že sdílení víc než pár základních řádek kódu je nemožné. Z marketingového pohledu je to pochopitelné, ale když se podíváte na datasheet daného SoC, zjistíte, že počet unikátních periferních bloků není tak velký. Vzhledem k tomu, že většina SoC se zaměřuje na stejný trh a stejnou základnu zákazníků, dá se to víceméně očekávat. Bližší pohled ukáže, že různí výrobci často používají pro danou funkcionalitu stejné nebo velmi podobné IP bloky. Je jenom omezené množství funkčních způsobů, jak v hardware implementovat daný požadavek a je jenom pár relevantních prodejců IP bloků, kteří dodávají své „unikátní“ IP bloky všem výrobcům SoC. Diverzita se často omezuje jenom na lišící se rozvržení registrů nebo na fakt, že jeden výrobce použije jinou část funkcionality bloku než jiný.

    Nedávno jsem v jádře viděl konzolidační práce, které mi dávají za pravdu. Když se pročišťoval subsystém přerušení, všiml jsem si, že jsou tam pouze dva široce používané typy řadičů přerušení. Bez velké snahy bylo možné nahradit kód pro více než třicet odlišných implementací „tak odlišných“ čipů implementací obecnou. Chystá se podobná snaha nahradit neustále se opakující vzory v kódu pro podporu GPIO čipů. To je nejméně pracné a potenciálu pro konzolidaci je mnohem více.

    Vyhýbání se zbytečné práci

    link

    Řešení věcí se správci a často omezený čas na revize se považují za úzké hrdlo. Práce navíc, která je důsledkem komentářů revidovatelů, se také považuje za plýtvání časem. Počet správců a čas dostupný pro revize je skutečně omezujícím faktorem a je potřeba to řešit. Možnost revidovat není omezena na lidi, kteří spravují daný subsystém jádra a rádi bychom viděli, kdyby se na revidování podílelo více lidí. Strávit trochu času revidováním kódu jiných lidí je velmi prospěšné, protože to umožňuje seznámit se s jinými postupy a lépe pochopit celkový obraz.

    Na druhou stranu nechat svůj kód revidovat někým jiným je také prospěšné, obecně to vede k lepšímu a lépe udržovatelnému kódu. Také to pomáhá vyhnout se chybám u příštího projektu. V nedávné revizi, která prošla několika opakováními, se 1200 řádků dlouhý ovladač zmenšil na 250 řádek a přitom bylo opraveno několik chyb a významných omylů.

    Když mám příležitost mluvit s vývojáři po dlouhém procesu revidování, většina z nich souhlasí, že příležitost naučit se a pochopit více z toho, jakým způsobem probíhá vývoj Linuxu, významně převyšuje problémy vzešlé z revizí a nutné přepracování kódu. Když se potom podívám na patche od stejných vývojářů, je vidět, že se zlepšili a že se již vyhýbají chybám, které udělali při svých prvních pokusech. Revidování je tedy prospěšné pro vývojáře i pro jeho zaměstnavatele, protože to pomáhá napsat lepší kód efektivněji. Prohlašuji, že ti, kdo stále tvrdí, že revize a práce z nich vycházející jsou významnou překážkou, jsou pokrytci, kteří se snaží shodit vinu za nedostatky ve vlastní firmě na jadernou komunitu.

    Jedním nedostatkem je přiřadit vývojáře proprietárních RTOS k psaní linuxového jaderného kódu, aniž by byl poučen o tom, jak s spolupracovat s komunitou. Není žádné zneuctění to nevědět; každý vývojář jádra včetně mě začal s tím, že to nevěděl. Zabralo mi čas, než jsem se to naučil a stejně tak to zabere čas vývojářům proprietárních RTOS; ten čas i snaha za to ale stojí.

    Co by se vyřešilo forkem ARM jádra?

    link

    Předpokládejme, že by existoval specifický gitový repozitář pro ARM, který by fungoval jako smetiště pro všechny stromy výrobců. Jednou za čas by přetahoval zlepšení z reálného stromu hlavní řady, takže by lidé od embedded zařízení získávali nové souborové systémy, vlastnosti síťování atd. Pokud extrapolujeme nedávný tok patchů pro podporu SoC do Linuxu a vynecháme všechny kontroly, výsledkem bude takové tempo růstu, že by strom ARM rychle překonal tempo růstu hlavní řady jako takové. Ale co když vylepšení v hlavní řadě bude vyžadovat změnu v každém ovladači v ARM stromě, jako to vyžadovala moje nedávná práce? Kdo ty změny udělá? Pokud jsou ovladače v hlavní řadě, součástí zlepšení je i změna ovladačů. Pokud by existoval oddělený fork pro ARM, takové změny by musel dělat nějaký správce.

    A kdo bude takový strom udržovat? Mám vážné pochyby o tom, že by se z ničeho nic objevilo dostatečné množství kvalifikovaných správců, kteří by byli dost rychlí a měli dost zkušeností na to, aby se vypořádali s takovou povodní změn. Aby se tedy odbouralo úzké hrdlo, které je jednou ze stížností na práci s hlavní řadou, museli by tito správci pravděpodobně převzít roli pouhých integrátorů, kteří spojují jednotlivé stromy na jednom místě.

    Jaký zisk by z něčeho takového plynul? Co vidím já, tak žádný, akorát by to všem umožnilo tvrdit, že jejich kód je součástí tajemného ARM gitového stromu a samozřejmě by to splnilo nejdůležitější požadavek na dobu do dodání na trh. Alespoň krátkodobě.

    Jak dlouho by byl ARM fork udržitelný?

    link

    Vážně pochybuji o tom, že by fork ARM fungoval déle než několik vývojových cyklů jádra, jednoduše proto, že by změny základního kódu vyústily v naprosto neudržovatelný zmatek #ifdef s nekompatibilními API specifickými pro SoC, který by přivedl každého, kdo by takové monstrum musel „udržovat“, k šílenství. Jsem si docela jistý, že nikdo z obhájců forku ARM se nikdy nepokoušel přetáhnout pět kompletních stromů od výrobců do jednoho jádra a následně řešit konflikty změn v API DMA, subsystému ovladačů a infrastruktuře. Vím, že správci embedded distribučních jader jsou přesně z těchto důvodů téměř okamžitě zoufalí a pochybuji, že nějaký dostatečně rozumný vývojář jádra je dost šílený, aby se s takovou hrůzou byl schopen vypořádávat déle než několik měsíců.

    Krom toho, že užitečnost takového stromu je pochybná, fork ARM by odtrhl svět ARM zařízení od možnosti ovlivňovat celkový směr, kterým se pohybuje linuxové jádro. ARM by pro většinu zkušených správců z hlavní řady byl něco, o co se nemusí zajímat, stejně jako je to u jiných projektů mimo strom. Pochybuji o tom, že by si ARM průmysl mohl dovolit takto se oddělit, obzvláště vzhledem k tomu, že složitost software na úrovni operačního systému se neustále zvyšuje.

    Je lepší možnost?

    link

    Nikdy není žádná konečná odpověď, který by magicky vyřešila všechny problémy, ale je spousta malých, které dokáží efektivně vyřešit hlavní problémy.

    Jedna z hlavních příčin současného stavu je historická. Více než dvacet let se průmysl potýkal s uzavřenými operačními systémy, kde změny základního kódu nebyly možné a spolupráce s konkurencí nemyslitelná a nepoužitelná. Teď i po přechodu na Linux v průmyslu stále tento dobře známý model používají a nechají své techniky – kteří často před prací na Linuxu pracovali na jiných operačních systémech – pracovat stejným způsobem i nadále. Je to perfektivní řešení i pro management, protože existující struktury a myšlenka vývoje a správy softwaru shora dolů [top-down] platí i nadále.

    To „funguje“, dokud není potřeba výsledný kód integrovat do hlavní řady a dokud si každý výrobce udržuje samostatný fork. Existují ale rozumné požadavky zákazníků, aby byl kód integrován v hlavní řadě, protože to zjednodušuje přijímaní nových vlastností, omezují se závislosti na zmrazených jádrech výrobců a – jak je vidět v poslední době – umožňuje to konzolidaci směrem k multiplatformním jádrům. To poslední je důležité, protože to umožňuje rozumnou distribuci práce na netbooky, tablety a podobná zařízení. To platí ještě více vzhledem ke spekulacím o ARM serverech, o kterých se předpokládá, že se v blízké budoucnosti objeví. Taková konzolidace vyžaduje nejenom kooperaci mezi jednotlivými výrobci ARM zařízení, vyžaduje to i spolupráci mezi mnoha součástmi hlavní řády jádra a vstup od správců a vývojářů, kteří nutně nemusí být součástí světa ARM.

    Potřebujeme tedy managementu pomoci pochopit, že držet se známých modelů není efektivním způsobem, jak se vypořádat s rostoucí složitostí SoC hardware a s výzvami spojenými s efektivním a udržitelným vývojem operačního systému ve světě open source. A zároveň s tím potřebujeme vysvětlit na technické úrovni, že pracovat s Linuxem stejným způsobem jako s ostatními platformami jim ztěžuje život a je to přinejmenším částečně odpovědné za smutky, které lze vidět, když se se kód objeví v mailové konferenci kvůli revizím.

    Další oblastí, na které je potřeba pracovat, je masivní konzolidace spolupráce, což znamená zajistit, aby výrobci hardwaru přijali fakt, že přinejmenším na úrovni návrhu operačního systému nejsou jejich SoC tak unikátní, jak by jim marketingové oddělení chtělo namluvit. Jak jsem vysvětlil výše, je jenom omezený počet způsobů, jak v hardwaru implementovat danou funkcionalitu, což obzvláště platí pro hardware na nízké úrovni složitosti. Potřebujeme tedy vývojáře podporovat v tom, aby se nejprve podívali, jestli by bylo možné refaktorovat existující kód tak, aby ho bylo možné použít pro nové zařízení, místo toho, aby se slepě zkopíroval nejlépe odpovídající ovladač – nebo přinejhorším náhodný ovladač – a nějak se přehackoval do potřebné podoby.

    Tomu by měli více věnovat pozornost i vývojáři jádra a pomoci vyhnout se znovuvynalézání kola. Pokud nelze znovu využít ovladač, často lze přesunout společnou funkcionalitu do základního kódu a duplikaci se vyhnout takto. V tomto ohledu je věcí, kde se to dá udělat snadno, hodně a komunita okolo Linuxu potřebuje více využívat mozkové cykly k tomu, aby se omezila duplikace.

    Jedním krokem v této oblasti jsou snahy o konzolidaci ARM SoC, které započalo Linaro. To ale uspěje jenom v případě, že si budeme vědomi existujících konfliktů s korporátní kulturou a těmto konfliktům se budeme věnovat i na netechnické úrovni.

    Tajnosti

    link

    Kromě výše zmíněných problémů bude významnou výzvou bariéra tajností. Výrobce samozřejmě dělá tajnosti ohledně detailů návrhu příští generace SoC, ale informace, které jsou odhaleny v marketingovém oznámení, nám umožňují poměrně přesně předvídat přinejmenším některé jeho části.

    Nejlepším případem z poslední doby jsou příští generace ARM SoC od různých výrobců, které mají přijít na trh koncem roku 2011. Mnoho z nich bude mít podporu USB 3.0. Když se podíváme na nabídky výrobců IP bloků, zjistíme, že nabízených IP bloků je méně než prodejců SoC, kteří oznámili nové čipy s podporou USB 3.0. To znamená, že se pracuje na duplicitních ovladačích a jsem si jistý, že i když o tom technici ví, mají zakázáno komunikovat s týmy od konkurence. A i kdyby mohli, není možné zjistit, kdo použije jaký IP blok. Takže až bude za pár měsíců zvednuta opona tajností, uvidíme několik týmů, které se budou hádat o „správné“ implementaci, která má být začleněna do hlavní řady.

    Soupeřící implementace nejsou jako takové špatnou věcí, ale nemožnost výměny informací a diskuze o variantách návrhu nikomu v závodu o čas do uvedení na trh nepomůže. Vážně pochybuji o tom, že některý z budoucích ovladačů bude mít relevantní konkurenční výhodu. A i kdyby ano, ta od zveřejnění nevydrží dlouho. Je smutné že se příležitosti spolupracovat a ušetřit drahý čas vývojářů pro všechny zúčastněné obětuje ve prospěch historických na soupeření orientovaných vzorů chování. Tyto vzory se nezměnily od doby před dvaceti či více lety, kdy byly vynalezeny, a nikdy je nikdo nepodrobil zkoumání v kontextu konkurence na hřišti vývoje otevřeného operačního systému.

    Cesta kupředu

    link

    Neustále se zvyšující složitost hardware, která následně vede na složitější software na úrovni operačního systému, způsobila nedostatek kvalifikovaných vývojářů operačních systémů. To nelze vyvážit ani penězi ani nasazením velkého počtu levných vývojářů. Svět ARM je dostatečně diverzifikován na to, aby žádný z výrobců neměl šanci pořídit si dost jaderných vývojářů a způsobit tak vážnou škodu konkurenci. To je ještě umocněno faktem, že většina z těchto vývojářů raději pracuje v otevřeném než v polouzavřeném prostředí.

    Je čas, aby si manažeři znovu promysleli konkurenční modely a začali chápat a využívat masivní výhodu spolupracujících modelů oproti historickému a již nefungujícímu modelu, který předpokládá neomezenou dostupnost pracovních sil, když do ringu hodíte dost peněz. Schopní vývojáři jistě jen tak nezahodí příležitost získat příjem navíc, ale možnost získat lepší pracovní prostředí za cenu o něco menšího příjmu je pro ně silnou motivací pokušení odolat. Zajímavá je pro mě myšlenka, že žádné howto pro „čas do uvedení na trh“, příručka pro „hodnotu akcií“ ani kurz „řízení lidských zdrojů“ neberou v potaz, že lidé jsou o něco méně úplatní, než se obecně myslí; obzvláště když se jedná o lidi, kteří jsou jedním z nejméně dostupných zdrojů v tomto průmyslu.

    Doufám, že manažeři pracující pro výrobce embedded zařízení začnou chápat, jak funguje otevřený software a proč se hodně vyplatí spolupráce s komunitou. Konec konců těžkopádní výrobci serverů na to přišli, takže pro rychle se pohybující oblast embedded zařízení to nemůže být tak těžké. Realista ve mě – občas se mu říká „starý bručoun“ – který v embedded průmyslu pracoval více než dvacet pět let, tomu nevěří vůbec. Příliš mnoho výrobců SoC se rozhodlo „spolupracovat“ s komunitou kvůli tlaku z vnějšku a kvůli posedlosti držet se aktuálních trendů.

    Tlak z vnějšku nemusí být to, v co příznivci otevřeného software mohou doufat: tím je vliv samotné komunity. Ne, jedná se jednoduše o tlak (významných) zákazníků, kteří požadují, aby byl čip – alespoň základně – podporován hlavní řadou jádra. Následování trendů je všudypřítomné a vždy se to zdá být platným argumentem pro to vyhnout se rozhodnutím založeným na zdravém rozumu se zvážením dlouhodobých důsledků.

    Věčný optimista ve mně stále doufá, že se svět embedded zařízení stane občanem první třídy v linuxové komunitě spíše dříve než později. Realista ve mě tak nějak pochybuje, že se to stane dřív, než „starý bručoun“ odejde do důchodu.

           

    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ář

    13.6.2011 08:38 Honz
    Rozbalit Rozbalit vše Re: Jaderné noviny – 3. 6. 2011: Proč neforkovat jádro kvůli ARM
    "Také jaké jsou velké změny?" Má tam být "tak"?
    13.6.2011 10:31 Dusan | skóre: 23 | blog: Moje_trable_s_internetom
    Rozbalit Rozbalit vše Re: Jaderné noviny – 3. 6. 2011: Proč neforkovat jádro kvůli ARM
    Nie som síce vývojár/programátor, ale po prečítaní príspevku "Fork ARM jádra?" od Thomas Gleixner my skoro padla sánka.

    +1000
    13.6.2011 13:58 dopisovatel | blog: zpravicky
    Rozbalit Rozbalit vše Re: Jaderné noviny – 3. 6. 2011: Proč neforkovat jádro kvůli ARM
    Články od jirky bourka jsou už dlouhou dobu stabilně to nejlepší, co tady na abclinuxu existuje.
    15.6.2011 14:51 Aminux
    Rozbalit Rozbalit vše Re: Jaderné noviny – 3. 6. 2011: Proč neforkovat jádro kvůli ARM
    Ale diskuse pod článkem tomu moc neodpovídá. Skoro se divím, že už se na to autor dávno nevyfláknul. Kdybych psal podobně kvylitní články a měl bych takovouto odezvu, už bych se na to dávno vyprd.
    13.6.2011 20:44 olgo
    Rozbalit Rozbalit vše Re: Jaderné noviny – 3. 6. 2011: Proč neforkovat jádro kvůli ARM
    Naprostý súhlas
    13.6.2011 10:34 pet
    Rozbalit Rozbalit vše Re: Jaderné noviny – 3. 6. 2011: Proč neforkovat jádro kvůli ARM
    Tento dil sice obsahuje vice chybicek nez dily jine, ale jeho informacni hodnota je stale a stabilne prevazuje.

    Diky za cely serial a jen tak dal!
    13.6.2011 14:01 dopisovatel | blog: zpravicky
    Rozbalit Rozbalit vše Re: Jaderné noviny – 3. 6. 2011: Proč neforkovat jádro kvůli ARM
    Ty chybičky jsou jen proto, že abclinuxu nemá nikoho, komu by se dalo říkat redaktor. Ovšem seriál jako takový je výborný, protože jirka bourek je člověk na svém místě.
    13.6.2011 10:56 melkors | skóre: 13 | blog: kdo_chce_kam
    Rozbalit Rozbalit vše Re: Jaderné noviny – 3. 6. 2011: Proč neforkovat jádro kvůli ARM
    "... komunita okolo Linuxu potřebuje více využívat mozkové cykly ..."

    Was ist das "mozkove cykly"? Nemelo by byt zavity?
    13.6.2011 11:27 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Jaderné noviny – 3. 6. 2011: Proč neforkovat jádro kvůli ARM
    Já to chápu jako strojové cykly ale u člověka...
    Quando omni flunkus moritati
    Grunt avatar 13.6.2011 11:02 Grunt | skóre: 22 | blog: Expresivní zabručení | Lanžhot
    Rozbalit Rozbalit vše Re: Jaderné noviny – 3. 6. 2011: Proč neforkovat jádro kvůli ARM
    Také jaké jsou velké změny? ŽÁDNÉ. Absolutně žádné. Jasně, jako obvykle jsou dvě třetiny změny ovladačů, pak je tu spousta náhodných věcí, ale klíčové je, že 3.0 je jenom přečíslování
    Ach jo. To je lečo. Tak proč to proboha dělá? Mě je jasné, že on se v tom vyzná, ale jak zas budu sakra vysvětlovat, že víc změn se událo i v přechodu z 3.0.0 na 3.0.1 než z 2.6.39 na 3.0 a, že 3.0 automaticky neznamená „Super-stable brand-new next-generation line, který prostě musíš mít“ a že je to jen další z dlouhé řady a že to číslo vlastně nic neznamená. Prostě existují i lidé s znalostmi elementární matematiky, kteří se v ničem jiném než v těch číslech nevyznají. Proč nemyslí Linus i na ně?

    Doufám, že manažeři pracující pro výrobce embedded zařízení začnou chápat…

    Je čas, aby si manažeři znovu promysleli konkurenční modely a začali chápat a využívat masivní výhodu spolupracujících modelů oproti historickému a již nefungujícímu modelu

    LOL, to je snílek. To jsem zvědavý jestli kdy vůbec ten bordel v ARM stromu zmizne.
    Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
    13.6.2011 11:39 R
    Rozbalit Rozbalit vše Re: Jaderné noviny – 3. 6. 2011: Proč neforkovat jádro kvůli ARM
    3.0->3.0.1 nebude obsahovat viac zmien ako 2.6.39->3.0.
    Grunt avatar 13.6.2011 11:42 Grunt | skóre: 22 | blog: Expresivní zabručení | Lanžhot
    Rozbalit Rozbalit vše Re: Jaderné noviny – 3. 6. 2011: Proč neforkovat jádro kvůli ARM
    Další astrolog nebo se prostě někdo vrátil z dovolené z Delf?
    Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
    Grunt avatar 13.6.2011 11:42 Grunt | skóre: 22 | blog: Expresivní zabručení | Lanžhot
    Rozbalit Rozbalit vše Re: Jaderné noviny – 3. 6. 2011: Proč neforkovat jádro kvůli ARM
    BTW: Proč?
    Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
    13.6.2011 11:49 R
    Rozbalit Rozbalit vše Re: Jaderné noviny – 3. 6. 2011: Proč neforkovat jádro kvůli ARM
    Lebo 3.0.1 bude len -stable (ako napr. 2.6.39.1). Dalsia mainline verzia bude 3.1.
    Grunt avatar 13.6.2011 11:51 Grunt | skóre: 22 | blog: Expresivní zabručení | Lanžhot
    Rozbalit Rozbalit vše Re: Jaderné noviny – 3. 6. 2011: Proč neforkovat jádro kvůli ARM
    Ach jo. Jdu se pověsit za koule do průvanu. To má větší smysl.
    Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
    13.6.2011 11:13 kip | skóre: 8 | blog: kip | Nový Jičín
    Rozbalit Rozbalit vše Re: Jaderné noviny – 3. 6. 2011: Proč neforkovat jádro kvůli ARM
    V půlce pátého odstavce kapitolky Je lepší možnost? jsou přehozené "d" a "w" v "harwdare".
    13.6.2011 14:02 dopisovatel | blog: zpravicky
    Rozbalit Rozbalit vše Re: Jaderné noviny – 3. 6. 2011: Proč neforkovat jádro kvůli ARM
    Jak říkám výše, není tu redaktor na plný úvazek. Přitom vhodných osob by se našlo...
    Luboš Doležel (Doli) avatar 13.6.2011 14:23 Luboš Doležel (Doli) | skóre: 98 | blog: Doliho blog | Kladensko
    Rozbalit Rozbalit vše Re: Jaderné noviny – 3. 6. 2011: Proč neforkovat jádro kvůli ARM
    Z čeho by se to platilo? Já to dělám zadarmo a i tak je za letošek Abc ve ztrátě.
    13.6.2011 16:21 Dalibor Malina | blog: bigblog
    Rozbalit Rozbalit vše Re: Jaderné noviny – 3. 6. 2011: Proč neforkovat jádro kvůli ARM
    Že se do toho pletu. Ale loni tu Robert Krátký psal, že řada autorů odmítla honoráře za články (asi v době, když dělal redaktora). Takže šetřit se možná dá i tím směrem.
    Luboš Doležel (Doli) avatar 13.6.2011 16:41 Luboš Doležel (Doli) | skóre: 98 | blog: Doliho blog | Kladensko
    Rozbalit Rozbalit vše Re: Jaderné noviny – 3. 6. 2011: Proč neforkovat jádro kvůli ARM
    Takoví také jsou, ale většina si přivydělat chce :-)
    13.6.2011 14:29 Václav HFechs Švirga | skóre: 26 | blog: HF | Kopřivnice
    Rozbalit Rozbalit vše Re: Jaderné noviny – 3. 6. 2011: Proč neforkovat jádro kvůli ARM
    Jsi samozvolený mluvčí abclinuxu?
    Baník pyčo!
    13.6.2011 19:41 dopisovatel | blog: zpravicky
    Rozbalit Rozbalit vše Re: Jaderné noviny – 3. 6. 2011: Proč neforkovat jádro kvůli ARM
    To se ptáš sám sebe?
    14.6.2011 12:23 Václav HFechs Švirga | skóre: 26 | blog: HF | Kopřivnice
    Rozbalit Rozbalit vše Re: Jaderné noviny – 3. 6. 2011: Proč neforkovat jádro kvůli ARM
    Trapné (raději upřesním: TEBE považuji za trapného).
    Baník pyčo!
    13.6.2011 15:28 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Jaderné noviny – 3. 6. 2011: Proč neforkovat jádro kvůli ARM
    Mám ten pocit, že jsem tu někde viděl, že tohle je komunitní portál o Linuxu. Tak se komunita může posnažit, kdo najde chybu, tak na ni upozorní, Luboš to opraví.
    Quando omni flunkus moritati
    13.6.2011 19:42 dopisovatel | blog: zpravicky
    Rozbalit Rozbalit vše Re: Jaderné noviny – 3. 6. 2011: Proč neforkovat jádro kvůli ARM
    Nechme toho, podstatné je, že Jirka Bourek je výborný autor.
    13.6.2011 21:09 Filip Jirsák | skóre: 67 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Jaderné noviny – 3. 6. 2011: Proč neforkovat jádro kvůli ARM
    Je hezké psát to pod články, které překládá. Ne že by to snižovalo hodnotu jeho práce, ale sem by se hodilo spíš poděkovat za jeho překlady.
    14.6.2011 15:56 dopisovatel
    Rozbalit Rozbalit vše Re: Jaderné noviny – 3. 6. 2011: Proč neforkovat jádro kvůli ARM
    Takže děkuji za jeho překlady.
    Heron avatar 14.6.2011 10:05 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Jaderné noviny – 3. 6. 2011: Proč neforkovat jádro kvůli ARM
    Nejsem jsi uplně jistý zda víš, na koho jsi teď reagoval.
    14.6.2011 15:58 dopisovatel
    Rozbalit Rozbalit vše Re: Jaderné noviny – 3. 6. 2011: Proč neforkovat jádro kvůli ARM
    Zajímá mne především kvalita článku a nestarám se, kdo je autor a jakou má přezdívku.
    belisarivs avatar 14.6.2011 11:17 belisarivs | skóre: 22 | blog: Psychobláboly
    Rozbalit Rozbalit vše Re: Jaderné noviny – 3. 6. 2011: Proč neforkovat jádro kvůli ARM
    Ehm, vis na koho reagujes?
    IRC is just multiplayer notepad.
    belisarivs avatar 14.6.2011 11:17 belisarivs | skóre: 22 | blog: Psychobláboly
    Rozbalit Rozbalit vše Re: Jaderné noviny – 3. 6. 2011: Proč neforkovat jádro kvůli ARM
    Fsck. To je tak, kdyz delam refresh jednou za sto let.
    IRC is just multiplayer notepad.
    15.6.2011 08:11 filbar | skóre: 36 | blog: Denicek_programatora | Ostrava
    Rozbalit Rozbalit vše Re: Jaderné noviny – 3. 6. 2011: Proč neforkovat jádro kvůli ARM
    Nevíte někdo co to jsou ty IP bloky?
    15.6.2011 08:17 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Jaderné noviny – 3. 6. 2011: Proč neforkovat jádro kvůli ARM
    Intelectual Property. V podstatě je to produkt firmy, která nevyrábí žádné zařízení, ale jenom (zjednodušeně) schéma zapojení nějakého funkčního bloku (třeba zmíněného řadiče USB). Výrobce skutečného zařízení si tohle koupí a aniž by musel cokoliv vymýšlet, flákne to na čip a má USB vyřešené.

    Quando omni flunkus moritati

    Založit nové vláknoNahoru

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