Vlákno názorů k článku
Netbooky zrychlí nástup Linuxu od Kaacz - Ono je to mirne i dusledek politiky MS....

obávam sa, že poznám všetky "hacky" - od kompilácie freetype so zapnutými správnymi prepínačmi, cez ručnú editáciu konfigurákov až po inštaláciu Windows fontov. Pomáha to, ale vždy je to trochu horšie než Windows alebo Mac.

ja nehovorím len o tom linuxovom zvyku vyhladzovať ja malé fonty, čo Windows riešia inak. Hovorím aj o tých problémoch Linuxu udržať rozostupy a tvary písma pri silnejšom vyhladzovaní,neschopnosti Linuxu použiť rovnaký spôsob vyhladzovania na všetky aplikácie (OOo sa vždy správa po svojom a občas býva naozaj príšerný. Nedávno som skúsil nainštalovať na Vistu Wordnet (písaný v Tcl/Tka) a bol som v šoku, že aj ten môže vyzerať dobre. Pod Linuxom Tcl/Tk aplikácie slúžia len ako pripomínač zabudnutých počiatkov okenných aplikácií.

Ve Windows je možné při zobrazení textu říci, jaký antialiasing či subpixel rendering se má provádět. Pokud to aplikace explicitně neurčí, použije se nastavení systému. V Linuxu je bohužel okolo fontů trošku chaos - ostatně fonty nejsou jediným takovým případem.

V Linuxu si to také můžete nastavit.

Vy si vždycky zjistíte, že na Windows je něco nového, pěkného. To je fajn a pro čtenáře tady je to přínos o tom také vědět. Jenže pak, aniž si zjistíte podrobnosti, předpokládáte, že v Linuxu to není.

Z globálního pohledu je samozřejmě plus, že jednak chladíte přílišné nadšení nebo že upozorňujete na vývoj Windows, ale pokud si nezjistíte, jak je to v Linuxu, tak to mnoho čtenářů bere jako snahu o vyvolání flamewar. Někdy z toho mám taky takový pocit. :-)

Mohu rovnou uvést příklad. V některé ze zpráviček z posledního týdne tvrdíte, že Linux nemá floating point souřadnice. Někdo vás opraví, že má, pokud používáte Cairo (které, pokud netrváte na přístupu přímo přes xlib, ale používáte nějaký widget framework, dost možná používáte - aniž byste o tom věděl), tak floating-point souřadnice máte. Vy kontrujete, že ale Cairo stejně renderuje do X11, ale zase vás opravím, že ne nutně - že X11 je jen jeden z back-endů Caira, že většinou renderuje přes OpenGL, kde floating-point souřadnice jsou bez problémů. Teď se musím přiznat, že jsem si teď hned neověřoval, zda se opravdu floating-point souřadnice při OpenGL renderingu použijí nebo ne, ale předpokládám, že vy také ne, když jste ani nevěděl o OpenGL backendu, na který byl mimochodem kladen důraz a kvúli akcelerovanému renderingu primitiv a fontů bylo Cairo vůbec napsáno.

Opravdu je lepší být opatrnější, zvlášť když někoho kritizujete a nejdřív si ověrit fakta. A jestli nechcete nebo nemáte čas, tak můžete kritiku položit jako otázku ("jakou podporu má Linux ve floating-point souřadnicích"). Zní to lépe, neděláte ze sebe blbce a působí to mnohem konstruktivněji.
Navíc - pokud danou věc Linux podporovat nebude - jim to, linuxákům, stejně natřete. :-)

Když také opakovaně suverénně tvrdíte věci, které nejsou pravda - i když to není vědomá lež ale jen neznalost - tak vám lidi nebudou věřit.

Ono je to trochu jinak. Když se tu o něčem píše, mnohdy se mluví o řadě věcí, které již byly dávno uspokojivě (a často lépe) vyřešeny ve Windows. Pokud o takové věci vím, někdy to napíšu v diskuzi. Souhlas, že to někteří čtenáři omylem berou jako snahu o vyvolání flamewar. A také souhlas, že *zcela výjimečně* může jít i o lehkou provokaci - hoďte kamenem, kdo nikdy nic takového neudělal :). Na druhé straně si všimněte, že nikdy nespamuji diskuze blbostmi typu "X je shit, používejte Y", a typicky se neúčastním diskuzí, které mají flamewar vyvolávat (naposledy viz článek Přechod z OS Windows na Linux - diskuze asi bude kompletně flamewar, to rád vynechám).

Je faktem, že Linux neznám ani zdaleka tak dobře, jako Windows. Proto často nemůžu přímo srovnávat. Například o Cairo jsem slyšel naposledy v době, kdy bylo možné stáhnout zdroják nějaké alpha verze, a neexistovala ani dokumentace. Ale ke Cairo a OpenGL můžeme mluvit v příšlušné diskuzi.

V případě fontů (a grafiky obecně) mi situace na Linuxu přijde mimořádně nepřehledná. Původně X11 nepočítalo s vektorovými fonty, a rastrové fonty obstarával X11 server. Později přišly rastrové fonty, které se v principu řešily na X11 serveru (pomocí font serveru). Aby aplikace měla seznam fontů a jejich metriky, musel mít X11 klient tyto informace na lokálním disku, což dost narušilo oddělení klienta a serveru. Situace v oblasti metrik a hintingu byla už tehdy nepřehledná - hinting zapnutý či vypnutý, pro patentované technologie hintingu (tj ty použitelné) bylo nutné kompilovat ze zdrojáku (zřejmě nelegálně) atp. S forwardingem textur skrz X11 protokol (XRender) se fonty přesouvají na klientskou stranu, kde jsou zřejmě dodnes. Pak je tu ovšem DRI coby přístup ke grafickému HW paralelní k X11, Xgl pro forwarding textur pomocí X11, AIGLX pro totéž (viz GLX extension) atd. Samozřejmě jde o sadu extensions, které běhají každá s nějakými konkrétními drivery. A frameworky i aplikace jsou psané pro různá vývojová stádia grafiky na Linuxu (např různé extensions), a jestli například konkrétní aplikace použije antialiasing nebo subpixel rendering, to asi vyjma autorů kód ví jen ten, kdo to zkusí.

Předchozí odstavec je důvodem, proč situaci na Linuxu popisuji jako cahotickou, nepřehlednou. Takhle totiž nevypadá dobrý design. Podívejte se na GDI, WPF, nebo Apple Quartz. Oproti výše popsanému jde o nádherně čistý design, navržený s ohledem na budoucí potřeby.

Jak jsem psal výše, nemůžu mít vždy pravdu. I Lael je jen člověk. Nicméně si přesto myslím, že jsou moje příspěvky technicky korektní a věcně správné v daleko vyšší míře, než jaká je ve zdejších diskuzích zvykem (bez ohledu na to, jestli se pak shodneme na subjektivním hodnocení těch fakt). Pokud mi nesedí fakta, nebo jsou v té které věci mé závěry zjevně nesprávné, rád se to dozvím.

Stejně tak můžete říct, že původně Windows (např. verze 1.0) teké nepočítaly s vektorovými fonty

Ano, na rozdíl od centralizované filosofie Windows je v Linuxu opravdu několik konkurujících si řešení (AIGLX a XGL - co teprve až přijde EGL :-), což je sice variace XGL, ale zase to bude něco trochu jiného).
Ale je to prostě rozdíl ve filosofii. Protože se vývoj nedělá centralizovaně a s hodnocením variant budoucího vývoje, naráží se často na slepé větve. Proto je pozitivní, že existuje paralelně víc větví - z nich pak některá přežije. Věřím, že ve většině případů ta lepší, ale někdy ani nejde říct, která je lepší, např. vývoj HW může upřednostit technologie, které se předtím zdály horší - teď mluvím např. o tom, jak různými algoritmy a přístupy zamíchala třeba změna poměru rychlosti čtení z cache procesoru a z paměti nebo z paměti a z disku, nedej bože nově technologie jako nástup flash technologií v discích.

Proto "čístý design navržený na budoucí potřeby" je často jen sen, který v praxi nejde splnit.

A třeba v tom, že jednotlivé aplikace jsou psány pro různá rozšíření, se myslím mýlíte. Většina aplikací používá framework jako jsou Qt nebo Gtk nebo něco podobného. Pak je jim jedno, jestli to Qt vyrendruje přes Cairo, přes čísté X11 nebo přes cokoli jiného. Další věc, co budu asi těžko hledat, je aplikace závislá na tom, zda mám XGL nebo AIGLX. Aplikace jsou podle mě méně ohrožované tímto chaotickým vývojem, než si myslíte. Např. je dodnes možné spustit binárky pro původní Linux přes 15 let starý. Možná si myslíte, že je to nevýhoda, ale v mnoha oblastech se to cení. A ukazuje to, že ten původní návrh zas tak špatný nebyl.

Font server byla hrůza, to s vámi souhlasím. Ale vyřadit ho nebyl z pohledu aplikací prakticky žádný problém (opravte mě, pokud si to nemyslíte).

Jinak musím dodat, že když se čas od času na root podívám, tak si vaše příspěvky s chutí přečtu a obohatí mě - a to přesto, že jak v práci, tak při podnikání nebo soukromém používání "jedu" asi z 90% na Linuxu. A přesto, že se skoro vždy se dají shrnout do dvou kategorií: "nemáte pravdu, protože business to nechce" a potom "Windows jsou lepší a Linux zastaralý, protože...", s tím, že varianta č. 1 vychází z varianty č. 2, která je v příspěvku buď zmíněna přímo nebo implicitně.

V tom, že technicky jsou vaše příspěvky asi nadprůměrně korektní, s vámi možná i souhlasím. Ale vzhledem k vašim schopnostem byste jistě mohl mířit ještě výš. :-)

Samozřejmě další krok je 2D grafika ve float koordinátech, což mimo jiné umožňuje začínat rastrování glyphu na subpixelu (tedy třeba o třetinu pixelu doprava). To umí Vista a MacOS (u MacOS nevím, jestli umí float souřadnice).

k cemu mi jsou float souradnice, kdyz na otevreni jednoducheho okna cekam 5 sekund a chrci u toho HDD jak pominutej, protoze fragmentace pameti, protoze holt proste VMM ala MS atd.

to se muzete stavet 100x na hlavu, bit se do prsou a hlasit, jak to neni mozny, ze je chyba u mne a podobne nesmysly. stejne tu realitu nezmenite. leda byste pocitali s tvrzenim, ze 100x opakovana lez se stava skutecnosti, ale to byste jeste museli pridat.

Otázka je, čemu říkáte otevření jednoduchého okna. To vlastní otevření okna je velmi rychlé. Pokud "otevřením okna" rozumíte zavedení aplikace, tak asi víte, že tam je věc trochu náročnější. A jestli máte aplikaci zavedenou, tak zřejmě není ve fyzické RAM (kupte si více paměti, je dnes směšně levná), nebo ten kód za tím oknem provádí ještě řadu dalších věcí, které nevidíte - vizuální složitost okna nemá pochopitelně se složitostí toho kódu nic společného. VMM ala MS je proti VMM ala Linux velmi kvalitní - například nepotřebuje OOM Killer ;)

Zkusíte schválně popsat, jaké jednoduché okno to je, na jaké konfiguraci atd. - jinými slovy jak problém reprodukovat?

VMM ala MS je proti VMM ala Linux velmi kvalitní - například nepotřebuje OOM Killer

:=))))))))))))))))))))))) Hele, víš že v Thajsku už dealujou drogy vopice?

myslel jsem obnoveni z minimalizace. jo spravne - obnova okna z minimalizace. napr cmd, calculator, cygwin a dalsi. stava se to tak 5x za den.
vic RAM? windows hlasi, ze mam min. 40% RAM volne (ze 2GB). k cemu jeste vic? videl jsem to i na 4GB. vzdycky windows hlasil dost volnyho mista. do jakyho notebooku dam vic nez 4GB?

jasne, kdyz windows dam na kazdych 100MB aplikace 500MB RAM, tak fragmentaci minimalizuju. to ale moc aplikaci nepustim, protoze narazim na HW limity notebooku. a navic se stejne nezbavim toho debilniho algoritmu preventivniho swapovani.

neco podobneho (asi swap) se deje i se slozkama v menu jako je My Recent Documents, Control panel, My Computer atd. porad mi windows hlasi min. 40% RAM volno.

ze se to deje je jedna vec. druha je ta, ze neexistuje zadna komunita, zadna konference, kde by se uzivatel zeptal co s tim (a kde by mu pak poradili)

V tom případě zjevně nemáte aplikaci v RAM, a tahá se ze swapu. Důvodů může být spousta. Máte ale řadu možností, jak zjistit, co se děje. Například v Performance Monitoru sbírat data o vybraných procesech a celém stroji (%CPU, využití swapu, počet stránek natažených ze swapu nebo tamtéž zapsaných, a tisíce dalších counters), a později je rozebrat.

Samozřejmě pokud sám nemáte potřebné znalosti, lidí používajících Windows je po inetu veliká spousta, a mnoho jich zkusí poradit. Viz například www.expertsexchange.com, MS fóra (http://forums.microsoft.com, jsou tam i nějaká v češtině), a hromada dalších míst. Já mám znalosti, a tedy podobná místa typicky nenavštěvuji, takže vám více linků nedám.

Memory management ve Windows jiz vystizne jiz pred nekolika lety zhodnotil kolega. Rozebirat to dal naprosto nema smysl.

No s vámi to fakt smysl nemá.

To, že to někdo zhodnotil, neznamená, že měl pravdu. Navíc, pokud to bylo před několika lety, se mohl memory management ve Windows vylepšit. :-)

at uz je duvod jakykoli, ovlivnit to nejde.

zajimavy je, ze takova windows fora nenavstevujete, ale na rootu, ktery dle meho je tim typem serveru, jen zamerenym na linux, jste pomerne casto :-)

at uz je duvod jakykoli, ovlivnit to nejde.

at uz je duvod jakykoli, ovlivnit to nejde.

ovlivniv=eliminovat (ve win xp pro). a to jsem zadaval i jako trouble-ticket ve 2 pomerne velkych nadnarodnich spolecnostech se slusnym it zazemim.

Osobně nepamatuji, že by trvalo 5 sekund provést restore Notepadu nebo Calc.exe. Výjimkou může být, když došlo v mezičase došlo k zaplnění paměti (třeba resource leaks FireFoxu, nebo něčeho jiného), a tedy odložení dané aplikace do swapu. Jak ale říkám, je možný troubleshooting - tohle není magie, ale IT. Zkuste si sestavit postup k reprodukci problému, zjistit, jak funguje Performance Monitor, zjistit něco málo o tom, jak fungují Windows XP (předpokládám, že jde o stará XP), sesbírat relevantní data, a poté je analyzovat. Nebude vás to nejspíš stát více než nějaké procento úsilí, které jste dosud strávil učením se editoru vi ;)

V XP MM je problém v tom, že byly stavěné na stroje s 300MHz CPU a 64MB RAM. Na takovém stroji je velmi důležité efektivně spravovat to málo paměti, které má, zvláště pokud člověk nechce o dostupné paměti lhát, a potom nazdařbůh odstřelovat procesy (viz Linux, overcommit a OOM Killer). Proto XP udržují nízký počet dirty pages, což systému dává možnost rychle alokovat velká množství paměti (zahodí se clean pages, a přidělí se někomu jinému). To také znamená rychlejší spouštění aplikací. Bohužel pokud máte spoustu paměti (třeba z tehdejšího pohledu "celých 512MB", nebo dokonce více), systém zbytečně brzo swapuje. Vista je naopak lépe stavěná na paměť v řádu GB.

V XP MM je problém v tom, že byly stavěné na stroje s 300MHz CPU a 64MB RAM.

:=))))))))) Nechcete se zivit jako televizni bavic? :P

A nechcete přestat blbě kecat?

http://en.wikipedia.org/wiki/Windows_XP#System_requirements
Minimum: Processor 233 MHz, Memory 64 MB RAM. Recommended: Processor 300 MHz or higher, Memory 128 MB RAM or higher.

Minimální požadavky nepředstavují cílovou konfiguraci, pro kterou je systém určen, nýbrž konfiguraci, na které ještě jakž takž za skřípění zubů poběží.

Windows XP s 64 MB RAM jsou opravdu jen pro silné povahy. Abychom byli upřímní, tak KDE nebo Gnome úplně stejně.

Minimální požadavky jsou dolním omezením cílových konfigurací.

Windows XP na 64MB RAM déle bootují, odezva interface je pomalejší, a nejsou vhodné pro paměťově náročné aplikace či běh velkého množství aplikací najednou. Jinak v principu nejde o problém. Faktem je, že na silnějším HW má interface rychlejší odezvu, a lidé na takovou odezvu zvyklí potom na slabší konfiguraci trpí, protože jsou netrpěliví.

Windows XP na 64MB RAM déle bootují, odezva interface je pomalejší, a nejsou vhodné pro paměťově náročné aplikace či běh velkého množství aplikací najednou. Jinak v principu nejde o problém.

Ty demagogickej magore, Windows XP na 64MB RAM jsou naprosto nepouzitelne, protoze ten system celou dobu jenom swapuje. Kazdy se o tom sam muze presvedcit a trhat si vlasy sam. Ani samotny OS se do te pameti nevejde. Nekdo v MS by si mel vyndat mozek z prdele pred napsanim "minimalnich" specifikaci HW, na kterem to pobezi. WinXP nejsou navrzeny pro 64MB RAM, tecka.

Ad MM: tak ukazte zdrojaky, podle tech se to pozna nejlip.

> Samozřejmě další krok je 2D grafika ve float koordinátech,

A v Linuxu tohle ma Cairo API. Ackoliv osobne si myslim, ze to je nesmysl, protoze kdyz jsou pixely velke, tak je treba renderovat s ohledem na pixelovou mrizku, aby veci nevypadaly odporne rozplizle, a kdyz jsou pixely male, tak je to jedno a klidne se muze renderovat s pixelovou presnosti.

Já v mezičase zjistil, že Cocoa má také float koordináty.

Cairo je pokrok. Problém je v tom, že má úzký záběr, a tedy nenabízí ucelené řešení problému. Nabízí high level API, jenže na konci nekreslí do driverů zařízení, ale do X11, PDF, GDI apod, což jsou pro daný účel nesmyslně high level interfaces. Jde potom spíše o wrapper, než subsystém. Bez širšího záběru a lepšího přístupu k HW se těžko realizuje funkční color management (Cairo nakonec žádný nemá), podpora HDR, a využití GPU je spíše okrajové (těžko budete krmit Glitz float souřadnicemi, aby provedl HW akcelerovaný rendering začínající na subpixelu - musíte mu to SW vyrendrovat v Cairu, usazené na celý pixel). Ale jak říkám, proti "čistému" X11 je to pokrok.

Trošku ale překvapí, že Cairo je psané v C. Vždyť v C se relativně špatně píše, špatně ladí, špatně udržuje kód, a výsledek se špatně používá. Problém je zřejmě v tom, že C se považuje na unixech za nejmenší společný násobek, podobně jako C++ (a nyní nově se C#) na Windows.

Pokud máte velké LCD pixely, je naopak dobré použít subpixely. Konkrétně u textu je problémem změna šíře písma při změně rozlišení (zaokrouhlování, zachování symetrie), stejně jako pravidelnost písmen. Obojí se zlepší, když jste schopen používat subpixely, a začínat rendrování písmena na subpixelu.

jenže na konci nekreslí do driverů zařízení, ale do X11, PDF, GDI apod, což jsou pro daný účel nesmyslně high level interfaces.

OMG... ROFL... :=))))))

LOL ! Evidentně netušíš o čem mluvíš.

> Vždyť v C se relativně špatně píše, špatně ladí, špatně udržuje kód, a výsledek se špatně používá.

Myslim, ze ve srovnani s ostatnimi low-level jazyky ze stejne kategorie (treba C++) se v techto parametrech nijak vyrazne nelisi.

> Obojí se zlepší, když jste schopen používat subpixely, a začínat rendrování písmena na subpixelu.

To je sice pravda, ale pismo pak zacne mit barevny nadech, coz dost lidem vadi.

C++ mi přijde lepší. A samozřejmě je tu možnost použít C++/CLI (aka ECMA-372), případně C#.

Subpixel rendering by neměl vést ke znatelnému barevnému posuvu. Pokud k němu vede, může to být nesprávnou gamma korekcí. Navíc subpixel rendering (ve WPF realizovaný pomocí GPU grafické karty) lze triviálně vypnout; ovšem použít ho pokud není implementovaný, to jde velmi špatně.

Subpixel rendering vede k barevnému posunu na hranách, který je tím viditelnější, čím větší jsou pixely nebo čím z menší dálky se na displej díváme. Tuším, že celkově by barvy měly zůstat stejné, protože barevné posuny na hranách se kompenzují v okolních pixelech, kde nejsou ostré hrany - ale to spíš tipuji než že bych se v tom nějak extra vyznal.

Ano, subpixel rendering vede k barevnému posuvu na hranách. Nicméně má být implementovaný tak, aby posuv nebyl příliš velký, a ty barevné hrany tedy nebyly znatelné. Obdobně třeba MP3 vede ke ztrátě řady detailů komprimovaného zvuku, ale implementace je taková, že to nemá být slyšet. No a jak jsem doufám už psal, ty barevné okraje může zvýraznit třeba špatně korigovaná gamma zobrazovače.

No vtip je právě v tom, že Cairo nemusí vykreslovat jen do X11, ale i do OpenGL a tam může floating-point souřadnice bez problému využít.

Takže jsme vlastně tam, kde jsme v případě WPF - v rámci okna se o renderování stará Cairo, o kompozitní vykreslování oken zase Compiz (nebo KWin nebo něco jiného), jenom to má navíc podporu dalších výstupů (X11, Quartz, GDI, PNG, PDF, PostScript, SVG a další).

Co vy na to? :-)