Byla vydána verze R14.1.2 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5). Přehled novinek v poznámkách k vydání, podrobnosti v seznamu změn.
Dnešním dnem lze již také v Česku nakupovat na Google Store (telefony a sluchátka Google Pixel).
Apple představil (keynote) iPad Pro s čipem Apple M4, předělaný iPad Air ve dvou velikostech a nový Apple Pencil Pro.
Richard Biener oznámil vydání verze 14.1 (14.1.0) kolekce kompilátorů pro různé programovací jazyky GCC (GNU Compiler Collection). Jedná se o první stabilní verzi řady 14. Přehled změn, nových vlastností a oprav a aktualizovaná dokumentace na stránkách projektu. Některé zdrojové kódy, které bylo možné přeložit s předchozími verzemi GCC, bude nutné upravit.
Free Software Foundation zveřejnila ocenění Free Software Awards za rok 2023. Vybráni byli Bruno Haible za dlouhodobé příspěvky a správu knihovny Gnulib, nováček Nick Logozzo za front-end Parabolic pro yt-dlp a tým Mission logiciels libres francouzského státu za nasazování svobodného softwaru do praxe.
Před 10 lety Microsoft dokončil akvizici divize mobilních telefonů společnosti Nokia a pod značkou Microsoft Mobile ji zanedlouho pohřbil.
Fedora 40 release party v Praze proběhne v pátek 17. května od 18:30 v prostorách společnosti Etnetera Core na adrese Jankovcova 1037/49, Praha 7. Součástí bude program kratších přednášek o novinkách ve Fedoře.
Stack Overflow se dohodl s OpenAI o zpřístupnění obsahu Stack Overflow pro vylepšení OpenAI AI modelů.
AlmaLinux byl vydán v nové stabilní verzi 9.4 (Mastodon, 𝕏). S kódovým názvem Seafoam Ocelot. Přehled novinek v příspěvku na blogu a v poznámkách k vydání.
Před 50 lety, 5. května 1974 v žurnálu IEEE Transactions on Communications, Vint Cerf a Bob Kahn popsali protokol TCP (pdf).
Současné vývojové jádro je 3.0-rc1 vydané 29. května. Linus řekl:
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.
'abyste se mohli zabezpečit, musíte být privilegovaní'
-- Ingo Molnár
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á!
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.
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 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.
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?
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.
Ř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í.
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ě.
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.
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.
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.
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.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
13.6.2011 11:02
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
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ě?
LOL, to je snílek. To jsem zvědavý jestli kdy vůbec ten bordel v ARM stromu zmizne.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
13.6.2011 11:42
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
13.6.2011 11:42
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
13.6.2011 11:51
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
13.6.2011 14:23
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
13.6.2011 16:41
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
14.6.2011 10:05
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
14.6.2011 11:17
belisarivs | skóre: 22
| blog: Psychobláboly
14.6.2011 11:17
belisarivs | skóre: 22
| blog: Psychobláboly
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz