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

[Honz]

Překlep: operování jádra za živa

[1john2]

Muze nekdo prosim vysvetlit ten "pomaly pahyl"?

[Petr Tomášek]

Stačí se podívat na průměrný pornoserver a pochopíš...

[Milan Vančura]

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.

[Radek Hladik]

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"...

[petr_p]

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.

[Michal Kubeček]

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…

[Milan Vančura]

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.

[Michal Kubeček]

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.

[Milan Vančura]

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ý.

[CZTomi]

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?

[Michal Kubeček]

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ě.

[Filip Jirsák]

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.

[smazáno]

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.

[ebik]

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.

[smazáno]

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.

[Michal]

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...?

[ebik]

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.

[pavele]

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.

[Michal Kubeček]

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.

[ebik]

Ne pokud, ta oprava zabraňuje úspěšnému dokončení operace.

[Michal Kubeček]

Zkuste si rozmyslet, jak reálná taková situace asi je.

[Sid]

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.

[victor8]

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 :)

[Sid]

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.

[victor8]

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.

[zigi]

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.

[Michal Kubeček]

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.

[Milan Vančura]

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."? :)

[Ivan]

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.

[Ivan]

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.

[Jiri Kosina]

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.

[Ivan]

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.

[Jiri Kosina]

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.

[smazáno]

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. )?

[Jiri Kosina]

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.

[smazáno]

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.

[nyan]

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

[Michal]

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.

[Ivan]

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.

[smazáno]

Jo souhlas - stejny (podobny) pristup by sel (a mel byt pouzit) i pro userspace. Gdb a trochu python ...

[nyan]

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

[j]

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.

[Michal]

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]

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?

[Michal Kubeček]

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]

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).

[Michal Kubeček]

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]

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.

[Michal Kubeček]

…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]

, to je fakt. Ale teď je situace opravdu, ale opravdu jiná.

[Bystroushaak]

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]

tty například

Huh? Co je špatně na tty?

[Bystroushaak]

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]

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.

[Michal Kubeček]

Vždyť linux k tomu už skoro dospěl

Jak se to projevuje?

[Bystroushaak]

Spousta dobrých myšlenek z Plan9 byla začleněna do linuxu. Například FUSE.

[Michal Kubeček]

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]

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.

[Michal Kubeček]

/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]

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čí :)

[Michal Kubeček]

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]

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]

Tohle platí úplně všude, nejen v prog. jazycích.

[Michal]

Tak to doufám že ne! Nerad bych se dočkal řízku co by byl hybrid mezi erlangem, smalltalkem a lispem!!!

[Bystroushaak]

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]

Přílohy:

• IMG092.jpg (270970 bytů)
• IMG093.jpg (277346 bytů)

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

[ebik]

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

[ebik]

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.

[citanus]

 

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

 

[mato]

A čo taký QNX príp. vxWorks ? .. Tie sa zdajú dostatočne výkonné.