Jaderné noviny – 11. 11. 2010: Život po X

29. 11. 2010 | Jirka Bourek

Články - Jaderné noviny – 11. 11. 2010: Život po X  

Aktuální verze jádra: 2.6.37-rc1. Citáty týdne: Tejun Heo, Dan Rosenberg. Netoops (posílání zpráv o Oops po síti). LPC: Život po X.

Obsah

• Aktuální verze jádra: 2.6.37-rc1
• Citáty týdne: Tejun Heo, Dan Rosenberg
• Netoops
• LPC: Život po X
  • Do budoucnosti bez X
  • Práce k odvedení

Aktuální verze jádra: 2.6.37-rc1

Současné vývojové jádro je stále 2.6.37-rc1; během minulého týdne nevyšly žádné předverze a tempo začleňování bylo také pomalé, od 2.6.37-rc1 bylo začleněno pouze 148 neslučovacích sad změn.

Stabilní aktualizace: v uplynulém týdnu žádné nevyšly

Citáty týdne: Tejun Heo, Dan Rosenberg

A vkládej text svého příspěvku dolů. Vzhledem k tomu, že jsme takoví antisociální egomaniaci, jací jsme, lidé na lkml preferují možnost rozsekat zprávy, na které reagují, vkládat do nich útočné komentáře přímo tam, kde budou nejefektivnější, a odstraňovat části, ze kterých nevzejdou efektivní výsledky.

-- Tejun Heo

Dokázal jsi to. Po hodinách gdb a kofeinu máš konečně shell na cílovém serveru. Možná si příště dvakrát rozmyslí nasadit na produkční stroj MujPrvniFITProjektFTPD. Pak si znovu usrkneš Jehlavanky, vybereš kousky čipsů z vousů a začneš plánovat další krok – je čas pohrát si s jádrem.

Co by mělo být tvým cílem? Eskalace práv? To není možné, v Linuxu nic takového jako slabiny umožňující eskalaci práv není. Odepření služby? Co jsi zač, nějaké skript kiddie? Kdepak, odpověď je jasná. Musíš číst neinicializované byty z jaderného zásobníku, protože ty obsahují všechna tajemství vesmíru a smysl života.

-- Dan Rosenberg

Netoops

napsal Jonathan Corbet, 10 listopadu 2010

Oops jádra vygeneruje slušné množství dat, která mohou být užitečná při snaze vysledovat problém k místu, kde je chyba. Tato data jsou ale užitečná jenom v případě, že je zachytí a prozkoumá někdo, kdo ví, jak je interpretovat. Zachycení výsledků oopsu ale může být složité; typicky se nedostanou do žádných logů na trvalém úložišti. Z toho důvodu často vidíme výstup zaslaný ve formě fotografie monitoru. Používat jako ladící nástroj fotoaparát může fungovat pro desktop, ale rozhodně to nebude škálovat dobře v datovém centru s tisící stroji. Google jedno nebo dvě taková místa spravuje, takže není překvapivé, že mají zájem na lepší práci s informacemi oops.

Google svůj nástroj pro sbírání dat z oops používá interně již léta; nedávno byl zaslán k začlenění jako netoops. Netoops je v podstatě jednoduchý ovladač, který zareaguje na jaderný oops tím, že nejnovější logy jádra odešle přes síť serveru. Taková funkce vypadá užitečně, ale první verze patche byla zpochybňována: netoops se podobá existujícímu systému netconsole, takže nebylo jasné, jestli je opravdu zapotřebí. Proč prostě nepřidat chybějící vlastnosti do netconsole?

Mike Waychison, který patch zaslal, v reakci vyjmenoval více důvodů, které od té doby také přidal do changelogu. Netoops posílá pouze data oopsu, takže spotřebovává menší šířku pásma sítě. Data jsou zabalena do struktur, takže je jednodušší je procházet jak strojově, tak pro člověka; to Googlu umožnilo vytvoření obrovské interní „databáze oops“. Netoops může zastavit výstup po prvním oops, což opět šetří síťový provoz. A tak dál. Oproti netconsole je rozdílů tolik, že její správce Matt Mackal souhlasil, že dává smysl začlenit netoops jako samostatnou vlastnost.

Zjevně je tu prostor pro sdílení kódu mezi těmito dvěma vlastnostmi, přičemž netconsole by přitom mohla být vylepšena. Současná verze patche netoops obsahuje nějaké části, které se mají o toto sdílení kódu postarat. Nezdá se, že by tu byla další opozice, ale je potřeba poznamenat, že Mike v changelogu patche píše, že se mu úplně nelíbí ABI pro uživatelský prostor, ani formát dat. Pokud tedy někoho dalšího zajímá tato funkcionalita, je správný čas zaslat připomínky nebo patche.

LPC: Život po X

napsal Jonathan Corbet, 5 listopadu 2010

Keith Packard pravděpodobně věnoval práci na X Window Systemu víc času než kdokoliv jiný. S historií 25 let dlouhou má X hodně za sebou, ale nic není věčné. Blíží se historie X ke konci? A co by mohlo přijít po nich? Ve své přednášce na Linux Plumbers Conference Keith prohlásil, že nemá žádný vliv na to, kudy se věci budou ubírat, ale že má pár nápadů. Tyto nápady se skládají do zajímavé vize naší grafiky.

Dostali jsme se do bodu, kde mnoho grafických aplikací běží na mnoha druzích systémů. Je zde klasické desktopové prostředí, do kterých se X server zrodil, ale to je jenom začátek. Mobilní systémy jsou čím dál tím silnější a v mnoha situacích nahrazují desktopy. Zařízení specifická pro média mají své vlastní požadavky na zobrazení. Vidíme grafické aplikace v dopravních prostředcích a v mnoha dalších situacích, kde se nasazují embedded řešení.

Keith položil otázku: kolik z těchto aplikací zajímá síťová transparence, která byla původně jednou z nejvýznamnějších vlastností X? Kolik z nich zajímá splnění ICCCM? Kolik z nich zajímají X jako taková? Odpověď na tyto otázky je samozřejmě „velmi málo“. Místo toho vývojáři navrhující pro tyto systémy s velkou pravděpodobností X odmítnou kvůli složitosti, náročnosti na paměť a CPU a kvůli tomu, že přispívají k dlouhému bootování. S klidem by se X zbavili úplně a Keith říká, že má v úmyslu jim vyhovět, aniž by přitom napáchal škody nám ostatním.

Do budoucnosti bez X

Ať už je to dobře, nebo ne, v současnosti je tu široká škála vykreslovacích API, ze kterých si můžeme vybrat, když programujeme grafické aplikace. Podle Keitha jsou zajímavá jenom dvě. Pro vykreslování videa je tu pár VDPAU/VAAPI; pro všechno ostatní je tu OpenGL. Při cestě kupředu na ničem jiném nezáleží.

V éře přímého vykreslování ani jedno z těchto API nezávisí na X. K čemu je tedy X server dobrý? Stále se toho v něm dělá hodně, nastavováním režimu zobrazení počínaje. Velká část této práce byla přesunuta do jádra, přinejmenším pro grafické čipové sady od „velké trojky“, ale zbytek stále dělá X. Pokud stále používáte nudnou 2D grafiku, X je právě pro vás - jak to řekl Keith, všichni milujeme ošklivé čáry a kostičkovaný text. Vstup z větší částí stále řeší X; jaderné rozhraní evdev se o něco postará, ale ne o všechno. Mapování kláves řeší X; opět to, co poskytuje jádro v této oblasti, je „primitivní“. X řeší ořezávání, když se okna aplikací překrývají; také se stará o správu 3D objektů pomocí rozšíření GLX.

To všechno hodně souvisí s tím, proč se o naše obrazovky stále stará X server. Nastavování režimu je odjakživa složitý úkol a potřebný kód je zakopán hluboko uvnitř X serveru; to zvyšuje bariéru pro konkurenci. Ořezávání oken se někde řešit musí. O správu videopaměti se stará X server, což vede k situaci, že pouze server může využívat jakoukoliv trvalou videopaměť. Díky X také fungují externí správci oken (a od jisté doby také kompozitní správci oken).

Za těch 25 nebo tak nějak let, co Keith pracuje na X, se ale věci změnily. V roku 1985 unixové systémy nepodporovaly sdílené knihovny; když uživatel spustil dvě aplikace linkované ke stejné knihovně, do paměti se načetly dvě kopie, přičemž paměť tenkrát byla vzácným zdrojem. Dávalo tedy smysl vložit kód grafiky do jednoho centrálního serveru (X), kde by ho bylo možné sdílet mezi aplikacemi. To už dávno dělat nemusíme; systémy mnohem lépe sdílí kód, který se objevuje v různých adresových prostorech.

Máme mnohem složitější aplikace – tenkrát v podstatě existoval jenom xterm. Tyto aplikace manipulují s mnohem větším objemem grafických dat a téměř každá operace zahrnuje obrázek. Vzdálené aplikace jsou implementovány protokoly, jako je HTTP; už není moc účelné k tomu používat X protokol. Máme grafické toolkity, které implementují dynamická témata, takže už není nutné používat samostatný správce oken, abychom vynutili jednotné systémové téma. Je mnohem jednodušší zajistit, aby systém reagoval „dostatečně rychle“; v X serveru je spousta obezliček (jako vlastnost „předbíhající se myš“ [mouse ahead]), které byly navrženy v době, kdy stroje reagovaly mnohem pomaleji. A také máme barevné obrazovky; v prvních dnech X byly ojedinělé a drahé.

Postupem času byl X window systém rozdělen do mnoha částí – X server, správce oken, kompozitní správce atd. Všechny tyto kousky jsou propojeny složitými asynchronními protokoly. Výsledkem je, že trpí výkonnost; například každý stisk klávesy musí projít přinejmenším třemi procesy: aplikací, X serverem a kompozitním manažerem. Takhle ale věci již dělat nemusíme; můžeme architekturu zjednodušit a zlepšit odezvy. S odstraněním všech těchto procesů jsou spojeny nevyřešené problémy – není jasné, jak by bylo možné implementovat ty hezké 3D efekty, které nabízí správci oken/kompozitní správci jako compiz – ale bez těch se možná obejdeme.

Co ale vzdálené aplikace ve světě bez X? Keith naznačil, že síťová průhlednost ve stylu X již není tolik zapotřebí. Jedním z prvních nasazení této transparence byly aplikace orientované na formuláře a dialogová okna; obojí je teď implementováno v prohlížečích webu. Pro ostatní aplikace fungují nástroje jako VNC a rdesktop a chovají se lépe než nativní X. Technologie jako WiDi (bezdrátový display Intelu) mohou také v některých situacích řešit potřebu vzdáleného zobrazení.

Práce k odvedení

Takže X se možná zbavit můžeme, ale jak bylo popsáno výše, stále je mnoho důležitých věcí, které dělá X server. Jestliže X zmizí, tyto funkce bude muset převzít něco jiného. Nastavování režimu se přesouvá do jádra, ale stále je mnoho zařízení bez podpory jaderného nastavování režimu [kernel mode setting, KMS]. Někdo bude muset implementovat KMS ovladače pro tato zařízení, jinak by mohla přestat fungovat. Podpora vstupních zařízení je částečně řešena pomocí evdev. Správu grafické paměti v mnoha případech řeší jádro pomocí GEM. Jinými slovy – věci se přesouvají do jádra a Keith je podle všeho potěšen, že se ze všech těchto funkcí stal problém někoho jiného.

Jiné věci ale chybí. Jednou z nich je slušné mapování kláves; to nelze (nebo by nemělo) být řešeno v jádře. Pracuje se na vytvoření knihovny „libxkbcommon“, která by umožňovala mapování kláves vložit přímo do aplikací. Záležitosti spojené s přístupností – například klávesnice místo myši [mouse keys], přidržení kláves [sticky keys] – je také potřeba řešit někde v uživatelském prostoru. Problém s ovladači vstupních zařízení není zcela vyřešen; komplikovaná zařízení (jako touchpady) potřebují podporu v uživatelském prostoru. U některých věcí je potřeba, aby práce s nimi nebyla tak náročná, přičemž tento úkol by bylo možné vyřešit nahrazením API efektivnějšími variantami. GLX by bylo možné v mnoha případech nahradit pomocí EGL, místo OpenGL by se mohlo použít GLES a VDPAU je zlepšení oproti Xv. Také je tu problém s kombinací X a ne-X aplikací tak, aby pro uživatele vypadaly unifikovaně.

Keith chvíli mluvil o nezamýšlených výhodách, které vzešly z vývoje za posledních několik let; mnoho z nich se bude hodit při cestě dále. Například kompozitní manažery vznikly kvůli tomu, aby se 2D aplikacím přidaly hezké efekty. Jenže, jak si vývojáři uvědomili, je ho možné také využít k vykreslování oken, aniž by bylo potřeba řešit ořezávání, což věci výrazně zjednodušilo. Oddělení vykreslování od změny obsahu na obrazovce – dva úkoly, které předtím byly nerozlučně spjaty – umožňuje používat vykreslování mnohem šířeji. Cílů kódu GEM bylo mnoho včetně možnosti stránkovat videopaměť, umožnit vytvářet textury z pixmap bez kopírování a spravovat trvalé 3D objekty. Společně s GEM přišlo přímé vykreslování bez zamykání, což zlepšuje výkonnost a umožňuje spustit více správců oken bez postihu výkonnosti. Jaderné nastavování režimu mělo zvýšit spolehlivost nastavení grafiky a umožnit zobrazení jaderných chybových zpráv, ale také zjednodušilo implementaci alternativních window systémů – nebo spouštění aplikací úplně bez nich. EGL bylo navrženo k portování aplikací mezi platformami; také to umožnilo spustit tyto aplikace v ne-X systémech a zahodit drahé schéma se sdílením GLX bufferů.

Keith ukázal dva obrázky zobrazující organizaci grafiky v Linuxu. Na obrázku „předtím“ byla k vidění hromada vykreslovacích rozhraní, která si všechna povídají s X serverem, jenž je středem vesmíru. Na obrázku „poté“ místo toho ve středu sedělo jádro a window systémy jako X a Wayland byly odstrčeny do rohu s tím, že jsou to trochu zvláštní aplikace. Když se dostaneme k „poté“, budeme mít mnohem jednodušší grafický systém nabízející větší flexibilitu i výkonnost.

Dostat se do tohoto bodu bude přirozeně vyžadovat mnohem více. Stále je potřeba odvést nějakou práci na plné integraci GL a VDPAU do systému. Je potřeba vyřešit problém se vstupními zařízení stejně jako podporu KMS ve video zařízeních od ostatních výrobců kromě „velké trojky“. Když se zbavíme správců oken, jejich práci bude muset převzít něco jiného; Windows a Mac OS tuto práci vytlačují přímo do aplikací, možná bychom měli také. V ostatních ohledech je tato budoucnost ale přímo před námi. Je například možné spustit X jako klienta Waylandu – a obráceně. Éra po X se blíží.

Diskuse k tomuto článku

[Marián Kyral]

Plány pěkné, ale jsem zvědav, jestli to bude někdy fungovat.

[kavol]

Vzdálené aplikace jsou implementovány protokoly, jako je Hyper Text Transfer Protocol ...

to myslím vypovídá o mnohém

[trekker.dk]

Od té doby, co existuje tag img, CSS styly apod., bych řekl, že ta část "text" už netvoří moc velkou část.

Krom toho velká část aplikací - obzvlášť těch, se kterými se pracuje vzdáleně - pracuje hlavně s textovými daty. Zbytek je jenom od toho, aby to vypadalo pěkně.

[Grunt]

No dobře, ale můj názor je, že implementace nějakého protokolu vzdálené plochy pomocí HTTP je prasárna². To už radši RTSP.

[trekker.dk]

Jakého protokolu vzdálené plochy? Třeba ábíčko je vzdálená plocha? Není, ale přesto s ním pracuješ jako se vzdálenou aplikací.

[Grunt]

No to těžko. Jestli pro někoho je aplikace vstup/výstup do databáze a formátování jeho výstupu, tak prosím. Pro mně teda ani omylem.

[trekker.dk]

Většina aplikací, které dneska potřebují pracovat na vzdáleném serveru, funguje přesně takhle. Uživatel se připojí přes webové rozhraní, něco někde vyplní, na serveru se zpracuje a pošle se výsledek. A obzvlášť u aplikací na zakázku tohle vyjde levněji, než nějaké nativní aplikace a protokoly pro přenos obrazu.

(A to nemluvím o faktu, že tu aplikací musíš nainstalovat, kdežto webový prohlížeč je všude.)

[Semo]

A to nemluvím o faktu, že tu aplikací musíš nainstalovat

Vzdialene spustanie cez X protokol je PRAVE o tom, ze ju instalovat nemusis. Staci ti X server a spustis uplne vsetko.

[trekker.dk]

Já měl na mysli aplikaci, která funguje lokálně a pracuje se vzdálenými daty... OK, je to off-topic.

Nicméně to ještě víc potvrzuje, co jsem napsal, protože aplikace napsaná na míru a spouštěná na vzdáleném serveru přes X bude tuplem dražší, než ta samá aplikace napsaná v PHP/Rails/apod.

[Grunt]

aplikace napsaná v PHP/Rails/apod

Možná bych si měl na termínu „bastl” trvat, protože aplikaci napsanou v PHP/RoR/apod. jsem ještě neviděl. Max. v Pythonu(PyGTK,…). Teda ne jako že by to snad nešlo…

[trekker.dk]

Jasně, když aplikace nefunguje způsobem, který ty uznáš za přijatelný, není to aplikace, ale bastl. Zajímavé měřítko, ale nepříliš objektivní. Spíš na hlavu padlé.

[Grunt]

všelijaké portály a na zakázku dělané systémy pro ukládání a správu a zpracování obecných dat.

Podaří-li se najít lepší, všemi uznávaný termín, budu pro něj všemi deseti. No na rozdělení si opravdu musím trvat.

[Vskutečnosti Saýc]

Jakoze webove aplikace nejsou aplikace? Proc se jim potom rika "webove aplikace"?

Pochopitelne je rozdil mezi CMS a slozitou aplikaci (ERP, SCM, nejaky dalsi zkratky by se najit daly). Ale prave u CMS je ten rozdil nejvic videt, abclinuxu je "aplikace pro cteni clanku a diskutovani o nich" a to bych v QT delat nechtel.

[pavlix]

Ale prave u CMS je ten rozdil nejvic videt, abclinuxu je "aplikace pro cteni clanku a diskutovani o nich" a to bych v QT delat nechtel.

Pokud by Qt byl můj oblíbený toolkit (což není), tak bych ho s klidem použil i na aplikaci pro čtení článků a účast na diskuzích. A instaloval bych to na desktop a použil nějaký slušný protokol pro komunikaci se serverem.

[imploder]

Ale fuj. Internet, na kterém bych si jen kvůli okomentování článku musel instalovat speciální binární (možná zavirovanou) aplikaci, by byl smutný internet. Buďme rádi za web a možnosti, které nám nabízí.

[pavlix]

Ale fuj. Internet, na kterém bych si jen kvůli okomentování článku musel instalovat speciální binární (možná zavirovanou) aplikaci, by byl smutný internet. Buďme rádi za web a možnosti, které nám nabízí.

Unavuje mě vyvracet argumenty postavené na hlavu.

1) Existují i jiné než binární aplikace.

2) Neexistuje jediný důvod, proč by pouhá existence binární aplikace na čtení článků znamenala její povinnou instalaci.

Buďme rádi za web a možnosti, které nám nabízí.

Žádal tu snad někdo o zrušení webu?

[trekker.dk]

Existují i jiné než binární aplikace.

Interpretované nebo binární, není v tom velký rozdíl. Furt to znamená něco instalovat naprosto zbytečně.

[pavlix]

Interpretované nebo binární, není v tom velký rozdíl. Furt to znamená něco instalovat naprosto zbytečně.

Nevím, jestli ty s oblibou instaluješ něco zbytečně. Já osobně si software k instalaci většinou vybírám.

[imploder]

Přesně tak. To bych byl nucen k instalaci aplikace, jenom abych si mohl číst články.

Však jestli chcete, můžete desktopovou aplikaci na čtení abíčka vyrobit. Ale tipuju, že se to moc neujme, většina lidí dá přednost mnohem univerzálnější aplikaci: prohlížeči. Aby to mělo smysl, musela by mít ta aplikace oproti webové nějaké zásadní výhody. Nenapadá mě, co by to mohlo být.

[Josef Kufner]

Tak ono takové aplikace už existují.

[imploder]

Ano, to znám a jsem nucen používat. V čem že je to lepší, než webová aplikace? I z webové aplikace se dají novinky zasílat RSS nebo mailem. A webová aplikace má lepší rozhraní (specializované na daný web).

[Josef Kufner]

Neříkám, že to je lepší (či horší). Jen že to už existuje, tak aby to nějaký tajtrlík nechtěl psát znova.

[pavlix]

Umí to vkládat komentáře? Pokud ne, tak je to jako diskuzní aplikace dost k ničemu.

[Josef Kufner]

Jo, je to obousměrné.

[Grunt]

Jakoze webove aplikace nejsou aplikace?

Tak možná z definice, ale když už to aspoň uznám tak bych prosil označení jiný druh aplikací. Jinak to že to nejsou aplikace jsem myslel zcela Pejorativně, nic víc (prostě se to blbě hackuje gdbčkem).

Pochopitelne je rozdil mezi CMS a slozitou aplikaci (ERP, SCM, nejaky dalsi zkratky by se najit daly).

No zrovna v tomhle já moc rozdíl nevidím a stavím všechny tyhle udělátka přibližně na stejnou úroveň. Možná proto, protože jedno jde udělat pomocí druhého (tím myslím ERP, SCM, usw. by se mělo držet striktně za hranicí WA a CMS a nedělat ostudu jinde). Primárním cílem těch udělátek totiž není fungovat, ale vydělat prachy či umožnit vydělat prachy. Takové drobnosti jako fungování nebo plnění účelu jsou u nich většinou až na druhém místě.

Ale prave u CMS je ten rozdil nejvic videt, abclinuxu je "aplikace pro cteni clanku a diskutovani o nich" a to bych v QT delat nechtel.

Docela drsné by bylo tohle dělení v dobách kdy vládnul Minesweeper a Netscape.

[imploder]

prostě se to blbě hackuje gdbčkem

To je teda opravdu svérázné kritérium pro to, co je a co není aplikace Pokud "hackováním" myslíš ladění, tak stejně tak můžu tvrdit, že v Qt se nedá napsat aplikace, páč se to blbě hackuje Laděnkou.

Primárním cílem těch udělátek totiž není fungovat, ale vydělat prachy či umožnit vydělat prachy. Takové drobnosti jako fungování nebo plnění účelu jsou u nich většinou až na druhém místě.

Jo, a protože je to úplně nefunkční, tak to tak dobře vydělává, že jo

[www]

aplikace napsaná na míru a spouštěná na vzdáleném serveru přes X bude tuplem dražší, než ta samá aplikace napsaná v PHP/Rails/apod.

Z týhle věty vyplývá, že v PHP nejde napsat desktopová aplikace. No v PHP neprogramuju, ale řekl bych, že se v PHP napsat dá. Ozývam se ale proto, že jestli tim "Rails" je myšleno "Ruby", tak můžu s čistým svědomím říct, že v Ruby se desktopová aplikace napsat dá a je to podle mě i dobrej nápad v Ruby takovou "desktopovou aplikaci" psát.

[trekker.dk]

Nic takového z té věty nevyplývá...

[Grunt]

A nebylo by už na čase začít nazývat věci pravými jmény? Tohle nejsou desktopové aplikace, ale všelijaké portály a na zakázku dělané systémy pro ukládání a správu dat. Vím, že titul „programátor aplikací” zní mnohem honosněji než třeba „bastlič”, ale já si aplikaci představuju trochu jinak na název nehledě. Samozřejmě pro využívání platformy webových služeb pro takové systémy jsem všemi deseti, no zvláštní je, že co jsem měl tu čest, tak zatím se to všechno dělalo přesně opačně (kdejaký .NET a kupa frameworků, které ani jmény pojmenovat neumím).

[Grunt]

A to nemluvím o faktu, že tu aplikací musíš nainstalovat, kdežto webový prohlížeč je všude.

A možná to někdo právě definoval sám líp, než já bych kdy byl vůbec schopen.

[Vskutečnosti Saýc]

Aplikace uz znamou definici davno ma, je to "kus sw co umoznuje uzivateli delat nejakou ulohu". Clovek muze mit pochopitelne vlastni, ale nevim jak moc bude uzitecna.

[Limoto]

Vždyť se tam zmiňuje o xtermu, tak co bys chtěl

[Martin]

Zda se mi to nebo se popis reseni odstraneni X napadne podoba tomu jak to principielne funguje nyni ve windows? (samozrejme ne uplne stejne)

[Milan]

Tak nejak :-/ Nejsem si jisty jestli to je dobre nebo ne, to nejspise ukaze az cas...

[imploder]

Neřekl bych. Nikdo necpe grafiku do jádra tím způsobem jako ve Windowsech. V čem to bude jako Windows, je rychlost. Odstraněním X se sníží režie. Je to tam napsané: X vzniklo v době, kdy nebylo na unixech dynamické linkování, takže místo oddělených knihoven se udělal celý oddělený program - server. Teď už je lepší to řešit jinak. Pro ty, kdo chtěljí používat vzdálené aplikace přes X protokol, bude i dál k dispozici X server - ne už ale jako nutný základ, ale jako možnost. Wayland s ním počítá jako s klientem.

[Roger]

Průšvih s "tak si na vzdálené aplikace dál používejte X" je v tom, že pro X už je nikdo psát nebude.

[imploder]

Nebude zbývat než použít toolkit, který X podporuje. No a když ne, tak smůla - aplikace nepůjde používat vzdáleně.

[Grunt]

O toolkity si starost nedělám. Zatím všechny mají jako hlavní výstup X11 a jsou s Xlib nalinkované dobře. Problém je takový, že už teď vznikají aplikace, které nepočítají s tím, že by mohly být použity vzdáleně, mají nestandardní chování a nebo používají nesmyslné zdroje.

[Jardík]

Vždyť je to zbytečné, kolik lidí si spustí na vzdáleném xserveru např. gimp, aby si maloval a ukládal na vzdálený server, kolik lidí si spustí pitivy, aby upravoval vzdáleně video, kolik lidí si pustí brasero a bude vypalovat, když vypalovačka je někde daleko, ... u většiny aplikací nemá vzdálený přístup smysl a utěch pár není problém, když si naimplementují posílání obrázků okna přes internet - s rozumným algoritmem to bude stejné, jako se vzdáleným x serverem.

[Grunt]

Třeba ten kdo není úplný debil a dovede využít síly X-protokolu v implementaci tenkého klienta, ten komu se zrovna nechce Googlit příkaz (variantu, že ho znát nechce si nepřipouštím, protože takovému člověku administrace do rukou nepatří) pro provedení nějaké akce, kterou lze na vzdáleném systému provést graficky a přitom nechce rušit uživatele, který na něm pracuje, ten kdo potřebuje nějakou grafickou aplikaci aby na vzdáleném systému něco monitoroval, ten kdo chce na jednom stroji paralelně provozovat jak Windows, tak GNU/Linux, ten …

…máš strašně malou představivost.

[trekker.dk]

Jo, to jsou možnosti... a teď kolik lidí něco takového opravdu dělá. Následně porovnej s počtem lidí, kteří vůbec nestojí o zpomalení všech svých aplikací kvůli pár exotům.

A btw.

dovede využít síly X-protokolu v implementaci tenkého klienta

... což dneska pravděpodobně nedělá nikdo, protože HW je levný.

ten komu se zrovna nechce Googlit příkaz pro provedení nějaké akce, kterou lze na vzdáleném systému provést graficky

... příklad?

ten kdo potřebuje nějakou grafickou aplikaci aby na vzdáleném systému něco monitoroval

... na to jsou mnohem vhodnější nástroje

ten kdo chce na jednom stroji paralelně provozovat jak Windows, tak GNU/Linux

... na to taky. Zadej do Google slovo virtualizace

[Josef Kufner]

Další pěknou mozností je něco jako grafický screen. Tedy že si spustíš grafickou aplikaci někde, necháš ji pracovat a čas od času se k ní vzdáleně připojíš (např. z notebooku) abys ji zkontroloval nebo trošku upravil nastavení. Už jsem několikrát viděl lidi se připojovat z domova na pracovní počítače v zaměstnání, protože se potřebovali na něco podívat nebo udělat nějakou drobnost. Tady webové rozhraní nemá šanci. Trošku to řeší např. VNC a podobné technologie, ale ty jsou dost pomalé a neohrabané.

[Grunt]

Vida. Pořád mluvím o schématu tenký klient/cluster,mainframe a na schéma embedded/pracovní stanice po vzoru MikroTik Winboxu jsem úplně zapomněl.

[Grunt]

Jo, to jsou možnosti... a teď kolik lidí něco takového opravdu dělá.

No právě pamatuju se, že jsem se s pavlixem bavil o systému pro embedded ve kterém grafiku přímo vykresluje jádro a jen dostává skrze nějakou linku z uživatelského prostoru jako symboly jednotlivé grafické prvky a dostal jsem odpověď: Proboha, na co? Vždy do dnešních embedded (které kvůli tomu musí mít všechno rozhozené do samostatný pouzder a brání to ještě v jejich větší miniaturizaci) systémů stačí doobjednat nějaký SRAM čip, nějaký NAND čip a můžeš na tom provozovat Xka nebo OpenGL aplikace. (a nebo aspoň něco v tom smyslu) Zatím mi přijde, že všechno se dělá přesně opačně než by se dělat mělo. Web do silných desktopů (protože kvůli různorodosti už prakticky není záruka, že cokoliv jiného nemůže skončit SIGTERMem) a OpenGL a podobné udělátka (v podobě Androidu) do Embedded systémů.

což dneska pravděpodobně nedělá nikdo, protože HW je levný

LOL, byl to opravdu pavlix?

příklad?

gnome-system-monitor

na to jsou mnohem vhodnější nástroje

Pokud jde o nějaký vědecký nástroj, pro který je nejlepší vizualizace grafická a který potřebuje vstupy s co nejmenší odezvou? (dost to splňuje definic aplikace) Nic lepšího než Xka mě nenapadá, zvláště pokud je třeba na zakázku napsaný v nějakém toolkitu a nenabízí třeba CLI.

Zadej do Google slovo virtualizace

Ach jo. Má to cenu se vůbec namáhat?

[trekker.dk]

Jasně, takže místo standardního rozhraní budu vymýšlet nějaké prasárny, kde bude něco vykreslovat přímo jádro, nebude to přenositelné na víc než jednu architekturu, o nějaké možnosti údržby ani nemluvě.

příklad?

gnome-system-monitor

To není akce, ale aplikace.

Pokud jde o nějaký vědecký nástroj, pro který je nejlepší vizualizace grafická a který potřebuje vstupy s co nejmenší odezvou?

Jak to souvisí se vzdáleným monitorováním systému?

A ty bys chtěl, aby nějaký vědecký nástroj (který pravděpodobně bude běžet dlouho na nějakém superpočítači), běžel zároveň s X aplikací? Myslím, že by se ti asi vysmáli, takové stroje se v co největší míře odstřihávají od sítě a vypíná se na nich všechno, co má jenom vzdálenou šanci ten systém sestřelit.

[Grunt]

Jasně, takže místo standardního rozhraní budu vymýšlet nějaké prasárny, kde bude něco vykreslovat přímo jádro, nebude to přenositelné na víc než jednu architekturu, o nějaké možnosti údržby ani nemluvě.

Ještě jednou: Embedded. Jinak přesně to se momentálně u Embedded děje.

To není akce, ale aplikace.

Která dovoluje provést určité akce.

A ty bys chtěl, aby nějaký vědecký nástroj (který pravděpodobně bude běžet dlouho na nějakém superpočítači), běžel zároveň s X aplikací? Myslím, že by se ti asi vysmáli, takové stroje se v co největší míře odstřihávají od sítě a vypíná se na nich všechno, co má jenom vzdálenou šanci ten systém sestřelit.

Očividně oba mluvíme úplně o něčem jiném.

[trekker.dk]

To není akce, ale aplikace.

Která dovoluje provést určité akce.

A ten příklad bude? Ne všichni používáme všechno, co ty.

Očividně oba mluvíme úplně o něčem jiném.

To zjevně, když jsi několikrát citoval jednu otázku a pak odpovídal na jinou...

[pavlix]

LOL, byl to opravdu pavlix?

Kde, jak, proč?

Mimochodem, vzdálené pouštění X aplikací s oblibou používám a dokonce i těch, které spoléhají na dostupnost D-busu, když už jsme u toho.

Ale zpět ke mně... co jsem teda provedl?

[Grunt]

BTW: Co tak reakce na ten výpustek? Též nemám nekonečně velkou představivost, což ovšem neznamená, že už nic jiného nejde vymyslet.

[Jakub Lucký]

... což dneska pravděpodobně nedělá nikdo, protože HW je levný.

Asi před dvěma rokama jedno pražské gymnázium implementovala tenko-klientovou třídu (15 počítačů + server) (na Windows)

Znám firmu s elektrem která má takto řešenou většinu firemních počítačů... taky na Windows...

[Grunt]

Ono všelijaké hotové mini-ITX klony a hotové sestavy jako ION PC jsou dneska hodně populární. Já dokonce pracoval ve firmě kde nic jiného než takový embedded PC (odhlédneme-li tedy od faktu, že je silnější než můj stolní PC) neměly, na něm Windows Embedded (přemalované XPčka mínus nějaké standardní redundantní vychytávky…skoro jako navrhovaný Windows 7 Started Edition) a RDP. Xka by pro takové leča co to implementovali bylo asi něco jako jaderná zbraň pro nacisty.

[pavlix]

Jo, to jsou možnosti... a teď kolik lidí něco takového opravdu dělá. Následně porovnej s počtem lidí, kteří vůbec nestojí o zpomalení všech svých aplikací kvůli pár exotům.

Potom by bylo zřejmě nejlepší celý Linux zrušit... Proč řešit kvůli pár exotům nějaký Linux, když stejně skoro všichni používají Windows?

Teď vážně, tady vůbec nejde o poměr počtu exotů vůči počtu trekkerů (vypůjčuju si toto slovo k označení opaku exota). Celý svět opensource dokazuje, že ne vždy záleží na názoru početní většiny (a nejen svět opensource).

Vzdálené pouštění jednotlivých grafických aplikací i celých grafických rozhraní považuju za extrémně užitečnou vlastnost. Jistě, pokud si někdo hloupě myslí, že tato vlastnost vyžaduje výrazné zpomalení všeho ostatního, v pořádku, neberu mu to. Ale zablokování možnosti vzdáleného běhu je významná regrese.

Jestliže velká část lidí vzdálené grafické aplikace nepoužívá, nemusí to nutně znamenat, že jsou neužitečné, třeba jsou jen běžnému člověku nedostupné (z různých důvodů).

[trekker.dk]

Potom by bylo zřejmě nejlepší celý Linux zrušit... Proč řešit kvůli pár exotům nějaký Linux, když stejně skoro všichni používají Windows?

Skoro všichni používají Windows? Cože? Největší superpočítače běží na Linuxu, tak polovina běžných serverů taky, potom jsou tu mobily (tam Windows rozhodně nepoužívá většina lidí), různé embedded aplikace, malé domácí routery (krabičky), a já nevim co ještě. Takže myšlenka zajímavá, ale stavíš na naprosto špatném předpokladu.

Za druhé: když si pořádně přečteš, na co reaguješ, tak je tam poměr lidí, kteří v produktu P používají vlastnost V, oproti lidem, kterým vlastnost V při používání produktu P škodí. Windows vs. Linux je něco jiného, protože používám-li na desktopu Linux, nijak to neovlivňuje fungování sousedova desktopu s Windows.

Jistě, pokud si někdo hloupě myslí, že tato vlastnost vyžaduje výrazné zpomalení všeho ostatního, v pořádku, neberu mu to.

Vyžaduje? Asi ne. V aktuálním provedení způsobuje? Rozhodně. A třeba by se to dalo i opravit, jenže to stojí práci, čas a prachy. A vzhledem k tomu, že tu vlastnost - přestože pár lidí vehementně tvrdí, jak strašně je užitečná - téměř nikdo nepoužívá, těžko bude nějaký výrobce vynakládat významnější prostředky na její zachování.

Ale zablokování možnosti vzdáleného běhu je významná regrese.

To je věc názoru. Pokud nějaká aplikace nikdy nebyla myšlena tak, že se má používat vzdáleně, není regrese, když to vůbec nebude možné. A tam, kde to šlo, to půjde dál. Nikdo neříká, že X server má být smeten z povrchu zemského. Pokud se o něj někdo bude chtít starat.

tady vůbec nejde o poměr počtu exotů vůči počtu trekkerů (vypůjčuju si toto slovo k označení opaku exota). Celý svět opensource dokazuje, že ne vždy záleží na názoru početní většiny

Ne, tady jde o poměr lidí, co něco dělají či financují vývoj a udávají směr, a pavlixů (vypůjčuju si toto slovo pro označení pitomce, co jenom kušní, že by něco chtěl, ale sám nehne prstem vůbec nebo téměř vůbec)

[Luboš Doležel (Doli)]

Tady se musím pavlixe zastat. X11 Forwarding je funkce, kterou používám opravdu velmi často a přijde mi nenahraditelná. Že ji Ubuntisti nevyužívají neznamená, že se to nehodí při vývoji a testování.

Kromě toho si na výkon v 2D nemůžu pod X stěžovat.

[pavlix]

Tady se musím pavlixe zastat.

Pozor Luboši, když se zastaneš hlupáka, budeš sám označen za hlupáka :P.

[pavlix]

Skoro všichni používají Windows? Cože? Největší superpočítače běží na Linuxu, tak polovina běžných serverů taky, potom jsou tu mobily (tam Windows rozhodně nepoužívá většina lidí), různé embedded aplikace, malé domácí routery (krabičky), a já nevim co ještě. Takže myšlenka zajímavá, ale stavíš na naprosto špatném předpokladu.

Je mi líto, že sis toho nevšiml, ale jediným účelem té věty bylo poukázat na nedomyšlenost tvého argumentu o podílu lidí, kteří používají vzdálený přístup ke grafickým aplikacím. Teď je to snad jasné.

Za druhé: když si pořádně přečteš, na co reaguješ, tak je tam poměr lidí, kteří v produktu P používají vlastnost V, oproti lidem, kterým vlastnost V při používání produktu P škodí.

A to je právě ta chyba. Ty vycházíš z předpokladu, že možnost použít vzdálený přístup někomu škodí. Já tento předpoklad považuju za nesmyslný a vycucaný z prstu.

Vyžaduje? Asi ne.

Výborně, to bych řekl, že potvrzuje spíše mou představu.

V aktuálním provedení způsobuje? Rozhodně.

Možná, možná ne. Já osobně jsem toho názoru, že možnost vzdálených session není příčinou pomalosti lokálních. Skutečného argumentu, který by mě přesvědčil, že se mýlím, se asi nedočkám.

A vzhledem k tomu, že tu vlastnost - přestože pár lidí vehementně tvrdí, jak strašně je užitečná - téměř nikdo nepoužívá, těžko bude nějaký výrobce vynakládat významnější prostředky na její zachování.

Nevím, čemu říkáš téměř nikdo. Já osobně se pohybuju mezi lidmi, kteří znají možnosti nástrojů, které používají a téměř všichni po síti X protokol aspoň čas od času používají.

Nevidím důvod, aby se kvůli 98 uživatelům začátečníkům udělala zbytečná regrese, i kdyby ji používali v poměru používali třeba jen dva lidi ze sta. Ale pořád je to dáno tím, že ty té funkci dáváš vinu za zpomalené, za které já ji vinu nedávám, takže se těžko můžeme shodnout (nehledě na to, že ani není potřeba, abysme se shodli :)).

Ne, tady jde o poměr lidí, co něco dělají či financují vývoj a udávají směr, a pavlixů (vypůjčuju si toto slovo pro označení pitomce, co jenom kušní, že by něco chtěl, ale sám nehne prstem vůbec nebo téměř vůbec)

A jak se potom nazývá člověk, který někoho nazývá hlupákem, na základě něčeho, co se o dotyčném ani nenamáhal zjistit?

Ale aspoň jsi na sebe všem čtenářům prozradil, co jsi zač a jak se chováš, když ti dojdou poslední zbytky argumentů.

[Lord Vetinari]

Aka regresia sa v X chysta ? Lebo ja som na zaklade sprav dospel k nazoru ze akurat pribudne wayland. Dufam ze vam nevadi ze si niekto bude moct vybrat nieco ine, co mu vyhovuje viacej.

Inac ma udivuje kolko ludi tvrdi ze X cez siet pouzivaju. Mozno by mohla byt anketa.

[pavlix]

Aka regresia sa v X chysta ? Lebo ja som na zaklade sprav dospel k nazoru ze akurat pribudne wayland. Dufam ze vam nevadi ze si niekto bude moct vybrat nieco ine, co mu vyhovuje viacej.

Já jsem za vznik Waylandu rád. Pokud to nebylo doteď poznat, tak zde to veřejně prohlašuju. Rovněž jsem zvědavý na budoucí vývoj. Jen jsem oponoval těm, kteří považují vzdálené spouštění aplikací za nesmysl. Se zrychlující se sítí bych v tom naopak viděl budoucnost (netrvám nutně na protokolu X11).

Pokud někdo navíc prohlašuje, že Wayland dokáže plně nahradit X11 a zároveň přiznává, že Wayland nefunguje po síti, říkám, že si protiřečí (tedy pokud to myslí globálně a ne jen ve svém případě).

Inac ma udivuje kolko ludi tvrdi ze X cez siet pouzivaju. Mozno by mohla byt anketa.

V podstatě všichni uživatelé X11, kteří splňují zároveň následující podmínky:

1) Nejsou úplné lamy (tedy jsou schopni si v dokumentaci najít jak například použít X over SSH).

2) Pracují se vzdálenými počítači.

3) Naráží přitom na úlohy pohodlněji či lépe řešitelné grafickou aplikací než konzolovou.

A vedle toho občas někdo někomu i neznalému zařídí na ploše ikonku na vzdálené spuštění aplikace.

Ještě mě napadá jeden případ z mojí praxe, a to je pouštění grafických aplikací na virtuálních strojích bez (plné) emulace grafiky.

A potom je potřeba připomenout na v některých místech zcela běžný způsob práce, a to je použití tenkých klientů. Tam o tom uživatel ani nemusí vědět, že je uživatelem síťového X11, prostě sedí u počítače a všechno funguje.

[Grunt]

1) Nejsou úplné lamy

Doporučuji zaGooglit si termín XDMCP. Ještě než to z gdm a kdm vyhodili, tak by to zvládla i moje babička.

pouštění grafických aplikací na virtuálních strojích bez (plné) emulace grafiky.

IMHO core fíčura, kterou se hedle tak nahradit nepodaří.

[pavlix]

IMHO core fíčura, kterou se hedle tak nahradit nepodaří.

Což o to, když je to technicky proveditelné na protokolu X11, není důvod, aby to nešlo implementovat jinde. Stejně je dneska veškerá grafika v podstatě posloupnost požadavků pro grafický chip. Podle mého skromného názoru je implementační detail, jestli se ty požadavky serializují na sběrnici nebo po TCP/IP, pokud se to vyloženě nezprasí.

[Grunt]

Tam jde spíš o ty okna, prvky a nějaké zajímavé funkce. To se hned tak redirectem sběrnice vybudovat nepodaří.

[pavlix]

Tam jde spíš o ty okna, prvky a nějaké zajímavé funkce. To se hned tak redirectem sběrnice vybudovat nepodaří.

Tak, grafická rozhraní mají přinejmenším dva úhly pohledu... co to umí za efekty, a jak se to dá usadit na hardware. Podle mě, když se jedno z toho udělá dobře, tak nic nebráním tomu, udělat dobře i to druhé, v podstatě nezávisle na tom.

[trekker.dk]

Ty vycházíš z předpokladu, že možnost použít vzdálený přístup někomu škodí. Já tento předpoklad považuju za nesmyslný a vycucaný z prstu.

Citace z článku, který popisuje přednášku jednoho z hlavních vývojářů X serveru:

Postupem času byl X window systém rozdělen do mnoha částí – X server, správce oken, kompozitní správce atd. Všechny tyto kousky jsou propojeny složitými asynchronními protokoly. Výsledkem je, že trpí výkonnost; například každý stisk klávesy musí projít přinejmenším třemi procesy: aplikací, X serverem a kompozitním manažerem. Takhle ale věci již dělat nemusíme; můžeme architekturu zjednodušit a zlepšit odezvy.

A to není jediný případ, kde se tohle tvrzení objevuje. Pokud se mám rozhodnout, jestli uvěřím dlouholetému vývojáři X serveru, nebo tobě, tak hádej koho si vyberu.

A jak se potom nazývá člověk, který někoho nazývá hlupákem, na základě něčeho, co se o dotyčném ani nenamáhal zjistit?

Jak jsi do lesa volal, tak se z lesa ozvalo. Ale prosím, dle libosti můžeš předvést, kde jsi něco financoval nebo hnul prstem.

Ale aspoň jsi na sebe všem čtenářům prozradil, co jsi zač a jak se chováš, když ti dojdou poslední zbytky argumentů.

Tak teď jsi mě málem rozplakal... doufám, že nepřijde na řadu spravedlivý hněv lidu, který se mnou zatočí.

[Grunt]

Postupem času byl X window systém rozdělen do mnoha částí – X server, správce oken, kompozitní správce atd. Všechny tyto kousky jsou propojeny složitými asynchronními protokoly. Výsledkem je, že trpí výkonnost; například každý stisk klávesy musí projít přinejmenším třemi procesy: aplikací, X serverem a kompozitním manažerem. Takhle ale věci již dělat nemusíme; můžeme architekturu zjednodušit a zlepšit odezvy.

Tohlencto můžu potvrdit. Tohle je pravda. Zrovna se v tom hrabu. Na všechny eventy (požadavky, odpovědi, chyby) to má frontu, která se sama plní a pak se postupným voláním nějaké Eventové procedury v libX11 likviduje. A tohle se týká asi skoro všeho a to i na straně serveru. No na druhou stranu těch pár instrukcí navíc (teda aspoň v poměru k tomu co ty dnešní rachotiny dovedou za sekundu zpracovat) a trocha paměti co si to vezme je jen velice malá cena vzhledem k tomu co to všechno dovoluje. A to se týká jak té asynchronnosti, tak jednotlivé rozvrstvení celé architektury do spousty menších celků (, které se jako celek dost blbě spravují).

[trekker.dk]

No na druhou stranu těch pár instrukcí navíc (teda aspoň v poměru k tomu co ty dnešní rachotiny dovedou za sekundu zpracovat) a trocha paměti co si to vezme je jen velice malá cena vzhledem k tomu co to všechno dovoluje.

Asi to nebude jenom pár instrukcí navíc. Hádám, že jestli tam je víc procesů, tak to taky znamená nějaké IPC, přepínání, plánování... z hlediska latencí nepříliš ideální situace i pro nabušenou mašinu.

A navíc se to docela vztahuje k tomu, co řešíme dole. Stolní rachotina to "navíc" možná zvládne, ale u mobilů by se toho výrobci rádi zbavili, takže pracují na změnách. No a když už to půjde na mobilech, proč by to samé nemohlo jít na PC...?

[Grunt]

Asi to nebude jenom pár instrukcí navíc.

Říkám že v poměru. Jinýma slovama na status-baru vytížení procesoru to není poznat už nějaký 10, 20 let. Problém je v tom, že když by se tento prvek z řetězu odstranil, tak většinu těch činností stejně bude muset buď dělat někdo jiný a nebo se o to budou muset starat ty aplikace samy, takže fakt pokrok. Ale klidně to zprofiluju, jestli bude potřeba.

z hlediska latencí nepříliš ideální situace i pro nabušenou mašinu.

Na dnešních mašinách lidským vjemem až na pár speciálních případů téměř nepostřehnutelné.

Stolní rachotina to "navíc" možná zvládne, ale u mobilů by se toho výrobci rádi zbavili, takže pracují na změnách.

Sorry, ale původní Xková architektura počítala s tím, že dostane píchnuto od hardwaru při pomáhání zpracovávání dat, které tak pracně od sebe odděluje a ne že data která předá dál bude zase softwarově zpracovávat nějaký proces vedle běžící na stejném procesoru. Když se do takového mobilu nacpe jeden víceúčelový procesor, který měl sloužit pouze jako kontrolér nejde od toho čekat nějaké zázraky. Když se do něj nacpe nějaký kontrolér a nějaké specializované jednoúčelové DSP, pak se možná zázraky dít budou.

No a když už to půjde na mobilech, proč by to samé nemohlo jít na PC...?

Protože se tím nezíská nic významného a bečí po tom maximálně ovečky co to potřebují na sledování porna. Netvrdím, že nápady jako Wayland jsou čiré temné zlo. Určitě svoje uplatnění najdou a sám to budu určitě používat, pokud to vznikne. Ovšem je potřeba vyvarovat se neuváženého a nevhodného nasazení, protože tím můžeme dost snadno zabít velice dobrou technologii vyvíjenou po 25 let (za cenu porna).

[imploder]

Netvrdím, že nápady jako Wayland jsou čiré temné zlo. Určitě svoje uplatnění najdou a sám to budu určitě používat, pokud to vznikne. Ovšem je potřeba vyvarovat se neuváženého a nevhodného nasazení, protože tím můžeme dost snadno zabít velice dobrou technologii vyvíjenou po 25 let (za cenu porna).

+1

[trekker.dk]

Říkám že v poměru. Jinýma slovama na status-baru vytížení procesoru to není poznat už nějaký 10, 20 let

Nemluvím o vytížení procesoru, mluvím o latencích, které zatahuje střídání procesů (studené cache, cache bouncing) a spol.

Na dnešních mašinách lidským vjemem až na pár speciálních případů téměř nepostřehnutelné.

No to je právě to, s čím s tebou spousta lidí nebude souhlasit. Jinak by pomalé odezvy desktopu asi nikdo neřešil, ale řeší se hodně.

Sorry, ale původní Xková architektura počítala s tím, že dostane píchnuto od hardwaru při pomáhání zpracovávání dat, které tak pracně od sebe odděluje a ne že data která předá dál bude zase softwarově zpracovávat nějaký proces vedle běžící na stejném procesoru.

No já nevim... mám jednu aplikaci, která chce něco vykreslovat (a tak si o to říká X serveru), a pak druhou (X server samotný), tam míň procesů než dva mít prostě nejde.

Ovšem je potřeba vyvarovat se neuváženého a nevhodného nasazení, protože tím můžeme dost snadno zabít velice dobrou technologii vyvíjenou po 25 let

No a to je právě to. Jeden z autorů té technologie tvrdí, že pomalu zastarává, a podkládá to docela dobrými argumenty... na druhé straně barikády přitom hlavním (a téměř jediným) argumentem je "já chci spouštět grafické aplikace vzdáleně"

[imploder]

No to je právě to, s čím s tebou spousta lidí nebude souhlasit. Jinak by pomalé odezvy desktopu asi nikdo neřešil, ale řeší se hodně.

Kromě toho PC, to není jenom desktop, ale taky hry. A tam na tom sakra záleží. A neříkej, že tím pohrdáš. Někomu (asi velké většině lidí) zase můžou být u ty-víš-čeho všichni ti tencí klienti a jiné výmysly.

[trekker.dk]

Možná reaguješ na špatný příspěvek a/nebo na špatného člověka.

[imploder]

Reaguju na příspěvek správného člověka Chtěl jsem doplnit

Na dnešních mašinách lidským vjemem až na pár speciálních případů téměř nepostřehnutelné.

No to je právě to, s čím s tebou spousta lidí nebude souhlasit. Jinak by pomalé odezvy desktopu asi nikdo neřešil, ale řeší se hodně.

- viz "kromě toho".

[Grunt]

Dejte s tím pornem pokoj.

[mirec]

Ehm neviem ako je to u hier, ale réžia X u videa je zanedbateľná. Nedávno som to zo srandy skúšal, celková réžia video výstupu HD 1080 mizernej kvality (poslal nejaký spolužiak že vraj priveľa objektov a nedá sa prehrať lebo je to zložité blabla, na 1.5 GHz som mal rezervu asi 40%) bola 8% (réžia == posielanie dát do grafiky + prevod yuv + pridanie nejakého OSD + kompletná réžia X vrátane prepínania procesov). Pri HD lepšej kvality, ktoré už fakt nemám šancu prehrať v reálnom čase je réžia < 5% (ktovie koľko z toho spôsobujú X). Takže zrýchlenie prehrávania HD zrušením X je zanedbateľné. No a zvyšné kraviny o réžii stlačenia klávesy sú oničom, snáď mi nikto nechce tvrdiť, že stlačím klávesu a teraz musím nejako dlho čakať na X až to doručia aplikácii. Tá latencia je dostatočne malá na to, aby som ju ani nepostrehol (mimochodom robím aj s Win 7 a tam problémy s latenciou a pomalosťou renderovania zaznamenávam bežne). X11 má svoje muchy, ale nie je príčinou pomalosti.

[Grunt]

S tím pornem jsem to myslel jako obrazně.

[Grunt]

mluvím o latencích, které zatahuje střídání procesů (studené cache, cache bouncing) a spol.

No neúnosné. Stěžoval si doposud někdo? Celé je to jen o vyčištění fronty, zpracování dat, naplnění fronty. Strašný overhead. Většina dnešních procesorů to zpracuje na jedno probuzení, protože v případě XShm je to jen šoupání pointerů sem a tam. A místa na optimalizaci je dost. Takže v čem je problém?

No to je právě to, s čím s tebou spousta lidí nebude souhlasit. Jinak by pomalé odezvy desktopu asi nikdo neřešil, ale řeší se hodně.

Netvrdím, že celá architektura Xek je naprosto dokonalá (25 let se asi podepíše na každém). Místa na zlepšení je spousty, ale zlepšení zabitím , tomu je dost obdobné vrtění psem.

No já nevim... mám jednu aplikaci, která chce něco vykreslovat (a tak si o to říká X serveru), a pak druhou (X server samotný), tam míň procesů než dva mít prostě nejde.

Tím jsem myslel moduly, Cairo, smrt font serveru a podobné vychytávky.

na druhé straně barikády přitom hlavním (a téměř jediným) argumentem je "já chci spouštět grafické aplikace vzdáleně"

Hlavním argumentem je: Architektura X je pečlivě a dobře navržená (i když má své mouchy) a hned tak na povel se toto století vhodnou náhradu na podobné úrovni vymyslet nepodaří. Teda aspoň z mé strany.

[trekker.dk]

No neúnosné. Stěžoval si doposud někdo?

Na latence desktopu a grafiky? Co tak čtu diskuze tady, tak jednoznačně jo.

Místa na zlepšení je spousty, ale zlepšení zabitím , tomu je dost obdobné vrtění psem.

Zase zabití - opakuju znovu, že nikdo neříká, že by X server měl být zrušen. Nicméně pokud o něj nebude zájem, protože bude k dispozici lepší alternativa, bude utlumen vývoj.

Tím jsem myslel moduly, Cairo, smrt font serveru a podobné vychytávky.

No ale tím se vracíme na začátek - já měl na mysli to, co už jsem psal vejš: požadavky na vykreslení a samotné vykreslování mají na starosti dvě různé aplikace, místo toho aby se aplikace vykreslovala sama. Možná s tím, že by se něco maximálně staralo o to, které okno je nahoře a které dole, což se samozřejmě netýká aplikací běžících ve fullscreenu.

hned tak na povel se toto století vhodnou náhradu na podobné úrovni vymyslet nepodaří

Tak to je HODNĚ odvážné tvrzení.

[imploder]

A přitom zrovna na mobilech a podobných zařízeních dává používání vzdálených aplikací spíš větší smysl než na PC, kde je typicky spoustu místa a výkonu na to, aby mohly běžet lokálně. Asi bude lepší, když bude možnost používat to, co se na dané použití hodí a ne např. všude cpát Xka, i když se na nic nevyužijou; nebo naopak nasadit něco šíleně výkonného, co by ale vzdálené používání aplikací znemožňovalo. Prostě každý program dělá jednu věc a dělá ji pořádně.

[trekker.dk]

A přitom zrovna na mobilech a podobných zařízeních dává používání vzdálených aplikací spíš větší smysl než na PC

Tohle je IMO nesmysl. Doma možná, tam si můžeš natáhnout wifi nebo kabel, ale někde mimo - na ~40kbps GPRS, v lepším případě možná EDGE - by ses ze vzdáleně běžících aplikací pravděpodobně zbláznil. (A pravděpodobně by ses taky nedoplatil.)

[imploder]

Nemyslel jsem to tak, že je nutné mít na mobilu X-server a používat aplikace přes X protokol. Myslím to tak, že se hodí mít možnost obecně z mobilu používat vzdálené aplikace (s vhodným protokolem). Možná je načase vymyslet nějakou lepší alternativu. Příkazové řádky si na mobilu taky moc neužiju, blbě se na tom píše. Ve světle těchhle zjištění se nakonec webové aplikace jeví jako dost dobrá alternativa, resp. nic lepšího teď nemáme.

[trekker.dk]

Myslím to tak, že se hodí mít možnost obecně z mobilu používat vzdálené aplikace (s vhodným protokolem).

V principu nemám námitky, ale v praxi - když pominu ty webové aplikace - je to IMO aktuálně ve větším rozsahu jenom těžko realizovatelné.

[pavlix]

A to není jediný případ, kde se tohle tvrzení objevuje. Pokud se mám rozhodnout, jestli uvěřím dlouholetému vývojáři X serveru, nebo tobě, tak hádej koho si vyberu.

Jak tak čtu, tak si s dlouholetým vývojářem X serveru nijak neprotiřečím. To, že máš potřebu si někoho z nás vybrat je jen tvůj problém, který si holt nějak vyřešíš.

Jak jsi do lesa volal, tak se z lesa ozvalo.

To by platilo, pokud bych ti začal bezdůvodně nadávat já, ale tak se to nestalo (ještě jednou jsem si to po sobě přečetl a ověřil jsem si, že jsi s nelichotivými označeními přišel první).

Ale prosím, dle libosti můžeš předvést, kde jsi něco financoval nebo hnul prstem.

Ehm tobě? Děláš si ze mě legraci? Nejdřív mi nadáváš, a pak mě snad ještě požádáš o životopis :).

Já si počkám, až mi ty dokážeš, že stojíš aspoň za tu diskuzi. Mně totiž diskutování celkem baví, ale jen s lidma, kteří udržují určitou kulturu komunikace, která mi vyhovuje. Výhodou je, když přinesou i nějaké nové informace, ale požadovat to samozřejmě nemůžu.

Tak teď jsi mě málem rozplakal... doufám, že nepřijde na řadu spravedlivý hněv lidu, který se mnou zatočí.

Ok, pochopil jsem, že tě názor jiných lidí než tebe samotného nezajímá, proč taky.

[trekker.dk]

Děláš si ze mě legraci? Nejdřív mi nadáváš, a pak mě snad ještě požádáš o životopis

O nic nežádám, to sis vyložil špatně. Jenom jsem tě taktně upozornil na to, že máš možnost (použijeme rétoriku tvého #100) před všemi čtenáři ukázat, jak moc se pletu.

[pavlix]

O nic nežádám, to sis vyložil špatně. Jenom jsem tě taktně upozornil na to, že máš možnost (použijeme rétoriku tvého #100) před všemi čtenáři ukázat, jak moc se pletu.

Velká část čtenářů mě zná. A nevím proč bych zrovna tobě měl něco dokazovat.

Ohledně mého #100 a tedy tvého #90, tam už jsi se předvedl ty myslím dostatečně :). Nebudu s tebou závodit, kdo umí druhého lépe urážet a sám sebe vyzdvihovat, na to si jistě najdeš někoho jiného.

[imploder]

Však se nic neruší. Některé aplikace budou pořád psané pod toolkitem schopným komunikovat s X serverem. Pro ty ostatní snad bude existovat nějaké proxy, které bude emulovat X klienta.

[pavlix]

Však se nic neruší. Některé aplikace budou pořád psané pod toolkitem schopným komunikovat s X serverem. Pro ty ostatní snad bude existovat nějaké proxy, které bude emulovat X klienta.

To je nedorozumění, já reagoval na trekkera, který zřejmě pro odstranění možnosti vzdálených aplikací je.

To ještě neznamená, že bych věřil, že lidi jako trekker dokážou prosadit svou :). Fakt to byla jenom reakce to, co jsem četl v diskuzi vždy o příspěvek výše.

[trekker.dk]

To je nedorozumění, já reagoval na trekkera, který zřejmě pro odstranění možnosti vzdálených aplikací je.

Zjevně máš problémy s chápáním psaného textu. Zkus trénovat a třeba se to zlepší.

[pavlix]

Ne vždy je problém u příjemce.

[Petr Ježek]

"...protože HW je levný." To je argument ve stylu "protože mám dobrou náladu" - tady někdo nesleduje vývoj ekonomiky a jejích drojů. Kromě toho, již dnes se zdražuje provoz HW, a to tím rychleji, čím více je autonomních plně napájených jednotek (stanic). Prosím, opusťte stereotypní myšlení i tam, kde nejde o perspektivu X a alternativních řešení...

[trekker.dk]

tady někdo nesleduje vývoj ekonomiky a jejích drojů.

... ale zato sleduje vývoj cen hardwaru, kde za stejné peníze je možnoswt pořizovat čím dál tím výkonnější stroje - a tím pádem za čím dál menší peníze za stejně výkonné stroje, dokud jsou k dispozici. Obě kategorie přitom umožňují bezproblémový lokální běh aplikací a není tedy zapotřebí vkládat prostředky k nasazování infrastruktury pro tenké klienty.

Takže "HW je levný" JE dobrý argument.

[Grunt]

Co ovšem není vůbec levné jsou zdroje energie co to mají pohánět a nějak se né a né spravit, což zase je dobrý argument pro.

[trekker.dk]

V tomhle ohledu jsem optimista. Pokud se nebudou vymýšlet nespolehlivé a zpravidla neekologické kraviny typu elektrárny na mrkev biomasu, solární elektrárny, větrné elektrárny, bude energie ještě nějaký pátek dost.

A jinak bych si tipl, že mezi spotřebou tenkého klienta udělaného ze starého šrotu a normálního desktopu tak velký rozdíl nebude. U opravdového tenkého klienta to bude něco jiného, ale po zkušenostech s těmahle udělátorama od Sunu bych tohle nasadil tak maximálně u svého největšího nepřítele.

[imploder]

Nejefektivnější a přitom ekologické jsou jaderné elektrárny. Nesmí je ovšem provozovat diletanti. Zelení jsou celkem nepochopitelně proti nim; přitom druhá alternativa je zůstat u uhlí ==> špinavý vzduch, zničené lesy, skleníkový efekt; a časem uhlí dojde.

[Jiří Svoboda]

Jsem zastáncem jaderné energie, ale dovoluji si upozornit, že i ten uran dojde.

[imploder]

Všechno jednou dojde. Uran dojde až za dost dlouho (stovky let) a mezitím se možná vyvine studená fúze nebo jiná alternativní technologie.

[Jakub Lucký]

Jo, přesně to s Gimpem potřebuju... Mám pomalý tabletPC a výkonný počítač...

[Grunt]

Nechci ti do toho kecat, ale už ti říkali jak strašně efektivní je tahat obrovské nekomprimované bitmapy po síti? Dost často s tím mívají problémy i sběrnice uvnitř počítače a ty dost často valí na úplně jiných rychlostech než jaké nabízí síť. Teda ne že by to nešlo, ale…

[Jakub Lucký]

Já jsem to teda ještě pořádně nezkoušel... Ale ten Gbit to neutáhne?

[Grunt]

Tak netvrdím že to neutáhne, no ale práce to nebude nic moc. Teda samozřejmě záleží na tom co to bude za práci.

[xurfa]

gimp utahle vpohode i 100MB/s

[Grunt]

když si naimplementují posílání obrázků okna přes internet - s rozumným algoritmem to bude stejné, jako se vzdáleným x serverem.

Ještě ten rozumný algoritmus by mě zajímal. Doufám, že už opravdu nebudeš schopen ničím mě překvapit, protože už jsem viděl i takové návrhy jako JPEG.

[Jardík]

Spíš jsem tím myslel to, že se nebude pokaždé posílat celá bitmapa, ale jenom změněný kousek.

[Grunt]

Otázka: Nač odesílat bitmapu (i pouze jako residuum nehledě na to, že v případě fullscreen gimpu a posouvání zazoomovaného obrázku tím toho stejně moc nevychytáš), když většina grafiky je stejně vektorová a dovede ji renderovat až nějaká jednotka GPU, když teď je efektivně zaběhnutý systém práce s glyfy a podobné vychytávky. Jestli se ti podaří implementovat rozumnější algoritmus, tak tě asi osobně půjdu navrhnout na nobelovku.

[Grunt]

Vždyť je to zbytečné, kolik lidí si spustí na vzdáleném xserveru např. gimp, aby si maloval a ukládal na vzdálený server

Jinak když už si to navrhnul, tak si vůbec nedovedu představit nějakou místnost plnou grafiků a podobné chamradě, která pracuje na tenkých klientech (teda tenkých aspoň v poměru) připojených Xkama na nějaký cluster nebo mainframe (klidně i se specializovanými DSP) kde zpracovávají v GIMPu nějaké bitmapy v gigantickém rozlišení. Teda odhlédneme-li od faktu, že posílání bitmap tak jak je řešené momentálně je pro takovou práci silně neefektivní, muselo by se ňák předělat a práce by to prozatím asi nebyla nic moc.

[trekker.dk]

Kdyby to byl problém, pak by vznikl tlak na autory, aby aplikaci upravili. Tlak není, takže tenhle problém je zjevně zanedbatelný.

A ber to tak, že do budoucna si 99% uživatelů z rychlost vs. vzdálené spuštění vybere raději rychlost.

[Grunt]

A ber to tak, že do budoucna si 99% uživatelů z rychlost vs. vzdálené spuštění vybere raději rychlost.

Dost to souvisí také s tím jak se uživatelská základna začíná měnit (resp. rozrůstat). Chtěl-li někdo odpověď na to proč ne nové uživatele (z větší části lamy) ke GNU, tak tady je odpověď.

[trekker.dk]

Abych pravdu řekl, za lamu se nepovažuju a bez X se taky s klidem objedu. Na desktopu mi stačí, když všechno funguje lokálně, na server mám SSH.

Ale pokud chceš, můžeš si klidně hrát na svém písečku, nové uživatele (a to, co používají) s klidem ignorovat, a někde v koutku brečet, že pro tebe a těch dalších ani ne 1% lidí nikdo nevyvíjí aplikace.

[Grunt]

Abych pravdu řekl, za lamu se nepovažuju a bez X se taky s klidem objedu.

Netvrdím, že já ne. Ale těch pár procent overheadu jež X Server představuje je pro mě snesitelných (vzhledem k tomu kde se většinou nasazuje) výměnou za síťovou transparentnost pro všechny na něj napojitelné aplikace, kterou nabízí.

Na desktopu mi stačí, když všechno funguje lokálně, na server mám SSH.

Jak říkám: Prostě malá představivost.

Ale pokud chceš, můžeš si klidně hrát na svém písečku, nové uživatele (a to, co používají) s klidem ignorovat, a někde v koutku brečet, že pro tebe a těch dalších ani ne 1% lidí nikdo nevyvíjí aplikace.

Nic jiného mi už asi ani nezbude.

[pavlix]

Abych pravdu řekl, za lamu se nepovažuju a bez X se taky s klidem objedu. Na desktopu mi stačí, když všechno funguje lokálně, na server mám SSH.

Zablokování možnosti použití grafických aplikací běžících na serveru je významná regrese.

[trekker.dk]

Co to furt meleš o nějakém zablokovávání? To furt operuješ za předpokladu, že X server bude zrušen a bez náhrady zničen? Jo, jestli se přestane vyvíjet, to budeš mít smůlu, ale to není žádná regrese, ale prostě nedostupnost nové verze.

[Grunt]

O toolkity si starost nedělám. Zatím všechny mají jako hlavní výstup X11 a jsou s Xlib nalinkované dobře. Problém je takový, že už teď vznikají aplikace, které nepočítají s tím, že by mohly být použity vzdáleně, mají nestandardní chování a nebo používají nesmyslné zdroje. ^↑

Jinýma slovama:Všechny aplikace, které do teď běží skrze unixový socket lokálně s největší pravděpodobností nebudou mít nejmenší problém běžet skrze TCP/IP vzdáleně (až na některé leča). V případě, že nebude splněna první podmínka, dost pochybuju o to že bude splněna i ta druhá.

[pavlix]

Co to furt meleš o nějakém zablokovávání? To furt operuješ za předpokladu, že X server bude zrušen a bez náhrady zničen? Jo, jestli se přestane vyvíjet, to budeš mít smůlu, ale to není žádná regrese, ale prostě nedostupnost nové verze.

Vzhledem k tomu, že mě považuješ za hlupáka, asi nemá cenu, abys se mnou nadále diskutoval, že :).

[trekker.dk]

A pak komu dochází poslední zbytky argumentů...

[pavlix]

Třeba to jednou pochopíš :).

[JoHnY2]

A nebylo by resenim pouzivat obdobu RDP, ICA nebo treba SPICE? Prijdeme tim o cast kouzel X serveru, ale kdyz porovnam jak po jedny lince chodi X protokol, RDPcko a ICA, tak jsou to uplne jiny ligy. A na SPICE jsem slysel uplny chvalozpevy

[Grunt]

Ano, můžeme něco udělat blbě a můžeme něco udělat úplně na ho***. Takže proč to dělat blbě, že?

[trekker.dk]

Ty tvoje úplně na ho*** se na pomalé lince používají mnohem lépe než X. Vyzkoušeno.

[Grunt]

Co tak zkusit zapnou kompresi, vypnout SW render a v případě přenášení velkého množství (určitě nutných) bitmap/pixmap zmenšit bitovou hloubku? Netvrdím, že zrovna v tomto ohledu je X protokol zrovna 100% bezchybný, ale jako jeho náhradu navrhovat RDP chce buď dost zvláštní duševní rozpoložení nebo hodně vysokou hladinu alkoholu v krvi, protože jinak to snad ani není ospravedlnitelné. Když už, tak aspoň doporučení ITU-T T.120 jehož znásilněnou verzí RDP je.

[R]

Bolo by pekne, keby som sa konecne po tolkych rokoch pouzivania Linuxu dockal na mojich relativne starych PC rychleho GUI? Na Radeone mozno ano, ale horsie to bude s grafikami mimo mainstream...

[Jardík]

Nikdo necpe grafiku do jádra tím způsobem jako ve Windowsech.

Ve Windows je pro grafiku věcí minimálně, od Windows Vista je grafický subsystém hezky oddělen, dokonce víc, než nějaké KMS v kernelu, díky kterému je každá chyba v grafice pro kernel smrtelná. Ve Windows se to hezky dokáže vzpamatovat a to dokonce bez ukončení GUI aplikací.

[Grunt]

Ale dej už svatý pokoj.

[Jardík]

Tak já nevím, on trolluje, jak je to ve windows narvaný v jádře a přitom tomu tak pár let už není. Měl by si ověřit fakta, než plácne takovou kravinu, obzvláště, když do linuxu narvali KMS.

[trekker.dk]

KMS není grafika v jádře. KMS je způsob, jak manipulovat s grafickým hardwarem standardním způsobem a v jádře, kam taky manipulace s (jakýmkoliv) hardwarem patří. Windows v jádře měly všechno.

Takže než plácneš kravinu, měl by sis ověřit fakta.

[Jardík]

Měly ... a jsme u toho. Kdy, před 9 lety? V té době byla jediná GUI aplikace na linux xterm. A když se grafika v linuxu zblázní zavření a otevření displeje, to je správný způsob, jak manipulovat s hardwarem? KMS je neskutečná šmejďárna, už se mi párkrát stalo, že se kvůli tomu zaseknul celý systém (s opensource intel ovladačem).

[hanzz]

A jsme u toho..., Pred deviti lety bylo vice GUI aplikaci nez xterm.

[trekker.dk]

XP to ještě měly postaru a ty se používaly do roku 2007(?), protože novější Windows nebyly. Takže se nějakými 9 roky jdi mlžit někam na lživě.

[Jardík]

Ano, měly to postaru, ale je vidět značné zlepšení, ale v linuxu se všechno narve do kernelu a bude to ještě horší, než to bývalo (i když on ten X server dokázal/dokáže celej systém zasekat taky i bez KMS, před pár lety jsem tu popisoval hezká DnD v gimpu).

[Grunt]

Já ti říkal aby ses uklidnil. KMS není nic jiného než změna rozlišení, frekvence monitoru a podobných parametrů ovladačem v jádře, který ty parametry buď dostane jako parametr kernelu a nebo z uživatelského prostoru. Nic víc. Dřív se to buď dělalo jako BIOS volání před tím než bylo vůbec načtené jádro a než přeplo adresovací režim, nebo právě pomocí UMS z Xserveru a znalostí ovladačů pro Xserver (což funguje většinou dodnes). To co ty obviňuješ je cpaní ovladačů grafických zařízení z uživatelského prostoru (Xka) do prostoru jaderného (DRM, DRI, …), ale dělá se to mimo jiné také právě kvůli takovým výmyslům jako je Wayland.

[trekker.dk]

dělá se to mimo jiné také právě kvůli takovým výmyslům jako je Wayland.

To je docela dost zkreslený pohled na věc. Dělá se to hlavně proto, že řešit přepínání režimů karty z uživatelského prostoru (tzn. aktuálně z X serveru) je prasárna; mimo jiné kvůli tomu X musí běžet pod rootem.

Wayland a další možnosti, které z toho plynou, jsou už jenom takový užitečný vedlejší efekt.

[Grunt]

Znáš Tai-chi? Mohl by si to zkusit praktikovat. Jinak se uklidni, udělej si čaj (nejlépe nějaký zelený pu-erh), zhluboka se nadechni,…

[mkoubik]

Pu-erh je zelenej?

[Grunt]

Yup. Než je z něj Pu-erh (bavíme-li se teda o klasickém černém), tak většinou je zelený a jinak existuje varianta zeleného pu-erhu (teda on je po vyluhování spíš žlutý, ale ty listy a ten matroš v gaiwanu je jasně zelený), kterou jsem omylem koupil.

[Jakub Lucký]

Mimochodem, shu (tmavý pu-erh) je výdobytek moderní doby a je to jen urychlení procesů v shengu (zeleném)... Za starých dobrých dob čínského císařství existoval jen sheng...

Kdybys uložil dobrý sheng na pár desítek let, tak se to začne tomu Shu blížit...

[Grunt]

shu/sheng

Ha, já si to myslel, ale nebyl jsem si jistý.

Kdybys uložil dobrý sheng na pár desítek let, tak…

…zplesniví, ztratí vůní a stane se z něj Létající špagetové monstrum. Ale jinak jsem už o tom dost vážně uvažoval.

[Jakub Lucký]

Ale prdlajs... Sheng Pu-erh když je uložený za adekvátních podmínek vydrží fakt dlouho... Tam je spíš problém v tom, že ho člověk vypije

Skladovací podmínky se asi dají najít buď na e-čajovna.net nebo se zeptat u Zdeňka Prachaře...

[Grunt]

za adekvátních podmínek

Mezi mrtvýma mnichama? Nemáš pár mrtvol na prodej?

Skladovací podmínky se asi dají najít buď na e-čajovna.net nebo se zeptat u Zdeňka Prachaře...

Dík. Zařazeno do fronty. Mrknu na to až pročistím frontu.

[Jakub Lucký]

No, obecně je to stálé prostředí, mírné proudění vzduchu a vlhkost okolo 60-70%

Mrtvoly neprodávám... A pu-erhy na zrání mám, ale nenechávám je cíleně zrát, protože prostě těch 10 let nevydržím

[Jakub Lucký]

No, číňani tak říkají sheng pu-erhu (anglicky raw, česky se mu fakt říká zelený)...

Ale s "klasickým" zeleným čajem se to neshoduje...

[trekker.dk]

díky kterému je každá chyba v grafice pro kernel smrtelná

Chyba v grafickém ovladači. A chyby se mají opravovat, ne tiše ignorovat.

[Semo]

chyby se mají opravovat, ne tiše ignorovat.

Podla tejto logiky by bolo spravne, aby jadro vzdy pri zdetekovanej chybe premazalo uzivatelovi disk. Tym by sa vyvinul spravny tlak na vyvojarov, aby opravovali chyby. Chyby sa maju opravovat!

Naopak, podla zdravej logiky by sa jadro malo zotavit z co najviac chyb samo, pretoze user ho nepouziva primarne preto aby na nom ladil chyby, ale aby spravil nejaku pracu.

[trekker.dk]

Máš zajímavé vyvozování...

A když jsme u toho... předchozí stav byl takový, že kvůli chybě grafiky se všechno seklo, nešlo se ani přepnout do konzole, takže i kdyby někdo chtěl ladit chyby, měl smůlu.

Teď aspoň funguje to přepínání a nějaké ladění je aspoň možné. To je podle mě krok kupředu.

[Semo]

Aspon 3/4 roka funugjem na KMS, mozno viac. Kuse sa to rovnako casto ako predtym bez KMS. Zakusy nie su rozchoditelne, vzdy to znamena reset. V 1/3 pripadov bud zo susedneho nb reboot cez ssh alebo aspon cez SysRq. Vo zvysku iba tlacitkom na bedni. Bez KMS sa to asi v 1/3 pripadov dalo opravit zostrelenim X serveru z nb a spustenim znova.

Jedine, co som vdaka KMS ziskal je rychle prepinanie medzi X servermi roznych uzivatelov, co ale pouzivam celkom casto.

[Grunt]

LOL, tady si někdo spletl výrazy uživatel a bůh.

Podla tejto logiky by bolo spravne, aby jadro vzdy pri zdetekovanej chybe premazalo uzivatelovi disk.

Návrh docela dobrý, asi se na něj mrknu až budu mít trochu víc času a pokusím se ho protlačit.

[Jardík]

Bez komentáře.

[imploder]

GDI běží pořád v režimu jádra, ne?

[Jardík]

ne.

[Martin]

Ja narazel napriklad na vykreslovani "okraju" nebo presun okna atd. Z clanku vypliva ze by se to presunulo do aplikace, coz je pristup windows. Tech podobnosti je vic. Netvrdim co je lepsi, pouze poukazuji na velkou podobnost tohoto reseni se stavajici implementaci ve windows

[Josef Kufner]

Ono pokud nacpe vše do knihoven a tedy do aplikací, tak bude zajímavé sledovat, co to bude dělat až taková aplikace přestane poslouchat. Teď stačí jen xserveru říct, ať zabije majitele toho okna nebo windowmanageru, aby okno odsunul někam stranou než aplikace zas poslouchat začne (třeba jen něco dělá a nepřekresluje okno).

Myslím, že X serveru se nepůjde zbavit. Alespoň ne úplně. Dobrou cestu však vidím ve ztenčení X serveru a jeho přeskakování při předávání dat, kdy X server bude jen správcem starajícím se o alokace oken a předávání základních událostí (zobrazení/skrytí okna, možná i stisky kláves a další vstupy), ale třeba kreslení na obrazovku už by nemuselo jít skrz něj.

Síťová transparence by se dala řešit na úrovni knihovny (xlib), kdy by se jen místo (kreslicích) funkcí volaly nějaké proxy funkce přeposílající volání na vzdálený X server, který by je pak prováděl (např. by ve stylu inetd spustil obslužného klienta, který by to pořešil). Lokálně by však tato proxy vrstva zcela odpadla a nepřidávala žádnou režii navíc (mohlo by to být řešeno někde na úrovni dynamického linkování (dlopen())).

Latence se sníží a koza zůstane celá.

[Petr]

Tak se pomalu rozloucim se skenovanim na vzdalenem pocitaci (ktery je pripojen ke scaneru), vypalovanim blue-ray na vzdalenem pocitaci (ktery tu blue-ray vypalovacku ma), ctenim diskety ze vzdaleneho pocitace (ktery ma jeste disketovou mechaniku).

Jeste si vzpominam, jak se ve skole v ucebne s Windows pocitacemi staly fronty na pocitac se skenerem/disketovkou/vypalovackou, kdezto v mistnostech s Linuxem nikde zadna fronta nebyla a vse odsypalo...

Ach jo, zamacknu slzu pri vzpomince na tyto casy. Premyslim, proc vlastne rovnou nenainstalovat Windows...

[miso]

LOL

[trekker.dk]

SANE má utilitu pro skenování z příkazové řádky. Vypalování pravděpodobně taky. Disketa - scp?

[Grunt]

Co když jsem lama a nebo nemám klávesnici (, ale třeba tablet což samozřejmě není jen hypotetická situace).

[Lord Vetinari]

pouzijes to co ostatny : NX

[msaft]

SANE je spatny priklad protoze vesele funguje po siti frontend/backend. Jinak sitova transparentnost je dost uzitecna vec a nekdy k nezaplaceni.

[Michal Kubeček]

Vypalování pravděpodobně taky.

Samozřejmě, konkrétně je to cdrecord resp. wodim. Ostatně mám temné podezření, že k3b a spol. jsou jen nadstavby nad ním.

[trekker.dk]

Samozřejmě, konkrétně je to cdrecord resp. wodim.

Což to jo, já jenom nevěděl, jestli to umí i Blu-Ray, tak jsem nekonkretizoval.

Ostatně mám temné podezření, že k3b a spol. jsou jen nadstavby nad ním.

Nevím proč temné, ale k3b je určitě nástavba nad tím - dokonce je při vypalování vidět příkazová řádka i výstup

[Michal Kubeček]

Ten výraz jsem použil proto, že mi pak připadá poněkud nepatřičné prohlašovat cdrecord/wodim za textovou náhradu grafických vypalovacích programů.

[trekker.dk]

Slovo "náhrada" jsem nepoužil, jenom jsem poukazoval na to, že vypalovat na vzdáleném stroji jde i bez grafického udělátoru.

[Michal Kubeček]

To bylo právě namířeno spíš na vašeho předřečníka (Petr), který trpěl představou, že když nebude moci vzdáleně spouštět grafické aplikace, musí se rozloučit s možností vypalovat na dálku. Vzhledem k tomu, že ty grafické nástroje jsou vesměs jen frontendy k příkazu, který se dá volat rovnou (a obvykle je to i rychlejší), je taková představa celkem úsměvná.

[Luboš Doležel (Doli)]

Jde to. A X teď používat nejde, že se musí nahradit?

[pán tě vidí]

X jsou pomalé. A proto je třeba je nahradit něčím mnohem svižnějším a méně náročným na zdroje, neboť X v mobilu stejně nemáš.

[pavlix]

neboť X v mobilu stejně nemáš.

Jsi si nějak jistý :D.

[Grunt]

Ono je zvláštní, že zrovna do toho mobilu chtěli za každou cenu ty Xka nacpat i když tam vůbec nebyly potřeba (nehledě na to, že si sebou táhne jako závislost síťoví stack). Teď se bohudík/bohužel přeorientovali ještě na žravější OpenGL v podobě GLESu. Jak říkám: Prostě všechno přesně naopak než jak by mělo být.

[trekker.dk]

Přesně. Mnohem lepší je spatlat si neportovatelné kraviny do jádra.

[Grunt]

Jasně, zato GLES to všechno zachrání. Jak se okna při odchodu nevlní, tak to není mobilní telefon (tohle skutečně u Androidu je). Dnes už to není tak markantní, protože prostředků je dost, ale dřív mobilní zařízení oplývali velmi malým množstvím paměti (ať už NAND nebo SRAM) a bylo to rádo, když to dovedlo provozovat alespoň to jádro (mnohdy ani to ne). Sdílení kódu s jádrem dovedlo nároky na paměť docela razantně snížit (nebylo potřeba znovu v uživatelském prostoru sdílet funkce, které už jádro mělo naimplementované i když asi mnohem nebezpečněji – stačil pak blbý initramfs a nějaký klibc jako binding na syscally a uživatelská aplikace…vše z initramfs), stejně jako to dovedlo vyřadit spousty nesmyslných závislostí a jednoznačně ušetřit procesorový čas (přechod z userspacu do kernelspacu rozhodně není jen jedna instrukce). A to není z mojí hlavy, ale tohle se fakt v minulosti používalo (i když asi na jiných systémech než zrovna GNU/Linux). ^{Celá reakce předpokládá, že reaguje na ironii.}

[trekker.dk]

Jasně, zato GLES to všechno zachrání. Jak se okna při odchodu nevlní, tak to není mobilní telefon

GLES se určitě nepoužívá kvůli tomu, aby se mohla vlnit okna, spíš to považuju za vedlejší efekt (eye-candy pomáhá prodávat, takže vcelku pochopitelný)

Dnes už to není tak markantní, protože prostředků je dost, ale dřív mobilní zařízení oplývali velmi malým množstvím paměti ... (nebylo potřeba znovu v uživatelském prostoru sdílet funkce, které už jádro mělo naimplementované i když asi mnohem nebezpečněji)

Když už je prostředků dost, tak nevidím nejmenší důvod udělat věci pořádně a oddělit jádro od userspace. Jednak to bude bezpečnější*, taky to umožní měnit jádro, když se k tomu výrobce rozhodne (aniž by hrozilo riziko, že kvůli tomu přestane fungovat nějaká aplikace, která používala sdílený kód)

A to ani nemluvě o tom, že jedna aplikace pak může s malými nebo žádnými úpravami snadno fungovat na víc telefonech (obecně mobilních zařízeních), což při používání kódu z jádra jen tak nepůjde (jiné zařízení - jiné jádro)

* je mi jasné, že bezpečnost aplikací na mobilních telefonech dneska (zatím) skoro nikdo neřeší. Sice tam bývá uloženo stejné množství citlivých dat, jako na normálním PC, ale hej, je to jenom mobil, ne?

[Grunt]

GLES se určitě nepoužívá kvůli tomu, aby se mohla vlnit okna, spíš to považuju za vedlejší efekt (eye-candy pomáhá prodávat, takže vcelku pochopitelný)

Používá se díky tomu, že většina platforem už má stejně většinou nějaký nepříliš výkonný čip v sobě od základu nacpaný a 2D operace by se na něj stejně už jen překládaly. Teda aspoň tolik můj odhad.

[trekker.dk]

Já myslel spíš něco jako že je to standardizované rozhraní, seženou se na to knihovny apod. Plus samozřejmě, že na zařízení je dostupný HW, který asistuje při vykreslování.

Tedy ne 2D grafika vs. 3D, ale spíš GLES vs. něco jiného, co by se o tu grafiku staralo.

[Grunt]

Já myslel spíš něco jako že je to standardizované rozhraní, seženou se na to knihovny apod.

A ty osattní jsou asi lečo, ne?

[trekker.dk]

Ještě jsem možná měl dodat "perspektivní"

A musíš uznat, že rozhraní "naflákám něco do jádra a udělám pro zařízení specifický způsob komunikace aplikací a vykreslování" není ani perspektivní, ani se nedá dobře udržovat a ani to není přenositelné.

[imploder]

Nebyly potřeba z tvojeho pohledu. Spoustě lidí by se možnost používání vzdálených aplikací z mobilu hodila.

[Grunt]

Nebyly potřeba z tvojeho pohledu.

Ne, spíš jde o to, že nebyly potřeba z toho důvodu, že např. platforma krom Xek na nic jiného nepotřebovala síťový stack a v pohodě se to dalo nahradit třeba nežravým DirectFB (a tak se to i dělalo). Dneska už je to s jinýma prostředkama o něčem jiném.

[trekker.dk]

Četl jste někdo vůbec ten článek, nebo jste všichni rovnou skočili do diskuze? Já že bych se na to příště rovnou vysral a zkrátil to na "flejmujeme o X", "flejmujeme o interaktivitě desktopu" apod.

[FlayerGun]

Ach - to by bylo krásné. Přesně jak článek píše - X11 jsou úplně zastaralé a "mimo". Bude to prima svět, kde bude všechno fungovat líp, přenositelně a plynule. I když kapku pochybuju o těch 3D frajeřinkách na nějakých mini-boocích nebo jak nazvat takové ty počítače - nepočítače, telefony apod. Zárověň bych ale nerad přišel o koncept window manažeru - to je věc, kterou na X-ech miluju od počátku (teda od počátku co jsem je začal používat - rok 1991). Neznám horší frustraci než když si člověk nemůže nastavit tlačítka na oknech, a předefinovat ovládání - to defaultní nikdy nevyhovuje. S úctou FG

[Petr Ježek]

Zdravý konzervativismus. Právě kouzla s WM a jejich kombinacemi s DM jsou cestou, jak poskytnout uživateli optimalizovatelné GUI a systému optimalizovatelného uživatele, který jej nebude zatěžovat pitomostmi, které zdržují a nic nepřinášejí. Pokud Xka zeštíhlí na schopnost spolupráce s WM, pak bych slzy neronil...

[xurfa]

Teda panove nevim, ale ja teda bez sitove transparence ani ranu. Wayland je strasna sracka...

[geebranz]

Consider possibilities

des moines seo company