Byla vydána verze 0.2.0 v Rustu napsaného frameworku Pingora pro vytváření rychlých, spolehlivých a programovatelných síťových systémů. Společnost Cloudflare jej letos v únoru uvolnila pod licencí Apache 2.0.
Open source RDP (Remote Desktop Protocol) server xrdp (Wikipedie) byl vydán ve verzi 0.10.0. Z novinek je vypíchnuta podpora GFX (Graphic Pipeline Extension). Nová větev řeší také několik bezpečnostních chyb.
Rocky Linux byl vydán v nové stabilní verzi 9.4. Přehled novinek v poznámkách k vydání.
Dellu byla odcizena databáze zákazníků (jméno, adresa, seznam zakoupených produktů) [Customer Care, Bleeping Computer].
V lednu byl otevřen editor kódů Zed od autorů editoru Atom a Tree-sitter. Tenkrát běžel pouze na macOS. Byl napevno svázán s Metalem. Situace se ale postupně mění. V aktuálním příspěvku Kdy Zed na Linuxu? na blogu Zedu vývojáři popisují aktuální stav. Blíží se alfa verze.
O víkendu 11. a 12. května lze navštívit Maker Faire Prague, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Byl vydán Fedora Asahi Remix 40, tj. linuxová distribuce pro Apple Silicon vycházející z Fedora Linuxu 40.
Představena byla služba Raspberry Pi Connect usnadňující vzdálený grafický přístup k vašim Raspberry Pi z webového prohlížeče. Odkudkoli. Zdarma. Zatím v beta verzi. Detaily v dokumentaci.
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).
Aktuální vývojovou verzí jádra je 3.1-rc5 vydané 4. září. Pokračující problémy na kernel.org zapříčinily, že toto vydání je hostované na neobvyklém místě.
master.kernel.org je však stále mimo provoz a moc aktivně se nevyvíjelo, takže jsem uvažoval nad tím, že prostě přeskočíme jeden týden. Jenže celým smyslem (no dobře, *jedním* ze smyslů) distribuovaného vývoje je to, že jedno místo není ve skutečnosti odlišné od kteréhokoliv jiného, takže když už jsem si udělal účet na githubu pro můj divelog [záznam potápění], proč nevyzkoušet, jestli to vydrží, když tam dám celý repozitář jádra?
Ze zjevných důvodů není na kernel.org aktuálně dostupný kompletní seznam změn.
Stabilní aktualizace: během uplynulého týdne nevyšly žádné stabilní aktualizace a ani se žádné nerevidují.
Není možné vyloženě říct, že mnoho distributorů Androidu již nemá právo distribuovat Linux. Ale nelze také vyloženě říct, že o toto právo nepřišli. Libovolný dostatečně motivovaný držitel autorských práv v jádře by se mohl pravděpodobně zapojit do značně efektivního nájezdu proti dodavatelům Androidu. Jestli to udělají, to se ještě uvidí, ale, upřímně, kdybych byl dodavatelem Androidu, měl bych obavy. Je zde řada lidí, kteří drží autorská práva na značné části jádra. Opravdu byste si vsadili, že všichni z nich jsou lidé s velkou ctí?
Myslím si, že bychom se rozhodně měli podívat na naše postupy, ale já osobně přesto vkládám mnoho důvěry do „mezilidských vztahů“.
Často více než do „technických modelů“.
Takže obyčejné lidské „toto vypadá jako ten typ požadavku o přetažení, jaký očekávám“ je dosti bezpečné. Mnoho jaderných vývojářů píše hezké zprávy vysvětlující přetažení a v takovém textu nemusí být kryptografický podpis, ale je tam rozhodně „lidský podpis“, který pak začnete očekávat.
Kernelroll je jaderný modul pro Linux pro pokročilé rickrollování. Funguje tak, že opatchuje systémové volání open() tak, aby došlo k otevření vybraného hudebního souboru namísto jiných hudebních souborů. Aktuálně hlídá jen příponu „mp3“ a následně zavolá původní open() s určenou cestou.
-- „fpletz“; zařazení do hlavní řady jádra není zaručeno
napsal Jonathan Corbet
LWN se nedávno zabývalo diskuzí kolem přesunu bezdrátového ovladače Broadcom do hlavní řady ze staging. Tento ovladač vede k řadě otázek kolem toho, jak komunita jádra spolupracuje s výrobci hardwaru. Jeden důležitý aspekt této diskuze se ale zatím nedostal na povrch. Od ovladačů pro Linux se očekává, že jsou jen pro Linux. Pokusy o údržbu linuxového ovladače jako multiplatformního ovladače povedou z několika důvodů k neštěstí. Následuje článek, který zcela bez rozpaků zdůvodňuje, proč se multiplatformní ovladače do linuxového jádra nehodí.
S problémem přišel vývojář Broadcomu Henry Ptasinski, když psal o tom, proč společnost nemá zájem podporovat ovladač b43, který je v hlavní řadě jádra:
Ovladač brcmsmac je architektonicky v souladu s našimi ovladači pro ostatní operační systémy a máme v plánu tento ovladač udržovat souběžně s ovladači pro ostatní operační systémy. Údržba tohoto souladu mezi naším ovladačem pro Linux a ovladači pro jiné operační systémy nám umožní nabídnout podporu funkcí a čipů napříč platformami.
Vývojářům, kteří s jádrem už nějakou dobu pracují, toto zní jako elementární chyba. Ostatním ale přijde v pořádku: pokud chce Broadcom podporovat svůj hardware, proč je nenechat dělat to po svém?
Jednoznačným problémem při snaze udržovat „architektonický soulad“ s ovladači pro ostatní operační systémy je to, že jen původní firma je schopna tento soulad udržovat. Ostatní spolčené ovladače téměř jistě nejsou open source; nikdy jiný z komunity nemůže vědět, jaké změny jsou v souladu s těmito ovladači a jaké ne. Dokonce ani správce dotečného subsystému není schopen dělat taková rozhodnutí.
Je také nutné vzít v úvahu to, že většina ostatních vývojářů jádra není nijak motivována – a ani na tom nemá zájem – udržovat soulad mezi ovladači, i kdyby věděli, jak na to.
Jasným závěrem je to, že pokud máme ponechat výrobce, aby ve stromě jádra udržoval multiplatformní ovladač, tak musí mít nad kódem naprostou kontrolu. Pokud budou ostatní moci dělat libovolné změny, tak výrobce nebude mít šanci udržet ovladače konsistentními. Jenže v jádře nemá absolutní moc nikdo, leda s výjimkou Linuse Torvaldse. Pokud je třeba něco opravit nebo změnit, může to udělat kdokoliv s náležitými technickými schopnostmi. Pokud by kus stromu měl být obehnán plotem se zákazem vstupu pro vývojáře jádra, jádro jako celek by bylo o něco méně svobodné.
A na této svobodě záleží. Zvažme problém změny interního API. Jak všichni, kteří sledují vývoj jádra, ví, interní rozhraní se mění v jednom kuse následkem problémů a měnících se potřeb. Tyto změny mohou někdy znamenat velké změny pro uživatele dotčených rozhraní. Současná pravidla vyžadují, že vývojář, který dělá změnu v rozhraní, musí opravit veškerý kód, který tato změna rozbije. Kód, který je vyčleněn jako nepřístupný pro ostatní, bude těžké takto opravovat, což povede ke zpomalení rozvoje jádra jako celku. Jako příklad se můžeme podívat na odstranění velkého jaderného zámku (BKL); tento úkol si vyžádal významné změny v zamykání na mnoha místech. V průběhu bylo nutné změnit doslova stovky ovladačů. Odložení těchto změn by odstranění BKL ještě více zpomalilo – možná i znemožnilo.
Výrobci nejsou známí dlouhotrvající podporou svých produktů; nemají žádný dobrý důvod podporovat pět let starý čipset, který už neprodávají. Mají zajisté mnoho důvodů ukončit podporu a podporovat to, aby byl starý hardware nahrazen nablýskaným novým. Linux má ale tendenci podporovat hardware, dokud je používán. Tím, že bychom výrobci dali plnou kontrolu nad ovladačem, bychom jistě způsobili konflikt, jakmile by se výrobce rozhodl ukončit podporu starších čipsetů.
Plány výrobce se mohou lišit od potřeby komunity i v jiných směrech. Výrobci nemusí mít radost z patchů, které povolují nedokumentované funkce nebo zajišťují, že levnější produkty fungují jako jejich dražší alternativy. Nebo se podívejte na odpor Hanse Reisera vůči přidání podpory ACL a rozšířených atributů do reiserfs. Jeho argumentem bylo, že by uživatelé meli počkat na zbrusu nový souborový systém Reiser4, kde tyto funkce budou; kdyby jej ostatní poslouchali, tak by se uživatelé reiserfs těchto základních schopností souborového systému nikdy nedočkali. Jádro funguje, protože je spravováno tak, jak je dlouhodobě nejlepší pro uživatele, i když to někdy zapříčiní konflikty s krátkodobými touhami výrobce.
Multiplatformní ovladače od výrobců mají sklon k tomu být napsané kolem minimální sady funkcí dostupné na všech platformách. Výsledkem je spousta kódu, jenž duplikuje funkčnost, která už v linuxovém jádře je; vezměte si například kolik bezdrátových ovladačů mělo zpočátku vlastní vestavěnou podporu 802.11. Vývoj a údržba jedné solidní implementace 802.11 je obtížná; pokud bychom jich mělo v jádře několik, jádro by se nafukovalo a vedlo by to k řadě podřadných implementací – které by všechny musely být v budoucnu udržovány. Jinému podpůrnému kódu – od jednoduchých zřetězených seznamů po komplikovanou správu paměti – se multiplatformní ovladače rovněž často vyhýbají. Takové ovladače budou větší, chybovitější a pro vývojáře jádra obtížnější pro pochopení a podporu. Je u nich také mnohem menší pravděpodobnost, že by se chovaly konzistentně s jinými linuxovými ovladači pro stejný typ hardwaru.
Mimo vše výše uvedené je také zcela nejisté, že by údržba multiplatformního ovladače skutečně vedla k úspoře práce. Ovladače psané pro Linux mohou plně využívat veškerou podpůrnou infrastrukturu. Multiplatformní ovladače namísto toho musí duplikovat velkou část této funkčnost a také mudí udržovat abstrakční vrstvu nad operačním systémem. Udržovat multiplatformní ovladač znamená udržovat větší objem kódu bez pomoci komunity.
Abych to shrnul: snažit se udržovat jediný ovladač pro vícero operačních systémů se může na první pohled zdát jako dobrý nápad. Ale je to udržitelné jen ve světě, kde má výrobce naprostou kontrolu nad kódem. A i tehdy to vede k horšímu kódu, duplikaci vyvíjeného úsilí, problémy s dlouhodobou údržbou a celkově k většímu množství práce. Linux funguje nejlépe, pokud jsou jeho ovladače psané pro Linux a mohou být plně integrovány se zbytkem jádra. Komunitní vývojáři toto dobře vědí; to je důvodem, proč mají multiplatformní ovladače problém dostat se do hlavní řady.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
20.9.2011 00:07
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
Pak jsem jí strčil do zakázaných MAC adres. Od té doby jsem neměl odvahu to znovu povolit.
21.9.2011 15:41
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
Nástroj iw umožňuje za běhu přepnout regulační doménu.
Definice regulačních domén má dva zdroje. Za prvé jednu tabulku můžete mít zakompilovanou přímo v jádře (CFG80211_INTERNAL_REGDB), za druhé tabulku můžete do jádra nahrát později nástrojem crda. Tabulka z uživatelského prostoru by měla jadernou přepsat. Integrace jde tak daleko, že když jádro údaje pro konkrétní doménu nemá, pošle netlinkem zprávu, tu zachytí udev a spustí crda, který jádru potřebné udaje dodá.
Pokud chcete mít regulační domény definované ještě před inicializací ovladačů rádií, zavádějte modul cfg80211 s parametrem ieee8021_regdom=CZ.
Z názvu modulu vyplývá, že regulační databáze je dostupná jen ovladačům, které používají infrastrukturu cfg80211, například ovladače nad vrstvou mac80211. Prakticky jsou to ty, které lze ovládat nástrojem iw. Dejete si pozor, že ovladače mimo hlavní strom si často vláčí vlastní historickou verzi mac80211, která s cfg80211 nemluví.
Nakonec je ještě třeba dodat, že existuje rozšíření 802.11 (mám dojem, že se schovává pod písmenem d), které umožňuje ápéčkám oznamovat identifikátor regulační domény nebo dokonce přímo frekvenční definici domény klientům. Takže pokud si někdo koupí router z dovozu, může se stát, že začne oznamovat blbosti. Oznamovaný kód lze najít na výpisu scanu nástrojem iw.
Jako úvod do problematiky doporučuji stránku na LinuxWireless.
Ta externí REGDB, není v nějakém binárním formátu, nemusí být podepsaná? Pokud ano, dá se svévolně modifikovat? Ona věc stojí ale jinak: my nepotřebujeme hackovat REGDB. Defaultní REGDB obsahuje pro naši doménu správná data - není důvod záznamy modifikovat.
Horší je, že změna domény za chodu není úplně čistá. Ovladač si při startu usmyslí nějakou výchozí defaultní doménu. V případě ath5k a R52 EEPROMka indikuje, že ovladač má použít svůj default. A ovladač má ve zdrojáku natvrdo zadáno, že v téhle situaci defaultní doména je US. Pokud změníte doménu za jízdy na CZ, tak se prostě nevymění předpis pro US na předpis pro CZ. CDRA z obou domén vyrobí "společnou podmnožinu povoleného pásma". Fakt je, že jsem nezkoumal, jestli náhodou v našem případě tenhle průnik není identický s celou doménou CZ - ale obecně mi to leze krkem.
Má to řešení: v drivers/net/wireless/ath/regd.c je potřeba změnit zmíněný tvrdý default na CTRY_CZECH:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
if (reg->country_code == CTRY_DEFAULT &&
regdmn == CTRY_DEFAULT) {
printk(KERN_DEBUG "ath: EEPROM indicates default "
"country code should be used\n");
reg->country_code = CTRY_CZECH;
}
No a když jsem tohle všecko udělal, tak mi stejně R52 nechce na 5 GHz povolit AP režim. Všimněte si, že takové omezení v REGDB není přítomno (možná není ani kódovatelné? nebo ano?)
Co tam ještě schází? Zamítavý result kód vrací navenek CRDA. Ale mám podezření, že uvnitř za to může callback driveru ath5k, který se ještě navrch zeptá (opět) EEPROMky na kartě (a vrátí výsledek crdě). Tenhle callback je zmíněný v dokumentaci, měl by se jmenovat reg_notifier(). Takže odsud budu čenichat dál, až se k tomu zase dostanu 
Ostatně jsem přímo tady na Ábíčku našel jeden konkrétní způsob
Ta externí REGDB, není v nějakém binárním formátu, nemusí být podepsaná? Pokud ano, dá se svévolně modifikovat?
Pokud je crda přeložen s podporou kryptografie, pak přijímá jen podepsanou databázi. Veřejné klíče pro ověření lze doinstalovat vlastní. Postup je popsán na stránce, co jsem odkazoval.
CDRA z obou domén vyrobí "společnou podmnožinu povoleného pásma".
Ano, to je vlastnost. Výrobci zařízení se bojí, že by jinak nedostali od FCC certifikaci.
A ovladač má ve zdrojáku natvrdo zadáno, že v téhle situaci defaultní doména je US.
Z hlediska softwaru to je chyba. Z hlediska výrobce hardwaru to je vlastnost. Výrobce občas umožňuje hodnotu v EEPROM přeprogramovat. Samozřejmě z hlediska uživatele to je opruz. Napiš autorovi ovladače (nebo do mailing listu), co se s tím dá dělat.
19.9.2011 14:55
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko