Služba Dropbox Sign (původně HelloSign) pro elektronické podepisování smluv byla hacknuta.
Byla vydána nová major verze 8.0 textového editoru GNU nano (Wikipedie). Podrobný přehled novinek a oprav v oznámení v diskusním listu info-nano nebo v souboru ChangeLog na Savannah. Volbou --modernbindings (-/) lze povolit "moderní" klávesové zkratky: ^C kopírování, ^V vložení, ^Z vrácení zpět, … Tato volba je aktivována také pokud binárka s nano nebo link na ni začíná písmenem "e".
Před 60 lety, 1. května 1964, byl představen programovací jazyk BASIC (Beginners' All-purpose Symbolic Instruction Code).
Byla vydána nová verze 12.0 minimalistické linuxové distribuce (JeOS, Just enough Operating System) pro Kodi (dříve XBMC) a multimediálního centra LibreELEC (Libre Embedded Linux Entertainment Center). Jedná se o fork linuxové distribuce OpenELEC (Open Embedded Linux Entertainment Center). LibreELEC 12.0 přichází s Kodi 21.0 "Omega".
Microsoft vydal novou velkou aktualizaci 2404.23 v září 2019 pod licencí SIL Open Font License (OFL) zveřejněné rodiny písma Cascadia Code pro zobrazování textu v emulátorech terminálu a vývojových prostředích.
OpenTofu, tj. svobodný a otevřený fork Terraformu vzniknuvší jako reakce na přelicencování Terraformu z MPL na BSL (Business Source License) společností HashiCorp, bylo vydáno ve verzi 1.7.0. Přehled novinek v aktualizované dokumentaci. Vypíchnout lze State encryption.
Spouštět webový prohlížeč jenom kvůli nákupu kávy? Nestačí ssh? Stačí: ssh terminal.shop (𝕏).
Yocto Project byl vydán ve verzi 5.0. Její kódové jméno je Scarthgap. Yocto Project usnadňuje vývoj vestavěných (embedded) linuxových systémů na míru konkrétním zařízením. Cílem projektu je nabídnou vývojářům vše potřebné. Jedná se o projekt Linux Foundation.
Operační systém 9front, fork operačního systému Plan 9, byl vydán v nové verzi "do not install" (pdf). Více o 9front v FQA.
Svobodná webová platforma pro sdílení a přehrávání videí PeerTube (Wikipedie) byla vydána v nové verzi 6.1. Přehled novinek i s náhledy v oficiálním oznámení a na GitHubu. Řešeny jsou také 2 bezpečnostní chyby.
Současné vývojové jádro je 2.6.33-rc5 vydané 21. ledna. Obsahuje mnoho oprav, tempo patchů přicházejících do 2.6.33 je stále poměrně vysoké.
Ve vývojovém jádře 2.6.33-rc5 zůstává 23 nevyřešených regresí (ze 75 nahlášených).
Stabilní aktualizace: 2.6.32.5 bylo vydáno 22. ledna, následováno 2.6.32.6 z 25. ledna; obě obsahují poměrně hodně důležitých oprav. 2.6.32.7 je revidováno v době psaní tohoto článku; obsahuje 98 oprav a lze ho očekávat někdy po 28. lednu.
-- Al Viro
Normálně je jádro, které nepadá, považováno za dobré jádro. Může ale také být zdrojem opravdové frustrace pro ty, kteří chtějí vidět, jak systém letí v plamenech k zemi. Spolehlivost systému znamená, že člověk čekající na pád může při čekání zestárnout.
Simon Kagstrom zaslechl o problémech takových uživatelů; proto zaslal jaderný modul pro ty, kdo si chtějí sestřelit systém na vyžádání. Tento modul vytvoří v debugfs adresář (provoke_crash [vyprovokuj_pád]), ve kterém je několik užitečných souborů. Pro ty, kdo mají jednoduché požadavky, zápis do bugon vyústí v přímočaré volání BUG(). Uživatelé s jemněji vytříbeným vkusem mohou zapsat do null_dereference a tím způsobit dereferenci nulového ukazatele, overwrite_allocation zapíše za alokovanou haldu [heap], corrupt_stack přepíše zásobník. Opravdu výstřední uživatelé mají k dispozici i oops_interrupt_context dereferencující nulový ukazatel v režimu softirq, write_after_free, který šlápne do uvolněné paměti, či unaligned_load_store, který provede špatně zarovnané operace s pamětí.
Není potřeba říkat, že toto není modul, který by někdo chtěl nechat nahraný v jádře na produkčním systému; lepší je držet ho na tajném místě a vytáhnout, až když děti spí. Samozřejmě kromě případů, kdy pro něj máte skutečné využití; Simon ho používal k tomu, aby kmsg_dump() dělala v různých případech pádu správnou věc. U většiny vývojářů je nicméně práce řízena potřebou pádům se vyhýbat; protože pro tuto vlastnost nemají využití, není jasné, jestli se tento malý modul někdy dostane do hlavní řady.
Linux má již dlouho systémové volání mincore(), které aplikaci umožňuje zjistit, jestli je daná stránka v RAM, nebo ne. Není ale snadné zjistit, jestli je daná stránka ze souboru v cache stránek, nebo ne. Aplikace může soubor namapovat pomocí mmap() a použít mincore(), ale to může být pomalé. Christ Frost proto navrhl nové systémové volání fincore(), které by to zajistilo:
int fincore(int fd, loff_t start, loff_t len, unsigned char *vec);
Volání fincore() se podívá na stránky souboru spojené s fd v rozsahu určeném start a len. Pro každou stránku v souboru je jeden byte ve vec nastaven na nenulovou hodnotu, pokud je tato stránka v paměti. Odpověď je přirozeně pouze přibližná – situace se během běhu systémového volání může změnit.
To nicméně může být pro Chrisovy potřeby dostatečně dobré. Jeho cílem je zrychlit aplikace, které provádí mnoho nesekvenčních čtení ze souboru. Tradiční kód dopředného čtení se s takovou situací vyrovnává špatně, vzhledem k tomu, že vzor přístupů nelze předem odhadnout. Aplikace ale často dopředu zná sekvenci, ve které bude číst; pokud by bylo možné jádru říci, aby tyto stránky natáhlo předem, mohlo by řadit I/O operace optimálně a celou věc zrychlit. Když to udělal u sqlite a GIMPu, hlásil Chris významné zrychlení.
Přednačtení dat lze vyžádat systémovým voláním fadvise(). Je tu ale problém: Pro přednačítací knihovnu je těžké zjistit, kolik je k dispozici systémové paměti. Pokud je přednačteno příliš málo dat, výkonnostní zisky nebudou takové, jaké by mohly být; přednačtení příliš mnoha dat však může vést ke značnému zpomalení. A proto systémové volání fincore(): Jestliže přednačtené stránky nejsou k dispozici, když se aplikace dostane k tomu, že je chce použít, knihovna ví, že chtěla příliš a že by měla zpomalit.
Andrewu Mortonovi se patch líbí:
Jamie Lokier se ale ptal, jestli by nebylo lepší najít způsob, jak aplikace informovat o tom, že jsou jejich stránky odstraněny před použitím.
Jde o první zaslání tohoto systémového volání, takže se mu nedostalo příliš pozornosti; určitě bude nutná delší diskuze, než ho bude možné začlenit. Více informací najdete na stránce o libprefetch.
Ti z vás, kteří mají rádi prezentace Davea Airlieho plné koťátek, byli dost možná nespokojeni s jeho přednáškou na linux.conf.au, která byla nazvána "Tak jste přestěhovali grafické ovladače do jádra… a co teď? Můžu mít poníta?" Poníci ale také mohou být hezcí a shrnutí novinek ohledně stavu grafických ovladačů v jádře stálo za to si vyslechnout.
Nyní je to přibližně rok od doby, co bylo do hlavní řady začleněno jaderné nastavování režimu [kernel mode setting, KMS]. KMS ukončuje ten „nepořádek“, který vzešel z toho, že grafické ovladače byly v uživatelském prostoru; vykopat se z této jámy trvalo dobrých sedm let. Teď jsou grafické ovladače v jádře stejně jako většina ostatních.
Kromě vyklizení tohoto zmatku je několik dalších dobrých důvodů pro začlenění KMS. Jedním z nich je, že systém je nyní plně schopen využít možnosti úspory energie hardwarem; před KMS jádro nikdy nevědělo, co se s hardwarem děje. Co se týče úspory energie, ovladače od Intelu mohou nyní fungovat stejně dobře jako na Windows; ovladače od ATI tak daleko ještě nejsou. Další hezká vlastnost je možnost použít jaderný debugger na systému, na kterém běží grafika; nyní je možné odskočit do debuggeru a pak se vrátit do běžícího systému a vše bude fungovat.
Jediný důvod, proč tak dlouho trvalo KMS začlenit, bylo to, že od jádra vyžaduje spoustu nových věcí. Na začátku seznamu je slušný správce grafické paměti. To je složitý problém, takový, kterému se vývojáři grafiky chtěli věnovat někdy Opravdu Brzy. Nakonec se k tomu dostali vývojáři TTM, ale ti rychle narazili na mnoho problémů s API. Po nějaké snaze se vývojáři od Intelu rozhodli, že obecný přístup k API správy paměti nebude fungovat; z toho vzešel správce paměti GEM, který se pokoušel řešit problém jenom u Intelu.
Vývojáři pracující na čipových sadách ATI následně brzy zjistili, že GEM nemá možnosti, které potřebují. Proto se vrátili zpět k TTM, ale ne předtím, než na něj našroubovali něco, co vypadá jako API GEM. TTM byl nedávno začleněn, takže KMS je možné použít u čipových sad ATI.
Co nás tedy čeká? Jedna z budoucích vlastností je architektura Gallium 3D. Gallium, jak říká Dave, začíná fungovat, ale ještě bude chvíli trvat, než bude plně funkční. Úprava ovladačů pro Gallium bude nepříjemné cvičení; již teď existuje několik API, která je potřeba podporovat. Také se blíží DRI2; tato vlastnost je nutná k tomu, aby KMS fungovalo správně, obzvláště u kompozitních záležitostí. Stále jsou ale výkonnostní problémy, které je potřeba vyřešit.
Další věc, na kterou se můžeme těšit, je zobrazovací server Wayland. Wayland lze považovat za jednodušší a menší náhradu X vystavěnou nad KMS. Nyní na něm mohou běžet GTK a GL aplikace; také pro něj existuje emulátor X serveru. Zbývá několik potíží včetně toho, že Wayland není X; vzhledem k tomu, že X je v dané oblasti standard, alternativy bude obtížné prodat. Vývojáři Waylandu se také ještě nepotýkali s problémem vstupu, přičemž to je velký kus kódu X. Wayland tedy také bude ještě chvíli na cestě; možná se dostane nejprve do embedded řešení.
Dave věnoval nějaký čas současnému stavu grafických ovladačů. Intel, jak řekl, je v současnosti ve vedení. Podporuje KMS všude – dobrá, téměř všude; „čipová sada, o které nemluvíme“ (proprietární GMA500) podporu stále postrádá. Ovladač obsahuje všechny vlastnosti, ale Dave ho nechce nazývat „dokončený“; na to bude potřeba ještě jedno nebo dvě vydání. Jak zde bylo dříve zmíněno, ovladač bude muset nějakou dobu udržovat nastavování režimu z uživatelského prostoru [user mode setting, UMS], nicméně současné zdrojové kódy X.org v upstreamu již podporu UMS z X serveru vyřadily.
Ovladače ATI/AMD jsou trochu více pozadu, ale blíží se; vzhledem k mnoha variacím čipových sad je tento ovladač složitější než ovladač Intelu. V současnosti jsou podporovány čipové sady od R100 do R700; Podporu R800 lze očekávat během několika týdnů. Ovladač aktuálně funguje „skoro tak dobře jako ten starý“; uspávání a probouzení fungují lépe než dříve. Podpora úspory energie chybí, ale očekává se v 2.6.34. Ovladač Radeon je v současnosti ve stromě -staging, ale z toho se může dostat před koncem vývojového cyklu 2.6.33.
Co ovladač RadeonHD? Oddělení tohoto ovladače je primárně důsledkem neshody ohledně používání tabulek BIOSu ATI; ovladač Radeon obsahuje interpreter těchto tabulek, zatímco RadeonHD reimplementuje funkce, které tyto tabulky poskytují. Používání tabulek BIOSu značně ulehčuje práci; umožňuje to ovladači ignorovat mnoho detailů spojených s různými variantami čipových sad. Kód pro tabulky BIOSu je součástí implementace KMS, která byla začleněna do hlavní řady; to by podle Davida mělo neshody vyřešit.
„Poník“ zobrazený u zmínky o Nouveau byl ve skutečnosti Trojský kůň. Nouveau bylo samozřejmě začleněno do 2.6.33. Ovladač právě ztratil svoji podporu pro nastavování z uživatelského prostoru; umí pouze KMS. Podporovány jsou čipové sady od NV4 po G80 a poslední kousky budou brzy doplněny. Firmware „ctxprogs“ je zkoumán; verze pro NV40 byla již nahrazena přepsaným ekvivalentem se svobodnou licencí a u NV50 se na tom pracuje. Dave poznamenal, že ať už si lze o spolupráci nvidie s komunitou myslet cokoliv, jejich hardware bývá relativně dobrý a snadno se s ním pracuje.
Když byl Dave dotázán na podporu nelinuxových systémů, odpověděl, že většina z nich byla ponechána svému osudu. U Sunu se zjevně pracuje na portu pro OpenSolaris, ale tato skupina nevydala žádný kód. Další člověk z publika se zeptal na běh X bez oprávnění roota: To nyní funguje a Moblin to používá. Zbývá ale několik problémů, obzvláště co se týká rychlého přepínání uživatelů. Vzhledem k absenci systémového volání revoke() nelze nijak garantovat, že nějaký uživatel neodposlouchává jiného. Protože je revoke() obtížný problém, není jisté, jak bude tato záležitost vyřešena.
Nástroje: Tisk bez diskuse
Tiskni Sdílej:
Je tu jeden překlep z poníka na poníta.Není to překlep.
Je tu jeden překlep z poníka na poníta.To není překlep.
Jadra 2.6.27 <= verzie >= 2.6.31 hadzali deterministicky oopsy pri odmountovani fs mountovanom s -o loop. Robit na takom jadre s obrazmi diskov z VirtualBoxu je fakt radost.S loop jsem si nedávno na 2.6.31 užíval docela dost. Ani jeden oops. A stěžovat si na jádro, když do něj cpeš binární sra?ky...
A stěžovat si na jádro, když do něj cpeš binární sra?ky...VirtualBox má i opensource edici a ten jaderný modul je AFAIK otevřený vždy.