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í
×

včera 19:22 | Nová verze

Ondřej Filip, výkonný ředitel sdružení CZ.NIC, oznámil vydání verze 2.0.0 open source routovacího démona BIRD (Wikipedie). Přehled novinek v diskusním listu a v aktualizované dokumentaci.

Ladislav Hagara | Komentářů: 0
včera 09:22 | Pozvánky

V Praze dnes probíhá Konference e-infrastruktury CESNET. Na programu je řada zajímavých přednášek. Sledovat je lze i online na stránce konference.

Ladislav Hagara | Komentářů: 1
9.12. 20:11 | Nová verze

Byl vydán Debian 9.3, tj. třetí opravná verze Debianu 9 s kódovým názvem Stretch a Debian 8.10, tj. desátá opravná verze Debianu 8 s kódovým názvem Jessie. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 9 a Debianu 8 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.

Ladislav Hagara | Komentářů: 0
9.12. 00:44 | Nová verze

Po 6 měsících vývoje od vydání verze 0.13.0 byla vydána verze 0.14.0 správce balíčků GNU Guix a na něm postavené systémové distribuce GuixSD (Guix System Distribution). Na vývoji se podílelo 88 vývojářů. Přibylo 1 211 nových balíčků. Jejich aktuální počet je 6 668. Aktualizována byla také dokumentace.

Ladislav Hagara | Komentářů: 4
8.12. 21:33 | Nová verze

Po půl roce vývoje od vydání verze 5.9 byla vydána nová stabilní verze 5.10 toolkitu Qt. Přehled novinek na wiki stránce. Současně byla vydána nová verze 4.5.0 integrovaného vývojového prostředí (IDE) Qt Creator nebo verze 1.10 nástroje pro překlad a sestavení programů ze zdrojových kódů Qbs.

Ladislav Hagara | Komentářů: 0
7.12. 11:11 | Komunita

Naprostá většina příjmů Mozilly pochází od výchozích webových vyhledávačů ve Firefoxu. Do konce listopadu 2014 měla Mozilla globální smlouvu se společností Google. Následně bylo místo jedné globální smlouvy uzavřeno několik smluv s konkrétními vyhledávači pro jednotlivé země. V USA byla podepsána pětiletá smlouva s vyhledávačem Yahoo. Dle příspěvku na blogu Mozilly podala společnost Yahoo na Mozillu žalobu ohledně porušení této

… více »
Ladislav Hagara | Komentářů: 0
7.12. 05:55 | Zajímavý článek

V Londýně probíhá konference věnovaná počítačové bezpečnosti Black Hat Europe 2017. Průběžně jsou zveřejňovány prezentace. Videozáznamy budou na YouTube zveřejněny o několik měsíců. Zveřejněna byla například prezentace (pdf) k přednášce "Jak se nabourat do vypnutého počítače, a nebo jak v Intel Management Engine spustit vlastní nepodepsaný kód". Dle oznámení na Twitteru, aktualizace vydaná společností Intel nevylučuje možnost útoku.

Ladislav Hagara | Komentářů: 5
7.12. 04:44 | Komunita

Virtualizační nástroj GNOME Boxy ve Fedoře 27 umožňuje jednoduše stáhnout a nainstalovat Red Hat Enterprise Linux, který je pro vývojáře zdarma. Vývojová verze GNOME Boxy již umožňuje jednoduše stáhnout a nainstalovat další linuxové distribuce. Ukázka na YouTube. Seznam distribucí a jejich verze, nastavení a cesty k ISO obrazům je udržován v knihovně a databázi libosinfo (GitLab).

Ladislav Hagara | Komentářů: 0
7.12. 03:33 | Nová verze

Google Chrome 63 byl prohlášen za stabilní (YouTube). Nejnovější stabilní verze 63.0.3239.84 tohoto webového prohlížeče přináší řadu oprav a vylepšení. Vylepšeny byly také nástroje pro vývojáře. Opraveno bylo 37 bezpečnostních chyb.

Ladislav Hagara | Komentářů: 12
6.12. 22:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených technologií a otevřeného přístupu na 147. brněnský sraz, který proběhne v pátek 15. prosince od 18:00 hodin v restauraci Severka na rohu Tučkové a Zahradníkové.

Ladislav Hagara | Komentářů: 0
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (8%)
 (1%)
 (1%)
 (1%)
 (75%)
 (14%)
Celkem 952 hlasů
 Komentářů: 45, poslední 1.12. 19:00
    Rozcestník

    Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu

    19. 5. 2014 | Luboš Doležel | Jaderné noviny | 4829×

    Aktuální verze jádra: 3.15-rc3. Počáteční podoba kGraftu.

    Obsah

    Aktuální verze jádra: 3.15-rc3

    link

    Aktuální vývojová verze jádra je 3.15-rc3 vydaná 27. dubna. Máme za sebou další týden a další rc. Zatím nic hrozivého a rc3 je odpovídajícím způsobem menší než rc2, takže se to odvíjí správně.

    Stabilní aktualizace: verze 3.14.2, 3.10.38 a 3.4.88 vyšly 26. dubna.

    Počáteční podoba kGraftu

    link

    Nutnost restartovat systém kvůli instalaci opravy jádra je otravné. V mnoha případech je to dokonce ještě horší: systém(y), o které jde, mohou mít omezení týkající se dostupnosti, která znemožňují restartování dle potřeby. Uživatelé, kteří takovým nesnázím čelí, by často rádi měli způsob, jak dostat do jádra kritický patch bez nutnosti systém vypnout. Jako odpověď na toto se už v roce 2008 objevila první verze sady patchů Ksplice. Ksplice se nikdy ale nedostalo do hlavní řady jádra a po odkoupení Oraclem pravděpodobně z linuxového světa zmizelo. V poslední době bylo oznámeno několik alternativních patchů nabízejících podobnou funkčnost; jeden z nich – kGraft – byl nyní zaslán ke zvážení.

    KGraft je prací Jiřího Kosiny a Jiřího Slabého ze SUSE. Přístup, který použili, je snazší než v případdě Ksplice a scházejí mu některé schopnosti, které Ksplice nabízí. Na druhou stranu má základní patch s kódem kGrafu jen 600 řádek a proces aplikace patchů je o dost jednodušší a s menším dopadem na systém.

    KGraft funguje tak, že v jádře nahrazuje celé funkce. Za použití nástrojů dodaných s kGraftem může na základě patche jádra vytvořit seznam změněných funkcí; nové verze těchto funkcí jsou pak zkompilovány do odděleného jaderného modulu. Jakmile je tento modul nahrán do jádra, kGraft se postará o nahrazení stávajících porouchaných funkcí jejich novými opravenými verzemi.

    Toto nahrazování je poněkud zrádná věc; operování jádra za živa skýtá spousty nebezpečí. Dobrou zprávou pro vývojáře kGraftu je to, že tento problém už byl za ně z větší části vyřešen. Subsystém trasování funkcí (ftrace) potřebuje dělat právě tento typ patchování za běhu, takže se vývojáři ftrace už postarali o napsání kódu, který to zajistí, odladili všechny podivné vady a také to náležitě odnesli, když něco nefungovalo tak, jak by mělo. Vývojáři kGraftu zkrátka jen musí použít nástroje ftrace – které už umí zachytit volání funkcí v běžícím jádře – a použít je k nahrazení volání vadných funkcí za volání nového kódu.

    Jsou tu samozřejmě ještě nějaká rizika. Tím největším z nich je: co se stane, když proces běží při aplikování patche zrovna v jaderném prostoru? Tento proces může jednou zavolat starou verzi funkce a krátce na to zavolat novou verzi; v závislosti na tom, co se mezitím změnilo, by to mohlo vést ke zmatení a k výpadkům, kterým se právě takto snažíme předejít. Při pohledu na tento problém dospěli vývojáři kGraftu k tomu závěru, že se dá problémům předejít, pokud žádný proces neuvidí dvě verze té samé funkce při jediném průchodu do jaderného prostoru a zpátky.

    Proto patch přidává do struktury thread_info v každém procesu příznak, zda tento proces opustil nebo se vrátil do uživatelského prostoru od začátku aplikování patche. Jakmile je zachyceno volání staré funkce, „pomalý pahýl“ zkontroluje zmiňovaný příznak pro běžící proces; pokud proces vstoupil do prostoru jádra nebo jej opustil, tak se má za to, že běží ve „starém světě“ a dostane starou verzi této funkce. Jinak se řízení předává nové verzi. Jakmile každý proces v systému přešel do nového světa, pak může být pomalý pahýl odstraněn a nová funkce může být volána nepodmínečně.

    A co s procesy, které tento přechod neprovedou v rozumném čase? Například proces zaseklý při čekání na I/O na síťovém socketu by mohl v jádře zůstat velmi dlouho a bránil by tak pročištění po operaci graft. Když Vojtěch Pavlík hovořil o této práci na březnovém Linux Foundation Collaboration Summitu, zmínil mechanismus, který by pomalým procesům poslal signál, aby byl přechod vynucen. Tento mechanismus ale není v zaslaném patchi přítomen. Na druhou stranu je pod /proc k dispozici příznak umožňující administrátorům identifikovat procesy, které brání dokončení operace.

    Další otázka: co s jadernými vlákny, která nejsou spuštěna z uživatelského prostoru? Většina jaderných vláken, jakmile doběhnou do vhodného místa, zavolá kthread_should_stop(), aby zjistila, jestli se mají ukončit. Kód kgraft upravuje kthread_should_stop() tak, aby resetovalo příznak „starého světa“. Pro vlákna, která taková volání nedělají, vložili vývojáři kGraftu volání kgr_task_safe(), která na vhodných místech značí přechod do nového světa.

    Nakonec tu máme otázku přerušení. Kód kgraftu může blokovat přerušení na lokálním CPU, zatímco provádí změny, ale nemůže je zablokovat globálně. Aby si kGraft byl jistý, že při běhu obsluhy přerušení nedojde k žádným překvapením, tak přidává pole specifické pro každé CPU, aby bylo možné sledovat, zda každý procesor běžel v kontextu procesu (mimo přerušení). Tento příznak je ze začátku nastavený na false a následně je zavoláno schedule_on_each_cpu(), aby došlo ke spuštění funkce kGraftu v kontextu procesu na každém z procesorů. Tato funkce, která nemůže být spuštěna, dokud jsou obsluhována přerušení na daném CPU, nastaví pro dané CPU příznak. Pahýl umístěný při nahrazování funkce mezitím vynutí to, aby kód z obsluhy přerušení používal kód ze starého světa, dokud nemá dané CPU nastavení příznak pro „nový svět“.

    Tento článek byl napsán jen krátce po zaslání patche kGraft, proto doposud není moc co psát o reakcích, jaké vyvolal. Zatím se ale neobjevily žádné námitky k tomu, jak vývojáři celou věc pojali. Tato funkčnost má zjevný přínos, takže můžeme očekávat, že něco někdy bude začleněno. Nejistotu do rovnice vnáší další soupěřící patche, jež čekají na svou příležitost. V jádře není místo pro dva nebo více mechanismů pro patchování za běhu, takže tyto patche buď budou muset být sjednoceny, nebo bude někdo muset učinit rozhodnutí.

           

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

    19.5.2014 09:15 Honz
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    Překlep: operování jádra za živa
    19.5.2014 11:55 1john2 | skóre: 35 | blog: jo12hn | zlín, brno
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    Muze nekdo prosim vysvetlit ten "pomaly pahyl"?
    Petr Tomášek avatar 19.5.2014 23:01 Petr Tomášek | skóre: 37 | blog: Vejšplechty
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    Stačí se podívat na průměrný pornoserver a pochopíš... :-)
    19.5.2014 23:40 Milan Vančura | skóre: 2
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    Ten termín znamená: "Pokaždé se dobře rozmysli, jestli česká lokalizace je krok ke zlepšení porozumění počítači nebo spíš naopak." - a o článcích o SW to platí taky :)

    Abychom si rozuměli: já nehaním překladatele, já poukazuji na to, že všichni trpíme neustálenou terminologií. Překladatelé v prvé řadě. Myslím, že to jsou zkušenosti, které člověku připomenou, že máme obdivovat lidi jako byl Presl.
    20.5.2014 01:25 Radek Hladik | skóre: 20
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    Ono je to těžké, dneska se všecko tak rychle vyvíjí, že neni moc čas tu termitologii ustalovat :-) Vzpomínám si, jak jsme ve škole (FI MUNI) měli předmět o češtině a stylu, kde jsme měli psát všecko česky. Asi už to nenajdu, ale opravdu to občas byly perly, kterým nikdo nerozuměl. V hlavě mi zůstalo snad jen "ochranný štít"...
    20.5.2014 06:34 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu

    Pahýl je znám z české Wikipedie. Pomalý je běžný překlad běžného přívlastku. Navíc autor sousloví změkčil uvozovkami, jak pravidla žádají. Jinak řečeno tohle byl záměr a já jsem se dobře pobavil.

    20.5.2014 08:35 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    Já si zase myslím, že je-li v odborném článku jedinou možností, jak termín pochopit, otrocký překlad zpět do angličtiny, je něco špatně. Ale já jsem obecně toho názoru, že národní obrození sice bylo nutnou a významnou kapitolou našich dějin, ale že už sto let nemáme důvod v něm pokračovat…
    20.5.2014 10:01 Milan Vančura | skóre: 2
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    Naprosto s tebou souhlasím ohledně tohoto článku: nemá asi smysl zavádět českou terminologii pro funkce linuxového kernelu, že. Ale je potřeba nahlas říct proč: protože komunita kolem linuxového kernelu je mezinárodní a neexistuje významná česká sub-komunita, která by potřebovala vlastní terminologii. Proto měl být v článku uvedený v závorkách původní výraz.

    Oproti tomu pro termíny jako "directory", "mail folder" atp. je závěr přesně opačný, protože je přesně opačná i situace lidí, kteří je používají: jsou to už dnes laici žijící normálně v ČR, mluvící česky a používající tyto termíny v běžné mluvě i psané formě - naprosto mimo IT sféru. A přesně pro takové termíny je potřeba mít jednotný český překlad, s českými možnostmi skloňování či časování atp. aby se dal nešroubovaně použít v běžných větách typu "Do Prčic, do kterého 'mail folder' `sem si mrskla ten recept na bábovku od Boženky?!".

    Proto naopak považuji myšlenku národního obrození, samozřejmě moderně chápanou (bez nacionalistických extrémů), za nejen stále živou, ale zrovna v naší branži extrémně potřebnou.
    20.5.2014 10:17 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    Oproti tomu pro termíny jako "directory", "mail folder" atp. je závěr přesně opačný, protože je přesně opačná i situace lidí, kteří je používají: jsou to už dnes laici žijící normálně v ČR, mluvící česky a používající tyto termíny v běžné mluvě i psané formě … Proto naopak považuji myšlenku národního obrození, samozřejmě moderně chápanou (bez nacionalistických extrémů), za nejen stále živou, ale zrovna v naší branži extrémně potřebnou.

    Vytváření vlastních překladů (nebo někdy jen přepisů) termínů používaných v běžném životě je ale proces, který se děje v každé době a v každé zemi - a děje se i u národů, které byly vždy natolik svébytné, že hnutí odpovídající našemu národnímu obrození nikdy nepotřebovaly. Tím (ne)pokračováním v národním obrození jsem myslel právě to, že dnes už nejsme v situaci, kdy by bylo potřeba povzbuzovat umírajícího národního ducha tím, že bychom za každou cenu počešťovali úplně všechno.

    20.5.2014 10:30 Milan Vančura | skóre: 2
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    Ale je potřeba organizovaná snaha o to sjednocení terminologie. Jinak skončíme tak, že nám vnutí Microsoft to z Windows, byť to budou občas nesmysly. A to je ještě ten lepší případ, jak vidíš v roztříštěnosti počeštění aplikací na Linuxu. Každý si nazývá i úplně obyčejné věci jinými termíny a výsledek je, že lokalizace má opačný efekt než by měla mít: zabraňuje porozumění.

    A tu organizovanou snahu vedenou vzdělanými lidmi bych nazýval právě tím moderním národním obrozením. I když je to zavádějící termín. Spíš by se nemělo pro to hledat žádná "vznešená" pojmenování, ale brát to jako běžnou údržbu jazyka, běžnou práci Ústavu pro jazyk český.
    23.5.2014 09:55 CZTomi
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    Ano, tak jest. Nejhorší jsou pseudo české překlady made in Microsoft. Zrovna včera mi volal BFU brácha, že potřebuje cosi nastavit ve WIN7 (kooperaci se SAMBOU). On samozřejmě má české WIN a zaboha se mi nepovedlo ho po telefonu navést, co tam má nastavit. A úplně nejhorší na tom je, že u zrovna ne nevýznamné části populace se ta hatmatilka bere jako oficiální česká IT terminologie. Nebo termitologie?
    23.5.2014 10:10 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    To ale tak úplně nesouvisí s otázkou překladu termínů, protože Microsoft si dost často své vlastní termíny rozdílné od zavedených zavádí i v angličtině.
    20.5.2014 07:43 Filip Jirsák
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    Rychlá cesta / pomalá cesta se v jádru používá pro označení variant kódu při optimalizaci. Rychlá cesta je rychlejší kód, který se použije ve velkém množství případů, nebo v případech, které nejsou nějakou změnou ovlivněny. Pomalá cesta je pomalejší kód, často je tam různé zamykání, a používá se ve speciálních případech. Pahýl je tady použit z toho důvodu, že to není celá ta funkce s nějakou logikou, ale je to jenom krátký kód, který má rozhodnout o tom, která varianta funkce se má použít. Pomalý pahýl je to tedy z toho důvodu, že je to pomalejší kód (je tam nějaký zámek) a není to ten skutečný výkonný kód funkce. Když z běhového prostředí zmizí všechny případy, kdy by bylo nutné volat tu starou verzi funkce, nahradí se tahle pomalá cesta kódu rychlou cestou – přímým voláním té nové funkce.
    20.5.2014 00:48 luv | skóre: 18 | blog: luv
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    Vypada skvele. No napada me, ze jednodusse nahradit funkci je ok v erlangu nebo v haskellu.

    Ale to prece nemuze stacit na live patchovani kernelu napsaneho v C.
    20.5.2014 05:56 ebik
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    A proč ne? Pokud v tom erlangu nebo haskellu máte data uložená v nějakých "strukturách" a změněná funkce v tom udělá bordel a celé to nakonec spadne (zničí data), tak to je přesně to co se může stát v tom C. Rozdíl je jen ten, že v C se musí dávat o trochu větší pozor na strukturu dat.
    20.5.2014 12:46 luv | skóre: 18 | blog: luv
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    V ciste funkcionalnim jazyku by si nemel mit globalni stav (narozdil od C).

    Problem, ze muzes zmenit co znamena typ parametru funkce napriklad "void x(foo a) .." a zmenis co znamena foo - se teda tyka i funkcionalnich jazyku.
    20.5.2014 05:38 Michal
    Rozbalit Rozbalit vše Patchovani kernelu - a co zbytek systému?
    Pořád nějak nerozumím proč se z live patchování kernelu dělá taková věda a nezmiňuje se že security patche jsou o dost častěji nutné i v userlandu?

    Instalovali jsme teď Oracle RAC pro zákazníka a oni (aniž by pořádně věděli o čem mluví) strašně trvali na ksplice aby už nikdy nemuseli ty servery rebootovat. No fajn říkám, ale co když bude nějaký další Heartbleed v OpenSSL, co když bude security bug v Glibc, atd? Stejně bude potřeba restartovat většinu procesů a to už zrovna můžeme rebootovat celý stroj.

    Nějak ten hype kolem ksplice / kgraft nechápu - vždyť to řeší jen zlomek problému...?
    20.5.2014 06:03 ebik
    Rozbalit Rozbalit vše Re: Patchovani kernelu - a co zbytek systému?
    No v "běžném" provozu je dobré být připraven na výpadek/odstávku stroje z různých důvodů, takže se ten reboot výjmečně udělat může. Ale existuje pár (extrémních) případů, kdy to má smysl. Třeba pokud by to byl řídící systém nějakého HW, které zrovna nelze vypnout, tak bych ten řídící linux asi nerad rebootoval.
    20.5.2014 06:45 pavele
    Rozbalit Rozbalit vše Re: Patchovani kernelu - a co zbytek systému?
    Třeba když to bude HW, na kterém právě běží robotická operace srdce. Těžko potom budeš vysvětlovat mrtvému pacientovi, že byl potřeba reboot kvůli aktualizaci jádra.
    20.5.2014 07:18 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Patchovani kernelu - a co zbytek systému?
    To není moc dobrý příklad. Systém, kde stačí počkat pár hodin a pak už bude všem jedno, že je pár minut down, rozhodně není use case pro live kernel patching.
    20.5.2014 15:30 ebik
    Rozbalit Rozbalit vše Re: Patchovani kernelu - a co zbytek systému?
    Ne pokud, ta oprava zabraňuje úspěšnému dokončení operace.
    20.5.2014 16:58 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Patchovani kernelu - a co zbytek systému?
    Zkuste si rozmyslet, jak reálná taková situace asi je.
    20.5.2014 09:50 Sid
    Rozbalit Rozbalit vše Re: Patchovani kernelu - a co zbytek systému?
    tak tak, skor by som zameral pozornost na rozne scada aplikacie napr. Kde sa casto skor riesi HW aby bol dokonale odolny a ocakava,ze to nepretrzite bude bezat roky.
    20.5.2014 13:32 victor8 | skóre: 24 | blog: blog | Košice
    Rozbalit Rozbalit vše Re: Patchovani kernelu - a co zbytek systému?
    Ani velmi nie - SCADy (aspon tie ktore som mal ja tu "cest" vidiet) bezia vo vacsine pripadov na windowse (casto som vidaval este w2k, a to sa bavim o roku 2006+), a vonkoncom sa od nich nerata, ze by mali bezat 24/7/365.

    Koniec-koncov, SCADA sa aj tak len pripaja niekam na PLCcko, ktore riadi technologicky proces - to uz v kuse bezat samozrejme musi :)
    20.5.2014 15:15 Sid
    Rozbalit Rozbalit vše Re: Patchovani kernelu - a co zbytek systému?
    no asi zalezi na tom co si videl. A ze sa pripaja SCADA len na PLC je tiez zavadzajuce. Sice je fakt a mas pravdu, ze Windows je az neuveritelne rozsireny v automatizacnom svete. Ale ked sa budeme bavit o unixe tak som videl vxWorks a Solaris a aj Linux. Zaroven to boli stroje stroje ktore maju uptime v rokoch. Osobne som sice v automatizacii nezazil taku situaciu kde by restart sa nedal vylozene urobit ale islo to napr cez x ludi, v pripade dlhsieho vypadku (hodina) uz boli z toho tahanice takze si viem dobre predstavit, ze obcasny patch nejakej superkritickej veci bez toho aby sa prerusila sluzba by mal celkom dobry vyznam. Kde som toto patchovanie za behu zazil boli telekomunikacie kde sa bezne patchovalo jadro (ale vlastny OS). A robilo sa to napriek tomu, ze povacsine tie karty boli spriahnute 2 takze v pripade vypadku jednej by nastupila zalozna.
    20.5.2014 15:37 victor8 | skóre: 24 | blog: blog | Košice
    Rozbalit Rozbalit vše Re: Patchovani kernelu - a co zbytek systému?
    Suhlasim, svet je vacsi ako to com som mal moznost vidiet ja - povacsinou len Promoticy, popr. WinCC - v podstate veci na "domace" zuvanie.

    Asi sa zhodneme, ze takato moznost v kerneli nikdy nebude na skodu, aj keby sa v zivote nemala pouzit (co by bol zrejme idealny pripad), aspon tu moznot mat je vzdy fajn.
    20.5.2014 09:32 zigi | skóre: 12
    Rozbalit Rozbalit vše Re: Patchovani kernelu - a co zbytek systému?
    Taky se zapomina na to, ze i ten hardware obcas potrebuje udrzbu.

    Aktualiza BIOSu, firmwaru RAID radice, firmwaru dohledove karty (eLOM, iLOM, iLO, DRAC atd. - obcas ty mrsky dokonce chtej na par minut odpojit od napajeni), vymena BBU u RAID radice atd.

    Takze odstavkam se clovek fakt nevyhne, pokud to chce delat dusledne. Proti tomu vsemu zase jde zlate pravidlo, ze kdyz to funguje, nech to byt a nesahej na to.

    Opravy totiz nechodi samy a sem tam sebou privedou problem nekde jinde.
    20.5.2014 09:52 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Patchovani kernelu - a co zbytek systému?

    Smysl live kernel patching není vyhnout se odstávkám úplně. Jde o to, aby v případě kritické chyby v jádře (např. remote root exploit) bylo možné odložit tu odstávku na reboot do doby, kdy se to bude hodit (až update projde interní QA zákazníka, až bude maintanance window, až doběhne měsíc trvající simulace, …).

    Rozhodně je tedy mylná představa, že se budou live patche generovat pro všechny opravy (to obecně ani nejde) a rebootovat se nebude nikdy. Jde o to, aby když přijde kritický problém, s jehož opravou nelze čekat dny až týdny, opatchovalo se živé jádro a s rebootem na nový update se mohlo počkat na vhodný okamžik.

    20.5.2014 10:03 Milan Vančura | skóre: 2
    Rozbalit Rozbalit vše Re: Patchovani kernelu - a co zbytek systému?
    No, jak bych to tak řekl... Napadla tě možnost: "Protože jim Oracle obchodníci vymluvili díru do hlavy, když si kupovali ten RAC."? :)
    20.5.2014 10:30 Ivan
    Rozbalit Rozbalit vše Re: Patchovani kernelu - a co zbytek systému?
    Pokud provozujete celo-zemekoulovej system tak s tim muzete mit problemy. V takovym pripade se da nejlip dohodnout vypadek na dobu kdy slunce prechazi nad Tichym oceanem. Ten je dost velikej a v te oblasti zije jen malo lidi. Ono uplne klidne staci aby se muslimove a zide mezi sebou dohodli jestli vypadek bude v patek, sobotu anebo v nedeli.

    S tim RACem to ale moc nechapu. Zrovna tehle SW taky umi hot-patching. Tzn. vetsinu patchu jde aplikovat za behu databaze. Ovsem za jen predpokladu, ze aplikace podporuje TAF (transparent application failover), tzn databaze "nabidne" klientum aby se pripojili na jiny node a pak muzete vesele patchovat - dokonce i ten server muzete otocit.
    20.5.2014 10:38 Ivan
    Rozbalit Rozbalit vše Re: Patchovani kernelu - a co zbytek systému?
    Jo jeste jsem si vzpomel. Kdysi jsem taky takovy "ksplice" taky "napsal". Soubor v /proc/<pid>/smaps na RHEL ver 5 nezobrazoval jestli je adresni prostor procesu zamceny anebo ne. Novejsi kernely uz to zobrazovaly. Takze jsem udelal ovladac do kernelu ktery obsahoval fci z novejsiho kernelu (ale s jinym jmenem) a pri natazeni ten modul binarne prepsal zacatek stare fce. Proste tam nakopiroval instrukci "jmp <addr>. Takze pri vypisovani toho souboru kernel zavolal starou fci, ale ta hned skocila na zacatek "nove" fce z mojeho modulu.
    20.5.2014 11:19 Jiri Kosina
    Rozbalit Rozbalit vše Re: Patchovani kernelu - a co zbytek systému?
    I short jmp ma na x86_64 5 bajtu, takze atomicky tu zmenu neprovedete; tudiz se muze klidne stat, ze kdyz zrovna bude nejaky jiny CPU vykonavat kod na dane adrese, uvidi nesmyslny opcode.
    20.5.2014 12:24 Ivan
    Rozbalit Rozbalit vše Re: Patchovani kernelu - a co zbytek systému?
    Jo to se muze stat. Nastesti v mym pripade jsem vedel, ze jsem to jen ja kdo pristupuje k tomu /proc filesystemu. Myslim, ze MSVC na to ma neco podobneho prepinac /hotpatch ktery zaruci, ze prvni instrukce ve funkci ma alespon 2 bajty. Akorat nevim jakou instrukci tak cpou oni.
    20.5.2014 13:51 Jiri Kosina
    Rozbalit Rozbalit vše Re: Patchovani kernelu - a co zbytek systému?
    Pokud vim, tak oni pouzivaji neco trochu jineho -- maji v kazde funkci od zacatku pripraveny relativni short jmp s defaultnim offsetem 0 (tedy vpodstate nop -- relativni skok na nasledujici instrukci) a v pripade patchovani skoci timto kraktym jumpem na rezervovane misto pred funkci, kde si mohou v klidu predtim pripravit dlouhy jmp.
    20.5.2014 13:03 luv | skóre: 18 | blog: luv
    Rozbalit Rozbalit vše Re: Patchovani kernelu - a co zbytek systému?
    Zajimave. Predpokladam, ze toto nemusite v kgraft resit, diky tomu rozsireni struktury thread_info.

    A kdyz uz jsme v tomto threadu, jak toto resit v userspace?

    Mimochodem, chapu spravne, ze patche pro kgraft musi byt specialne pripravene a overene (tzn. nova funkce napr. nemuze pouzivat jine definice struct atd. )?
    20.5.2014 13:53 Jiri Kosina
    Rozbalit Rozbalit vše Re: Patchovani kernelu - a co zbytek systému?
    Pro userspace je to aktualne trochu komplikovane -- slo by pres ptrace() vkladat na prislusna mista int3 trapy a ty pak handlovat, ale to neni uplne sikovne. Existuje patchset ktery pridava novy syscall text_poke(), ktery implementuje vpodstate to same co kernelovy text_poke_bp() pro userspace kod, ale zatim neni zamergovany.

    A ano, live patche budou zcela jiste vzdy vyzadovat nejakou manualni interakci a overeni, i kdyz je snaha celou zalezitost co nejvice automatizovat.
    20.5.2014 14:45 luv | skóre: 18 | blog: luv
    Rozbalit Rozbalit vše Re: Patchovani kernelu - a co zbytek systému?
    Me napada. Attachnu gdb k procesu, pokud zadny thread neni zrovna v te funkci co se chystam patchovat, tak proste vlozim na zacatek jmp instrukci. Pokud nejaky thread zrovna je v te funkci, tak nejjednodussi asi chvili pockat a zkusit znova (nebo si trochu pohrat s breakpointama jak rikas). Ptrace imho staci.
    20.5.2014 13:35 nyan
    Rozbalit Rozbalit vše Re: Patchovani kernelu - a co zbytek systému?
    Ono uplne klidne staci aby se muslimove a zide mezi sebou dohodli jestli vypadek bude v patek, sobotu anebo v nedeli.
    Jo, ten byl dobrej, diky :-)
    21.5.2014 00:19 Michal
    Rozbalit Rozbalit vše Re: Patchovani kernelu - a co zbytek systému?
    S tim RACem to ale moc nechapu. Zrovna tehle SW taky umi hot-patching.
    Sam sebe jiste opatchovat umi, ale kdyz je chyba v externi knihovne, treba OpenSSL nebo v GLibc tak ti to nepomuze.
    21.5.2014 08:56 Ivan
    Rozbalit Rozbalit vše Re: Patchovani kernelu - a co zbytek systému?
    Pomuze mi rolling upgrade. RAC umoznuje presunout service a vsechna DB spojeni na jiny node v clusteru. Pak si muzu delat co chci, dokonce i rebootovat. Pak ten node vratim do clusteru a ani nevadi, ze kazdy nod v clusteru pouziva jinou verzi binarek. No a pak udelam to samy s druhym(a kadym dalsim) nodem.

    Bohuzel Oracle obcas taktne zamlcuje, ze presun konexi mezi nody musi podporovat i aplikace.

    20.5.2014 12:49 luv | skóre: 18 | blog: luv
    Rozbalit Rozbalit vše Re: Patchovani kernelu - a co zbytek systému?
    Jo souhlas - stejny (podobny) pristup by sel (a mel byt pouzit) i pro userspace. Gdb a trochu python ... :-)

    20.5.2014 13:33 nyan
    Rozbalit Rozbalit vše Re: Patchovani kernelu - a co zbytek systému?
    No, smysl to ma u virtualizace - teda konkretne patchovani jadra hosta. Preci jen userspace u hosta neni kritickej, a rebootovat vsechny guesty kvuli update hosta je vopruz.

    (ovsem jestli tadle sada patchu funguje i s virtualizaci, netusim)

    Ale jinak souhlas, u ostatnich masin je userspace vetsi problem.

    Kdyz uz mas tendle napad... muzes zkusit napsat vlastni nastroj pro patchovani userspace-u a udelat hype kolem neho ;-)
    20.5.2014 14:17 j
    Rozbalit Rozbalit vše Re: Patchovani kernelu - a co zbytek systému?
    Guesty premigrujes za chodu na jinyho hosta ... a sklidem restartujes co jen hrdlo raci ... provozovat ve virtualu vic stroju na singl stroji muze stejne leda blazen. To je prave ta krasa virtualizace ... ze tohle nemusis resit.

    At ctu jak ctu, zatim tu nikdo neprisel s nicim, kvuli cemu by tohle bylo treba resit.
    21.5.2014 00:21 Michal
    Rozbalit Rozbalit vše Re: Patchovani kernelu - a co zbytek systému?
    Kdyz uz mas tendle napad... muzes zkusit napsat vlastni nastroj pro patchovani userspace-u a udelat hype kolem neho
    Jdu na to. Pojmenuju to usplice a pak to zkusim prodat Oraclu za mega penez ;)
    Grunt avatar 20.5.2014 09:34 Grunt | skóre: 22 | blog: Expresivní zabručení | Lanžhot
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    WOW. Já když tak sleduju složitost s jakou rostou na první pohled jednoduché úkoly v jádře si říkám, že on ten mikrokernel s IPC mezi servery na úplném začátku nebyl až zas tak úplně špatný nápad. Monolit linux už dávno není a zatím to vypadá na hybrid, který se blíží ideálu mikrojádra s tunou modulů pro každý úkol včetně uprdnutí si, víc a víc. Akorát při zběžném pohledu na některé funkce si říkám, že i kdybych to chtěl vymyslet fakt složitě, na tohle bych nepřišel. Vidím to tak, že až se bude linux blížit verzi 3.55.2-rc5 se kompletně celé zdrojáky zahodí a zůstanou jako legacy mód pro embedded zařízení a jaderní vývojáři se přesunou k vývoji GNU/Hurdu 0.5 (u této příležitosti se vydá ještě GNOME4 aby toho nebylo málo), ne?
    Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
    20.5.2014 10:05 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    zatím to vypadá na hybrid, který se blíží ideálu mikrojádra s tunou modulů pro každý úkol včetně uprdnutí si

    To si vůbec nemyslím. I kernel thready běží pořád ve stejném paměťovém prostoru a se stejnou úrovní oprávnění jako "core" jádro. Navíc když si vezmu typický driver zařízení, třeba síťové karty, tak mám sice oddělenou hardirq a softirq část, ale nejen že IRQ handler je součástí jádra, ale ani ta softirq část neběží zdaleka vždy v rámci kernel threadu. Takže ideálu mikrokernelu, kde by byly drivery zařízení striktně odděleny od "core" jádra, nejsme o moc blíž než na začátku.

    Grunt avatar 20.5.2014 17:36 Grunt | skóre: 22 | blog: Expresivní zabručení | Lanžhot
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    I kernel thready běží pořád ve stejném paměťovém prostoru a se stejnou úrovní oprávnění jako "core" jádro
    To je vlastně fakt. Jenže díky tomu taky hodně stoupá složitost samotného monolitického blobu. Ono už z názvů funkcí lze vytušit, že provést nějaký jednoduchý úkol v jádře nemusí být jenom tak. Tohleto on-line patchování tomu jen nasazuje korunku (přitom by stačilo zabít příslušný proces a spustit ho znova).
    Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
    20.5.2014 19:16 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu

    Ten nárůst komplexity je zjevný, ale ona není samoúčelná. Ve starých jádrech sice byla spousta věcí jednodušší, ale tehdejší jádra nemusela být schopna běhat na 4096 procesorech a obsluhovat 6 TB paměti nebo čtyřicetigigabitové ethernetové karty, život vývojářů nekomplikovaly věci jako namespaces nebo cgroups atd.

    Pokud si dobře vzpomínám na někdejší debaty na téma monolitické jádro vs. mikrokernel, tak hlavní problém byl právě v tom, že úplně čistý mikrokernel měl sice spoustu designových předností, ale nikdo ho nedokázal implementovat tak, aby to bylo neprůstřelné a efektivitou se to vyrovnalo monolitickým jádrům. A za jeden z hlavních důvodů toho, proč se z mnoha různých systémů prosadil právě Linux, považuji to, že Linus je pragmatik, neopájí se tolik vznešenými idejemi a má čich na výběr toho řešení, které bude rozumně fungovat. Což ve výsledku znamená, že v Linuxu je sice spousta designových kompromisů a nouzových řešení, nad kterými srdce neplesá, ale na druhou stranu se moc často nestává, že by se prosadilo řešení, které je sice teoreticky dokonalé, ale v praxi buď pořádně nefunguje nebo je zoufale neefektivní.

    Grunt avatar 20.5.2014 19:38 Grunt | skóre: 22 | blog: Expresivní zabručení | Lanžhot
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    Ve starých jádrech sice byla spousta věcí jednodušší, ale tehdejší jádra nemusela být schopna běhat na 4096 procesorech a obsluhovat 6 TB paměti nebo čtyřicetigigabitové ethernetové karty, život vývojářů nekomplikovaly věci jako namespaces nebo cgroups atd.
    Pravda. Jen by nebyly složité samotné subsystémy a ovladače, nýbrž servery v uživatelském prostoru.
    Pokud si dobře vzpomínám na někdejší debaty na téma monolitické jádro vs. mikrokernel, tak hlavní problém byl právě v tom, že úplně čistý mikrokernel měl sice spoustu designových předností, ale nikdo ho nedokázal implementovat tak, aby to bylo neprůstřelné a efektivitou se to vyrovnalo monolitickým jádrům. A za jeden z hlavních důvodů toho, proč se z mnoha různých systémů prosadil právě Linux, považuji to, že Linus je pragmatik, neopájí se tolik vznešenými idejemi a má čich na výběr toho řešení, které bude rozumně fungovat. Což ve výsledku znamená, že v Linuxu je sice spousta designových kompromisů a nouzových řešení, nad kterými srdce neplesá, ale na druhou stranu se moc často nestává, že by se prosadilo řešení, které je sice teoreticky dokonalé, ale v praxi buď pořádně nefunguje nebo je zoufale neefektivní.
    Moje pozorování? Ten pragmatismus se k tomu idealismu vždycky pragmatickou cestou stejně propracuje. Dle mého názoru prostě složitost jádra furt poroste až jednoho dle prostě Linus prohlásí „Tenhle bloatware já udržovat nebudu. Smazat a znovu přepsat!“ a stejně se to k něčemu jako je GNU/Hurd jednou propracuje. Akorát to bude dýl trvat.
    Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
    20.5.2014 21:18 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    …a stejně se to k něčemu jako je GNU/Hurd jednou propracuje. Akorát to bude dýl trvat.

    Dokud neuvidím, neuvěřím. :-)

    Připomíná mi to, jak jsem se někdy v roce 1993 nebo 1994 začal zajímat o to, jak dostat na PC nějaký unixový systém, a kamarád mi zasvěceně vysvětloval, že unix, to už je odepsaná záležitost, že teď je skvělý nový systém plan9, který je navržen mnohem lépe a že to je budoucnost…

    Grunt avatar 20.5.2014 21:22 Grunt | skóre: 22 | blog: Expresivní zabručení | Lanžhot
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    :-), to je fakt. Ale teď je situace opravdu, ale opravdu jiná. :-)
    Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
    Bystroushaak avatar 20.5.2014 21:53 Bystroushaak | skóre: 32 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    plan9, který je navržen mnohem lépe a že to je budoucnost…
    To je v podstatě to, o čem Grunt mluví. Vždyť linux k tomu už skoro dospěl, jen je podstatně ošklivější a táhne si s sebou některé opravdu nepěkné dedictví (tty například).
    Grunt avatar 20.5.2014 21:56 Grunt | skóre: 22 | blog: Expresivní zabručení | Lanžhot
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    tty například
    Huh? Co je špatně na tty?
    Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
    Bystroushaak avatar 20.5.2014 23:21 Bystroushaak | skóre: 32 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    Třeba to, že je to uvnitř pořád to samé, co kdysi řídilo dálnopisné tiskárny? Tedy nepřehledný mess věcí, které jsou dnes z většiny k ničemu? Programování složitějších multiplatformních (třeba jen v rámci unix-like systémů) terminálových aplikací je docela bolest.

    Jinak viz seriál na rootu.
    Grunt avatar 21.5.2014 17:30 Grunt | skóre: 22 | blog: Expresivní zabručení | Lanžhot
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    Jo, to možná jo. Na druhou stranu fakt, že můžu ke konzoli připojit svůj Robotron a vím, že to bude fungovat mě docela hřeje u srdce.
    Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
    20.5.2014 22:19 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    Vždyť linux k tomu už skoro dospěl

    Jak se to projevuje?

    Bystroushaak avatar 20.5.2014 23:22 Bystroushaak | skóre: 32 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    Spousta dobrých myšlenek z Plan9 byla začleněna do linuxu. Například FUSE.
    20.5.2014 23:57 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    To je hodně divoká konstrukce. FUSE se používá v Linuxu jako rozhraní pro speciální filesystémy, které buď v jádře z nějakých důvodů implementovat nejde (ZFS) nebo by to bylo příliš nepraktické (curlftpfs). Tedy spíš tam, kde není jiného zbytí. Výkon za moc nestojí a skoro nikoho by nenapadlo používat to pro normální filesystémy na běžných instalacích. Tomu říkáte "Linux skoro dospěl k plan9"? Opravdu myslíte, že takhle nějak si to lidé, kteří navrhovali plan9, představovali?
    Bystroushaak avatar 21.5.2014 00:25 Bystroushaak | skóre: 32 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    Opravdu myslíte, že takhle nějak si to lidé, kteří navrhovali plan9, představovali?
    Ne, to si nemyslím. Na druhou stranu spousta z technologií, které tam uvedli byla portována v nějaké alternativě do linuxu. /proc, používání UTF a FUSE jsou takové hlavní příklady, které nemusí být nutně tak elegantní, jak byly navrženy v plan9, ale funkčně jsou na tom dost podobně. Tím nechci hanit plan9, ani nějak vyzdvihovat linux.

    Osobně by se mi líbilo, kdyby se plan9 pohnul k větší praktické použitelnosti a z dlouhodobého hlediska se mu chci věnovat víc, až na to někdy budu mít čas.
    21.5.2014 07:21 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    /proc, používání UTF a FUSE jsou takové hlavní příklady, které nemusí být nutně tak elegantní, jak byly navrženy v plan9, ale funkčně jsou na tom dost podobně

    Tomu se tuším říká post hoc ergo propter hoc. Unicode se vyvíjel nezávisle na plan9 a postupný příklon k němu měl pramálo společného s tím, že si ho vybrali (i) v plan9. K FUSE už jsem se vyjádřil. A procfs existoval i v řadě jiných systémů, a to dokonce i před plan9. Stránka na wikipedii sice tvrdí, že implementace v Linuxu vznikla jako klon té z plan9, ovšem s poznámkou "citation needed". Ale i kdyby to byla pravda, stejně je to moc málo na to, aby se dalo tvrdit "Vždyť linux k tomu už skoro dospěl."

    Bystroushaak avatar 21.5.2014 13:20 Bystroushaak | skóre: 32 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    Unicode se vyvíjel nezávisle na plan9 a postupný příklon k němu měl pramálo společného s tím, že si ho vybrali (i) v plan9.
    Unicode vs UTF. Afaik UTF-8 vzniklo právě pro plan9, ale můžu se mýlit.
    Ale i kdyby to byla pravda, stejně je to moc málo na to, aby se dalo tvrdit "Vždyť linux k tomu už skoro dospěl."
    Mě to stačí :)
    21.5.2014 14:04 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    Unicode vs UTF.

    V tom případě ale také UTF vs. UTF-8.

    Afaik UTF-8 vzniklo právě pro plan9, ale můžu se mýlit.

    Podle wikipedie sice s poslední úpravou oproti předchozím kódováním přišel Ken Thompson, který v té době pracoval na plan9, a plan9 byl prvním systémem, který UTF-8 začal používat, ale přesto bych to nepovažoval za nějakou featuru převzatou z plan9.

    Bystroushaak avatar 20.5.2014 21:51 Bystroushaak | skóre: 32 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    Moje pozorování? Ten pragmatismus se k tomu idealismu vždycky pragmatickou cestou stejně propracuje.
    Tohle je docela dobré pozorování, které platí i v programovacích jazycích. Za pár (desítek) let bude vše hybrid mezi erlangem, smalltalkem a lispem :)
    Grunt avatar 20.5.2014 21:57 Grunt | skóre: 22 | blog: Expresivní zabručení | Lanžhot
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    Tohle platí úplně všude, nejen v prog. jazycích.
    Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
    21.5.2014 00:25 Michal
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    Tak to doufám že ne! Nerad bych se dočkal řízku co by byl hybrid mezi erlangem, smalltalkem a lispem!!!
    Bystroushaak avatar 21.5.2014 01:23 Bystroushaak | skóre: 32 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    To já se řízku nebojím! Hybrid nehybrid, pokud to není zkažené, tak na sádle, s trochou cibulky a pažitky by to nemělo chybu.
    Grunt avatar 21.5.2014 19:04 Grunt | skóre: 22 | blog: Expresivní zabručení | Lanžhot
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    Přílohy:
    Suchare. Já žeru řízky i růžové a svítící… bych chtěl vidět jak by ses pak nebál. I když trocha kečupu, salátu, erteplí a nikdo skoro nic nepozná. :-)
    Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
    21.5.2014 20:39 ebik
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    Jenže se dopracuje k tomu ideálnímu stavu jen tam je to potřeba. Tam kde to potřeba není a kde idealismus zanáší zbytečnou složitost zůstane jednoduché a přehledné řešení.
    21.5.2014 20:55 ebik
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    A tak kde o to nejde tak zůstane sice ošklivé řešení, ale s tím, že až to bude potřeba přepsat, tak pak teprve tomu někdo věnuje drahocenný čas vývojáře. Další výhodu pragmatismu vidím v tom, že idealismus občas vyřeší naprosto elegantním způsobem situaci, ke které v praxi nedojde a ztíží řešení situace ke které dojde.

    Co je ale důležitější Linuz umí vést projekt tak, aby jeho vývoj byl trvale udržitelný. Prostě žádné nakupení featur (včetně návrhových featur) s tím, že se to vyčistí později (na což nedojde a další vývojář v pořadí provede refaktor, protože není v jeho silách porozumět kódu, který napsal předchozí vývojář). A to není jen o pragmatismu.
    22.5.2014 12:20 citanus | skóre: 10 | Cork (Ireland)
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu

     

    Co je ale důležitější Linuz umí vést projekt tak, aby jeho vývoj byl trvale udržitelný. Prostě žádné nakupení featur (včetně návrhových featur) s tím, že se to vyčistí později (na což nedojde a další vývojář v pořadí provede refaktor, protože není v jeho silách porozumět kódu, který napsal předchozí vývojář). A to není jen o pragmatismu.

    +1

     

    13.12.2014 16:51 mato
    Rozbalit Rozbalit vše Re: Jaderné noviny – 1. 5. 2014: kGraft – patchování jádra za běhu
    A čo taký QNX príp. vxWorks ? .. Tie sa zdajú dostatočne výkonné.

    Založit nové vláknoNahoru

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