Bylo oznámeno vydání Fedora Linuxu 40. Přehled novinek ve Fedora Workstation 40 a Fedora KDE 40 na stránkách Fedora Magazinu. Současně byl oznámen notebook Slimbook Fedora 2.
ČTK (Česká tisková kancelář) upozorňuje (X), že na jejím zpravodajském webu České noviny byly dnes dopoledne neznámým útočníkem umístěny dva smyšlené texty, které nepocházejí z její produkce. Jde o text s titulkem „BIS zabránila pokusu o atentát na nově zvoleného slovenského prezidenta Petra Pelligriniho“ a o údajné mimořádné prohlášení ministra Lipavského k témuž. Tyto dezinformace byly útočníky zveřejněny i s příslušnými notifikacemi v mobilní aplikaci Českých novin. ČTK ve svém zpravodajském servisu žádnou informaci v tomto znění nevydala.
Byla založena nadace Open Home Foundation zastřešující více než 240 projektů, standardů, ovladačů a knihoven (Home Assistant, ESPHome, Zigpy, Piper, Improv Wi-Fi, Wyoming, …) pro otevřenou chytrou domácnost s důrazem na soukromí, možnost výběru a udržitelnost.
Společnost Meta otevírá svůj operační systém Meta Horizon OS pro headsety pro virtuální a rozšířenou realitu. Vedle Meta Quest se bude používat i v připravovaných headsetech od Asusu a Lenova.
Společnost Espressif (ESP8266, ESP32, …) získala většinový podíl ve společnosti M5Stack, čímž posiluje ekosystém AIoT.
Byla vydána nová stabilní verze 3.5 svobodného multiplatformního softwaru pro editování a nahrávání zvukových souborů Audacity (Wikipedie). Přehled novinek také na YouTube. Nově lze využívat cloud (audio.com). Ke stažení je oficiální AppImage. Zatím starší verze Audacity lze instalovat také z Flathubu a Snapcraftu.
50 let operačního systému CP/M, článek na webu Computer History Museum věnovaný operačnímu systému CP/M. Gary Kildall z Digital Research jej vytvořil v roce 1974.
Byl zveřejněn program a spuštěna registrace na letošní konferenci Prague PostgreSQL Developer Day, která se koná 4. a 5. června. Na programu jsou 4 workshopy a 8 přednášek na různá témata o PostgreSQL, od konfigurace a zálohování po využití pro AI a vector search. Stejně jako v předchozích letech se konference koná v prostorách FIT ČVUT v Praze.
Po 48 letech Zilog končí s výrobou 8bitového mikroprocesoru Zilog Z80 (Z84C00 Z80). Mikroprocesor byl uveden na trh v červenci 1976. Poslední objednávky jsou přijímány do 14. června [pdf].
Ještě letos vyjde Kingdom Come: Deliverance II (YouTube), pokračování počítačové hry Kingdom Come: Deliverance (Wikipedie, ProtonDB Gold).
Současné vývojové jádro 2.6 je stále 2.6.31-rc3; během minulého týdne nebyly vydány žádné předverze. Do repozitáře hlavní řady nicméně dále proudí patche a až budete tento článek číst, -rc4 již možná bude vydáno.
Současné stabilní jádro je 2.6.30.2, vydané (společně s 2.6.27.27) 19. července. Obě aktualizace obsahují mnoho oprav souvisejících s bezpečností včetně některých, které inspirovalo nedávné zneužití NULLového ukazatele. Vezměte na vědomí, že někteří uživatelé hlásili problémy s bootováním 2.6.27.27.; zdá se, že toto jádro narazilo na chybu v GCC 4.2, kvůli které se kompiluje chybně.
19. července bylo vydáno 2.4.37.3, první aktualizace 2.4 po nějaké době. Toto vydání bylo také motivováno zneužitím NULLového ukazatele; také opravuje některé vážné problémy se síťovým ovladačem r8169.
-- Brad Spengler (komentáře v kódu exploitu)
-- Eric Paris
Jenom málo příspěvků do jádra přitáhlo tolik pozornosti, jako když Microsoft přispěl svými ovladači pro Hyper-V do stromu staging. Tyto ovladače umožňují virtualizovat Linux pod Windows, což je vlastnost, kterou někdo pokládá za užitečnou. Obecně mezi reakcemi bylo překvapení, obavy a přinejmenším jedna předpověď okamžité a naprosté zkázy. Většina vývojové komunity to nicméně považovala za běžné zaslání patche. Kvalita kódu není příliš velká, ale od opravování věcí tu strom staging je.
Kdo má zájem, nějakou historii za tímto zasláním lze nalézt v tomto článku na weblogu Stephena Hemmingera.
Andrew "Tridge" Tridgell je zpět s novou sadu patchů VFAT, které mají obejít patenty vznesené proti tomuto souborovému systému. Pokročil ohledně řešení problémů s interoperabilitou, kterou hlásili testovatelé, nicméně několik malých záležitostí zbývá. Jako vždy hledá testery, kteří by mohli identifikovat zbývající problémy patche.
Oren Laaden zaslal novou sadu patchů kontrolního bodu/restart, která, jak říká, je již vhodná pro mnoho dávkových úloh. Patch přidává systémové volání clone_with_pids(), které umožní vytvořit obnovované procesy se stejným ID procesu, které měly v kontrolním bodu; není jasné, jestli obavy o bezpečnost této možnosti byly vyřešeny, nebo ne. Kontrolní bod/restart má stále mnoho otevřených záležitostí včetně neobsloužených signálů, FIFO zařízení, pseudoterminálů a dalších. Jedná se o složitou záležitost, ale zdá se, že patch se blíží svému cíli. Jsou u něj přiloženy instrukce pro ty, kteří by s ním chtěli experimentovat.
Jaderní vývojáři často potřebují alokovat několikastránkové kousky spojité paměti. Typicky se takové alokace dělají pomocí vmalloc(), ale toto řešení není ideální. Adresový prostor pro alokace vmalloc() je omezený (přinejmenším na 32bitových systémech) a tyto alokace jsou poněkud méně efektivní než normální jaderné alokace paměti.
V reakci na požadavek Andrewa Mortona Dave Hansen navrhl přidání nového API pro flexibilní pole [flexible array] do jádra. Flexibilní pole by řešilo velké alokace, ale pod kapotou by používalo jednostránkové kousky, které lze alokovat normálním (a spolehlivým) způsobem. Ve stručnosti je flexibilní pole vytvořeno takto:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
struct flex_array *flex_array_alloc(int element_size, int total,
gfp_t flags);
Jakmile je pole vytvořeno, data lze do něj a z něj kopírovat voláními:
int flex_array_put(struct flex_array *fa, int element_nr, void *src,
gfp_t flags);
void *flex_array_get(struct flex_array *fa, int element_nr);
Je zde mnoho dalších funkcí pro uvolňování částí pole, předalokování paměti atd.; celé API vizte v zaslání patche.
[coarse clocks] některé aplikace chtějí k systémovému času přistoupit tak rychle, jak je to možné, ale nezajímá je absolutní přesnost. Aby tento požadavek splnil, navrhl John Stultz pár nových typů hodin: CLOCK_REALTIME_COARSE a CLOCK_MONOTONIC_COARSE. V podstatě tyto hodiny fungují tak, že vrátí to, co systém považuje za aktuální čas, aniž by se přitom dotazovaly jakéhokoliv hardwaru. Nápad byl přijat relativně dobře s jedinou obavou: Vývojáři by nebyli rádi, aby se tato vlastnost v budoucnu stala další překážkou při odstraňování periodického tikání hodin (a jiffies). Toto odstranění zdaleka nehrozí – je kvůli tomu potřeba udělat spoustu práce – ale z mnoha důvodů je stále žádané.
V současnosti bude již většina čtenářů vědět o lokálně zneužitelné chybě, kterou nedávno odhalil Brad Spengler. Tato zranitelnost, která postihuje jádro 2.6.30 (a testovací verzi jádra „2.6.18“ RHEL5) je zajímavá v několika ohledech. Tento článek se detailně podívá na to, jak zneužití funguje, a na překvapující řetěz selhání, které ho umožňuje.
Ovladač TUN/TAP poskytuje virtuální síťové rozhraní, které provádí tunelování paketů; to je užitečné v mnoha situacích včetně virtualizace, virtuálních privátních sítí a dalších. Při běžném používání ovladače TUN program otevře /dev/net/tun a voláním ioctl() nastaví koncové body sítě. Herbert Xu si nedávno všiml problému, kde chybějící čítání paketů [packet accounting] umožnilo nepřátelské aplikaci zablokovat velké množství jaderné paměti a obecně degradovat výkonnost systému. Jeho řešením byl patch, který k zařízení přidává „pseudo-socket“, který mohou využít jaderné čítací mechanismy. Problém vyřešen, ale, jak se ukazuje, za cenu přidání mnohem vážnějšího problému.
Zařízení TUN podporuje systémové volání poll(). Začátek funkce, která tuto funkcionalitu podporuje (v 2.6.30), vypadá takto:
static unsigned int tun_chr_poll(struct file *file, poll_table * wait)
{
struct tun_file *tfile = file->private_data;
struct tun_struct *tun = __tun_get(tfile);
struct sock *sk = tun->sk;
unsigned int mask = 0;
if (!tun)
return POLLERR;
Podtržený řádek kódu byl přidán Herbertovým patchem; na tomto místě je ale první chyba. Dobře napsaný jaderný kód se pečlivě vyhýbá dereferencování ukazatelů, které mohou být NULLové; jak je vidět níže, tento kód opravdu nulovost ukazatele tun kontroluje. A to je dobře; ukazuje se, že pokud již bylo voláno konfigurující ioctl(), tun bude opravdu NULLový. Pokud by šlo všechno podle plánu, tun_chr_poll() by v tomto případě vrátil chybový kód.
Jenže Herbertův patch přidal řádku, která ukazatel dereferencuje před touto kontrolou. To je samozřejmě chyba. Při normální práci by dopad takové chyby byl poněkud omezený: měl by způsobit oops jádra v případě, že tun bude NULLové. Tento oops by nejdřív zabil proces, který způsobil chybné systémové volání, a následně zapsal děsivý výpis [traceback] do systémového logu, víc než to by se ale stát nemělo. V nejhorším případě by z toho mohl být problém odepření služby.
Tato úvaha má nicméně jednu chybu: NULL (nula) může být platná adresa ukazatele. Ve výchozím nastavení je úplné dno virtuálního adresového prostoru („nulová stránka“ a několik stránek nad ní) nastaveno tak, že je veškerý přístup zakázán, což je způsob, kterým lze zachytit chyby s nulovým ukazatelem (jako je ta popsaná výše) v jaderném i uživatelském prostoru. Použitím systémového volání mmap() je ale možné do spodní části virtuálního adresového prostoru vložit skutečnou paměť. Tato funkcionalita má několik korektních využití včetně spouštění starých binárek. I tak většina současných systémů nicméně zakazuje mapování nulové stránky pomocí sysctl nastavení mmap_min_addr.
Toto nastavení by mělo bránit programu v uživatelském prostoru v mapování nulové stránky a tudíž způsobit, že dereferencování nulového ukazatele způsobí oops jádra. Z neznámých důvodů nicméně kód mmap() odmítne v 2.6.30 vynucovat mmap_min_addr, pokud je v jádře zapnut mechanismus bezpečnostních modulů. Kontroly bezpečnostních modulů mají být dodatečné ke kontrolám, které již v jádře jsou, ale tentokrát to tak nefungovalo; co se týče nulové stránky, mohou bezpečnostní moduly povolit přístup, který by jinak byl znemožněn. A aby se selhání dokončilo, výchozí politika SELinuxu Red Hatu umožňuje mapování nulové stránky. V tomto případě SELinux ve skutečnosti snížil bezpečnost systému.
Ne že by byl život bez SELinuxu o mnoho lepší. Když SELinux není přítomen, zneužití chyby by narazilo na limit mmap_min_addr, který by na první pohled byl dostatečný k tomu, aby byl problém zastaven. Tuto konkrétní obtíž lze nicméně obejít použitím systémového volání personality() – povolení personality SVR4 způsobí, že je na adresu nula mapována stránka pouze pro čtení, pokud je program spuštěn pomocí exec(), ale pouze pokud proces, o který se jedná, má kvalifikaci CAP_SYS_RAWIO. Je tedy zapotřebí ještě jeden trik: Kód exploitu na nejvyšší úrovni nastaví personalitu SVR4, potom použije exec(), kterým spustí server pulseaudio se speciálním modulem pluginu. Pulseaudio je instalováno jako setuid root, takže bude mít při spuštění namapovanou nulovou stránku. V době, kdy je zavolán kód pluginu, již pulseaudio zahodilo svá oprávnění, ale v té době je nulová stránka kódu exploitu k dispozici, ten ji může přenastavit na zapisovatelnou a vložit tam svá data.
Výsledkem toho všeho je, že proces v uživatelském prostoru může namapovat nulovou stránku a zabránit tak tun_chr_poll() ve vyvolání jaderného oops. Jeden by si ale myslel, že to by útočníkovi moc nepomohlo, protože funkce hned v dalším kroku testuje tun na NULLovost. A tady je místo, kde se objeví další zajímavý krok v řetězu selhání: Překladač GCC ve výchozím nastavení test na NULL při optimalizaci odstraní. Logika je taková, že ukazatel již byl dereferencován (a nezměnil se), tudíž nemůže být NULLový. Není tedy důvod ho kontrolovat. Tato logika opět většinou dává smysl, ale ne v situacích, kdy NULL může být platný ukazatel.
Útočník tedy je schopen dostat se do těla tun_chr_poll() s NULLovým ukazatelem tun. Následně je potřeba vymyslet, jak za použití této situace získat kontrolu nad jádrem. Další krok využívá tohoto kódu, který je k nalezení o kousek dál v tun_chr_poll():
if (sock_writeable(sk) ||
(!test_and_set_bit(SOCK_ASYNC_NOSPACE, &sk->sk_socket->flags) &&
sock_writeable(sk)))
mask |= POLLOUT | POLLWRNORM;
Vzpomeňme, že hodnota sk přišla z dereferencování tun, je tedy pod útočníkovou kontrolou. SOCK_ASYNC_NOSPACE je nula, takže volání test_and_set_bit() lze využít k bezpodmínečnému nastavení nejméně významného bitu kdekoliv v paměti. Co se týče poškození jaderné paměti, tohle je poměrně malé, ale dostačuje. V Bradově exploitu sk->sk_socket->flags ukazuje na strukturu file_operations ovladače TUN; konkrétně ukazuje na funkci mmap(). Ovladač TUN mmap() nepodporuje, takže tento ukazatel je normálně NULLový; po volání poll() má místo toho hodnotu jedna.
Posledním krokem zneužití chyby je volání mmap() pro popisovače souboru zařízení TUN. Vzhledem k tomu, že interní operace mmap() již není NULLová (byla nastavena na jedničku), jádro do ní skočí. Tato adresa také žije v nulové stránce, kterou má exploit namapovanou, takže je pod kontrolou útočníka. Exploit na danou adresu umístí další skok do svého vlastního kódu, takže když jádro zavolá funkci mmap() ovladače TUN (nebo to, o čem si myslí, že je to funkce mmap()), výsledkem je, že v jaderném režimu je spuštěn libovolný kód; v tomto okamžiku má exploit kompletní kontrolu.
Na dobře navržených systémech jsou katastrofická selhání málokdy dílem jediné chyby. Toto je rozhodně ta situace: Aby byl tento exploit možný, muselo se pokazit několik věcí – bezpečnostní moduly byly schopné umožnit přístup k mapování dolní paměti přes systémovou politiku, politika SELinuxu umožnila toto mapování, pulseaudio lze zneužít k tomu, aby byla kódu exploitu k dispozici privilegovaná operace, NULLový ukazatel je dereferencován předtím, než je zkontrolován, kontrolu odstraní překladač a kód používá NULLový ukazatel způsobem, který umožní útočníkovi získat kontrolu nad systémem. Je to dlouhý řetěz chyb a každá z nich je zapotřebí k tomu, aby byl exploit možný.
Tato konkrétní slabina byla uzavřena, ale téměř určitě budou další jí podobné. Vizte druhý článek, který se zabývá tím, jak jaderní vývojáři na tuto chybu reagují.
První část Zábavy s NULLovými ukazateli se detailně zabývala řetězcem selhání, které umožnilo narušení bezpečnosti jádra dereferencováním NULLového ukazatele. Odstranění této chyby bylo poměrně přímočaré; chyba byla dokonce opravena předtím, než byla plně pochopena podstata této slabiny. Důležitost tohoto konkrétního problému je v jistém smyslu poměrně malá; je jenom pár distribucí, které dodávaly zranitelné verze jádra. Tento exploit nicméně naznačuje, že v jádře může být celá sada podobných problémů; je rozhodně šance, že lze nalézt podobné slabiny – pokud dokonce již nalezeny nebyly.
Jeden zjevný problém je to, že bezpečnostní moduly mohou odstranit administrátorem určený limit (mmap_min_addr) určující nejnižší platnou adresu v uživatelském prostoru. Toto chování porušuje to, jak bezpečnostní moduly běžně fungují: Měly by práva omezovat, ale nikdy je nezvyšovat. V tomto případě pouhá přítomnost SELinuxu oprávnění zvýšila a politika vynucovaná při většině nasazení SELinuxu tuto díru neuzavřela (komentáře v kódu exploitu naznačují, že AppArmor na tom nebyl o moc lépe).
Když navíc bezpečnostní moduly byly při konfiguraci vynechány úplně, mmap_min_addr se vůbec nevynucovalo. Hlavní řada nyní obsahuje patch, který zajišťuje, že je sysctl konfigurace map_min_addr vždy platná; tento patch byla také vložen do aktualizací 2.6.27.27 a 2.6.30.2 (stejně jako mnoho dalších zde popsaných).
Záležitosti jsou také opravovány na úrovni SELinuxu. Budoucí verze politiky SELinuxu od Red Hatu již nebudou umožňovat neomezenému (ale jinak neprivilegovanému) procesu mapovat stránky na dně adresového prostoru. Jsou zde nicméně stále nějaké otevřené problémy, obzvláště když se do směsi přihodí programy jako WINE. Není ještě jasné, jak by systém mohl bezpečně podporovat malý počet programů, které potřebují mapovat nulovou stránku. Nápady spouštět WINE pod rootem – čímž by možná chování napodobující Windows zašlo příliš daleko – si získaly jenom málo nadšení.
map_min_addr lze také obejít po další cestě, kterou je potřeba vyřešit: Privilegovaný proces, který běží pod personalitou SVR4, bude mít při exec() namapovanou stránku pouze pro čtení na nulové adrese. Některé staré SVR4 programy evidentně očekávají, že tam ta stránka bude, ale její přítomnost pomáhá umožnit zneužití nulového ukazatele. Další patch začleněný do hlavní řady a stabilních aktualizací resetuje personalitu SVR4 (nebo přinejmenším tu část, která mapuje nulovou stránku), když se spouští setuid program. Tento patch dostačuje k tomu, aby se zabránilo triku založeném na pulseaudio, který byl využit k získání přístupu ke stránce mapované na nulu.
Tato změna pro některé uživatele není dostatečná, žádali, aby bylo možné vlastnost personalit úplně vypnout. Možnost spouštět binárky pro unixové systémy založené na 386 prostě nemá ten význam, který měla řekněme roku 1995, takže se objevily nějaké otázky, jestli personality mají nějaký smysl vzhledem k jejich ceně. Linus odpověděl:
Konkrétně se zdá, že možnost zakázat znáhodňování adresového prostoru (což je vlastnost personality) je v mnoha situacích užitečná. personality() tedy pravděpodobně zůstane, ale jeho vlastnost mapování nulové stránky by zmizet mohla.
Další článek v řetězu selhání je odstranění kontroly nulovosti ukazatele překladačem. Tato kontrola by útok zastavila, ale GCC ji optimalizací odstranilo na základě teorie, že ukazatel nemůže (vzhledem k tomu, že již byl dereferencován) být NULLový. GCC má příznak (přirozeně), který tuto optimalizaci zakazuje; odteď tedy jádra budou ve výchozím nastavení překládána s příznakem -fno-delete-null-pointer-checks. Vzhledem k tomu, že NULL může být v jádře platná hodnota ukazatele, pravděpodobně dává smysl tuto optimalizaci zakázat trvale.
Dalo by se nicméně argumentovat, že i když jsou všechny změny uvedené výše v pořádku, částečně se přehlíží jedna věc: Kvalitní jádro by NULLový ukazatel vůbec nemělo dereferencovat. Právě toto dereferencování je skutečnou chybou, takže tam by také mělo být místo, kde se problém opraví. Zde nicméně přichází poměrně zajímavá historie, protože jaderným vývojářům bylo často doporučováno vynechávat kontroly NULLovosti ukazatelů. Konkrétně z kódu:
BUG_ON(nějaký_ukazatel == NULL); /* dereference nějakého_ukazatele */
byla často řádka BUG_ON() vyjímána s komentářem typu
Toto tvrzení je založené na předpokladu, že dereferencování NULLového ukazatele způsobí oops jádra. Na první pohled to dává smysl: Když hardware detekuje dereferencování NULLového ukazatele, nemá moc smysl přidávat další režii v podobě softwarové kontroly. Jak nicméně ukázal exploit, tento předpoklad je chybný. Mapování nulové stránky má dokonce legitimní důvody, takže nikdy nebude pravda, že je NULLový ukazatel nutně neplatný. Lze předpokládat, že vývojáři to již chápou, ale v jádře může být mnoho míst, kde byly nutné kontroly ukazatelů z kódu vyjmuty.
Většina problémů s NULLovými ukazateli v jádře jsou však pouhá přehlédnutí. Většinu z nich navíc nelze zneužít; když není možné, aby jádro v relevantním kódu skutečně narazilo na NULLový ukazatel, chybějící kontrola nic nemění. I tak by ale bylo hezké to všechno opravit.
Jednou možností, jak tyto problémy najít, by mohl být nástroj pro statickou analýzu Smatch. Smatch byl po několik let potichu, ale zdá se, že Dan Carpenter na něm znovu pracuje; nedávno zaslal informaci o chybě s NULLovým ukazatelem, kterou mu našel Smatch. Pokud by bylo možné Smatch změnit na všeobecný nástroj, který by mohl nacházet tento druh problémů, výsledkem by mohlo být bezpečnější jádro. Je nešťastné, že takovéto kontrolní nástroje nepřitahují příliš mnoho vývojářů; svobodný software je v této oblasti zastaralý a to nám škodí.
Další přístup používá Julia Lawall, která vytvořila „sémantický patch“ pro Coccinelle – ten vyhledává a opravuje chyby kontrola-po-dereferencování podobné té, která byla nalezena v ovladači TUN. Byla zaslána série patchů (příklady) s opravami tohoto problému; případy, kdy je ukazatel kontrolován po prvním dereferencování, jsou pravděpodobně malou podmnožinou problémů s NULLovými ukazateli v jádře, ale každý z nich indikuje situaci, kdy si programátor myslel, že je NULLový ukazatel v daném místě možný a problematický. Rozhodně tedy stojí za to je opravit.
Když to shrneme, tak zaslání tohoto exploitu posloužilo jako budíček pro jadernou komunitu; s trochou štěstí to vyústí v pročištění spousty kódu a uzavření mnoha bezpečnostních problémů. Brad Spengler, autor exploitu, nicméně zjevně doufá ve víc: Často vyjadřoval obavy z toho, že jsou vážné bezpečností chyby opravovány v tichosti nebo pomíjeny s tím, že jde přinejhorším o problémy s odepřením služby. Jestli se toto změní, se uvidí; v prostředí jádra má mnoho chyb bezpečnostní dopady, které nejsou zjevné, když je chyba opravena. Možná tedy neuvidíme víc chyb explicitně označených jako bezpečnostní záležitosti, ale budeme-li mít štěstí, dočkáme se více opravených chyb.
Autor tohoto článku (Jonathan Corbet) krátce navštívil 2009 Linux Symposium, které se poprvé konalo v Montrealu. Jedna z přednášek, kterou v té krátké době mohl zachytit, byla o změnách na kernel.org, prezentoval ji John Hawley. Jednalo se o zajímavý pohled na infrastrukturu, na kterou mnoho z nás spoléhá, ale kterou považujeme za danou.
„Zpráva o stavu serveru“ začala tradiční ukázkou bizarních e-mailů, které přišly na kernel.org. Postačí říci, že správci kernel.org dostávají hodně divných mailů. A také nemají žádné výčitky svědomí z toho, že tyto e-maily (lehce poupravené) ukazují pro pobavení.
V radě kernel.org je v současnosti pět lidí: H. Peter Anvin, Jeff Uphoff, Chris Wright, Kees Cook a Linus Torvalds. O Linusovi bylo řečeno, že se jednání rady nikdy neúčastní; John předpokládá, že je zaneprázdněn prací na jádře. Peter je nadále prezidentem organizace, dělá práci, která je zapotřebí, aby si nezisková společnost stála dobře. Většinu zbývající práce dělá John, který byl přijat v září 2008 jako první správce kernel.org na plný úvazek. Jeho zaměstnavatelem je Linux Foundation.
Během minulého roku kernel.org zvládl zrcadlení mnoha vydání velkých distribucí. Do sítě zrcadel byly přidány dvě nové (Gentoo a Moblin), do směsi se nyní přidává Slackware. Do wiki.kernel.org bylo přidáno několik instancí wiki. John řekl, že vytvořit wiki je jednoduché; relevantní projekty povzbudil k tomu, aby si zažádaly o wiki na kernel.org, pokud jim to pomůže.
Interně kernel.org běží na deseti „nechutně krásných“ strojích darovaných firmou HP. John nešetřil chválou na adresu HP a ISC (která poskytuje většinu ze značné šířky pásma, kterou kernel.org využívá); bez nich by kernel.org nefungovalo tak, jak funguje. Kromě ISC je několik strojů hostováno v open source laboratoři OSU a jeden na Umeå University ve Švédsku. Po dlouhém procesu byly všechny tyto stroje aktualizovány na Fedoru 9, těsně předtím, poznamenal John s úšklebkem, než byla podpora této distribuce ukončena. V blízké budoucnosti je tedy v plánu další kolo aktualizací.
Další významnou změnou za minulý rok je používání GeoDNS pro domény kernel.org. GeoDNS umožňuje DNS serveru vzít v potaz pozici tazatele a vrátit odpovídající sadu adres serverů. Uživatelé kernel.org nyní používají lokální zrcadla kernel.org, i když si žádné explicitně nevyžádají pomocí doménového jména pro danou zemi.
Nadcházejícím projektem je archive.kernel.org. Záměrem je vytvořit trvalý archiv aktualizací starších distribucí. Pokud by někdo pocítil potřebu nainstalovat si řekněme Red Hat Linux 5, bylo by možné ji uspokojit návštěvou archive.kernel.org. Plnění archivu zatím probíhá; mnoho vydání starších distribucí, zdá se, zmizelo ze sítě. Jak ale ukazují zkušenosti, mnoho ze starších vydání lze nakonec nalézt.
Dalším projektem, na kterém se pracuje, je „boot.kernel.org“. Tam má být vytvořen archiv distribucí bootovatelných po síti. Distributor může vytvořit miniaturní bootovací obraz, který nedělá o moc víc, než že nastaví síť a stáhne další fázi bootu z boot.kernel.org. Myšlenkou je to, aby bylo možné snadno nabootovat záchranné nebo live CD přes síť. Na boot.kernel.org by také mohly být hostovány distribuce, které podporují síťovou instalaci. Tato vlastnost by měla být připravena na veřejné spuštění někdy v blízké budoucnosti.
John přednášku skončil dalšími zábavnými e-maily. Když ale hlouposti ponecháme stranou, zdá se být jasné, že kernel.org je pevná organizace. Podporuje oblasti, které jdou v komunitě daleko za samotné jádro, a zdá se být připravena tak činit i nadále.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
21.8.2009 08:11
Petr Tomášek | skóre: 39
| blog: Vejšplechty
Česky se to řekne: „budeme-li mít štěstí, uvidíme ...“
21.8.2009 08:14
Petr Tomášek | skóre: 39
| blog: Vejšplechty
Podobně: „Ve shrnutí zaslání tohoto exploitu posloužilo...“ taky není česky. Buď „Shrnuto, zaslání...“, nebo něco jako „Summa sumárum, zaslání...“, či „Když to shrneme, zaslání...“
21.8.2009 08:30
alblaho | skóre: 17
| blog: alblog
Že GCC v takovéhle situaci generuje (s výchozím nastavením) špatný kód mě vůbec nepřekvapuje.
