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 14:22 | IT novinky

    Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.

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

    Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.

    Ladislav Hagara | Komentářů: 2
    2.5. 22:22 | Komunita

    Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).

    Ladislav Hagara | Komentářů: 0
    2.5. 19:11 | IT novinky

    Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.

    Ladislav Hagara | Komentářů: 3
    2.5. 11:22 | Zajímavý projekt

    Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.

    Ladislav Hagara | Komentářů: 2
    2.5. 09:11 | Bezpečnostní upozornění

    Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.

    Ladislav Hagara | Komentářů: 2
    1.5. 20:00 | Komunita

    V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.

    Ladislav Hagara | Komentářů: 3
    1.5. 19:22 | IT novinky

    Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).

    Ladislav Hagara | Komentářů: 0
    30.4. 22:33 | Nová verze

    Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.

    Ladislav Hagara | Komentářů: 0
    30.4. 17:44 | Zajímavý článek

    Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.

    karkar | Komentářů: 0
    Jaký filesystém primárně používáte?
     (57%)
     (1%)
     (9%)
     (21%)
     (4%)
     (2%)
     (3%)
     (0%)
     (1%)
     (3%)
    Celkem 515 hlasů
     Komentářů: 19, poslední 30.4. 11:32
    Rozcestník

    Jaderné noviny – 7. 7. 2010: Jak zařídit, aby Linus nevyhořel

    23. 7. 2010 | Jirka Bourek | Jaderné noviny | 5012×

    Aktuální verze jádra: 2.6.35-rc4. Citáty týdne: Dave Airlie, Rusty Russell. Ptejte se jaderného vývojáře. O škálovatelnosti Linuse. Příliš mnoho přetažení?
    LWN.net logo

    Obsah

    Aktuální verze jádra: 2.6.35-rc4

    link

    Současné vývojové jádro je 2.6.35-rc4 vydané 4. července. Už týden jsem zase online a soudě podle patchů a požadavků na přetažení, které dostávám, musím říct, že když jsem byl u -rc3 striktní, fungovalo to poměrně dobře. Diffstat mezi rc3 a rc4 vypadá docela rozumně i přes delší okno mezi -rc. A i když se rozhodně objevily věci, které potřebovaly opravit, doufám, že i přes mou dovolenou vyjde 2.6.35 včas […] Co se detailů týče, k dispozici jsou zkrácený changelogkompletní changelog.

    Stavidla stabilních jader se otevřela a vyplaveno bylo pět různých stabilních jader: 2.6.27.48, 2.6.31.14, 2.6.32.16, 2.6.33.62.6.34.1. Žádná další jádra 2.6.31 nebudou a pro vydání 2.6.33 vyjde už jenom jedna aktualizace. Ostatní budou ještě nějaký čas aktualizována.

    Citáty týdne: Dave Airlie, Rusty Russell

    link

    Takže jaderné kousky jste dostali do upstreamu a dobré kousky pro uživatelský prostor si necháváte pro sebe, leží vám na klíně a hladíte si je jako Dr. Zlo. Proč by jaderní správci měli tohle břemeno přebírat, když jim nechcete dát to, co opravdu potřebují ke zprovoznění svého hardwaru?

    -- Dave Airlie

    Poznámka: Když respektované zdroje informací mluví o něčem, s čím máte opravdu dobré zkušenosti, výsledkem je často to, že přemýšlíte, kolik výkalů jste jim zbaštili v oblastech, ve kterých se nevyznáte.

    -- Rusty Russell

    Ptejte se jaderného vývojáře

    link

    Originál tohoto článku pro lwn.net napsal Greg Kroah-Hartman.

    Jeden sloupek ze série, ve které se ptáte vývojáře jádra a on se snaží vaše dotazy zodpovědět. Pokud máte nějaké nezodpovězené dotazy ohledně technických nebo procedurálních záležitostí linuxového jádra, můžete je položit v sekci pro komentáře u originálu článku, nebo je zaslat e-mailem přímo autorovi.

    Jak zjistím, komu napsat o problému, který mám s jádrem. V jaderném logu vidím různé zprávy, jak podle nich poznám, který vývojář mi může pomoci?

    Například teď vidím následující chybu:

    [  658.831697] [drm:edid_is_valid] *ERROR* Raw EDID:
    [  658.831702] 48 48 48 48 50 50 50 50 20 20 20 20 4c 4c 4c 4c HHHHPPPP    LLLL
    [  658.831705] 50 50 50 50 33 33 33 33 30 30 30 30 36 36 36 36 PPPP333300006666
    [  658.831709] 35 35 35 35 0a 0a 0a 0a 20 20 20 20 20 20 20 20 5555…

    Kde mám začít, abych problém dohledal?

    Jaderný log ti říká, kde je problém, takže trik spočívá v tom zjistit, kdo je za zprávy zodpovědný. Jsou různé způsoby, jak na to. Nejprve můžeš zkusit grepovat zdrojové kódy jádra a hledat chybovou zprávu:

    $ cd linux-2.6
    $ git grep "\*ERROR\* Raw EDID"

    Ok, to nic neudělalo, takže zkusíme řetězec trochu zkrátit:

    $ git grep "Raw EDID"
    drivers/gpu/drm/drm_edid.c:            DRM_ERROR("Raw EDID:\n");

    Ok, teď máš soubor, do kterého se můžeš podívat. Ale kdo je za něj odpovědný? Jak bylo zmíněno dříve, můžeš použít skript get_maintainer.pl, kterému předáš jméno souboru, který tě zajímá:

    $ ./scripts/get_maintainer.pl -f drivers/gpu/drm/drm_edid.c
    David Airlie <airlied@linux.ie>
    Dave Airlie <airlied@redhat.com>
    Adam Jackson <ajax@redhat.com>
    Zhao Yakui <yakui.zhao@intel.com>
    dri-devel@lists.freedesktop.org
    linux-kernel@vger.kernel.org

    To nám ukázalo, že nejlepší osoba, které se zeptat, je hlavní vývojář DRM David Airlie, ale pomoci by mohli i další vývojáři. Když pošleš e-mail Davidovi a do CC přidáš ostatní zmíněné (včetně e-mailových konferencí), dostane se těm, kteří by nejpravděpodobněji mohli pomoci.

    Další možnost, jak zjistit, který kód je za problém zodpovědný, je podívat se na jméno funkce, která chybu vypisuje:

    [  658.831697] [drm:edid_is_valid] *ERROR* Raw EDID:

    Jméno funkce je uzavřeno v závorkách [] a můžeme se podívat, který kód ji volá:

    $ git grep edid_is_valid
    drivers/gpu/drm/drm_edid.c: * drm_edid_is_valid – sanity check EDID data
    drivers/gpu/drm/drm_edid.c:bool drm_edid_is_valid(struct edid *edid)
    drivers/gpu/drm/drm_edid.c:EXPORT_SYMBOL(drm_edid_is_valid);
    drivers/gpu/drm/drm_edid.c: if (!drm_edid_is_valid(edid)) {
    drivers/gpu/drm/radeon/radeon_combios.c:    if (!drm_edid_is_valid(edid)) {
    include/drm/drm_crtc.h:extern bool drm_edid_is_valid(struct edid *edid);

    To opět ukazuje, že za chybovou zprávu je odpovědný soubor drivers/gpu/drm/drm_edid.c.

    Když se podíváme na funkci drm_edid_is_valid, před touto zprávou jádro mohlo vypsat i další:

    if (csum) {
            DRM_ERROR("EDID checksum is invalid, remainder is %d\n", csum);
            goto bad;
    }
    
    if (edid->version != 1) {
            DRM_ERROR("EDID has major version %d, instead of 1\n", edid->version);
            goto bad;
    }

    Když tedy posíláš e-mail vývojářům a do e-mailových konferencí, které jsi našel skriptem get_maintainer.pl, je vždy důležité poskytnout všechny jaderné logy, ne jenom několik posledních řádek chyby, protože o něco výše může být víc informací, které mohou vývojáři použít pro odladění problému.

    [Za zaslání této otázky díky Peteru Favrholdtovi.]

    O škálovatelnosti Linuse

    link

    napsal Jonathan Corbet, 2. července 2010

    Vývojový proces Linuxu v mnoha ohledech vyniká; jedním z nich je fakt, že do „oficiálního“ repozitáře kód vkládá právě jedna osoba. O různé subsystémy se stará mnoho různých správců, ale každý patch, který tito správci začlení, musí nakonec přijmout Linus Torvalds, pokud se má dostat do hlavní řady. Linusova unikátní role tento proces mnoha způsoby ovlivňuje; například nyní, když je tento článek sepisován, se Linus právě vrátil z dovolené, která vedla k tomu, že do hlavní řady nebylo pár týdnů začleňováno nic. S tímto modelem jediného vkladatele kódu jsou však spjaty mnohem vážnější záležitosti, přičemž škálovatelnost se pohybuje na čelních pozicích.

    Někteří čtenáři Jaderných novin si určitě vzpomenou na vydání 2.1.123 v září 1998. Toto jádro se nedalo zkompilovat, protože Linus začlenil jenom část patchů pro framebuffer. Selhání překladu vývojového jádra nevypadá jako žádná velká krize, ale tato chyba se stala bodem, ve kterém se vybil vztek hromadící se v komunitě vývojářů: Patche byly čím dál tím více zahazovány a lidi to unavovalo. Na konci dlouhé a nepříjemné diskuze Linus rozhodil rukama a šel pryč:

    Abych byl upřímný, tato diskuze (a jiné před ní) mě jenom naštvaly a ZVYŠUJE to tlak na mě. Jestli máte problém s tím, jak pracuju s patchi, navrhuju vám, abyste se na pět minut zamysleli nad tím, s čím se musím potýkat.

    Jděte pryč, lidi. Nebo mě aspoň nedávejte do Cc. Nemám zájem, beru si dovolenou a nechci o tom nic víc slyšet. Ve zkratce: Vypadněte z mojí schránky.

    Samozřejmě se jedná o slavnou epizodu „Linusova vyhoření“ z roku 1998 (pozn. redakce: vizte článek Hořet, ale nevyhořet). Na chvíli se všechno zastavilo, dokud si Linus trochu neodpočinul, nevrátil se a nezačal opět začleňovat patche. Věci se opět trochu přiostřily roku 2000, což vedlo k trochu svatouškovské přednášce o prokletí nadaných od Erica Raymonda. Roku 2002, když se pracovalo na řadě 2.5, frustrace ze zahozených patchů opět vzrostla; základem pro další dlouhý flamewar o nefunkční podobě vývojového procesu jádra a o problému „Linus neškáluje“ byl tenkrát návrh „patchujícího tučňáka“ Roba Landleyho.

    Krátce poté se věci mnohem zlepšily. Není pochyb o tom, co je změnilo: Přijetí BitKeeperu – přes všechny flamewary, které kvůli tomu vznikly – zajistilo, že vývojový proces jádra začal fungovat. Přechod ke Gitu věci vylepšil ještě více; ukazuje se, že se správnými nástroji Linus škáluje velmi dobře. V roce 2010 zvládá takový objem patchů, který by tenkrát byl nemyslitelný, a vývojový proces přitom funguje velice hladce.

    Autor článku má nicméně obavu, že se na horizontu objevují mraky; blíží se další bod, kde se narazí na Linusovu škálovatelnost? V cyklu 2.6.34 Linus zavedl politiku nepředvídatelné délky začleňovacího okna – i když se zatím jednalo spíše o řeči než o činy. V případě 2.6.35 poměrně dost vývojářů zůstalo, co se požadavků na přetažení [pull request] týče, bez odezvy; Linus se je prostě rozhodl ignorovat. Výbuch ohledně architektury ARM toho byl součástí, ale nebyly přetaženy i další stromy. Do těch špatných dní, kdy patche jednoduše mizely v prázdnotě, jsme se nevrátili a Linus možná jenom trochu experimentuje s vývojovým procesem, aby některé správce vybídl k jinému chování. I tak ale tiché ignorování požadavků na přetažení vyvolává špatné vzpomínky z té doby.

    Příliš mnoho přetažení?

    link

    V typickém vývojovém cyklu je do hlavní řady začleněno více než 10 000 změn. Linus se však většiny těchto patchů nedotýká: Místo toho je přetahuje ze stromů, které spravují správci subsystémů. Kolik pozornosti je věnováno specifickým požadavkům na přetažení, není zcela jasné; na každý se Linus dívá dostatečně zblízka, aby se ujistil, že je v něm to, co mu řekl správce. Některá přetažení jsou zjevně podrobena bližšímu zkoumání, zatímco jiná projdou jenom s krátkou prohlídkou. I tak je jasné, že každý požadavek na přetažení a každý patch vyžaduje nějakou pozornost a přemýšlení, než je začleněn.

    Následující tabulka shrnuje Linusovu začleňovací aktivitu pro posledních deset verzí jádra (řádka 2.6.35 odráží stav do 2.6.35-rc3):

    VerzePřetažení Patche
    Začleňovací oknoCelkemPřímoCelkem
    2.6.26159426 2881496
    2.6.27153436 3391413
    2.6.28150398 313954
    2.6.29129418 267896
    2.6.30145411 249618
    2.6.31187479 300788
    2.6.32185451 112789
    2.6.33176444 104605
    2.6.34118393 94581
    2.6.35160218 38405

    Dva sloupce pod „přetažení“ ukazují počet stromů, ze kterých se přetahovalo během začleňovacího okna a během vývojového cyklu jako celku. Je potřeba říci, že tato čísla mohou být příliš malá, protože začleňování „rychle vpřed“ [fast-forward] v historii gitu nemusí ponechávat žádné stopy. Linus ale dělá jenom málo začlenění „rychle vpřed“, takže počet přehlédnutých začlenění bude malý, pokud vůbec nějaká budou.

    Linus také některé patche začleňuje přímo. Většina z nich pochází od Andrewa Mortona, který k předávání patchů Linusovi nepoužívá git. V tabulce výše sloupec „celkem“ zahrnuje změny, které přišly od Andrewa, zatímco sloupec „přímo“ počítá pouze patche, se kterými nepracoval Andrew.

    Z této tabulky jsou zjevné trendy: Počet patchů, které jdou přímo do hlavní řady, významně poklesl; téměř všechno nejprve prochází přes něčí strom. Na Linuse v tomto okamžiku zbývá povětšinou jenom označování verzí, urgentní opravy a reverty. Andrew Morton zůstává pro velkou část jádra správcem poslední záchrany, ale čím dál tím více změny neprochází ani přes jeho strom. Počet přetažení přitom zůstává přibližně stejný. Bylo by zajímavé zamyslet se nad tím, proč to tak je.

    I přes rostoucí počet stromů možná není potřeba víc přetažení. A nebo se blížíme přirozenému limitu toho, kolika požadavkům na přetažení ze subsystému dokáže jeden talentovaný benevolentní diktátor věnovat pozornost, aniž by vyhořel. Konec konců dává rozum, že počet požadavků, které Linus zpracuje, se nemůže neomezeně zvyšovat; jestliže jaderná komunita dál poroste, musí se zde zákonitě objevit úzké hrdlo škálovatelnosti. Zůstává jediná otázka, kdy by to mohlo nastat.

    [cesty začleňování do 2.6.35]

    Pokud zde máme oprávněné obavy, mohlo by stát za to zamyslet se nad reakcí dříve, než se věci zase rozbijí. Jedním ze zjevných přístupů by mohlo být změnit fakt, že jsou téměř všechny stromy přetahovány přímo do hlavní řady; na obrázku vpravo můžete vidět, jak plochá je tato struktura u 2.6.35. Správci subsystémů, kteří si vysloužili dostatečnou důvěru, by mohli řešit více požadavků na přetažení z nižší úrovně a výsledek předložit Linusovi s tím, že ho může začlenit s relativně malými starostmi. Subsystém síťování takto již funguje; mnoho stromů plní strom síťování Davida Millera předtím, než jsou patche zaslány výše. Na druhou stranu různé tlaky vedly k tomu, že na straně architektury ARM dochází k opačnému procesu: Nyní je zde několik stromů subarchitektur, které jdou přímo Linusovi. Počet přetažení u ARM se zjevně stal Linusovou motivací pro ukončení začleňovacího okna 2.6.35.

    Další řešení by bylo dát dalším lidem moc vkládat stromy přímo do hlavní řady. Není ale jisté, jestli je někdo připraven na takto radikální změnu ve vývojovém procesu jádra. A varování Teda Ts'o z roku 1998 všem, kteří by si přáli model „vnitřního týmu“, stojí za přečtení i po dvanácti letech.

    Jestliže si ale Linus ponechá svou pozici ve vývoji Linuxu pouze pro sebe, komunita jako celek bude muset zajistit, že proces jako takový bude škálovat a nezaplaví ho. Zajistit, aby více začlenění probíhalo před tím, než se kód dostane k Linusovi, vypadá jako přístup se slibným potenciálem, ale autor článku se doslechl, že Linus není moc nakloněn přílišnému slučování stromů; chce si věci na cestě do hlavní řady prohlédnout. I tak ale musí být místa, kde by to fungovalo. Možná potřebujeme strom, který by zase zastřešil celou architekturu ARM, a možná by mohlo být místo pro strom, kde by se shromažďovaly patche pro většinu ovladačů.

    Linuxové jádro a jeho vývojový proces je mnohem větší než roku 2002. Pokud by se tento proces měl znovu zadrhnout kvůli problémům se škálovatelnosti na vrcholu, důsledky by byly mnohem viditelnější veřejnosti. I když tu není nebezpečí akutních potíží, neměli bychom se plynulostí, s jakou se pracovalo posledních několik let, nechat ukolébat k tomu, že se nic podobného nemůže stát. Stejně jako u kódu samotného je dobré myslet na problémy se škálovatelností dříve, než udeří.

           

    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ář

    23.7.2010 00:14 pc2005 | skóre: 38 | blog: GardenOfEdenConfiguration | liberec
    Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 7. 2010: Jak zařídit, aby Linus nevyhořel
    Ad přetížení Linuse: Tak udělat dalšího správce na úrovni Linuse a decentralizovat. Akorát nevím zda by se pak neporvali :-D.
    poky74 avatar 23.7.2010 02:55 poky74 | skóre: 36 | blog: Zápisník | Vrchlabí
    Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 7. 2010: Jak zařídit, aby Linus nevyhořel

    To si nedovedu dost dobře představit. Že by každý dělal půlku práce? To je nesmysl. Vanilkové jádro je jen jedno, proto je pro něj nejlepší když se o něj stará právě jeden člověk.

    Chcete Linuxové samolepky nebo Tuxe na klíče? ->
    23.7.2010 14:10 pc2005 | skóre: 38 | blog: GardenOfEdenConfiguration | liberec
    Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 7. 2010: Jak zařídit, aby Linus nevyhořel
    Tam bylo napsaný, že Linus musí každý patch signovat (a tedy asi i zkontrolovat), tohle by klidně šlo rozdělit mezi více osob. Prostě by se věřilo třeba Adrew Mortonovi stejně jako Linusovi. Určitě z těch patchů za jádro nejsou všechny na sobě závislé, takže by šlo jejich příjem a kontrolu zparalelizovat (prostě make -j 2 sign oproti make -j 1 sign :-D).
    23.7.2010 03:02 JoHnY2
    Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 7. 2010: Jak zařídit, aby Linus nevyhořel
    Ja osobne si nemyslim, ze by mel existovat nekdo na urovni Linuse. Projekt jako celek podle me vzdycky potrebuje jednoho cloveka, kterej proste rekne "Udelame to takhle!". Navic u Linuse je velka vyhoda v tom, ze ho nikdo nemuze zpochybnovat nebo se sapat na jeho misto. On proste sedi na spicce pyramidy a hotovo.

    Docela by me zajimalo kolik patchu vazne potrebuje dohled od Linuse a kolik je pro nej jen rutinni zalezitost, kde neni moc co vymejslet, protoze zakladni praci udelal spravce subsystemu.
    23.7.2010 14:13 pc2005 | skóre: 38 | blog: GardenOfEdenConfiguration | liberec
    Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 7. 2010: Jak zařídit, aby Linus nevyhořel
    kterej proste rekne "Udelame to takhle!"
    Ovšem jen pokud pak neříká: "nestíhám!". Složitost jádra roste imho dost silně je klidně možný, že brzy překročí stav, kdy ho jeden člověk už nezvládne sledovat.
    a kolik je pro nej jen rutinni zalezitost
    No a právě tady by to za něj mohl dělat někdo jinej a ušetřit drahé Linuso-hodiny :-D.
    23.7.2010 09:30 π
    Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 7. 2010: Jak zařídit, aby Linus nevyhořel
    to jako myslíš fork? :P
    23.7.2010 10:27 Aleš Kapica | skóre: 52 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 7. 2010: Jak zařídit, aby Linus nevyhořel
    Momentálně slaví Linux kulaté 20-leté výročí. Zaregistroval to z vás vůbec někdo?.

    Jak píšu ve svém blogpostu z 20.7.2006 Až Linus zaklepe na nebeskou bránu.... Je to prozatím víceméně generační záležitost. Po čtyřicítce začíná opět stoupat pravděpodobnost že člověk znenadání natáhne brka. Soudě dle výše uvedeného textu nejsem sám, kdo si říká, že by současný začleňovací model měl být poněkud zkorigován.
    Jendа avatar 23.7.2010 11:24 Jendа | skóre: 78 | blog: Jenda | JO70FB
    Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 7. 2010: Jak zařídit, aby Linus nevyhořel
    Snad 19leté, ne?
    23.7.2010 14:17 pc2005 | skóre: 38 | blog: GardenOfEdenConfiguration | liberec
    Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 7. 2010: Jak zařídit, aby Linus nevyhořel
    Jo taky bych řekl a ani ne dneska:
    První verze linuxového jádra (0.01) byla na Internetu zveřejněna 17. září 1991.
    odsud.

    P.S. Já to vždycky zaregistruju až ze zpráviček tady :-).
    26.7.2010 08:37 Aleš Kapica | skóre: 52 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 7. 2010: Jak zařídit, aby Linus nevyhořel
    25.8.1991 - neznámý finský student Linus Benedict Torvalds zaslal do diskuzní skupiny comp.os.minix příspěvek s předmětem "What would you like to see most in minix?". O tom, že vyrábí free operační systém - nic komerčního a velkého, pouze jen tak ze zábavy.
    Rozdíl je v tom, že pro vás je podstatný porod, kdežto pro mne početí.. ;-)
    26.7.2010 11:39 trekker.dk | skóre: 72
    Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 7. 2010: Jak zařídit, aby Linus nevyhořel
    2010 - 1991 = ?
    Quando omni flunkus moritati
    26.7.2010 17:15 Aleš Kapica | skóre: 52 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 7. 2010: Jak zařídit, aby Linus nevyhořel
    On je ještě rok 2010? A sakra..
    26.7.2010 14:51 pc2005 | skóre: 38 | blog: GardenOfEdenConfiguration | liberec
    Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 7. 2010: Jak zařídit, aby Linus nevyhořel
    Jenže v tom případě jsem počal tak milion projektů (ovšem zřejmě je nikdy nedokončím :-D).
    pro vás je
    P.S. Pokud to není do publika, tak >patička<.
    23.7.2010 07:23 kip | skóre: 8 | blog: kip | Nový Jičín
    Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 7. 2010: Jak zařídit, aby Linus nevyhořel
    Neměl být v citátu Dava Airlieho spíš "Dr. Zloun" (z Austina Powerse)?
    tsLnox avatar 23.7.2010 08:25 tsLnox | skóre: 31 | blog: Blog jednoho ukecaného Gentoolemana | Žďár nad Sázavou
    Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 7. 2010: Jak zařídit, aby Linus nevyhořel
    Doktor Zlo z Bugemose je lepší :-P
    23.7.2010 08:43 Zopper | skóre: 15
    Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 7. 2010: Jak zařídit, aby Linus nevyhořel
    Asi ano.... Ale překladatel možná zná http://www.bugemos.com/?q=taxonomy/term/13 - tady je Dipl. Ing. F. Zlo, M.B.A., sice to není Dr., ale to nevadí :D
    "Dlouho ještě chcete soudit proti právu, stranit svévolníkům?" Ž 82,2
    27.7.2010 09:30 David Jaša | skóre: 44 | blog: Dejvův blog
    Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 7. 2010: Jak zařídit, aby Linus nevyhořel
    Na Dr. snad bylo habilitováno jeho jednovaječné dvojče, D. Zlo.
    23.7.2010 08:50 Honza
    Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 7. 2010: Jak zařídit, aby Linus nevyhořel
    I vyhořelé palivo se dá zpracovat...
    24.7.2010 03:02 the já
    Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 7. 2010: Jak zařídit, aby Linus nevyhořel
    Lol :-) cože
    Jendа avatar 24.7.2010 04:15 Jendа | skóre: 78 | blog: Jenda | JO70FB
    Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 7. 2010: Jak zařídit, aby Linus nevyhořel
    Co do svého oblíbeného vyhledávače zadat zpracování vyhořelého paliva? Dobré by bylo s tím ohřívat vodu pro ústřední topení :-).
    24.7.2010 22:24 imploder | skóre: 11
    Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 7. 2010: Jak zařídit, aby Linus nevyhořel
    Vyhořelým Linusem?
    23.7.2010 18:29 Bubak
    Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 7. 2010: Jak zařídit, aby Linus nevyhořel
    Je to jenom strom. Kdyz kvalita Linusova stromu klesne, proste se vyvoj rozstepi a pozdeji slouci na jinem strome. Navic ani Linus nema absolutni pravo veta, jak dokazuji modifikovana jadra v distribucich a Android.
    24.7.2010 15:57 lok
    Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 7. 2010: Jak zařídit, aby Linus nevyhořel
    Jiz se tesim, az nektere z Linusovych deti (myslim ze nejake ma, nevim kolik a jake), provede forknuti Linuxu a tatinek s potomkem si budou vesele konkurovat. :-)
    poky74 avatar 24.7.2010 17:07 poky74 | skóre: 36 | blog: Zápisník | Vrchlabí
    Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 7. 2010: Jak zařídit, aby Linus nevyhořel

    Má jen tuším 2 holky, šance že by šli ve šlépějích otce je mizivá, ale zajímavé by to bylo :)

    Chcete Linuxové samolepky nebo Tuxe na klíče? ->
    24.7.2010 17:15 pc2005 | skóre: 38 | blog: GardenOfEdenConfiguration | liberec
    Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 7. 2010: Jak zařídit, aby Linus nevyhořel
    Linuxačky s černým pásem v karate, to by bylo něco.
    24.7.2010 22:23 imploder | skóre: 11
    Rozbalit Rozbalit vše Re: Jaderné noviny – 7. 7. 2010: Jak zařídit, aby Linus nevyhořel
    To mi připomnělo xkcd: 1337 :-)

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.