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 13:00 | Komunita

Do 30. října se lze přihlásit do dalšího kola programu Outreachy (Wikipedie), jehož cílem je přitáhnout do světa svobodného a otevřeného softwaru lidi ze skupin, jež jsou ve světě svobodného a otevřeného softwaru málo zastoupeny. Za 3 měsíce práce, od 4. prosince 2018 do 4. března 2019, v participujících organizacích lze vydělat 5 500 USD.

Ladislav Hagara | Komentářů: 0
včera 22:22 | Komunita

Společnost Purism představila kryptografický token Librem Key. Koupit jej lze za 59 dolarů. Token byl vyvinut ve spolupráci se společností Nitrokey a poskytuje jak OpenPGP čipovou kartu, tak zabezpečení bootování notebooků Librem a také dalších notebooků s open source firmwarem Heads.

Ladislav Hagara | Komentářů: 1
včera 20:33 | Nová verze

Společnost NVIDIA oficiálně vydala verzi 10.0 toolkitu CUDA (Wikipedie) umožňujícího vývoj aplikací běžících na jejich grafických kartách. Přehled novinek v poznámkách k vydání.

Ladislav Hagara | Komentářů: 0
včera 20:00 | Upozornění

Příspěvek Jak přežít plánovanou údržbu DNS na blogu zaměstnanců CZ.NIC upozorňuje na historicky poprvé podepsání DNS root zóny novým klíčem dne 11. října 2018 v 18:00. Software, který nebude po tomto okamžiku obsahovat nový DNSSEC root klíč, nebude schopen resolvovat žádná data. Druhým důležitým datem je 1. února 2019, kdy významní výrobci DNS softwaru, také historicky poprvé, přestanou podporovat servery, které porušují DNS standard

… více »
Ladislav Hagara | Komentářů: 5
včera 15:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 156. brněnský sraz, který proběhne v pátek 21. září od 18:00 v restauraci Na Purkyňce na adrese Purkyňova 80.

Ladislav Hagara | Komentářů: 0
včera 13:22 | Nová verze

Alan Griffiths z Canonicalu oznámil vydání verze 1.0.0 display serveru Mir (GitHub, Wikipedie). Mir byl představen v březnu 2013 jako náhrada X serveru a alternativa k Waylandu. Dnes Mir běží nad Waylandem a cílen je na internet věcí (IoT).

Ladislav Hagara | Komentářů: 0
20.9. 22:00 | Nasazení Linuxu
Stabilní aktualizace Chrome OS 69 (resp. Chromium OS), konkrétně 69.0.3497.95, přináší mj. podporu linuxových aplikací. Implementována je pomocí virtualizace, a proto je tato funkce také omezena na zařízení s dostatkem paměti a podporou hardwarové akcelerace, tudíž nejsou podporovány chromebooky s 32bitovými architekturami ARM, či Intel Bay Trail (tzn. bez Intel VT-x).
Fluttershy, yay! | Komentářů: 5
20.9. 21:32 | Zajímavý projekt

Došlo k uvolnění linuxové distribuce CLIP OS, vyvíjené francouzským úřadem pro kybernetickou bezpečnost ANSSI, jako open source. Vznikla za účelem nasazení v úřadech, kde je potřeba omezit přístup k důvěrným datům. Je založená na Gentoo.

Fluttershy, yay! | Komentářů: 1
20.9. 16:00 | Komerce

Zjistěte více o bezpečné a flexibilní architektuře v cloudu! IBM Cloud poskytuje bezpečné úložiště pro Vaše obchodní data s možností škálovatelnosti a flexibilitou ukládání dat. Zároveň nabízí prostředky pro jejich analýzu, vizualizaci, reporting a podporu rozhodování.

… více »
Fluttershy, yay! | Komentářů: 12
20.9. 12:22 | Nová verze

V dubnu letošního roku Mozilla představila webový prohlížeč pro rozšířenou a virtuální realitu Firefox Reality (GitHub). V úterý oznámila vydání verze 1.0. Ukázka na YouTube. Firefox Reality je k dispozici pro Viveport, Oculus a Daydream.

Ladislav Hagara | Komentářů: 2
Na optické médium (CD, DVD, BD aj.) jsem naposledy vypaloval(a) data před méně než
 (13%)
 (14%)
 (21%)
 (23%)
 (25%)
 (4%)
 (1%)
Celkem 387 hlasů
 Komentářů: 33, poslední 16.9. 11:55
Rozcestník

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

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

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: 23 | 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: 23 | 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: 23 | 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: 23 | 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.