Hlavní navigace

Názor ke zprávičce Hlasování k OOXML v ČR od LO - GCC rozšíření: http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html Tak nečtěte diskuze s Linusem, a...

  • Aktualita je stará, nové názory již nelze přidávat.
  • 6. 9. 2007 20:28

    LO (neregistrovaný)
    GCC rozšíření: http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html

    Tak nečtěte diskuze s Linusem, a přečtěte si, co mikrokernel je, a jaké výhody přináší. Například modularitu, oddělení funkčních celků, používání výhradě dokumentovaných interfaců mezi moduly. Mimo jiné proto je možné nahradit ve Windows HAL (koncept, který Linux také nemá) za jiný, který implementuje hard real time extensions. Ale s Linusem souhlasím, že provést design up-to-date operačního systému a jeho implementaci je dalek náročnější, než splácat opis 40 let starého konceptu, a to ještě mizerně. Viz Linux a threading (LinuxThreads byla katastrofa), Linux a memory management atd.

    Pokud vím, tak CONFIG_NLS_UTF8 pouze natahuje převodní tabulku. Tedy pokud budete mít systém v 8859-2, můžete přimontovat disk s UTF-8 názvy, a tyto se budou překládat. Což je hezké, ale problém, kdy Qt aplikace zapíše název v UTF-8 to neřeší (naopak ho to ještě zhorší). Linuxové aplikace se samozřejmě nemohou držet locale, které neznají. Ale vy samozřejmě můžete používat pouze aplikace, které byly napsány pro Linux, a ještě pro správnou verzi kernelu, a ještě zabaleny pro vaše distro. Cokoliv jiného je velký problém. Ještě k podpoře Unicode: kdysi pánové zjistili, že by museli systém pro plnou podporu Unicode v podstatě komplet přepsat (podobně jako Windows NT). V duchu nejlepších unixových tradic pouze rozšířili stávající koncept (viz terminály a příšernost zvaná sekvence, též tabulky sekvencí), a akrz API používající CHAR cpali UTF-8. Bohužel na straně kernelu nikdo neví, jestli je string v UTF-8, 8859-2, nebo čemkoliv jiném, a ani ho to nezajímá (jedinou výjikou je práve ta poměrně nová konverze code page při přístupu na FS). Pokud máte aplikaci A, která píše názvy souborů v 8859-2, a aplikaci B, která je píše v UTF-8, budete mít na disku guláš, včetně invalidních UTF-8 sekvencí. Když si nastavíte konverzi code page při montování FS, bude to ještě horší. Například nastavíte 8852-2 pro systém, UTF-8 pro FS (parametr mountu). Názvy z aplikace píšící v 8859-2 skončí na disku jako UTF-8, a názvy z aplikace píšící v UTF-8 (Qt aplikace) skončí tak, že pro každý byte názvu se provede převod z 8859-2 do UTF-8 (tedy naprostý nesmysl). A víte také, že funkce (g)libc nepodporují Unicode? Když totiž vyhledáváte znak ve stringu (memchr), ten znak posíláte jako unsigned char. Bohužel písmeno v azbuce je má v UTF-8 dva chary. Jako další lahůdku uvedu, že Qt používá 16-bit reprezentaci Unicode, glibc 32-reprezentaci Unicode pro malý subset funkcí, a 8-bit UTF-8 pro ostatní funkce (kde ovšem převádí na 32-bit reprezentaci, kde je třeba); GTK používá 32-bit reprezentaci Unicode. Když Qt aplikace volá cokoliv, co propadne na glibc, tak volá Qt se stringem v UCS-2; Qt ho převede na UTF-8, předá glibc. Glibc možná provede převod na 32-reprezentaci, provede operaci smžným převodem výsledku na UTF-8, vrátí výsledek Qt, to převede string na 16-reprezentaci Unicide, a vrátí aplikaci. Jestli vám tohle přijde jako dobrý design, tak jste asi sám. Ano, na začátku to bylo málo práce (jako s terminály), na konci je z toho zprasek (jako u terminálů).

    Windows 9x a řady NT zapisují názvy v Unicode. Zkuste si na klíčenku uložit ěščřžýáí.txt, a podívejte se na directory entries v disk editoru.

    Ano, lze použít Qt a GTK. Ty ovšem pouze obalují X11 a CUPS, které, jak správně píšete, nikdy nebyly pro desktop určené. Samozřejmě X11 je nevhodné na cokoliv. Od session se nelze odpojit a pak se připojit, a je pomalé. Navíc si zkuste otevřít X11 session přes dial-up modem. Po půl minutě máte login screen, poté odezvu na klávesy cca 2 sekundy. Před RDP (Remote Desktop/Terminal Services) lze přes dial-up (i GPRS/EDGE) v pohodě pracovat.

    Úžasný vynález s paletami jste asi nepochopil. tagLOGPALETTE obsahuje pointer na pole struktur PALETTEENTRY. Struktura PALETTEENTRY má 4 byte, z toho první tři jsou RGB, poslední flagy. Náhradu fopen, která je bezpečnejší (například kontroluje, zda jsou striny null terminated, zda pointry nejsou null, atd), vás nikdo používat nenutí. Ale jestli nechápete, proč je strlwr_sbezpečnější než strlwr, tak je to těžké. Každopádně dnes je C pasé, a SW se píše v .NETu.

    Kvalita kódu samozřejmě velmi závisí na jazyku. Programátoři dělají chyby, a nedá se s tím nic dělat. Buffer overflow v Javě ale prostě neuděláte. Ale klidně tvrďte, že pro mizerně dokumentovaný Linux se píše skvěle. Jenom vaše tvrzení nebudou odpovídat realitě.

    Skripty není problém lokalizovat. Problém je, když vám utilita vypíše (lokalizovaně) 1 234,56 místo 1,234.56, protože výsledek parsujete jako text. Stejně tak když čekáte na "found", nějaké "nalezeno" vám moc nepomůže. Pochopitelně pokud utilita vrátí pole objektů, kde vyberete property LastWriteTime, tak vás problém "Jan 26" vs "1/26/2007" vs "1 led" fakt nebere. Nehledě na to, že se vyhnete věčnému volání utilit (vytvořit proces, parsovat vstup, provést akci, vypsat jako text, parsovat text ve skriptu), což je zabiják výkonu. PERL je sice roztomilý jazyk (vykazuje jisté podobnosti s PowerShellem), ale přehledný není ani náhodou. Vůbec ty staré jazyky, psané stylem "á, tady jsem našel na klávesnici ještě jeden symbol, copak asi bude dělat?", jsou poněkud out.

    Pochopitelně proces validace musí být bezvadný. Ovšem validátor lze validovat. Garbage collector je samozřejmě výzva. Nicméně je to cesta vpřed. Linux technologicky do budoucna nic nenabízí.

    S posledním odstavcem nelze souhlasit.