Vlákno názorů ke zprávičce Hlasování k OOXML v ČR

Ve Svedsku to probehlo zajimave. Odbornici dokument posoudili a predbezne se shodli na "ne, s pripominkami". V den hlasovani se z niceho nic pridalo 20 novych firem, ktere hlasovaly pro prijeti. Vysledek: 25 ano, 6 ne, 3 zastupci se zdrzeli hlasovani.

Vetsina z tech novych firem jsou partneri Microsoftu. Panuje podezreni, ze Microsoft si jejich hlasy koupil.

Takový Sun na to šel jinak. Nejprve nechával standardizovat formát OpenOffice, poté ho přejmenoval na OpenDocument, a když nikdo neprotestoval (ať si stnadardizují), tak teď křičí "standard můžeme mít jen my". Komedia je to kvalitní, nebýt toho, že ODF specifikace ODF je zcela nedostatečná.

Formát OpenOffice? LOL

Tady si někdo musí doplnit znalosti. Říká vám něco OASIS Open Office
XML Format Technical Committee? Od začátku bylo účelem standardizovat formát OpenOffice.org, později se vše přejmenovalo na OpenDocument. Viz mail archive OASIS, nejstarší kousky: http://www.oasis-open.org/archives/office/

Zvláštní, podle té "zcela nedostatečné" specifikace už je implementovaná podpora ODF do docela velkého počtu programů. http://en.wikipedia.org/wiki/OpenDocument_software

Zato podle dokonalé specifikace OOXML ještě nebyl napsán ani jeden jediný, dokonce ani MS Office 2007 tu specifikaci přesně neimplementuje, ale dělá si spoustu věcí po svém.

Všude se vytrubují chyby v OOXML, ale i ODF specifikace má slušné mezery - např. prý v implementaci tabulek (matematika, au!). Ale aspoň je nezávislejší.

Asi je velký rozdíl mezi mezerami (nedostatečné funkce) a chybami. A vzhledem k tomu "např. prý" o tom až tolik nevíte. Pravděpodobně jako těch dvacet nových členů ve Švédsku.

Ano, ODF formát není dokonalý, chystá se už druhá opravná specifikace, která má problémy odstranit. Ale aspoň narozdíl od OOXML se ODF nesnaží udělat z bugů jednoho konkrétního kancelářského balíku mezinárodní standard.

Příklad:
Sekce 3.17.41, SpreadsheetML Reference Material:
For legacy reasons, an implementation using the 1900 date base system shall treat 1900 as though it was a leap year. [Note: That is, serial value 59 corresponds to February 28, and serial value 61 corresponds to March 1, the next day, allowing the (nonexistent) date February 29 to have the serial value 60. end note] A consequence of this is that for dates between January 1 and February 28, WEEKDAY shall return a value for the day immediately prior to the correct day, so that the (nonexistent) date February 29 has a day-of-the-week that immediately follows that of February 28, and immediately precedes that of March 1.

Česky:
Z důvodu zpětné kompatibility bude implementace používající jako základ data rok 1900 považovat rok 1900 za přestupný. [Poznámka: Tedy sériové číslo 59 odpovídá 28. únoru a sériové číslo 61 odpovídá 1. březnu, následujícímu dni, čímž se umožní (neexistujícímu) datu 29. února přiřadit sériové číslo 60. konec poznámky] Důsledkem je, že pro data mezi 1. lednem a 28. únorem bude funkce WEEKDAY vracet hodnotu pro den předcházející zadanému datu tak, aby (neexistujícímu) datu 29. února byl přiřazen den v týdnu následující po 28. únoru a předcházející 1. březnu.

Co takhle kdyby Microsoft tenhle odstavec specifikace smazal, nafackoval tomu programátorovi co tenhle paskvil vymyslel a nechal ho to opravit v Office balíku?

To je pěkná ukázka neznalosti problematiky. MS těžko může nafackovat programátorovi Lotus 1-2-3, který tuhle blbost provedl kdysi před uvedním první verze L123 (1983). Opravit to v Office balíku nelze, protože tabulkové kalkulátory ukládají data jako čísla. K 1.5.2003 0:00 přičtete 7.5, a máte 8.5.2003 12:00. Datum vyšší než 36526 je po roce 2000. Když v tomto systému změníte systém počítání dat, může dlouhá řada sheetů přestat správně fungovat. Vy navíc nebudete mít ani možnost chyby nějak detekovat.

Stačí to pro ilsutraci toho, že svět není tak jednoduchý, jak se vám zdá?

Je škoda, že se to nevyřešilo tenkrát a rozšířilo z Lotusu do MS Office. Ale byla by větší škoda, když se to mělo nyní z MS Office rozšířit i do všech dalších kancelářských balíků.

Kontext, pointa?

Od vás je to zase ukázka neznalosti softwarové analytiky. Taková věc nemá v datovém formátu co dělat, to si má interně vyřešit program, který daný formát ukládá nebo načítá.

Ostatně ta detekce je velice jednoduchá: Načítám BIFF (původní binární formát Office) => je to špatně a musí se to opravit, pokud jsou v souboru použité formule s chybnými funkcemi, upozorním uživatele, aby si to zkontroloval. Načítám OOXML => je to dobře a není třeba nic opravovat. Ukládám BIFF => musím to uložit s chybou. Ukládám OOXML => ukládám to správně.

No to je skvělá myšlenka. Takže když vezmete vzorec =16738+12345, a výsledek naformátujete jako datum, jak podle formátu souboru, ve kterém zrovna ukládáte, dostanete buď 1.1.2007, nebo 31.12.2007. Když si pak vezmete soubor v OOXML, a dáte Save as XLS, tak se všechny datumy o den změní (protože není možné rozeznat,co je datu, a co je číslo). To jste vymyslel moc pěkně.

Tak se podíváme co nám udělá OpenOffice Calc 2.2 s datem. Do prázdné tabulky jsem do buňky A1 napsal "=59" a nechal to naformátovat jako datum. Výsledek v XML:

<table:table-cell table:formula="oooc:=59" office:value-type="date" office:date-value="1900-02-27">
<text:p>27.2.1900</text:p>
</table:table-cell>

Překvapivě tedy JE možné zjistit, že se číslo používá jako datum (office:value-type="date") a podle toho se dál chovat. Stejně tak to musí jít zjistit v BIFF souborech, jinak by se vám po otevření uloženého souboru s datem místo onoho data objevilo číslo.

Dokonce je i zajímavým způsobem vyřešená kompatibilita s MS Office:
59 ~ 27.2.1900
60 ~ 28.2.1900
61 ~ 1.3.1900
Tedy data po 1.3.1900 jsou číslována shodně jako v MS Office i bez toho, aby formát potřeboval nějaké neexistující datum 29.2.1900.

Na prvním místě je třeba říci, že hovoříme o OOo, nikoliv ODF. Všimněte si, že ODF vůbec neříká, co znamená jakési "oooc:=59".

Buňka obsahuje primárně vzorec, kterým je zde číslo 59. Nastavený formát zobrazení (value-type) můžete změnit. Jestli chcete vidět, jak se chování oproti Excelu liší, tak si do buňky A1 dejte datum 1.1.2007, A2 15.2.2007, C1 =A2-A1, formátované jako číslo, D1 =C1, formátované jako datum. V poli D1 vrátí MS Excel 14.1.1900, kdežto OOo Calc 13.1.1900. Jak tohle budete řešit v importních/exportních filtrech? Asi řeknete "neřešíme to, a spoléháme na to, že se odlišnost neprojeví". jinými slovy: staré dokumenty by byly převedeny se ztrátou.

Ano, specifikace ODF 1.0 ani 1.1 neříká, co "oooc:=59" znamená, ale specifikace 1.2 to už říkat bude, nebo aspoň bude říkat, co znamená nějaký ekvivalentní výraz.

Snad nemusím zdůrazňovat, že ten výsledek je chybný (jak v Excelu, tak oba výsledky ve vašem příspěvku).

Jak to budu řešit? Buňka je formátovaná jako datum, výsledek zadané formule je v rozsahu chybných dat => zařvi na uživatele, ať to zkontroluje a případně opraví.

Jasne, kdyz od sebe odectu dva datumy dostanu cislo, pocet dni, ktere od sebe uvedene datumy deli. Formatovat cislo jako datum je nesmysl => bunka zobrazi ERROR.
Navic pokud do bunky priradim hodnotu z jine bunky vzorcem, pak cilova bunka mela dedit i typ zdrojove bunky a jeji formatovani pro zobrazeni by melo podlehat stejne restrikci, jako zdrojova bunka. To znamena, ze ani Int ani Float nejde zobrazit, jako datum.
Nicmene, stale muzu jak Int tak Float pricist k nejakemu datumu a dostat opet typ datum. Jak proste.
Bohuzel ani OOo to nedela, coz je skoda.

Bohužel skoro všechny tabulkové kalkulátory umožňují formátovat číslo jako datum. Co s tím uděláte? Řeknete lidem, že je to špatně, a ať je přepíší? Uvědomujete si vůbec, o jakých nákladech se bavíme? Bylo by to tak asi v řádu Y2K bug ;)

Pochopitelně systémové řešení je mít u dat vždy uveden jejich typ (a formát). Data typu "datum" pak nelze sčítat s čísly, používají se na to výhradně funkce typu dateadd(interval, number, date), datediff(interval, date1, date2) apod. Excel tyhle funkce má ve VBA, i ve vzorcích. Bohužel nelze provést svévolnou destrukci dat uživatelů ve jménu "vyššího dobra".

Pro ODF 1.2 nebude problém napsat validátor, kterému předhodíte své dokumenty, a on vám řekne, které vlastnosti svého kancelářského balíku nedefinované ve standardu ODF v nich zneužíváte.

Jinými slovy sedozvíte, že váš dokument bude převeden se ztrátou. To ovšem problém v principu neřeší, že?

Zřejmě nechápete, co validátor ODF má vlastně dělat. Validátor ODF načte dokument ve formátu ODF, náhodně změní všechny parametry nespecifikované podle standardu, porovná výsledek s výsledkem při běžně používaných parametrech a zobrazí o tom zprávu. Tady nejde o žádné převádění starých dokumentů, ale o kontrolu, zda je možné daný dokument jednoduše přenášet mezi různými implementacemi ODF bez ohledu na změny parametrů, nebo jestli je výsledek výrazů závislý na postavení Slunce, Měsíce, Jupitera nebo na tom, jakou nohou jste ráno vstal z postele, protože ten dokument napsalo čuně.

Pokud tomu rozumím, tak to zdaleka nezaručuje interoperabilitu. V případě ODF 1.0 je fajn, že druhá strana dokument načte, ale je poněkud nepraktické, že bude dokument obsahovat i řadu věcí, které v ODF nejsou popsány, a které tedy nemůže interpretovat. Například ony vzorce.

Když jsme u toho postavení Slunce a Měsíce, popisuje ODF hebrejský lunární kalendář? Arabský kalendář s místními korekcemi? Japonský kalendář? Protože jestli ne, tak to pár stovek milionů lidí zamrzí.

A ještě jsem zapomněl dodat, že každý, kdo zadává konstantní datum pomocí pořadového čísla dne místo pomocí den/měsíc/rok podle národních zvyklostí, je prase, které si zaslouží, aby mu vzorce v tom dokumentu při dalším otevření vysypaly nesmysly.

Dosud se mu nesypou. Jestli je začne sypat u ODF SW, tak se začne sypat kamení na hlavu autorů ODF. Zatím je ovšem uživatelů ODF tak málo, že nestojí za řeč.

Ještě vysvětlení na stránkách MS: http://support.microsoft.com/kb/214326/en-us

Doplnění: jde o sekci 3.17.4.1. Mimo jiné se tam zmiňuje druhý systém s base date 1.1.1904, který problém s přestupným rokem 1900 nemá.

Ano, ale má jiný problém - roky 1900-1903 v něm raději nejsou definovány vůbec. Mimochodem, ODF 1.0 nespecifikuje žádné pevné základní datum, ale umožňuje v dokumentu vybrat libovolné datum, které bude odpovídat číslu 0 a rozsah možných dat není nijak omezen, ani shora, ani zdola. V tom je technicky jednoznačně lepší než OOXML.

systím začínajiící k 1.1.1900 zase nemá definovány hodnoty pro léta 1492-1494. Unixová dta nemají hodnoty pro léta1900-1904. Tak už to holt bývá. Otázkou je, proč by to mělo být špatně.

Nespecifikovat pevné základní datum je zbytečné. Dnes všechny aplikace používají 1.1.1900, nebo 1.1.1904; nač to měnit, když to funguje? Nebo by byl skvělý nápad dnes přijmout řekněme novou revizi POSIXu, kde by bylo možné nastavit vztažné datum libovolně?

Pro UNIX má datum 1.1.1970 jasně definovaný význam. První implementace časových funkcí vznikla až po něm, a tedy například není možné, aby před tímto datem byl na disk uložen soubor s časovými údaji. UNIXové programy samozřejmě mají k dispozici i jiné způsoby uložení data a času než obyčejný timestamp, které opět nejsou nijak omezené. Kancelářské balíky takto omezit nemůžete, protože tím například zbytečně ztížíte uložení statistik z 19. století, které určitě existovat mohou.

Před datem 1.1.1970 se soubory nevytvářely a nemodifikovaly? Samozřejmě je lze přsunout na unixový stroj, jenom o ten time stamp člověk přijde. A když tvrdíte, že formát data a času na unixu není omezený, tak si jistě uvědomujete, že to není pravda.

Pochopitelně Windows také používají jinou interpretaci data, než MS Excel.

Co statistiky z 19. století. Já si chci vytvořit telefonní seznam s datem narození a úmrtí klasiků, a počítat, kolik týdnů od té doby uplynulo. Když se dostaneme do starověku, začne to být velmi zajímavé. Ale roku na srdce - koho to zajímá. V nejhorším se místo standardních funkcí Excelu použije pár custom funkcí, nebo se celá věc nacpe do DB. Jinými slovy: popsaný problém není důležitý. Zato jeho vámi navrhované řešení může přinést praktické problémy.

Takový seznam narození a úmrtí klasiků je přece jen z hlediska účelu kancelářských datových fomátů mnohem zajímavější problém než bezztrátové převádění dokumentů ze zastaralých binárních formátů. Jistě, ruční opravování chyb převodu dočasně znamená zbytečnou práci navíc, ale na druhou stranu to ušetří daleko víc zbytečné práce v budoucnu zaviněné imitováním chyb starých programů.

Ano, je to jedno, protože se vám rozsype pouze jednou. Možná bude pár hodin trvat uvedení dokumentu do původního stavu, ale po jeho uložení v novém formátu už v něm budete moct dělat libovolné úpravy jako předtím. Na druhou stranu, kdyby Microsoft přestal vyvíjet Office, dřív nebo později byste stejně musel přejít na jiný kancelářský balík a o dokumenty byste pravděpodobně přišel úplně (pokud ne o všechny, tak alespoň o jejich velkou část), což je mnohem horší.

Aha, takže to má být jedno. Vy hovoříte o 200 mln dokumentech, ve skutečnosti jich bude daleko více. Pokud by úprava každého z nich trvala "pár hodin", tak zákazníci měli takové náklady, že by to bylo zcela nepřijatelné. Konverze do nových formátů musí být automatická a bezeztrátová. Na rozdíl od ODF tohle OOXML může zaručit. Volba je tedy jednoznačná. To by ovšem Sun a spol nesměli bránit standardizaci OOXML.

Mimochodem pokud pár hodin na "bezeztrátové otevření" staršího dokumentu považujete za přijatelné úsilí, tak jste opravdu poněkud deranged. Jako další problém bych zmínil to, že dokument těžko uvedete do původního stavu, když nevíte, jak původně vypadal (a ODF SW vám to jaksi neukáže).

Každého z nich určitě ne, skutečné problémy se týkají jen velmi malého zlomku procenta dokumentů, všechny ostatní je možné pevést beze ztrát.

Myslíte si, že hned po nainstalování nového kancelářského balíku administrátor smaže ten starý? Žádná firma nebude tak hloupá, aby po určitou dobu neměla na počítačích oba balíky zároveň právě kvůli převodu starých dokumentů do nového formátu.

A jen pro zajímavost, kolik si tak představujete, že za týden průměrný úředník nebo jiná "kancelářská krysa" otvírá starých unikátních dokumentů?

Ve firmě bývá zpravidla každý dokument unikátní. Jenom přechod z Office X na Office X+1 znamená aktualizaci hromady templatů, zkoušení vazeb na různé systémy apod. Náklady na přechod na ODF-office (říkejme mu třeba OpenOffice, protože nikdo jiný zřejmě ODF neimplementuje v použitelném produktu) by byly pro firmy velmi vysoké. Následné náklady na převod dokumentů by byly prohibitivní.

Nakonec se zkuste podívat do historie, jak dlouho MS převáděl trh na tak dobrý produkt, jakým je MS Office. Va vašich představách zřejmě firmy začnou zítra vše převádět všedo ODF, a stráví nad tím tisíce člověko-dnů. Kdybyste někdy zkusil větší projekt tohoto stylu, věděl byste, že do toho nepůjdou, a znal byste důvody.

Ano, po instalaci nového kancelářského balíku se starý odstraňuje. Uživatel pracuje s jedním produktem. Nebo chcete znásobit náklady na licence, školení helpdesk a podporu? Navíc by produkty musely být paralelně nainstalované trvale. Nechtěl byste snad zastavit na rok práci a ručně převádět všechny staré dokumenty?

Dívejte se na to realisticky. Jakýkoliv bude nový formát dokumentů, převod do něj musí být automatický a bezeztrátový. Už jen ztráta maker a šablon je veliký problém, ruční převod dokumentů je z říše sci-fi.

Unikátností jsem myslel to, že když za den 10x otevřete stejný dokument, bude se to počítat pouze jednou a ne 10x. S ODF aktualizace templatů a zkoušení vazeb díky ISO standardizaci odpadne úplně, nebo se aspoň sníží na zanedbatelnou míru (pokud těmi vazbami nemyslíte nějaké proprietární pluginy přímo do kancelářského balíku). ODF už je implementováno v tuctu různých balíků, navíc kancelářské balíky nejsou zdaleka jediný software, který kancelářské formáty implementuje.

Náklady na přechod na jakýkoliv jiný kancelářský balík než MS Office jsou prohibitivní, a to je jediná věc, která Microsoftu zajišťuje jeho aktuální postavení. Nevím jak pro vás, ale pro mě je právě toto učebnicová ukázka poškozování konkurence. Po přechodu na ODF ale budou vedlejší náklady na změnu kancelářského balíku minimální.

Zvláštní, v Mnichově nainstalovali OO.o již před dvěma lety a MS Office se tam určitě ještě na velké části počítačů najde. A proč by mělo dočasné využívání staré, již koupené licence na MS Office znásobovat náklady na licence, školení a podporu? Jak prohlížet staré dokumenty ve starém kancelářském balíku snad umí každý školitel vysvětlit za 10 minut i během školení o novém kancelářském balíku. Další úpravy už vysvětlovat nemusí, protože se budou dělat v tom novém.

Sám jste před chvílí tvrdil, že tak snadný není ani přechod mezi různými verzemi MS Office. Tak proč by měl být tak snadný přechod na zcela nový formát? MS Office s ODF pluginem od Sun Microsystems teď představuje asi nejlepší převodní program a až na výjimky funguje stejně dobře jako přechod MSO x => MSO x+1.

Samozřejmě pokud jeden dokument už převedete, tak ho asi trvale uložíte v novém formátu.

Pochopitelně update templatů by byl stejným problémem i s ODF. Nebo si myslíte, že třeba integraci s DB, workgroup SW, faxovým řešením, DMS apod. za vás někdo udělá?

ODF je implementováno všude možně. Ovšem jediný OpenOffice se počítá. Zbytek jsou zmetky typu KWord, Abiword, Google Docs, a podobné věci, které mají nulový podíl na trhu, a tedy nulovou relevanci. Mimochodem protože ODF SW dnes není zdaleka plně interoperabilní (ježto ODF toho moc nepopisuje), už s příštími verzemi ODF lze očekávat nekompatibility.

Po přechodu na ODF budou náklady na změnu kancelářského balíku minimální? Viz výše. Kdo vám předělá všechny customizace a spolupracující produkty? A licence budou také zadarmo?

Zvláštní je to, že v Mnichově trvá přechod na open source již řadu let, a zatím se podařilo migrovat leda browser. Mnichov jel na Office 97, takže pravda přechod na OOo znemaná více-méně stejnou funkcionalitu, jen daleko větší HW náročnost. A podívejte se, jaké byly motivy pro přechod na open source. Nebyla to cena, která by byla na Win+MSO nižší (i před slevami od představitelů MS), ale levicová politická orientace tamní radnice.

Přechod mezi jakýmikoliv verzemi čehokoliv je problém. Přechod na novou verzi SAP R/3 znamená upgradovat klienty na nový OS (tím pádem časté upgrade HW, a nová verze velké spousty aplikací), novou verzi klienta, novou verzi doprovodných aplikací, znovu-testování v podstatě všeho, kontrola a případně předělávání všech úprav i některých nastavení. Takový projekt vyjde na řadu milionů Kč.

Převod MSO to ODF od Sunu funguje pořád velmi mizerně. Zkuste si vzít 100 dokumentů z různých firem, a převést si je. Výsledek bude tristní. Navíc na to potřebujete původní MS Office. Ty dokumenty budete potřeboval otevírat i za pár let. Jak dlouho chcete mít na všech strojích staré aplikace? A jak dlouho budou ty aplikace podporované? Rovněž to školení nelze zvádnout za 10 minut, jak si naivně představujete.

Schválně mi zkuste říci, proč by mělo být lepší přejít na ODF a OpenOffice, než zůstat na MS Office a OOXML. Převody proběhnou bez problémnů, uživatelé současných verzí MSO si doinstalují plugin pro otevírání OOXML dokumentů, konkurence a partneři si mohou OOXML implementovat dle libosti, všichni jsou šťastní, převody bezeztrátové a automatické, náklady minimální. Naprosti tomu vy nabízíte jakési harakiri s přechodem na SW, který má minimální tržní podíl, je chudší na features, má horší interface, je HW náročnější, a neumí beze ztrát převést současné dokumenty. Vidíte tu absurditu? Přesně tak se na to dívá každý manager.

MS Office s každou verzí přináší drobné změny svého interního datového formátu a tedy i nutnost poopravit většinu šablon. Jenže součástí ODF šablony je i odkaz na konkrétní verzi ODF specifikace, podle které může kancelářský balík šablonu správně načíst, i když je už několik let zastaralá.

Odstavec o nákladech si přečtěte ještě jednou. Cena licence nepatří do vedlejších nákladů. Co se týče spolupracujících produktů, platí to samé co o šablonách. Navíc dobře napsaným ODF produktům by mělo stačit pouze změnit ODF knihovnu a případně je překompilovat.

Pokud ode mě čekáte reakci "fuj levičáci", čekáte špatně. Mně jsou politické motivy zcela lhostejné. Mnichovští politici mohou skládat účty pouze svým voličům, mezi které já nepatřím.

SAP využívá nějaký mezinárodní standard, jehož nová verze si vyžádala změnu OS?

Dnešní kompilátory jazyka C implementují normu ISO/IEC C99. Přesto je v nich možné přeložit kód napsaný před 20 lety, tedy ještě před normami ISO/IEC C90 a ANSI C89. Proč? Ne protože by se za 20 let standard skoro nezměnil. Naopak, některé staré varianty syntaxe (například stará definice hlavičky funkce) jsou ve všech těchto normách zakázané. Jenže kompilátory znají ještě jednu jednoznačně definovanou normu, kterou je K&R C a umožňují pomocí přepínače podle ní překládat. Pokud chcete opravdovou zpětnou kompatibilitu, potřebujete otevřený standard.

Jak dlouho vám trvá přednést následující:
- Klikněte pravým tlačítkem na starý dokument
- Zvolte "Otevřít v MS Word"
- Zkontrolujte, zda se dokument v obou programech zobrazil stejně a případně ve Writeru/KWordu/foo/bar/... udělejte potřebné úpravy
- Ve Wordu se můžete v dokumentu pohybovat pomocí posuvníku na pravé straně stejně jako ve Writeru/KWordu/foo/bar/..., na nic jiného nesahejte
- Nakonec zavřete Word. Pokud jste omylem udělali něco, co jste nechtěli, a Word se vás zeptá, zda chcete změny uložit, zvolte Ne
To je zhruba rozsah ovládání nutný ke kontrole formátování ve starém kancelářském balíku.

Možnost implementovat dle libosti je stále ještě sporná, přes právní analýzu od renomované firmy je vyjádření Microsoftu k patentů vágní a soudní spor s nepohodlným konkurentem zůstává hrozbou.

Většina manažerů také považuje za absurdní, že by operační systém, který je zcela zdarma, mohl být technicky lepší než operační systém za 10 000Kč. Specifikaci ODF chybí část funkčnosti, ale neobsahuje žádné zásadní technické chyby. OOXML sice část té chybějící funkčnosti obsahuje, ale na druhou stranu jí některé části také chybí (například definice v jakých jednotkách se zadávají parametry goniometrických funkcí), některé části jsou zcela chybné (statistické funkce) a některé části obsahují technické a logické chyby (kromě přestupnosti roku 1900 také používání escape sekvencí místo XML tagů). Pokud tyto problémy Microsoft vyřeší a doplní své prohlášení k patentům tak, aby bylo jednoznačné a umožňovalo implementaci OOXML komukoliv bez rozdílu, proti přijetí OOXML vůbec nic nemám.

To je samozřejmě nesmysl. Novější produkt MS Office vám udělá dokument dle šablony ze starší verze. Problém je v tom, že zpravidla chcete použít nějaké nové features, případně máte nové verze aplikací, které se s Office integrují.

Pokud si myslíte, že spolupracující produkty jsou o ODF knihovně, tak jste na těžkém omylu. Spolupracujícím produktem může být například DMS. Dialogy otevření souboru, uložení souboru, vložení souboru apod. se odchytí, a nahradí jinými dialogy, které vyhledávají v knihovně dokumentů dle metadat. Jiným spolupracujícím produktem je třeba generátor čárových kódu, který na dané volání vrací správný obrázek, a jeho integrace do Office (samozřejmě beze změny kódu produktu). Někdy mi ukážete, jak při přechodu na jiný office produkt tyhle věci budete řešit rekompilací :). Ale zatím pro OOo takovéto spolupracující produkty ani neexistují.

Pokud chcete opravodou zpětnou kompatibilitu, potřebujete MS Office. Ten dnes čte 15+ let staré dokumenty, čímž se OOo těžko může pochlubit. U jazyka C nějak nechápu souvislost. Proč potřebuji otevřený standard, abych mohl přeložit 20 let starý zdroják?

To školení si představujete celkem jednoduše. A je to v té tabulce dělané stylem odstavce, nebo přímým formátováním? A tahle písmena jsou posunutá nahoru o 3 body, nebo o 6 bodů? Jaká je šíře tohoto sloupce?

Soudní spor je hrozbou vždy. Můžu na vás zítra podat občanskoprávní žalobu v té věci, že jste mi pomočil psa. Soudní spor "hrozí" vždy každému, pokud je proti němu podána žaloba. Je to normální stav.

Samozřejmě Linux (který máte na mysli) je technická troska. Monolitický kernel, nulová podpora Unicode na úrovni jádra a FS (je super mít názvy na disku ve více code pages, případně v jedné, ale tak, aby aplikace nevěděly v jaké), příšerný systém terminálů byl zralý k nahrazení už před 20 lety, X11 je katastrofa, řešení zobrazování a tisku je běsné (zobrazování přes X11, tisk vlastními prostředky či cups, proti Windows GDI o 15-25 let pozadu), podpora multimédií nulová (třeba takový komponentový systém kompresorů a dekompresorů multimédií, služba přehrávání multimédií, to vše mají Windows jako součást API), a pár tisíc dalších věcí. K tomu mizerná dokumentace (MSDN rulez), nic-moc vývojové nástroje, úděs ve formě balíčkovacích systémů... Linux je opis koncepčně 40 let starých systémů, jedno volání po druhém. NT jsou nově navržený systém z 90. let, a za pár let prodělají reinkarnaci v systém založený na .NETu, což umožní dát na kernel i user mode komponenty záruky typu "určitě nikdy nemůže hrábnout do paměti kam nemá", "určitě nemůže dojít k deadlocku", apod.

ODF chybá zcela zásadní části, typu podpory hebrejštin, arabštiny a vzorců. Navíc plná implementace ODF vyžaduje Javu, ježto applety jsou v ODF nativními objekty (pokud se bavíme o ne-plné implementace, zapomeňme u OOXML na autospaceLikeWord95 apod). Zvlášť pikantní je to, že Java není ISO standardem, tedy ODF má závislost na něčem nestandardizovaném. A ještě drsnější je, že ODF s požadavkem byl přijat jako standard v době, kdy Sun ještě neuvolnil Javu, a ta byla chráněna patenty a autorským právem. Zjevně to nevadilo přijetí.

OOXML není dokonalý formát, protože takové formáty prostě nejsou. Ovšem těch pár technických problémů se dá lehko vyřešit v příští verzi, a není třeba kvůli tomu dělat dusno. To by ale pochopitelně nehrálo do karet Sunu...

Jak jsem psal o pár příspěvků zpátky, kromě proprietárních pluginů přímo do koncelářského balíku. Mnohem častějším spolupracujícím produktem jsou ale různé generátory statistik pro výrobní zařízení, ve kterých stačí změnit ODF knihovnu.

Souvislost je v tom, že pokud dnes chcete plnou zpětnou kompatibilitu s dokumenty z MS Office, potřebujete MS Office. Pokud chcete přeložit 20 let starý program v jazyce C, můžete si vybrat libovolný kompilátor, od GCC přes CodeWarrior až po MSVC, přestože dnešní normě už tehdejší kód nevyhovuje. A stejné to bude i s ODF nebo jiným otevřeným standardizovaným formátem.

Nechápu v čem je monolitický kernel špatný. Pokud sem chcete napsat přednášku o výhodách mikrokernelu, ušetřte si práci nebo jí pošlete do konference vývojářů jádra. Windows také používají monolitický kernel a navíc i triviální zásahy jako oprava poškozeného zavaděče v boot sektoru disku systému vyžadují úplnou reinstalaci Windows. Na Linuxu stačí znovu nainstalovat GRUB nebo LILO a na zbytek systému není třeba vůbec sahat (ano, už jsem to párkrát musel udělat). Podpora Unicode v jádře samozřejmě je, sám jí na svých počítačích používám. Při připojení disku je v Linuxu možné zapnout překlad ze znakové sady systému do znakové sady daného oddílu. Opět to používám k překladu mezi UTF-8 a CP-1250 na posledním počítači, kde mám ještě nainstalované Windows. Nevím co máte proti CUPS. Tiskárnu HP DeskJet 710C na Windows nikdy nefungovala správně, na Windows 98 padá ovladač, na Windows XP zase neodpovídají barvy a chybí spousta funkcí. Na Linuxu pod CUPS tisk funguje jak má i přestože je tiskový server a klient v jiném subnetu než server. Pokud chcete špičkovou dokumentaci, doporučuji Gentoo Linux. Vývojové nástroje na Linuxu mi plně vyhovují, kombinace BASH+GCC+MAKE+GVIM mi vyhovuje mnohem lépe než MS Visual Studio, a to jsem měl možnost vyzkoušet si hodně verzí. Pokud implementaci mezinárodního standardu považujete za opis, pak ano, je to opis. Až bude ve Windows NT funkční konsole a zmizí registry, dejte mi vědět. A ne, Microsoft Services for UNIX nepovažuji za funkční konzoli, ale špatný vtip. Takové záruky vám nikdo dát nemůže a Microsoft vám je nedává, dokonce je to napsané i v licenci toho vývojového prostředí.

Java nemusí být ISO standardem, aby na ní mohly ISO standardy odkazovat. Důležité je pouze to, že je dostatečně zdokumentovaná a nekonkuruje ničemu, co by ISO označovalo za standardní jazyk ke stejnému účelu. V době standardizace ODF už byla uvolněná minimální implementace Javy, která by pro plnou implementaci ODF měla stačit. A co vlastně pořád máte s tou Javou? OOXML ve specifikaci makro jazyka také odkazuje na .NET.

A proč to nevyřešit hned?

Tedy nevím, jestli výrobní zařízení (zřejmě máte na mysli technologické linky?) generují ODF, DOC, OOXML, nebo jakýkoliv jiný podobný formát. Když už se v průmyslu něco takového používá, tak CSV, případně XML, zcela výjimečně XLS.

Pokud chcete přeložit 20 let starý program, tak máte především veliký problém. A například dnešní gcc má řadu rozšíření, která jsou použita samozřejmě i v Linux kernelu, a které jiné překladače neumí.

Monolitický kernel je špatný, jen se daleko snadněji píše. Vývojářům jádra psát nebudu, diskuze už proběhla. Linus k tomu napsal, že mikrokernely mají nepopiratelné výhody, stejně jako nevýhody, a ty kdo chtějí mikrokernel odkázal na MINIX. Windows používají monolitický kernel, konkrétně Windows 9x. Řada NT má modifikovanou mikrokernelovou architekturu. Servery zde běží v kernel mode, což je zásadní pro výkon. Tradiční mikrokernel totiž umře na velké množství kernelmode transitions, což je pomalé. Viz třeba problémy MacOS s multithreadingem. Doplňte si znalosti.

Oprava poškozeného zavaděče se řeší tak, že vložíte instalační CD/DVD Windows, zabootujete z něj, a řeknete "repair startup environment" (navíc má boot sector zálohu na určeném místě na disku). Jestli místo toho reinstalujete, tak si doplňte pár znalostí o Windows. Pro začátek doporučuji nějaké školení, nebo lépe pár tisíc stran textů Windows Resource Kitu. Podporu Unicode samozřejmě Linux v jádře nemá. U FS se předávané stringy se prostě zapíší na disk jako jména souborů (nově s možností konverze CP). Takže když budete mít systém jedoucí v 8859-2, aplikace budou volat kernel se stringy v 8859-2. Ovšem aplikace psaná v Qt bude posílat stringy vždy v UTF-8 (a jiné aplikace v jiných code pages). Kernel si s tím neláme hlavu, string prostě použije jako file name, nejvýše ho převede. V důsledku toho má řada linuxových systémů názvy na disku ve více kódových stránkách, a nelze rozeznat, co je v Unicode a co ne. Windows naopak zapisují názvy souborů v Unicode UCS-2, a názvy souborů z aplikací jedoucích v 8-bit code pages (ještě takové bohužel existují) se do Unicode překládají. Mimochodem pokud na Linuxu mountujete Windows disky s konverzí UTF8-ANSI1250, děláte to špatně, protože Windows (VFAT i NTFS) ukládají názvy v Unicode.

Co mám proti CUPS? Zkoušel jste někdy napsat aplikaci, která zobrazuje a tiskne? Ve Windows to funguje asi tak: máme drivery zařízení. Driver má nějaké capabilities typu "umím kreslit čáry", "umím bitmapy", "umím křivky", "umím rastrovat text", "umím čtverce jedné barvy" apod. Takový driver je v principu stejný pro grafickou kartu, tiskárnu, RDP (Remote Desktop), Citrix Metaframe, plotter, nebo cokoliv jiného. Pak máme modul GDI. Ten exportuje funkce typu "kresli text", "kresli křivku" apod.; obecně na vyšší úrovni abstrakce, než drivery. Když aplikace zavolá funkci GDI, GDI jí přeloží natakové funkce driveru, které driver umí. Tedy pokud driver neumí kreslit křivky, tak je vyrastruje do bitmapy, převede na body či úsečky apod. Poud chcete kreslit na obrazovku a tiskárnu, provede to ta samá rutina, jenom jí podstrčíte jiný kontext zařízení (okno, nebo stránku tiskárny). GDI se mimo jiné stará o barevné profily zařízení, takže je v aplikaci vůbec nemusíte řešit, a přesto máte barvy na různých zařízeních shodné (pokud mají zařízení přiřazené správné profily). Co máte na Linuxu? Pomalou příšernost zvanou X11, pro kterou se píše za trest, pomocí které zobrazujete. Různé Xservery mají nejspíš i vlastní drivery (když už nemluvíme o politicky zapřičiněné nutnosti kompilovat(!) drivery). Na tisk máte CUPS, který má samozřejmě úplně jiné API. Podpora ICC profilů nulová, zato musíte používat různá API. Architektura na houby.

Dokumentace, to je věc. Viděl jste někdy MSDN Library? Plná dokumentace Win32, MFC, .NETu, reference C/C++, VB, C#, J#, VBScriptu, JavaScriptu, ASP, ASP.NET, OLEDB, ADO, ADO.NET, MS SQL Serveru, MS Exchange, a řady dalších věcí. Mimo jiné spousty tutorialů, příkladů, development guides. Chcete nahrávat video z capture karty, a ukládat ho? MSDN. Chcete psát DB aplikaci? MSDN. Chcete psát webové stránky? MSDN. Asi sám víte, že žádný jiný sytém takovou dokumentaci nemá. Navíc MS dodává řadu dalších SDK, například pro DirectX. Gcc+vim jsou pravěk, produktivita je nesrovnatelně nižší. Nehledě na to, že dnes se většina kódu píše v .NETu, kde nehrozí takové průšvihy, jako v C/C++ (if (a=1) ..., strcpy ap). Výsledkem je daleko vyšší produktivita, a kvalitnější kód.

Ve Windows je funkční konzole, jen s ní většina lidí neumí (viz typicky for /?). Navíc skriptování na unixech je předpotopní záložitost. Zavolej utilitu, parsuj výstup, zavolej s ním utilitu, parsuj výstup. Je to pomalé, utility nelze lokalizovat, mnohdy nelze přidávat funkce. Na Windows máme PowerShell, což je objektové skriptování nad .NETem. Samozřejmě můžete volat utility, když chcete, ale lepší je provést dotaz na objekt. Například dotaz na procesy může být Get-Process w* | Select-Object name,fileversion,productversion,company. Nikoliv volání utility ps, a parsování sloupců. Technicky vzato lze v PowerShellu vytvořit okno, nakreslit do něj tlačítko, a zavěsit na něj událost. Zkuste do z bashe.

Kde je probém se Services for Unix? Já je mám (nebo jsem měl) na stroji, a celkem fungovaly. Jo o registry jsme tu s kolegy diskutovali. Konfigurace má místo, kde se ukládá, a interface, kterým se mění. Tím interfacem má být vždy GUI, uživatel nemá nikdy lézt přímo do úložiště konfigurace. Proto registry nemají komentáře. Nakonec když si zakládáte účet v KMailu, děláte to ručně v konfiguráku? A když ho měníte, děláte to také v konfiguráku? Asi ani jedno. No a registry mají řadu výhod. Například jsou indexované a tedy rychlé, mají vždy zálohu poslední verze (máte vždy zálohu poslední verze /etc?) atd.

Samozřejmě záruky typu "určitě nikdy nemůže hrábnout do paměti kam nemá" učinit lze. Přestavte si, že jazyk nemá konstrukce typu pointery, které by vás odkázaly kamkoliv do paměti. A je hotovo. Nebo chcete záruku, že kód nikdy nezavolá konkrétní metodu, případně že objekt nemá reference mimo vlastní instanci? To vše lze zajistit (v .NETu či Javě, nikoliv v C/C++). Samozřejmě se analýza dělá na úrovni Common Intermediate Language, obdoby Java Bytecode. Zároveň to otevírá možnost oddělovat procesy popsaným způsobem (je zaručeno, že zkompilovaný kód nikam nehrábne, protože to bylo ověřeno při kompilaci), a tedy se lze zbavit kernel mode transition, což velmi šetří výkon. I díky tomu lze v .NETu napsat operační systém, viz Microsoft Singularity. Z vzhledem k tomu, že příští verze Windows bude běžet Win32 aplikace v sandboxu, je zjevné, že za pár let budou na trhu Windows s kernelem v .NETu. Kde bude zatím Linux? KDE obšlehne desktopové vyhledávání, a bude mít nové ikony?

Samozřejmě .NET je ISO standardem od roku 2003 (Common Language Infrastructure a C#), tedy by podle vaší logiky měl být v ODF použit místo Javy .NET. Ovšem ve skutečnosti může existovat více ISO standardů pro danou oblast. A zjevně lze v ISO standardu použít nestandardizovanou technologii namísto odkazu na existující ISO standard.

Pokud těmi rozšířeními myslíte nějaký nestandardní zápis kódu nebo chování výsledného programu, můžete mi uvést konkrétní příklad? GCC posledních pár let naopak začíná hlásit varování i u kódu, který podle normy není špatně, ale není ani zcela v pořádku.

Diskuzi o mikrokernelu jsem četl a více méně souhlasím s Linusem. Argumenty typu "monolitický kernel je špatný, protože je špatný" si prosím nechte jinam.

To je sice hezké, ale starší instalační CD to ještě neumí. Co tedy v Linuxovém jádře zapíná volba CONFIG_NLS_UTF8, když ne podporu UTF-8? Nevím co používáte za UNIX, ale na mých počítačích Linuxové aplikace striktně dodržují locale. Mám nastaveno UTF-8, tak aplikace běží v UTF-8. Když si nastavím ISO-8859-2 a převedu názvy souborů, poběží v ISO-8859-2. Tu větu o Unicode UCS-2 prosím pěkně neříkejte mě, ale těm posledním Windows, co u mě ještě přežívají vedle Linuxu. Podle všeho mají na věc jiný názor.

Nikdo vás nenutí psát přímo pro X. Můžete využít GTK nebo QT, které obsahují i API pro tisk. X server nikdy nebyl navržen jako desktopový systém s funkcemi pro tisk, ale jako nízkoúrovňový síťově transparentní systém pro počítačovou grafiku a uživatelské rozhraní. Stejně tak CUPS nikdy nebyl navržen jako desktopový tiskový systém, který mají používat koncové programy, ale jako síťový tiskový server založený na PostScriptu.

Ano, bohužel jsem MSDN viděl. Na úžasné vynálezy Microsoftu, jako třeba struktury s jednoprvkovým polem, do kterého se má zapsat celá barevná paleta, doporučenou náhradu funkce fopen(), která vlastně neumí nic jiného než ta původní, nebo funkce na procházení adresářem asi do smrti nezapomenu. Kvalita kódu příliš nezáleží na použitém jazyku, ale na schopnostech samotného programátora.

Lokalizace shell skriptů pomocí programu gettext není nijak složitá. Dokonce oproti Windows naprosto triviální. Perl skripty jsou rychlostí zhruba srovnatelné s Javou, ale i poměrně složité aplikace jde v Perlu napsat za zlomek času. Nevím proč bych měl z BASHe kreslit okno a tlačítko, když je na to Perl nebo Python vhodnější.

Záruku jistě učinit lze, ale když bude v kontrolním systému nebo garbage kolektoru drobná chybka, tak je vám k ničemu.

ISO standardizace programovacích jazyků a knihoven nemá za cíl vybrat jeden "nejlepší" jazyk nebo knihovnu, ale pouze popsat sadu vlastností, které musí každá implementace obsahovat. Pokud ale jde o výměnu dat, tak už jde i o sjednocení formátů napříč platformami a programy.

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.

gcc -pedantic vypíše varování pro každé použití těchto rozšíření, takže je možné je z kódu snadno odstranit. Jejich použití samozřejmě není podmínkou funkčnosti kompilátoru a je dokonce možné je vypnout pomocí podmíněné kompilace.

Když jsem před lety zkoušel vzdálenou plochu ve Windows XP přes 100Base-TX Ethernet, také odezva nebyla příliš dobrá a navíc bylo možné pouze jedno přihlášení. Nové spojení znamenalo tvrdé odhlášení toho předchozího. To X server nedělá. VNC sice umožňuje připojení více lidí ke stejné relaci zároveň, ale stejně fyzicky není možné, aby pracovali dva lidé zároveň. X protokol ale nekončí jen u přenosu celé relace. Mnohem častěji stačí jen přes SSH nastavit proměnnou DISPLAY v shellu vzdáleného počítače a spustit program tak, aby se přes síť připojil na relaci, která běží na vašem počítači. Tohle ve Windows jen tak neuděláte a je to daleko efektivnější.

Jistě, že jsem pochopil, že si musím alokovat velikost tagLOGPALETTE + (počet barev - 1) * sizeof(PALETTEENTY) a pak celou tu obludu přetypovat na tagLOGPALETTE, ale je to hnus a snadno se v těch výpočtech velikosti člověk splete. strlwr_s je bezpečnější v tom, že bere navíc jako parametr velikost pole, ale fopen_s nic takového navíc nedělá, respektive to, co dělá, může dělat i fopen interně.

Pokud bude ve virtuálním stroji vhodná chyba, tak udělám buffer overflow i v Javě. A že tam ta chyba nebude vám nikdo nikdy zaručit nemůže, zvlášť když jde o uzavřený program. Garbage kolektory a manažery kódu mají navíc své vlastní problémy.

Letos se na MFF UK vedla diskuze o zrušení výuky Pascalu a zavedení nového jazyka, který se bude vyučovat v prvním ročníku. Garbage kolektor se v ní považoval za velkou NEVÝHODU.

gcc -pedantic je hezké, ale to nic nemění na tom, že portabilita C není zdaleka taková, jak byste si asi představoval.

Windows XP jsou desktopový systém, takže umožňují pracovat jen jednomu uživateli v jeden čas (sessions může běžet více, aktivní může být jen jedna). Windows Server má možnost připojení 2 sessions pro vzdálenou administraci, nebo libovolného počtu v aplikačním modu Terminal Services. V tom druhém módu vám stačí na stole vě velikosti kabelového modemu, a můžete používat komplet desktop. Technologie je stejná u XP i Windows Serveru. Lze si spustit i vybranou aplikaci namísto desktopu. Odezva je vždy perfektní, minimálně ve srovnání s příšerně pomalým X11. VNC (tak jak ho známe na Windows, tedy coby primitivní program pro přístup ke grafické konzoli) je shit.

fopen_s má enhanced error reporting. Návratovou hodnotou je error code, což je konzistentní s ostatními security enhanced funkcemi. Navíc když mu dáte null pointer, tak nespadne aplikace (Access Violation exception), ale vrátí chybu. To samozřejmě nelze implementovat u fopen. A když jsme u toho, tak vždy jen _wfopen_s, protože Unicode. To s tagLOGPALETTE je přece v C naprosto běžné.

Pokud je ve virtuálním stroji chyba, není to chyba aplikace, ale virtuálního stroje. Chyby aplikace řešme v kontextu aplikace, chyby virtuálního stroje v jeho kontextu. A když jsme u virtuálního stroje, tak ten technologicky není nutný; lze použít kompilaci do nativního kódu. Pochopitelně pak musíte ověřit kompilátor, ale protože kompilátor může být psaný v .NETu (v Javě asi ne, protože kompilace nemůže trvat věky), lze i ten ověřit. Navíc i kdyby se vám podařilo specifické problémy bezpečnosti redukovat z aplikací jen na kompilátor, i to je obrovský úspěch, protože kompilátor je jeden, kdežto aplikací jsou veliké hromady. Zkuste uvažovat trochu prakticky - jak použít technologie pro zvýšení nevalné spolehlivosti a bezpečnosti SW průmyslu. Stávajícího situace totiž není dlouhodobě udržitelná.

MFF a Pascal není argument. To byste mohl tvrdit, že objektové programování je špatné, protože se jako prvníjazyky často volí neobjektové kousky. Faktem tedy je, že se někteří s objekty nikdy "vnitřně nesmíří". A nejlepší jsou absolventi, kteří na prvním ostrém projektu v C++ přetíží operátory, protože jim to ve škole ukazovali, a násobí objekty se stringy :(

Přenosnost programů v C závisí jen na tom, jak dobře je program napsaný. Když je správně použita podmíněná kompilace, může být klidně polovina kódu napsaná zvlášť pomocí rozšíření každého kompilátoru. Když se novináři ptali zástupců Oracle, jak složité bylo portovat jejich databázový systém na Linux, odpověď zněla: "Zadali jsme příkaz make." Ostatně nestandardní rozšíření jazyka C nejsou nejvhodnější příklad, protože kompilátor zdrojový kód pouze čte, ale nezapisuje (ano, o parametru gcc -E opravdu vím). Kancelářské balíky dělají obojí.

Chybový kód při volání fopen najdete v globální proměnné errno, tedy návratová hodnota fopen_s není žádná úžasná novinka. Pokud s tím předáváním NULL mluvíte o prvním parametru fopen_s, tak u fopen také aplikace nespadne, protože tam žádný takový ukazatel nepředáváte. Hlídat ostatní parametry fopen vám také nikdo nebrání. Pokud zadáte místo jména souboru nebo režimu otevření NULL, klidně vám může naskočit i oblíbená sponka z MS Office a oznámit vám popis problému, protože podle normy je chování v tomto případě nedefinované.

Na zlepšování spolehlivosti jsem slyšel jednu opravdu trefný výrok: Pokud se budete snažit udělat něco opravdu blbovzdorné, stvoříte pouze lepšího blbce, který to stejně dřív nebo později rozbije.

Podmíněná kompilace je hnus. "Nejlepší" je multiplatformní kód plný ifdefů. Říká se tomu ifdef hell. Linux může sloužit jako demonstrace.

Odpověď pánů z Oracle byla marketingového rázu. Navíc někeré "kvality" Linuxu, typu threading (res. jeho praktická absence do příchodu NPTL, a ani tam ta implementace přes clone() není moc chytrá) a nechvalně proslulý OOM Killer, dělají z Linuxu mizernou platformu i ve světě unixů. Ovšem pokud bereme Linux jako způsob, jak přejít z drahého profi unixového HW na Intel, a zůstat na unixu (protože desítky let zvyku se počítají), tak to pro jistá nasazení nemusí být špatný nápad. A protože Intel CPU dovedou pokrýt čím dál větší část potřeb zákazníků, je to pochopitelně velmi špatná zpráva pro Sun, IBM, SGI, HP a podobné.

Návratová hodnota fopen_s není nic revolučního, ale je konzistentní s COM (navíc: je err vázaný na thread? jestli ne, je to problém). Pokud byste změnil chování fopen, nebyl by to dobrý nápad. Chování API se vývojáři platformy snaží NIKDY neměnit. No a nakonec - procesem zvyšování bezpečnosti prošlo velké procento volání knihovny CRT. Se "starým" fopen by se jistě dalo žít, ale když už u stovky funkcí vracíte error code a pointer na handle, bylo by dobré mít i konzistentní fopen_s.

S tou spolehlivostí je to zvláštní. Proč myslíte, že vymysleli bezpečnostní pásy, airbagy, VSC, brzdy, kryty na strojích apod.? Všechno z toho samého důvodu: zvýšit spolehlivost a bezpečnost. Zkuste si někdy napsat projekt většího rozsahu, a uvidíte, kolik naprosto neočekávaných chyb (a bezpečnostních problémů) se podaří objevit během ostrého provozu. Cokoliv, co umožňuje jejich počet snížit, se počítá.

Několik dostatečně velkých projektů už jsem psal. Většinu paměťových chyb se mi podařilo objevit a opravit ještě během psaní kódu pomocí nástrojů jako je Valgrind, který mimochodem na Windows není dostupný. Chyby, které přežily až do ostrého provozu, byly většinou logického charakteru (překlep v podmínce, omyl v invariantech apod.) a ani .NET by je nezachytilo.

Dnešní trend ve zvyšování bezpečnosti a spolehlivosti programů není pasivní ochrana systému před následky chyb, ale blbovzdorné jazyky. Když se programátor něčím může střelit do nohy, tak mu sebereme možnost tu věc přímo ovlivňovat (dealokace paměti - garbage kolektor) a postavíme kolem toho automatické ochranné mechanismy (manažer kódu). Výsledek? Programátor v lepším případě daný problém úplně přestane vnímat a v horším bude navíc přepokládat chování, které není zaručené standardem. Když pak bude muset něco udělat bez pomoci berliček v podobě garbage kolektoru a manažeru kódu, bude se muset učit prakticky od nuly hledat a ladit chyby. Ale to už se dostáváme dost daleko od kancelářských balíků.

Samozřejmě pro Windows existuje řada nástrojů, které provádějí statickou či dynamickou analýzu kódu. Problém je ale v tom, že nikdy nemohou dát žádné záruky (což v .NETu lze). Nakonec se podívejte na tisíce bezpečnostních chyb různých produktů, které jsou hlášené každý měsíc. Tohle .NET i Java zachrání určitě. A při rozvedení konceptu verifikace, který jsem popisoval, budemožné stavět systémy zaručených vlastností, což je s C/C++ sci-fi.

Chyby alokace paměti jsou jedním z nejčastějších problémů dnešního SW (určitě by byly v top 5). Programátoři chybují, to "opravit" nelze. Kódu je třeba psát ohromné množství, protože zákazníci chtějí efektivnější práci (ne práci na počítači, ale svou práci). Jaké řešení nabízíte vy?

Když říkáte hledat a ladit chyby, tak to zní, jako by to mělo řešit problém. Neřeší. Myslíte, že autoři děravých či zabugovaných produktů (tedy většiny veškerého SW) neladili a chyby nehledali?

Co se týká lokalizace, program může detekovat, jestli je připojený na interaktivní terminál, nebo na rouru a podle toho zapnout nebo vypnout lokalizaci.

Hezké, nicméně ten kolotoč zůstává stejný: spustit proces, naparsovat textový výstup, spustit s výsledkem jiný proces. K efektivitě a elegentnímu designu to má asi tak daleko, jako 40 let staré unixy k NT.

Úplně efektivní to samozřejmě není (aspoň ne BASH skripty, Perl a Python jsou na tom daleko lépe). Jenže ono ani není cílem BASH skriptů napsat výkonnostně efektivní program. Cílem je poskytnou možnost napsat za 10 minut skript, který za minutu udělá věc, kterou byste ručně dělal hodinu nebo pro to půl roku psal plnohodnotný program, který by to řešil za vteřinu.

Bash má hromadu omezení, není to jen o výkonu. Například začíná a končí na command line, už z principu vylučuje callback, atd. Zkuste přidat účet do KMailu, připojit se k DB a provést dotaz (zvláště parsování výsledku je zábavné), pracovat se soubory OpenOffice Calcu... Přitom to jsou v praxi celkem potřebné věci, na rozdíl od stavu před 40 lety, kdy bylo veledůležité parsovat texty a volat utility. PowerShell oproti bashi je generačně úplně jinde, obdobně jako NT kernel proti klasickému unixovému.

GUI je sice dobrý sluha, ale zlý pán. Když potřebujete změnit dvě položky v konfiguraci serveru, který je x kilometrů daleko, tak připojovat se vzdálenou plochou, prohrabat se skrz menu a hromadu dialogů je zbytečná práce na 5 minut. Přes SSH to v terminálu zvládnu za 10 vteřin s připojením klidně přes 300baudový modem a poslepu.

Na svém desktopu zatím nepotřebuji /etc zálohovat, protože jsem dělal jen pár úprav, síťové služby moc neprovozuji a Gentoo se při updatu zeptá, jestli chci ponechat starý konfigurační soubor, přepsat ho novým, nebo je interaktivně spojit dohromady. Pokud vám to ale udělá radost, můžu si /etc uložit do Subversion repozitáře. Takový luxus, jako prohlížení rozdílů mezi 10 různými verzemi nastavení, vám registry rozhodně nenabízí :D A i přes indexování a stromovou strukturu se dřív nebo později registry zaplní natolik, že začnou celý systém brzdit. Hlavně protože každý program nechává i po odinstalování v registrech hromadu smetí, které se těžko hledá a maže.

Když potřebuji změnit dvě položky v konfiguraci serveru, tak to provedu ve vzdáleném GUI úplně stejně, jako bych to provedl v GUI, kdyby byl stroj na mém stole. Pokud bude spojení přes GPRS, tak to pravda bude trochu pomalé, ale půjde to. Pokud bych věděl, kde konkrétní hodnotu změnit přímo v konfiguraci, samozřejmě mohu použít regedit na lokálním stroji, připojit ho ke stroji vzdálenému (File/Connect to network registry), a editovat vzdálenou konfiguraci. A kdybych byl masochista, mohl bych jet textový terminálový přístup k NT. Ale proč bych to dělal? Mimochodem jak konfigurujete svůj KMail a ICQ? Otevřete konfigurák a zakládáte účet, případně upravujete jeho vlastnosti, nebo prostě použijete GUI, a o obsahu konfiguráku vlastně nemáte ani páru?

Ehm. Opravdu si myslíte, že stromová struktura Windows Registry, která má po instalaci pár desítek MB, se začne zpomalovat kvůli nárůstu velikosti na nějaký směšný x-násobek, kde x je menší než 10? To asi těžko. Problém je úplně jinde. Například Explorer (tedy desktop a spol) je složený z COM objektů. Objekt toolbaru, objekt property sheet, objekt context menu handler. Problém je na prvním místě s počtem těchto objektů. Když na souboru typu ZIP či EXE zmáčknete pravou myš, zavolá se COM objekt patřící WinZIPu (což znamená mimo jiné pár dotazů do Registry). Pokud je soubor typu EXE, podívá se do něj, jestli to není self extracting ZIP. Pokud uzná za vhodné, přidá do kontextového menu správné ikonky, které umožní soubor rozbalit. To je skvělý koncept (který jiné systémy nemohou nabídnout), ale pokud to s extensions přeženete, bude se systém zpomalovat. No a pokud WinZIP odeberete, ale zanecháte integraci v shellu, tak ten pokaždé bude neúspěšně hledat ten již neexistující COM object, což zbytečně zpomaluje. Přemíra extensions (vždyť je to DVD z Chipu, to musím zkusit), stejně jako smetí zanechané po zmršené odinstalaci, se podepisují na rychlosti. Dalším problémem je, že řada aplikací přidává položky, které se pouštějí po přilogování uživatele. Například front-end antiviru (ikona na systray), BlueTooth authentication agent, blbosti na konfiguraci zvukovek, grafických karet apod (autoři driverů zaslouží ránu do hlavy), program ověřující aktualizace Javy, RealPlayeru, Quicktime (ne, Scheduled Tasks na to nepoužívejte, počítač by se nezpomalil, a nebylo by to ono), Adobe Acrobat fast start (fuj) atd. Samozřejmě tyhle svinstva prodlužují start (přilogujete se, a poč je půl minuty mrtvý), a zabírají zbytečně paměť. Vlastní zpomalení Registry je ale minimální. Mimochodem textový export Registry na mám stroji má cca 70MB (pravda, jména klíčů se částečně opakují). Myslíte, že neindexované textové soubory by byly rychlejší (upozorňuji, že vyhledání COM objectu znamená několik dotazů na konfiguraci)? Nebo že když aplikace neodstraní své nastavení z Registry, odstranila by ho z konfiguráku? :)

Nakonec výkon Registry si můžete vyzkoušet. Vezměte si existující registry hive z čerstvě nainstalovaného stroje, jiný hive ze starého stroje, zkopírujte je na čistý disk, přimontujte je (regedit, load hive), a zkoušejte.

Samozřejmě verzování nastavení má řada systémů. Mimo jiné můžete provést export registry, a použít Subversion, což je luxus, který vám /etc rozhodně nenabídne ;)

KMail ani ICQ nepoužívám, navíc to nejsou síťové služby běžící na pozadí, které se jednou nakonfigurují a pak se na ně kromě výjimečných úprav konfigurace vůbec nesahá. Emailový nebo IM klient využíváte právě kvůli grafickému rozhraní. FTP nebo HTTP server zase používáte kvůli přístupu k souborům ze sítě a grafické rozhraní na straně serveru k tomu není potřeba.

KDE umí to samé i bez registrů, dokonce k tomu nepotřebuje COM objekt, ale umí si položku menu vygenerovat samo pro libovolný program. To vše je uložené v textovém konfiguračním souboru podle MIME typu souboru. Jistě, neindexované textové soubory jsou po čase rychlejší, protože v dobře navrženém souborovém systému příliš nehraje roli, jestli je souborů 10 nebo 1 000 000. Po otevření toho správného konfiguračního souboru už načítáte jen to, co vás opravdu zajímá, a nemusíte se prohrabávat konfigurací stovek dalších programů a samotného operačního systému. Zbytky konfigurace odinstalovaného programu jen zabírají místo na disku, ale nezpomalují ostatní programy.

I když budete používat export registrů v Subversion, brzy se v těch změnách ztratíte, protože 90% změn nebude dávat smysl ani administrátorovi. Mimochodem, exportované záznamy jsou v nějakém klíčem určeném pořadí, nebo tak, jak zrovna regeditu přijdou pod ruku (například setříděné podle četnosti přístupů)? Pokud to pořadí není vždy stejné, tak i změna pár položek může vygenerovat rozdíl o velikosti několika MB.

A poslední rýpnutí - celé registry nemůžete sdílet mezi všemi počítači na firemní síti (například kvůli různým sériovým číslům hardware, rozdílným nastavením desktopových programů apod.), /etc ano.

K používání síťové služby není třeba grafické rozhraní, k její administraci se přesto velmi hodí. Jsme v době, kdy i nákladní auta startujeme klíčkem ;). Důvody, proč unixy nemají GUI pro administraci (případně tak mizerné, že je lepší použít command line), jsou jasné. Na unixu nikdy nevíte, jestli vůbec nějaké GUI budete mít. Dlouho trvalo, než se vůbec nějaké GUI objevilo, ai pak bylo primitivní. A když už GUI máte, nevíte, jestli bude i toolkit, a jaký (Motif, GTK, Qt, cokoliv jiného). A navíc napsat GUI, nápovědu a spol dá dost práce (která pak šetří práci adminům). Nakonec zkuste si administrovat Oracle pomocí sqlplus, a MS SQL Server pomocí Enterprise Manageru. Ten rozdíl v efektivitě je řádový, samozřejmě ve prospěch GUI (plus Books Online, to je veliká výhoda).

KDE umí to samé? Abychom si rozuměli: když zobrazím kontextovou nabídku souboru, zavolá se externí plugin. Ten zjistí, jestli soubor má nějakou strukturu, a podle toho například přidá položky do toho kontextového menu. Vložit statickou položku do menu, to snad uměl už Norton Commander. Mimochodem KDE používá KConfig, což je obdoba Windows Registry; jen má jako backend konfigurák.

Nechci vám kazit radost s těmi konfiguráky, ale mýlíte se. FS se samozřejmě s počtem objektů zpomaluje, stejně jako registry, databáze apod., nicméně to při daném objemu konfigurace není problém (mimochodem proč byste se v registry měl prohrabávat konfigurací OS a nevím čím, a na FS nikoliv? je to dost podobná struktura). Nicméně vyhledávání v textovém souboru je VELMI neefektivní, a změna hodnoty v textovém konfiguráku pak VELMI VELMI neefektivní. Dále zbytky konfigurace mohou samozřejmě zpomalovat ostatní programy i v konfigurácích. Představte si, že do konfiguráku OpenOffice přidáte 1000 toolbarů, které ovšem neexistují, a necháte zavést 1000 rozšíření, které ale neexistují. Myslíte, že to nezpůsobí zpomalení, protože jsou informace v konfiguráku?

Vy si myslíte, že změny v konfiguraci KMailu dávají adminovi smysl? Některé ano, jiné ne. Ad exportované záznamy: jsou abecedně řazené, stejně jako výstup příkazu ls.

Vy sdílíte kompletní /etc mezi všemi počítači na síti? To máte jako všechny počítače se stejným host name? :)) Navíc to přináší ten side effect, že můžete například vzít uživatelský účet z jednoho systému, a "implantovat" ho do jiného systému včetně hesla. My samozřejmě ve Windows můžeme například klonovat stanice, ale po klonování pustíme utilitu, která změní SID (pseudonáhodně generované ID systému) a hostname. A mimo jiné máme ve Windows věc zvanou roaming profiles. Uživatel s profilem (data, nastavení) pracuje lokálně, a při odhlášení se profil replikuje na síť. Když se přihlásí na jiné stanici, profil se natáhne či aktualizuje ze sítě. No a navíc má profil části, které se nereplikují, a zůstávají jen lokálně. Kde by tahal na ostatní stanice cache browseru, temp folder apod. Tohle samozřejmě unixy neumí, protože se na desktopu nikdy výrazněji nepoužívaly.

Ano, Konqueror umí to samé. Když zobrazím kontextovou nabídku souboru, Konqueror si zjistí MIME typ souboru a podle toho přidá seznam programů, které jsou nastaveny k otevírání daného MIME typu. Například u PDF souboru mi nabídne KPDF a KGhostView, u TXT mi nabídne KWrite, KEdit, GVIM a Kate, u AVI mi nabídne MPlayer, u ZIP mi nabídne Ark, u JPG mi nabídne KView a KolourPaint apod. Výběr se neřídí příponou, ale skutečným obsahem souboru. A pokud si nainstaluji nějaký NSPlugin, který upravuje kontextovou nabídku podle obsahu vybraného souboru, bude se spouštět i ten NSPlugin.

Souborový systém většinou ukládá soubory daleko efektivnějším způsobem než jak jsou uložené položky v registrech. Navíc je souborů obvykle řádově mnohem méně než položek v registrech. U toho příkladu s OpenOffice bude úplně jedno, jestli to bude uložené v konfiguračním souboru nebo v registrech. Maximálně bude déle trvat načíst seznam všech pluginů. V konfiguračních souborech se také většinou nehledá, ale načítají se celé jednou při startu programu.

Snad nemá smysl zmiňovat, že těch pár souborů, které mají pouze lokální význam, do sdíleného repozitáře dávat nebudu. Kopírování uživatelů se obvykle nedělá, ale například se používá přihlašování přes LDAP. Jak klonování stanic, tak i následné udržování jednotné konfigurace, je na Linuxu daleko jednodušší. Jednoho klonování obrazu Windows XP na 15 počítačů jsem se už účastnil.

UNIXy to samozřejmě umí, stačí zkonfigurovat rsync a nainstalovat 2 skripty, které při přihlášení stáhnou kopii domovského adresáře uživatele ze serveru a při odhlášení zpět nahrají změny. Je sice hezké, že ve Windows je na spoustu věcí klikátko, ale implementace pomocí nějaké obecnější služby je většinou efektivnější, protože je možné vybrat nejefektivnější přenosový protokol a nastavit i drobnosti, které specializovaná služba neumí.

Mohu se zeptat, jak jinak, než podle přípony zjistíte, jakého typu je soubor na disku? Můžete použít magic numbers, jako utilita file. Výsledkem ale bude hromada omylů, protože klíčovou sekvenci může obsahovat prakticky libovolný soubor (třeba první dva byte souboru mohou být "if", a nemusí to být Composer 669 Module sound data). Samozřejmě kontextové menu tvořené statickou konfigurací je poměrně nuda. NSPlugin zní lépe. A teď mi řekněte, co se stane, když budete mít nainstalováno pár desítek NSPlugin-ů, a některé z nich budou pomalé. Odezva Konqueroru potom samozřejmě bude horší. Navíc ty pluginy budou buď zavedené od spuštění Konqueroru, a tedy prodlouží jeho start a zaberou permanentně nějakou paměť, nebo se instancují při každém použití, což je zase pomalé. A když budete mít v konfiguraci Konqueroru referenci na pár stovek či tisíc již odstraněných pluginů, i to bude stát čas. Velmi podobně, jako ve Windows. Jenom do svého Konqueroru asi neinstalujete všechny shity, co uvidíte (a asi jich bude existovat o pár řádů méně,než pluginů pro Windows Explorer).

Souborový systém ukládá efektivněji, než registry? A všiml jste si třeba, že na FS je místo zabrané souborem kvantované po blocích? Že FS udržuje last modification a last access time pro každý soubor, a přečtení či modifikace souboru znamená změnu příslušných time stamps v položce directory, i v nadřazených directories? Dále v konfiguračních souborech se samozřemě hledá. Například když máte komponentový model, tak je třeba mít seznam těch komponent, a odkazy na konkrétní binárky (plus konfigurační informace typu verze, impersonation atd). Těch komponent máme na Windows na každém stroji desítky tisíc (sdílené dialogy, DB komponenty, kompresory a dekompresory multimédií, průvodci, pluginy do browseru, property pages...), a aplikace jsou z nich poskládány. Poskytuje to neuvěřitelnou flexibilitu. Linux je pravda v této věci zatím v plenkách.

Nebo seznam MIME typů a akcí k nim příslušejících. Na mém stroji je zaregistrováno cca 1100 druhů přípon souborů, a velké procento z nich má registrované akce typu open, print, extract, context menu handler, atd. Přece tohle nebudete mít trvale zavedené v paměti. No a v textovém souboru zase budete jen permanentně seekovat. Tohle jsou důvody, proč má KDE svůj KConfig, který z konfiguráků sestaví binární "registry", se kterými pak aplikace pracují. Pochopitelně než přišel na Linux desktop, bez obdoby Windows Registry se bylo možné obejít; ale i na tak primitivním platformě, jako je Qt/KDE, ta potřeba už existuje.

Kopírování uživatelů se nejen nedělá, ale bylo by bezpečnostním problémem. Hash hesla jinak shodného uživatelského účtu by měl být na každém počítači jiný (to je důvod, proč mají Windows stroje unikátní SID). Nevím, jak vypadalo klonování, kterého jste se zúčastnil, ale v praxi se pustí Setup Manager, kde si vyberete, co se má na cílové instalaci provést (vytvořit partition, vytvořit page file, provést re-scan HW konfigurace, zobrazit dialog), pak řeknete, že se to spustí po rebootu, provedete shutdown, a jdete klonovat. Pokud má třeba cílový stroj odlišnou video kartu (a image pro ní má driver), tak bude automaticky použita (nebo dojde na SVGA fallback). V Linuxu skončí stroj po startu na command line schybovou hláškou, a určitě si sám nevybere driver videokarty. Navíc pro Windows existuje hromada SW pro deployment na desktopech, kde si vyberete skupinu strojů, řeknete, že na ně přijdou nějaké aplikace (balíčky včetně konfigurace), a víc se nestaráte. Linux je na desktopu velmi nezralý.

Unixy samozřejmě roaming profiles neumí. Jak rsync pozná, co je cache browseru, co je nastavení ICQ klienta, a co jsou dokumenty uživatele? Takovou cache browseru (a řadu dalších podobných věcí) totiž nemá smysl zbytečně tahat na síť a zpět. Naopak nastavení se tahat musí, stejně jako dokumenty. Windows v profilu mají vyhrazené adresáře, které se nereplikují, viz SDK. To je totiž pro použitelnost replikace profilu celkem zásadní, na rozdíl od protokolu (který může být různý pro připojení na Novell a Windows servery).

Utilita file nečte pouze první 2 byty, ale zkoumá prvních 512 bytů v souboru. Na identifikaci MIME typu to většinou stačí. KDE umí zavést NSPlugin moduly Konqueroru už během přihlašování. A navíc NSPlugin moduly si obvykle instaluje sám uživatel ručně, ne automaticky s každým druhým programem. Jediný automaticky nainstalovaný NSPlugin na mém počítači je Java, u které se dá instalace NSPluginu vypnout.

Optimalizace velikosti uložených dat pro soubory velikosti řádově stovky KB je v době 100+GB disků celkem zbytečná. Ukládání času posledního přístupu se dá vypnout (volba noatime při připojení disku). Na Linuxu se jako změna adresáře považuje smazání nebo vytvoření nového souboru v tom konkrétním adresáři. Změna dat v existujícím souboru se jako změna adresáře nebere. Díky stromové struktuře a nezávislosti na velikosti uložených souborů je ale mnohem rychlejší otevřít soubor než vyhledat záznam v registrech.

Proč bych nemohl mít seznam MIME typů a přiřazené akce trvale uložené v paměti? Textový konfigurační soubor s těmito údaji i komentáři má řádově desítky KB. Po načtení konfigurace se ta velikost změnší díky přístupovým optimalizacím (uložení MIME typů do trie apod.). Srovnávat binární cache s binárním konfiguračním systémem je nesmysl. Když se poškodí cache KDE, znovu se vygeneruje z těch snadno čitelných textových souborů. Když se poškodí registry ve Windows, můžete začít hledat System Rescue CD a poslední zálohu systému.

Na Linuxu rozdělíte disk, spustíte skript na klonování VFS, nakonec nastavíte hostname a další lokální nastavení, případně ještě upravíte konfiguraci jádra (pokud není univerzální) a jste hotový. Výhoda je v tom, že zdrojový počítač se vůbec nemusí vypínat, ale stačí se k němu připojit po síti. Opět nevím, co jste používal za UNIX, ale už jsem na svém počítači párkrát zapomněl po instalaci nového jádra doinstalovat ještě modul AMD FireGL (ovladač pro grafické karty Radeon), ale vždy se systém spustil v SVGA režimu. Pouze nefungovala 3D akcelerace, kterou v KDE stejně nepoužívám. Zatím se mi stalo jen jednou, že by nenastartoval X server, a to jen protože jako vývojář používám nestabilní verzi systému a bylo to po instalaci nové verze, ve které byla chyba.

rsync --exclude-from=soubor1 --include-from=soubor2
Do souboru prostě napíšete seznam souborů a adresářů (klidně i regulárním výrazem), které se mají ignorovat nebo naopak kopírovat navíc oproti základní konfiguraci.

Samozřejmě utilita file nezkoumá jen první dva byte. Má list, obsahující vždy offset, hodnotu která na daném offsetu musí být, a výsledný typ souboru. A soubory typu 669 poznává právě podle těch prvních dvou byte. Soubory typu RAR poznává podle toho, že začínají Rar!, přitom tak opět může začínat kde co. Jinými slovy toto řešení není dostatečně robusní.

Optimalizace velikosti uložených dat je celkem problém. Pokud budete mít 100000 souborů velikosti 1kB (to by mohlo sedět k exportu Windows Registry), tak celá konfigurace zabere 4x více místa, než je nutné (u 4kB bloků, které se nejčastěji používají). U některých FS, jako FAT16, navíc máte limit na 64k souborů :), přitom u Windows bylo požadavkem, že na FAT16 musí běžet. Výkon při čtení je u konfiguráků problémem, protože když přistoupíte k souboru, tak se změni last access time souboru i všech nadřazených adresářů. A soubor musíte samozřejmě proseekovat, abyste našel danou hodnotu. Ano, můžete vypnout last access time pro daný FS, ale moc to neřeší. Změna hodnoty v konfiguráku je pak výkonově ještě větší katastrofa. Texťák totiž musíte v podstatě komplet přepsat (plus aktualizovat directory a případně nadřazené).

Samozřejmě Windows Registry jsou strom. A jako každá podobná struktura (FS, binární strom, DB), i Windows Registry se zpomalují s růstem velikosti (a pochopitelně nikoliv lineárně). Nevím, kde vám řekli, že strom má konstantní počet iterací pro dosažení node, bez ohledu na počet prvků. To zpomalení je ale u Windows Registry nepodstatné. Už jsem vám psal, jak si ho můžete změřit.

Binární cache je horší, než Registry. Je nutné jí synchronizovat s textovými konfiguráky, což je zbytečné a pomalé. Navíc pokud někdo neumí napsat binární konfigurační DB tak, aby se mu nezhroutila, jak potom asi píše FS? A děláte si tedy zálohu struktur FS do snadno čitelných textových souborů, abyste z nich mohl FS přestavět, když se zhroutí? Asi ne. Prostě máte FS implementovaný tak, že funguje, a je odolný vůči nejrůznějším selháním (a případně ho zálohujete na úrovni souborů). Podobně jsou ve Windows implementované Registry. Navíc když se vám poškodí Windows Registry, máte vždy jejich zálohu z posledního úspěšného bootu, kterou můžete během bootu nechat použít. Když se vám poškodí FS s konfiguráky, hledáte také Rescue CD a poslední zálohu systému.

Při klonování je samozřejmě velmi dobrým nápadem pořídit image zdrojového stroje, ten umístit na síť (DVD, USB klíčenku, přenosný disk), a rozbalovat z image. Nebo vy si necháváte ten zdrojový stroj běžet na věky věků? Navíc u zapnutého stroje máte hromadu temp files atd. U větších firem celou problematiku řeší produkty pro lifecycle management, ale to je na jiné povídání.

Používal jsem DEC Ultrix, OSF/1, HP-UX, Solaris, AIX, a několik odrůd Linuxu. Například na FUD prodejců DEC jen tak nezapomenu. Na technické problémy s OSF/1 také ne. Linux se postupem let trochu zlepšuje, ale pořád je to slabota. K VGA: když máte nainstalovaný driver pro svou kartu, shodíte systém, vyměníte HW, a zabootujete (obdoba naklonování počítače, kde cílový stroj má odlišnou grafickou kartu), skončíte na command line s chybovou hláškou. Teprve v příští verzi Ubuntu prý bude "neprůstřelný" X11 server, který vždy naběhne minimálně v SVGA režimu. Jinak X mi samozřejmě selhávají často. Například driver nv nerozdýchal, když jsem ke kartě připojil druhý monitor (jen zasunul kabel, nic jiného jsem nemělil); po startu X11 se prostě obraz rozpadl, a konec. A samozřejmě instalace driverů grafické karty pro Linux, to je velmi zábavná aktivita. Stáhněte si zdrojáky kernelu (proboha proč?), gcc, nějaké další balíčky, a kompilujte (proboha proč?). Je smutné, že si FSF bere uživatele jako rukojmí při prosazování své politiky. Technicky totiž není problém mít drivery grafiky se stabilním binárním rozhraním.

Rsync roaming profiles neřeší. Nepomůže, že můžu specifikovat výjimky. Já potřebuji, aby se replikovalo jen to, co se replikovat musí, a abych nemusel ručně projíždět profily tisíců uživatelů, a vychytávat, co má nejspíš zůstat na lokále. Potřebuji, aby aplikace ukládaly lokální data na oddělené místo, a byly smířené s tím, že na jiném stroji tato data nebudou. To je ve Windows zajištěné (existují na to v profilu adresáře, je popsané jak je používat, a jejich správné používání je předpokladem certifikace Designed for Windows *). Unixy na to nikdy nebyly stavěné, takže s tím nepočítají.

Pokud nejsou jádro nebo X server nakonfigurované přesně na míru původního počítače a není v nich nic navíc (což desktopové distribuce obvykle nejsou), tak se vám taková věc stát na 99% nemůže ani po změně všech komponent. Jak taková změna poloviny systému vypadá na Windows a Linuxu si můžete přečíst zde: http://changelog.complete.org/posts/644-Linux-Hardware-Support-Better-Than-Windows.html

Opět selhání nv driveru není problém X serveru. To samé se vám může stát i na Windows, pokud v ovladačích bude stejná chyba. Ostatně na Linuxu platí, že pokud chcete funkční ovladač, tak chcete otevřený ovladač.

Proprietární linuxové ovladače ze stránek výrobce grafické karty nejsou určené koncový uživatelům, ale tvůrcům balíčků jednotlivých distribucí. Proč k jejich instalaci potřebujete GCC a zdrojové kódy jádra si přečtěte zde: http://lxr.linux.no/source/Documentation/stable_api_nonsense.txt Politika FSF s tím nemá nic společného.

Proč by měl rsync jako protokol pro přenos souborů po síti sám zkoumat, které soubory má nebo nemá přenášet? To je přece záležitost konfigurace a rozhoduje o tom administrátor. Konfigurační soubory jsou skryté v domovském adresáři a místo seznamu co nechcete je jednodušší definovat seznam těch, co chcete. U mě by to například představovalo jen .bash*, .kde* a .ooo-2.0

A jak na Windows budete řešit kopírování části konfigurace, která se ukládá mimo kopírované složky? Když si tvůrce programu usmyslí, že historie nepatří do profilu, ale vy ji přesto chcete kopírovat, co s tím naděláte?

Tvrdil jste mi, že chcete klonovat počítače, tedy nainstalovat jeden, a rozinstalovat na ostatní. Pokud máte na zdrojovém poči vybrán driver grafické karty, a na cílovém je odlišná grafická karta, Linux do grafiky nezabootuje. Ten samý problém nastane, pokud vyměníte grafickou kartu na lokálním stroji. To je neomluvitelné selhání designu UI, které je možné jen proto, že autorům jsou uživatelé ukradení. Nakonec kdyby Linux psala komerční firma, tak by jí výsledky (1% desktopů po 15 letech trvání projektu) donutily produkt velmi rychle vylepšit tak, aby zákazníkům vyhovoval, nebo by projekt skončil. Takový tlak ve světe open source bohužel není. Alternativně by byl projekt uvolněn jako open source, a vyzvedáván jako skvělý počin (Nautilus, OpenOffice, Java a další).

Proč mám dále komentovat článek, kde autor nelegálně kopíruje OEM verzi Windows na nový HW (viz EULA), a nemá instalační CD? Navíc Windows XP jsou 5 let starý systém, takže těžko může počítat, že s nimi dostane na médiu poslední drivery. A autor se ještě diví, že média nahrané od výrobce na poči, který koupil před 4 lety, nemají drivery pro nový HW :). Ty drivery samozřejmě dostane v balíčku, pokud si koupí poč s Windows. Ve Vistě je změna v tom, že certifikované drivery jsou *vždy* na Windows update, takže si je poč sám stáhne. V XP tam některé nebyly, takže do toho člověk musel jít ručně.

Driver nv je součástí xserveru. Je to open source driver - proto je pomalý, nemá 3D akceleraci, a nejspíš právě proto mi zlobil. Obecně na Linuxu platí, že jediný ovladač, který je rychlý, má slušnou 3D akceleraci, a lze ho reálně použít i na těch pár her, je tovární ovladač nVidia. Mimochodem pokusy o konfiguraci X11 tak, abych mohl připojovat a odpojovat druhý monitor za chodu, přepínat na druhý monitor, a měnit rozlišení, jsem vzdal. Stačilo pár hodin s rozsypaným obrazem a jeho troubleshootingem. Rovněž 3D akcelerace mi ani po instalaci nVidia driveru nešla, TuxRacer se plazil jako slimák. Neřešil jsem to - co bych na Linuxu akceleroval jiného, než ten TuxRacer pro vyzkoušení.

Pokud autor mého distra nepřipravil balíček, mám celkem problém (tak je to ovšem u veškerého SW pro Linux). Samozřejmě stable_api_nonsense.txt jsem četl už před lety. Je to nonsense. OS/2, Windows, a řada dalších systémů může mít stabilní kernelové API. V Linuxu to není možné, protože... co? Protože různé kompilátory mohou dávat růzé výsledky? Právě proto tam má být to stabilní API. Protože na jiné platformě je to jinak? To je ale jedno, v rámci jedné platformy může být kompatibilita úplná. Protože nové verze kernelu mohou přinést změny v interface? Pokud se to stane, holt musí autor driver přepsat. Samozřejmě to chce trochu plánovat dopředu, aby člověk neměnil interface co měsíc :). Nicméně pokud se interface změní, je nutné použít jiné binárky driverů stejně, jako je nutné upravit zdrojáky driverů (tedy stabilní binární interface není na škodu). Bylo by fér alespoň říci "nemáme binární interface proto, že chceme, aby výrobci drivery volnili jako open source". Bohužel je slyšet jen "stabilní interface pro drivery je technicky nesmyslný", a "kernelové moduly jsou vždy odvozené dílo, tedy musí být uvolněny pod GPL, takže nám dejte zdroják".

Rsync by neměl řešit, co se má kopírovat. Lokální data by měla být uložená zvlášť, aby rsync mohl kopírovat jen data,které mají migrovat. Samozřejmě manuální definice je naprosto nevhodná. Přenášet se mají veškeré dokumenty, nastavení uživatele, a data aplikací vyjma dat lokálních. Nevím, co byste na tom chtěl konfigurovat.

Pokud na Windows budete potřebovat kopírovat i něco jiného (proboha proč? pokud si tvůrce usmyslí, že se nebude držet design guides, řeší to support, nebo přijde jeho program do koše, a použije se jiný), použijete login/logoff script. Ještě jsem takvou potřebu neviděl, ale proč ne.

Po vypořádání připomínek bude zřejmě OOXML přijato. Jakkoliv je současná situace prezentována div ne jako vítězství pravdy a lásky nad lží a nenávistí, ve skutečnosti je výsledkem "podmínečné ano".

No to začíná být zajímavé. Jak asi takový Google Docs and Spreadsheets, KSpread a NeoOffice (tabulkové kalkulátory) implementují ODF, když ODF nepopisuje vzorce pro tabulkové kalkulátory? Nepřijde vám to trochu úchylné?

Zkuste si uložit nějaký dokument v OpenOffice, pak si ho otevřete, otevřete si k tomu specifikaci ODF, a podívejte se, co všechno není v ODF popsané. Budete nepříjemně překvapen. Pokud se někdo pozastavuje nad autospaceLikeWord95 (což je věc pro zajištění rendrování zcela shodného s Wordem 95, implementace není podmínkou a nedoporučuje se), jak asi budete implementovat PrinterSetup v dokumentu OpenOffice, který je jakýmsi application specific BLOBem bez dokumentace?

Zajimalo by me, zda existuje definice konceptu autoSpaceLikeWord95 v prirozenem jazyce nebo aspon v nejakem formalizmu, nebo ta definice existuje pouze ve forme binarniho kodu?

Taková definice určitě nikde neexistuje jinak, než ve formě binárního kódu. Word 95 napsal Bill Gates osobně v hexa editoru.

Vy jste mne nepochopil. Můj příspěvek byl sarkazmem na fenomén, kdy se ve specifikaci uvedou odkazy na chování jiné aplikace místo toho, aby se toto chování definovalo nebo uvedl odkaz kde je toto chování definováno. Efekt je ten samy, jako by definice existovala pouze ve formě binárního kódu.

Ono popsat toto chování je na dlouhé lokte (a všichni OOXML už tak vytýkají rozsah). K vyřešení připomínky v ISO řízení ovšem bude zřejmě stačit říci, že autospaceLikeWord95 provádí autospacing jako Word 95 (což v současné verzi OOXML opravdu řečeno není).

Tady si nemohu odpustit znovu zopakovat, že Sun OOo píše do dokumentů řadu věcí, které nemají s ODF nic společného. S tím zjevně problém nemáte, ale zato "MS Office 2007 tu specifikaci přesně neimplementuje, ale dělá si spoustu věcí po svém". Na každého je totiž třeba mít různý metr. Podle toho, jestli posuzovatele platí Sun Microsystems, nebo ne ;)

Rozdíl mezi doplněním nedefinovaných funkcí a nahrazením definovaných jinými je dost podstatný. ODF 1.0 říká, že existují vzorce. Neříká ale, jak vypadají. Tedy libovolná implementace vzorců je podle normy v pořádku, ale zatím není vyžadováno, aby vzorce z jednoho kancelářského balíku bylo možné spočítat v jiném. Podle této logiky se standardy řídí už celá desetiletí.

Jinými slovy máme výměnný formát, který se ale pro výměnu používat nedá, protože mu druhá strana nebude rozumět. Vzorce jsou totiž v tabulkových kalkulacích celkem zásadní věcí, tedy je musí implementovat každý. Takový formát neposkytuje interoperabilitu, a patří do koše.

LO, verím, že sa tak hlúpo iba tváriš, pretože ináč je každému rozumnému človeku jasné, že nemá zmysel, aby za tým istým účelom existovalo viacero rozdielnych štandardov.

Logicky sa nedostatky štandardu riešia jeho rozšírením a doplnením a novými verziami, a nie zaradením úplne odlišne konštruovaného uzavretého paškvilus takmer 200 verejne známymi chybami, ak nepočítame tie základné (neimplementovateľnosť, rozsah, patentová hrozba, porušovanie doterajších štandardov).

Velká část z těch 200 chyb jsou věci, které chybami nejsou. Třeba 1900 jako přestupný rok (viz výše), autoSpaceLikeWord95, a řada dalších.

Nikde není řečeno, že pro každou oblast by měl existovat právě jeden standard. A pokud by měl být standard jen jeden, tak proč by to měl být formát produktu OpenOffice, který je na trhu zcela okrajový?

Ještě jednou pro méně chápavé. Tabulkové kalkulátory ukládají datum jako číslo. Nikdo není schopen říci, zda je v nějakém poli číslo, nebo datum (pomocí detekce formátování není možné, protože nezachytíte spoustu situací, kdy se s daty jen počítá). Proto nemůžete "prostě převést všechna určení data".

Ano, implementace s falešně-přestupným rokem 1900 je tak obtížná, že celou implementaci výrazně prodraží :))

Nejde o cenu implementace, ale o to, že to nedává smysl. A pokud něco nedává smysl, nemá to co dělat v mezinárodní technické normě. Že "se s daty jen počítá" zachytíte při analýze závislostí formulí, kterou stejně musíte udělat kvůli přepočtu hodnot.

A jak jsem napsal výše, opravdu triviální řešení problému je použití 31.12.1899 jako dne s pořadovým číslem 1. 99,99% dokumentů tato drobná změna nijak nepostihne a problém bude vyřešen.

Zpětná kompatibilita nedává smysl? Pěkné, mluví z vás jistě praxe.

Samozřejmě drobná změna 99,99% dokumentů nepostihne. Tím je hotovo. Jenže ono je něco jiného 0,01% z dokumentů, které máte doma, a ze všech dokumentů MS Excelu, Lotus 1-2-3 a dalších produktů, které mají tento systém reprezentace data. Je to podobné, jako když naivní příznivci open source považují výsledek open source OCR, které rozezná 99% znaků, za dobrý. Oni si neuvědomí, že to znamená jednu chybu skoro na každém řádku.

Zbylý zlomek procenta bez problémů zachytí převodní filtr a upozorní uživatele. Zpětná kompatibilita dává smysl, dokud nenutí budoucí programy imitovat chyby vzniklé před víc než 10 lety.

Tabulkove kalkulatory (nejen OOCalc) si pamtuji FORMAT bunky, a jeho soucasti je i informace, ze to "cislo" je videt a pracuje se s nim jako s datem.

Jestli to M$ office tak nedela, tak bys mel vybehnout ze sve PR kancelare a svemu sefovi rict, ze mate v M$ dalsi problem. Kazdopadne by to byla chyba implementace M$ - obecne konstatovani "Tabulkove kalkulatory ukladaji datum jako cislo" je typicky zavadejici FUD z PR oddeleni Microsoftu.

Arogance M$ (a Tvoje predevsim) prodavat historicky vznikle a po desetileti neopravene chyby jako mezinarodni standard je skutecne strasna.

Když se podíváte na příklad, který jsem výše popsal, tak uvidíte, že kalkulace s daty provádí OOo Calc úplně stejně, jako Excel. S tím rozdílem, že kalkulace v Calcu nemají stejně výsledky, který mají kalkulace v Lotus 1-2-3 (a následně Excelu, a dalších produktech), a tedy při převodu dochází k chybě.

Někteří lidé jsou s tím ovšem rychle hotoví. Stávající dokumenty vem čert, a co na tom záleží, že na nich jede půlka známého vesmíru.

Ano, výsledky se liší. Excel a Lotus 1-2-3 počítá špatně, OO.o Calc správně. K chybě nedochází až při převodu, chyba je v těch dokumentech od začátku. Chyby je třeba konečně opravit a mělo se to udělat už před 10 lety, ale pořád lepší pozdě než nikdy.

Co je správně? Interpretovat hodnotu 1 jako: 1) 1.1.1900 s falešně přestupným rokem (Lotus 1-2-3, Excel, Quattro Pro, a řada dalších), 2) 2.1.1904 (některé aplikace pro Maca), 3) 31.12.1899? Můžete si vybrat v podstatě cokoliv, ale těžko obhájíte, že právě to ono je správně, a ostatní možnosti špatně. Je to věc dohody. A jednou z forem dohody je standard.

Mimochodem tvrdit, že "15.1.2007-1.1.2007=13.1.1900" je správně, to je pro většinu lidí trochu silná káva. A to bez ohledu na to, jaké je za rovnítkem datum.

Správný výsledek nesmyslně zadané rovnice je pořád správný. Pouze nemá žádný reálný ani logický význam.

I když to nejsou chyby, jsou to důvody, proč je formát špatně navržený a je třeba ho změnit. Jak už jsem řekl výše, otevřený univerzální datový formát nemůže být jen pouhou kopií vnitřního stavu jednoho konkrétního programu. Přestupnost roku 1900 nemá být součástí datového formátu, ale mají ji řešit načítací a ukládací funkce jednoho konkrétního programu, který z důvodů "zpětné kompatibility" obsahuje chybu. Stejně tak autoSpaceLikeWord95 nemá v otevřeném univerzálním datovém formátu co dělat, ale konvertor z BIFF má vygenerovat odpovídající formátování pomocí běžných formátovacích tagů.

Více standardů pro stejnou oblast je porušení ISO Global Relevance Policy, ISO Strategy 2005 - 2010 a WTO Agreement on Technical Barriers to Trade (Annex 3H).

Pokud je ODF okrajový formát, pak OOXML nepoužívá vůbec nikdo. V ODF jsou již řádově desítky tisíc dokumentů dostupných na webu, v OOXML jen několik stovek.

Nikdo neříká, že jediný ISO standard může být jen ODF, ale po ISO standardizaci revize 1.2 bude většina vámi jmenovaných nedostatků odstraněna a dokud Microsoft nevyřeší těch 300 technických připomínek, bude ODF mnohem lépe zajišťovat přenos dat mezi různými kancelářskými balíky a platformami.

Dokumenty MS Wordu se používají primárně interně, nikoliv na webu. Navíc až se MSO 2007 stane masivně používanou verzí, nahradí (bez ohledu na standardizaci) OOXML starší formáty MSO stejně, jako byly nahrazeny formáty Office 95. To se ovšem ODF stát nemůže, protože neumožňuje převést stávající dokumenty beze ztrát.

Pokud standardní formát nemůže být kopií vnitřního stavu jednoho programu, proč je tedy ODF kopií vnitřního stavu OpenOffice? Vždyť ODF je výsledkem snahy o standardizaci formátu OpenOffice (viz i původní název pracovní skupiny).

Které nedostatky budou odstraněny? To, že OpenOffice píše dokumenty, které s plnou implementací ODF nelze interpretovat? To, že ODF nepopisuje ani vzorce pro tabulkové kalkulátory, a ODF dokumenty psané OOo dnes obsahují binární bloby?

Kopie vnitřního stavu programu má všechny nedostatky a chyby toho programu a nutí ostatní implementace formátu tyto nedostatky imitovat. Reprezentace vnitřního stavu programu tyto nedostatky a chyby nemá a program je řeší sám. Reprezentace může být shodná s kopií, ale nemusí. Kromě toho již existuje dost implementací ODF na to, aby případné chyby a nedostatky formátu někdo nahlásil a začaly se řešit v další verzi formátu.

Které nedostatky? Formát zápisu formulí, tabulky v prezentacích a další.

Tedy se ptám, jak to, že byl standardizován zmetek bez popisu vzorců pro tabulkové kalkulátory, a je problémem standardizovat technicky lepší OOXML.

Kolik existuje implementací ODF? A jak jsou rozšířené? A jak řeší ten popis vzorců, a hromadu dalších věcí, které OOo do dokumentu píše, ale nejsou popsané v ODF? Přiznejme si to: pokud OOXML nemá být standardizován kvůli nízké kvalitě, ODF neměl být standardivozán v žádném případě. Ježe Sun se teď ze všech sil snaží, aby byl jediným standardním formátem interní formát jeho produktu - jakkoliv je prokazatelně nekvalitní, a neumí beze ztráty popsat dokumenty, které dnes zákazníci mají. Je zvláštní, že tomu tleskáte.

Seznam implementací ODF je například na http://en.wikipedia.org/wiki/OpenDocument_software.

Microsoftu nikdo nebránil standardizovat svůj vlastní formát už před lety. Jenže to neudělal a je až druhý, takže narozdíl od Sun Microsystems musí mnohem lépe zdůvodnit, proč by měl být další standard na to samé a v čem je lepší. Kromě toho snaha Microsoftu řešit připomínky je nulová a místo toho se snaží standard protlačit za každou cenu ve stávající podobě, takže se nemůže divit, že veřejnosti se to nelíbí.

Já měl za to, že MS nemůže návrh před hlasováním pružně měnit.

Otázka je, co je účelem přijetí standardu. Máme na světě obrovské hromady dokumentů. Z těch se dělají nové verze, které dál přežívají (proto má dnes řada dokumentů MSO nastavené compatibility flagy Wordu 95).

Nyní zde máme formát druhořadého office produktu, který nepopisuje ani vzorce, natož aby umožnil beze ztrát převést stávající dokumenty. Podle mě zjevně nevhodný k čemukoliv. Na druhé straně je tu formát, který umožní beze ztrát převést narostou většinu stávajících dokumentů, a dále s nimi pracovat. Dokonce s těmi novými dokumenty umožňuje pracovat i ve starších aplikacích (s pochopitelnými omezeními). Je přece zjevné, že OOXML je daleko lepší cesta. Tedy pokud člověk není zaměstnanec Sun Microsystems.

Sice nemůže návrh v období hlasování pružně měnit, ale může věcně diskutovat a průběžně pracovat na nové verzi, kterou předloží po skončení hlasování, až se začnou řešit jednotlivé připomínky.

Opět argumentujete tím, že do ODF není možné zcela beze změn převést všechny staré dokumenty. Jenže cílem zavedení ODF je právě to, aby v budoucnu nikdo další nemusel podobný problém s převáděním dokumentů řešit. Teď je na Internetu zhruba 100 000 000 BIFF dokumentů a přibližně stejné množství mimo Internet. Z toho jen pár tisíc obsahuje chyby, které bude třeba po převodu zkontrolovat a opravit. A z těch několika tisíc bude třeba převádět sotva pár desítek. Takže ty chyby opravíme už teď, když jich ještě není tolik, nebo si počkáme, až bude dokumentů ve formátech obsahujících tyto chyby 100 000 000 000?

Jak chcete věcně diskutovat s konkurencí typu Sun, která se jen snaží, aby měla standard pouze ona, a bandou fanatiků, kteří si myslí, že vytvářejí lepší svět, kde vše bude všech? Ani jedna tato skupina nemá zájem na dohodě, pouze na zamítnutí OOXML za každou cenu. Pro Sun je to otázkou (mizerné) business strategie, pro "komunitu" věcí náboženství.

Z čeho vycházíte, když mluvíte o počtech dokumentů a počtech chyb? Na světě je daleko více, než 200 firem, které mají přes milion dokumentů. A s těmi chybami podobně.

Otázkou je, čemu vadí přestupný rok 1900. Ať s tím klidně počítá každý dokument. Vždyť za sebou pořád táhneme nákladní vlak historie. Uživatelé unixů to vědí nejlépe. hjkl funguje, šipka dělá "píp" a vyzvrací pár nesmyslných znaků :). Vydrželo vám to už desítky let, a teď puristicky řešíte teoretické problémy bez praktických dopadů, ovše způsobem, který praktické dopady má.

Pokud je cílem zavést formát, ze kterého už lidé nebudou muset nic převádět, tak proč volit jako cílový formát něco, co současné dokumenty nedovede popsat? Není výhodnější použít formát, který je podrobně specifikovaný, a popsat je dovede?

Aha, a on už se někdo z Microsoftu zkoušel věcně bavit se zástupci Sun Microsystems o vylepšení ODF?

Z čeho vycházím? Z počtu výsledků, které vrátí Google na dotazy ext:doc, ext:xls a ext:ppt.

Nevím jakou prehistorickou verzi UNIXu nebo VI jste používal, ale ve VIM 6 a 7 šipky "píp" rozhodně nedělají a normálně fungují. Sice se to dá vypnout, ale standardně je to zapnuté.

Ostatně k tomu nákladnímu vlaku historie vám mohu dát jeden nádherný příklad. Za posledních 10 let byl TCP/IP subsystém v Linuxu i MS Windows od základu přepsán celkem 4x. Každé přepsání odstranilo spoustu chyb předchozí verze a zlepšilo výkon jádra při přenosu dat po síti.

V Linuxu nová verze vždy nahradila tu původní, takže kromě krátkého testovacího období byl v jádře vždy jen jeden TCP/IP subsystém a během testovacího období bylo možné vybrat si buď ten původní, nebo nový experimentální, ne oba zároveň. S programy a ovladači nebyl příliš velký probém, protože na jejich rozchození s novým TCP/IP subsystémem stačilo pár triviálních úprav a kompilace. Úprava těch programů a ovladačů byla práce navíc, ale ušetřila se tím spousta práce v budoucnu.

Oproti tomu dnes ve Windows XP a pravděpodobně i ve Vistě jsou všechny 4 historické TCP/IP subsystémy, z nichž ten první pamatuje ještě Windows 3.11. Proč? Kvůli zpětné kompatibilitě 15 let starých programů a ovladačů. Ty tři TCP/IP subsystémy navíc samozřejmě stále ještě obsahují většinu chyb a problémů, kvůli kterým vznikly novější implementace, a je třeba je stále udržovat.

Nikde jsem neřekl, že cílem je zavést formát, ze kterého nebude třeba nikdy nic převádět. Za pár let někdo určitě přijde s další úžasnou technologií, ještě lepší než XML, a určitě vznikne úplně nový standard pro kancelářské balíky. Ale když v té době už snad bude drtivá většina dokumentů v otevřeném formátu, který se nesnaží imitovat zastaralé chyby, takže převod do úplně nového formátu bude triviální, automatický a bez hrozby ztráty formátování. A o to jde především, bez ohledu na to, jestli v té době nejrozšířenějším formátem bude ODF nebo nějaký úplně jiný formát.

Proboha proč by se MS bavil se Sunem o vylepšování interních formátů jeho OpenOffice? Představujete si snad, že někdo s podílem na trhu Office produktů ve výši 90+% bude přepisovat své produkty tak, aby ukládaly v interním formátu konkurenčního produktu, který má na trhu nula celá nula nic procent? Ta představa nutí k úsměvu. Realisticky jsou tu 3 alternativy: 1) OOXML bude schválen, 2) OOXML nebude schválen, ale bude de-facto standard, a ODF umře, 3) OOXML nebude schválen, a ODF se bude používat jako transportní formát, který otevře každý, ale nikdo správně (jako dnes RTF).

S těmi čísly vám nechci kazit radost, ale inet není jen to, co indexuje Google. Navíc naprostá většina dokumentů se na inet nikdy nedostane. Kolik procent svých dokumentů ve formátech MS Office si myslíte, že vystaví na web třeba Škoda Auto, nebo Franta Vocásek? Fakt málo.

Používám řadu verzí různých unixů, a díky naprosto předpotopnímu systému terminálů (který byl jistě v době dálnopisů úžasný, ale doba pokročila) se pravidelně připojím k systému, přihlásím se, a neběhá backspace, delete, ani šipky. Až člověk dopatlá nastavení terminálu, spustí aplikaci, která toto nastavení ignoruje (midnight commander, Oracle sqlplus, a řada dalších), a opět je problém. V takové situaci je opravdu praktičtější to hjkl. Ale to je na jinou diskuzi, na téma "unixy jako skládka SW odpadu".

Windows mají 4 TCP/IP subsystémy? Můžete mi sdělit nějaké detaily, například které subsystémy to jsou? Windows totiž pracují tak, že mají subsystém, k němu user mode knihovny (public API), a ty teprve volají aplikace. V případě potřeby se změní "vnitřnosti", user-mode knihovny se upraví tak, aby poskytovaly stejnou funkcionalitu, a na staré aplikace se pochopitelně nesahá. Proto máme například kernelový modul GDI32, k němu public API GDI32, GDI+ a GDI+ pro .NET. To ovšem neznamená, že bychom měli 4 subsystémy GDI :). A nemohu nevzpomenout Javu a New I/O...

Nerad vám beru iluze, ale převody do nových formátů skoro nikdy nejsou bez problémů. Převod z XML based formátů do něčeho nového bude samozřejmě podobný. Je otázkou, jestli je XML vůbec dobrý nápad. Ale to je opět na jinou diskuzi.

Tak proč tu potom blábolíte o bandě fanatiků se kterou se nedá věcně diskutovat, když hned potom řeknete, že Microsoft nemá žádný důvod o něčem s ostatními věcně diskutovat?

Nic přepisovat nemusí, ODF plugin pro MS Office od Sun Microsystems už je skoro hotový a použitelný.

Varianta 2 je dost nepravděpodobná, protože v takovém případě alespoň některé státy odmítnou používat OOXML ve státní správě, a místo toho si vyberou ODF nebo jeho ekvivalent. Varianta 3 po standardizaci ODF 1.2 také přestane být reálná.

Kolik toho na web vystaví Škoda Auto? V tuto chvíli 76 dokumentů. Z těch 76 dokumentů ale bude třeba převést jen pár, protože se jedná vesměs o nabídky pracovních pozic, přihlášky do výběrových řízení, ceníky a tiskové zprávy. Stejné je to i s většinou interních dokumentů. Většina z nich jsou různé oběžníky, hlášení a další jednorázové věci, které si každý párkrát přečte a už je znovu neotevře. Taková státní správa ale na web dává mnohem víc dokumentů.

Například STREAMS transport z úplně prvního TCP/IP subsystému původně licencovaného od Spider Systems v jádře Windows pořád ještě je a s ním i nutná část toho původního TCP/IP subsystému. Dnes běžné programy ho nikdy nespustí, ale velmi staré programy ho stále mohou potřebovat. A podle vyjádření jednoho z bývalých zaměstnanců Microsoftu, který pracoval na implementaci prvních dvou TCP/IP subsystémů ve Windows NT, je to opravdu velmi pomalý kód.

Problémy s převodem mezi formáty vždy způsobují technické a logické chyby, špatná dokumentace datového formátu a implicitního stylu. Přes některé chybějící funkce ODF takové problémy nemá. ODF dokument napsaný čistým způsobem tedy nebude problém převést beze ztrát.

K diskuzi ještě jednou: proč by měl MS diskutovat se Sunem o featurách interního formátu konkurenčního produktu? Navíc ve chvíli, kdy je ten konkurenční produkt na trhu zcela okrajový, a jeho interní formát zdaleka nezvládá to, co MS potřebuje? To by asi bylo poněkud nesmyslné, nemyslíte?

Ano, ODF plugin od Sunu existuje, ovšem řadu věcí neumí převést beze ztráty. Kdo zabije zpětnou kompatibilitu, přijde o zákazníky.

Samozřejmě některé vlády mohou odmítnout OOXML pro publikování dokumentů. V takovém případě budou zřejmě exportovat z MSO do ODF. Nebo si opravdu myslíte, že přejdou na OpenOffice? :)

No vida. Škoda Auto má podle Google 76 dokumentů vystavených na webu. Ve skutečnosti to může být cokoliv mezi 76 a milionem. Interně to pak bude odhadem milion, možná více. Běžný obecní úřad jich bude mít desítky tisíc. Pro ilustraci si spočítejte milion krát (jen) deset minut na úpravu dokumentu po konverzi. To je 166 000 hodin času vlastních pracovníků, které by Škoda Auto musela zaplatit. To je odhadem 35 mln Kč jen na ztrátě času. Berte to tak, že OOXML oproti ODF umí společnosti Škoda Auto auto ušetřit 35 mln Kč. V zahraničí jsou mzdy daleko vyšší, tedy budou vyšší i úspory.

Streams z první verze NT jsou dávno pryč (tuším od NT 3.5). Pro aplikace toto rozhraní nikdy nebylo k dispozici. A pokud by interně streams byly k dispozici (což byste jistě doložil), tak to nemusí mít dopad na výkon. Natož aby bylo oprávněné tvrdit, že Windows mají kvůli zpětné kompatibilitě více TCP stacků.

To, že Linux nedrží zpětnou kompatibilitu, je samozřejmě ostuda. Znamená to, že použitelné jsou jen ty aplikace, které jsou součástí konkrétního distra, nebo pro něj byly připravené. Je zvláštní, když 1% trhu desktopů používá hromadu balíčkovacích systémů, a každou aplikaci je nutné zabalit pro každou verzi každého distra.

Problémy s převodem způsobuje řada faktorů. Například odlišnost modelů. Pokud se v novém formátu třeba rozhodnete, že tabulky budou mít u pole vždy typ obsahu, s tím že s daty se bude manipulovat jen přes funkce dateadd, datediff apod., ODF dokumenty opět nebude možné převést bez problémů. Faktem ale je, že mladické nadšení vám zdaleka nechybí :)

Nemusí diskutovat o interním formátu konkurenčního produktu. Může předložit návrh změn existujícího mezinárodního stadardu a diskutovat o něm.

Klidně ať z MSO exportují do ODF, nic víc než výsledné dokumenty v otevřeném formátu od nich nikdo nechce.

Na druhou stranu chyba v dokumentu, který sestavil pracovník neseznámený se všemi chybami MS Office, může firmu stát mnohonásobně víc. Schválně si u vás ve firmě obejděte kanceláře a udělejte malý průzkum, jak jsou vaši kolegové seznámeni s chybami produktů, které používají. A pokud je součástí školení i seznam chyb a způsoby jejich obcházení, pak to zase zbytečně prodražuje ono školení.

Linux samozřejmě zpětnou kompatibilitu drží. Ovšem nemusí ji držet tak úzkostlivým způsobem jako Windows, protože i poměrně velké změny jádra obvykle vyžadují jen triviální změny v uživatelských programech. Změny v ovladačích také pro běžné uživatele nejsou patrné, protože až na hardware teprve nedávno uvedený na trh je drtivá většina ovladačů přímo součástí jádra a jejich úpravy provedou sami autoři změn jádra. Často stačí jen program znovu zkompilovat, což je záležitost 3 příkazů, které musí umět každý uživatel UNIXu.

Balíčkovací systém je výhoda, nikoliv nutnost. Klidně můžete všechny programy instalovat pomocí ./configure; make; make install, ale budete muset sám hledat všechny potřebné knihovny a další závislosti. Balíčkovací systém tohle všechno udělá za vás. Nic víc, nic míň.

I odlišnost modelů je většinou algoritmicky řešitelný problém. Přestože detekce data nebo čísla může být pro člověka těžko představitelná, pro počítač je hračka projít všechny závislosti vzorců a podle nich rozhodnout.

Interní formát OpenOffice se stal mezinárodním standardem. Nevidím důvod, proč by ho MS měl měnit. Musel by ten standard nafoukout na několikanásobek objemu, aby byl dostatečně popisný.

Osobně mi přijde praktičtější, když budou úřady interně pracovat v OOXML, a dokumenty publikovat v OOXML. Nic se po cestě nemůže ztratit, nic se nepřevádí. Doma si pak můžete převádět, jak chcete.

MS Office má chyby? Je to SW, tedy má chyby už z definice :). Alefalešně přestupný rok 1900 není z tohoto pohledu chyba. Produkt se chová přesně tak, jak je popsáno. Chyba vypadá jinak.

Nevidím důvod, proč by po změnách v jádru mělo být nutné měnit aplikace, nebo je rekompilovat. Pokud to nutné je, jde o špatný návrh (a on návrh Linuxu patří k těm horším). Ve Windows je možné na Windows Vista provozovat aplikaci pro MS-DOS, Windows 2.0 i Windows 95. Kupodivu za těch 26 let od doby uvedení MS-DOSu nebylo nutné aplikace měnit kvůli tomu, že se změnilo jádro. Samozřejmě má i tento princip výjimky, jako všechno.

Balíčkovací systém je nutnost, nikoliv výhoda. Instalovat kompilací je pro běžného uživatele nepřekonatelný problém. Mnohdy je to problém i pro ostřílené linuxáky. Ono to píše, že nelze provést typovou konverzi, a pak ještě asi 3000 dalších chyb... Ovšem mít pro jeden OS, jednu platformu (x86-32) a necelé 1% trhu více než jeden společný balíček, to je tristní. A nutnost dělat balíček zvlášť pro každé distro (pokud balíčkovací systém vůbec má), a každou jeho verzi, to už je katastrofa.

Odlišnost modelů obecně řešit nelze. Například s těmi daty/čísly problém vyřešit automaticky prostě nejde. A podobných příkladů se dá vymyslet spousta.

Na svém blogu v příspěvku "The Formula for Failure" Rob Weir uvedl jenom část těch chyb a nedostatků, které on ve specifikaci vzorců v "technicky lepším" OOXML identifikoval. Zkuste to přečíst a pak ještě jednou zvážit co je ve skutečností zmetkem.

Takže na jedné straně máme ODF, kde nejsou vzorce na sheetech vůbec definovány. To je zcela ZÁSADNÍ nedostatek, a ODF nikdy nemělo projít skrz ISO standardizaci. Na druhé straně tu máme kompletně popsané vzorce, kterým hnidopich vytýká, že u převodu jednotky "cup" není popsáno, jestli jde o šálek americký, evropský, nebo jiný. Celé by to mělo skončit tak, že zmetek ODF bez specifikace vzorců projde standardizací, a OOXML bude zamítnuto, namísto připomínky "doplňte definici jednotky cup nebo odkaz na ni". Jen tak dál. Platí vás Sun?

Doufám, ze OOXML bude zamítnuto s připomínkou "doplňte definici jednotky cup nebo odkaz na ni".

Proboha, proč zrovna já a proč zrovna Sun? Já jsem na tomto webu, protože se zajímám o IT a jsem příznivcem FLOSS. Ale co vy tu děláte, když evidentně FLOSS nesnášíte? To je pro mě záhada.

Linkovný článek mě rozesmál ještě tím, že tvrdí: "lack of detailed definitions in this area make it impossible for anyone to rely on identical financial calculations from different OOXML implementations". To je super vtip. Řešením je totiž ODF, které vzorce pro jistotu vůbec nepopisuje. To se pak jistě dohodneme daleko lée, než pomocí OOXML :))

Je vidět, že jste přeskočil jeden z posledních odstavců toho textu:

So what is ODF doing about formulas? We're continuing to work on them. Rather than rush, we're doing careful, methodical work. We're documenting the functions in great detail. Where we have the choice between the common naive formula for a function and one that is numerically stable, we're documenting the stable function. For the NETWORKDAYS function, we created an optional extra parameter, so a user can pass in a flag that tells what their weekend conventions are. We have a professor of statistics reviewing our statistics functions for completeness and accuracy. We're verifying our assumptions about financial functions by referring to core specifications from groups like the ISDA and the NASD. We're creating a huge number of test cases and checking them with Excel and other applications.

No to je jistě skvělé. Ale jak to, že bylo ODF vůbec standardizováno, když nepopisovalo vzorce? To, že je tam ve verzi 1.2 možná dostanou v prvním nástřelu, který bude odlišný od všeho, co v mezičase používají ODF-enabled aplikace, je tristní. ODF tak ukáže, že není schopné udržet kompatibilitu ani pár let. Ve Wordu 2003 (a nejspíš i 2007) mohu dnes číst dokumenty Wordu 2.0, což je zpětná kompatibilita 16+ let.

Ještě se sluší dodat, že funkce Excelu počítají se systémovým nastavením kalendáře, nebo s tím, co uživatel manuálně specifikuje (pokud to daná konkrétní funkce umožňuje).

LO: Velká část z těch 200 chyb jsou věci, které chybami nejsou. Třeba 1900 jako přestupný rok (viz výše), autoSpaceLikeWord95, a řada dalších.

Tak jsou chyby chybami nebo nejsou? Vy jste me uplne popletl.

Clovek by si to mel probrat ve hlave pred tim, nez hodla vlozit prispevek. A zaroven zamyslet se, zda je ci neni chyba kdyz neprestupny rok se povazuje za prestupny. Pokud ovsem jeho cilem nejsou jen hricky se slovicky.

Především pokud někdo tvrdí, že návrhu kvalita OOXML je špatná, tak je třeba říci, že kvalita návrhu ODF byla daleko horší. Návrh na standardní formát dokumentu, který nepopisuje vzorce tabulkových kalkulátorů, projít mohl. Prošel i přes to, že se jedná o interní formát druhořadého produktu, který na trhu office produktů prakticky nikdo nepoužíváa do kterého nelzepřevést současnédokumenty beze ztrát. Prošel i přes to, že nepodporuje RTL jazyky (arabština a hebrejština). A najednou je hrozný problém v blbostech stylu "OOXML používá ne-ISO kódy států".

Neimplementovatelnost je nesmysl (nebo to nějak doložíte?). Rozsah odpovídá šíři problematiky, s tím, že jí na rozdíl od ODF opravdu popisuje. Patentová hrozba i otázky autorsko-právní jsou u Sun Microsystems úplně stejnou otázkou.

Prvořadým cílem ODF není a nikdy nebylo převádění starých dokumentů. Provařadým cílem ODF je být otevřeným formátem dostupným pro každou platformu a implementovatelný kýmkoliv bez zbytečncýh technických nebo právních překážek. A tento cíl i přes část chybějících funkcí stále plní, proto byl standardizován.

Zda by měl být za mezinárodní standard uznán datový formát, který toto nemá jako prvořadý cíl, je poměrně důležitá otázka.

Jinými slovy chcete, aby výsledným "univerzálním formátem" byl ODF, který neumožňuje popsat stávající dokumenty. Zákazníci si pohorší ohledně features, zhorší se interoperabilita (protože ODF spoustu věcí vůbec nepopisuje). Aplikace typu OOo už dne spíší dokumenty, které s pouhou implementací ODF zdaleka nedekódujete.

Prvořadým cílem ODF je poškození výrobce nejúspěšnějšího office SW, a navýšení tržního podílu produktů Sun Microsystems netržním způsobem.

OOXML nestandardizuje formát data, ale zápis data v OOXML. A to takovým způsobem, aby byla zachována zpětná kompatibilita. Jako doporučení pro převod do nového formátu jsem tu četl sledovat, které buňky se používají pro kalkulace s daty, a případně vyhazovat chyby. To je na implementaci, i pro uživatele, jistě daleko jenodušší, než zachování falešně přestupného roku 1900, že?

ODF 1.2 bude umět popsat všechny stávající dokumenty. Pouze bude problematický jejich převod.

Naopak, ISO standard otevře trh pro skutečnou konkurenci. Kolik jste si ještě před rokem mohl vybrat kancelářkých balíků pro svoji firmu, abyste zároveň mohl posílat dokumenty úřadům a obchodním partnerům? MS Office, MS Office, nebo MS Office. Za rok nebo dva, až se standardizuje ODF 1.2, si budete moct vybrat MS Office s pluginem, OO.o, KOffice, Google Docs nebo některý ze spousty dalších. Pokud toto považujete za poškozování konkurence, pak jsem velmi rád, že zbytek světa si pod poškozováním konkurence představuje něco zcela jiného.

Ano, pro uživatele je opravdu mnohem jednodušší implementace bez falešného přestupného roku 1900. Konečně se tím totiž svět zbaví chyby, která v některých dokumentech pěkně znepříjemnila uživatelům život.

Z čeho vycházíte, když tvrdíte, že ODF 1.2 bude umět popsat stávající dokumenty? A na rozdíl od OOXML to nějakým zázrakem bude umět bez autospaceLikeWord95? :) A i kdyby snad ODF 1.2 umělo popsat stávající dokumenty, *proč prošel standardizací zmetek ODF 1.0, který je popsat neuměl*?

Jako triviální příklad uvedu efekt Blur, který umí MS Word. Je popsaný v ODF? Není. Tedy převod do ODF nemůže být beze ztráty. Podobně Word umí jako odrážky používat obrázky. Pokud to ODF neumí (jako že tohle snad umí), opět nemůže být převod beze ztrát. Podobně třeba se stylem číslování poznámek. A zbytek diskuze je jen o tom, kolik se toho kde ztratí. Jenže ať se ztratí cokoliv, je to vždy špatně.

Pokud se prosadí vaše vize s MS Office, OOo, KOffice, Google Docs a dalšími, bude to fakt super. Vezmu smlouvu, pošlu jí partnerovi, a ten z ní uvidí právě tolik, kolik jeho Office umí. Pokud to bude Google Docs, tak neuvidí skoro nic. Všimněte si, že dnes OOo nemá problémy psát dokumenty, které obsahují řadu věcí, které ODF nepopisuje (a tedy nikdo na základě znalosti ODF neinterpretuje). Opravdová kompatibilita mezi dokumenty různých produktů je možná jen tehdy, pokud ty produkty mají shodné features (viz výše). Potom je ovšem otázkou, proč mít 20 Office produktů, když by podle vás měla existovat jedna standardní sada features. Aby se lišily barvou menu, a nikdo nemohl nabídnout žádnou konkurenční výhodu? Jo, to je úplná exploze konkurence :)

Jo, implementace bez falešnéhě přestupného roku 1900 je pro uživatele nejlepší. Konečně jim totiž přestanou fungovat dokumenty, které fungovaly 20 let. Lidé jako vy si pak budou moci připít slovy "tak na ten zmetek, kterému tleskáme". Samozřejmě chápu, že autorům OOo zpětná kompatibilita nic neříká.

Umět popsat a umět převést beze ztrát jsou dvě zcela odlišné věci. Už teď je v ODF možné uložit opis většiny dokumentů při dodržení veškerého formátování. Různé extra efekty je vždy možné nějak obejít, například vložením obrázku. Problém je opět pouze s automatickým převodem. *Protože to nikdy nebylo jeho cílem.*

ODF sice definuje minimální nutnou sadu features, ale nedefinuje ovládání kancelářských balíků. Poznámkový blok, VI a Emacs mají také určitou společnou minimální sadu features, ale zásadně se liší ve způsobu ovládání. ODF konečně po dlouhé době přinese konkurenci v efektivitě ovládání programů místo konkurence výhradně v podporovaných datových formátech, která tu byla až donedávna.

Uvedu vám trochu zajímavější příklad výrazu: =1.3.1900-7
Tady už je naprosto jasné jaký má být výsledek (22.2.1900) i jaký má význam (datum týden před 1.3.1900), ale Excel ho přesto spočítá špatně. Pokud to uživatel neví (dá se předpokládat, že o chybě v přestupnosti roku 1900 v MS Office ví jen pár lidí), čeká ho velmi nemilé překvapení přímo úměrné tomu, jak důležitá je správnost onoho výsledku.

Pokud nebylo cílem umožnit automatický převod dnešních dokumentů, byl cíl špatný, protože výsledek je pro zákazníky nevyhovující. Viz co jsem psal výše o převodech a nákladech na ně. Samozřejmě je daleko lepší použít formát, který s převodem nemá problémy. Obcházení problému vkládáním obrázků apod. vede k dokumentu-zmetku, který je prakticky neupravitelný. Například pokud máte smallcaps větší, než typograficky být mají (jedno z nastavení typu autospaceLikeWord95), tak to sice můžete obejít tím, že smallcaps dáte větší velikostí písma, ale editace takového dokumentu bude mimořádně nepříjemná (o konverzi do původního či jiného formátu nemluvě). Skvělý job odvedl například MS při konverzi z fomátů WordPerfectu.

Samozřejmě 1.3.1900-7 je problém. Jenže jak jsme si vysvětlili, když ho opravíte, můžete poškodit řadu sheetů, které pracují s dnešními daty. To si fakt myslíte (jako kdosi vtéto diskuzi), že tu opravu na pár řádek MS neumí implementovat? Umí, ale přemýšlí nad následky.

Oprava: Výsledek je krátkodobě nevyhovující pro zákazníky Microsoftu. Pro zákazníky jiných firem a dlouhodobě pro všechny je to výhra.

Podle vaší logiky Intel v roce 1994 zřejmě nad následky nepřemýšlel, když po několika měsících prodeje vadných čipů Pentium konečně uznal svou chybu a nabídl výměnu vadných kusů zdarma, přestože určitě spousta programů s tou chybou již počítala a obcházela ji v kódu, takže po výměně byl ten kód nefunkční.

V čem je pro zákazníky dlouhodobě výhodnější používat ODF, než používat OOXML? Při převodu do OOXML svá data uchovají, při převodu do ODF nikoliv (resp. na tom budou neakceptovatelné náklady). Dlouhodobě je ODF ztráta pro každého, kdo nepoužívá OpenOffice (tedy pro naprostou většinu uživatelů počítačů, o firmách nemluvě). Navíc pro ODF neexistuje jediný slušný Office. OpenOffice je někde na úrovni Office 97, a nic lepšího ODF nepodporuje.

S Intelem a FDIV bug je to samozřejmě nesmysl. Oprava na SW úrovni neměla žádný vliv na funkčnost na bezvadném HW, takže to přirovnání kulhá na všechny tři nohy.

Oprava na úrovni SW neměla vliv pouze pokud rozlišovala, zda je HW vadný nebo ne. Kdyby Intel nestáhl vadné procesory tak rychle, programátoři by to rozlišovat samozřejmě přestali. To by pak podle vaší logiky nutilo Intel imitovat tuto chybu i v nových procesorech.

Na trhu byly procesory s touto vadou, i bez ní. Dále bug neřešili programátoři, ale autoři nástrojů pro programátory (knihoven). A nakonec řešením problému byl typicky zákaz použití koprocesoru v případě, že se jednalo o vadný CPU. Tedy přirovnání nesedí.

Samozřejmě pokud by Intel 10 let vyráběl procesory s jedním špatně dokumentovaným opcodem, tak nemůže význam opcode změnit dle dokumentace, a musí je "špatně" vyrábět dále.

V roce 1994 bylo ještě zcela běžné psát pro DOSové programy kód pro matematický koprocesor v assembleru, takže argument o knihovnách příliš neobstojí. Zákaz použití koprocesoru je také nesmysl, když je vadná jedna instrukce. Jednu instrukci můžete nahradit vlastním kódem a zpomalit program 2x. Nebo můžete vypnout koprocesor úplně, využít přerušení DOSu a zpomalit program 20x.

A proč by ten opkód nemohl po 10 letech změnit? Nebo ještě lépe, proč by ten opkód nemohl prohlásit za zastaralý a udělat nový, který bude fungovat správně?

Mluvil jste o opravených programech, které počítaly s bugem, a proto by Intel dodával dále procesory s chybou. To je nesmysl, protože opravené procesory s programem obcházejícím chybu CPU (ať jí obchází jakkoliv) budou fungovat správně.

Opcode se po 10 letech nemůže změnit, protože by odešly všechny binárky, které ho využívají. Nový opcode je nesmysl, protože opcodů není libovolně mnoho. Řeší se to tak, že se opraví dokumentace, a ke staré se to vydá jako errata.

Pokud jí obcházejí tak, že chybnou instrukci nebudou používat vůbec, tak je změna nepostihne. Pokud jí obcházejí tak, že pomocí chybné instrukce spočítají chybný výsledek a pak ho opraví, tak je změna rozbije.

Intel za dobu existence platformy x86 vydal hned několik rozšiřujících sad instrukcí, takže pro jednu nebo dvě opravné instrukce navíc se místo určitě najde.

Tak se podívejte, co je třeba k navození té FDIV chyby. Postačující podmínky nejsou, narozdíl od nutných, definovány. Tedy výsledek ani nelze opravovat.

V instrukcích je jistý pořádek, zkuste si rozkreslit opcodes binárně. Budete mít X bitů, které říkají "je to MOV (reg),(reg)", 4 bity říkající "AX", 3 bity říkající "DX". Těžko z toho jednu instrukci vytrhávat, tím byste design dost zkomplikoval. Musel by k tomu být velmi dobrý důvod. Normálně se opravdu jen upraví dokumentace.

Přesto je chování chybného koprocesoru deterministické a při podrobnějším zkoumání by určitě někdo opravnou rutinu vymyslel.

Jak vypadá opkód procesoru mi nemusíte vysvětlovat, už jsem programoval kompilátor assembleru i disassembler. Jak funguje matematický koprocesor pro x86 procesory ale podle všeho netušíte, protože nemá přístup do běžných registrů, ale má své vlastní registry, ke kterým přistupuje jako k zásobníku.

Když jsem naposledy programoval v x86 ASM, bylo to pro 8086, a na koprocesory bylo embargo :). MOV byl ilustrativní příklad.

Ještě bych zmínil, že jakékoliv budoucí verze ODF, vyvinuté bez participace Sun Microsystems, jsou podle všeho nelegální (viz licence, kterou Sun uvádí ve specifikaci ODF). Jinými slovy Sun má ISO standard, jehož rozvoj závisí pouze a jen na něm. A pa mi tu něco vyprávějte o hrozbě plynoucí z toho, že OOXML je produktem MS.

Pokud chcete uspořádat petici za vyškrtnutí této podmínky z příští verze standardu, s radostí připojím svůj podpis.

Tedy nejprve přijmeme standard, který má pod palcem Sun, a potom budeme sepisovat petice. To není špatné. Proč tedy spousta lidí křičí, že MS má jakási blíže nespecifikovaná práva na OOXML, poteciálně bránící implementaci, když je to u Sunu velmi podobné? Protože je třeba měřit každému jiným metrem?

Ta blíže nespecifikovaná práva jsou konkrétní patenty. Tyto patenty brání implementaci formátu bez předchozí dohody s Microsoftem. Na druhou stranu Sun Microsystems nijak neomezuje možnost implementovat ODF, pouze si vyhradil, že bez jeho účasti se nesmí měnit standard ODF nebo od něj odvozovat jiný standard. V tom je pro každého programátora a každou firmu velmi podstatný rozdíl.

Pokud vím, tak MS učinil prohlášení podobné tomu, které učinil Sun. Nebo víte o konkrétních patentech, které implementaci prokazatelně brání?

To, že Sun může kdykoliv zastavit vývoj ODF, a nikdo *nebude smět* pokračovat, to opravdu nepovažujete za problém? A co když předvede obvyklou rošádu stylem "to, co vaše aplikace píše, není čisté ODF, ale něco odvozeného/rozšířeného, tedy máte problém"? Viz licitování okolo (dnes díky mizerné strategii skoro mrtvé) Javy.

Microsoft povolil pouze volné použití svých patentů nutných k implementaci závazných částí specifikace, které jsou ve specifikaci navíc podrobně popsány. Patenty, na které je pouze odkazováno, a to i ze závazných částí specifikace, bez licence od Microsoftu použít nesmíte.

Ano, za problém to považuji. Ale je to mnohem menší problém, než kdyby ještě před vznikem ODF Microsoft přestal vyvíjet Office. Obvyklou rošádu provést nemohou, protože v licenci ODF doslova stojí "no derived standard", tedy na obyčejná rozšíření formátu se tato podmínka nevztahuje, dokud je někdo nepodá ke standardizaci.

Kdyby MS přestal vyvíjet Office, ostatní firmy by se popraly o jeho zákazníky. Žádná katastrofa by se nekonala, zachránil by to (jako vždy) trh. Nejspíše by se pak trh postupně pročistil, a našel nový dominantní produkt.

Na které patenty konkrétně ODF odkazuje v závazné části specifikace? Já OOXML i ODF proběhl jen velmi zběžně, takže jsem si ničeho takového nevšiml.

Patentová politika Microsoftu je v souladu s ECMA Code of Conduct in Patent Matters. OOXML, obávám se, na žádné patenty přímo neodkazuje. Pokud existuje odkaz na patentovanou technologii třetí strany, je to věc mezi autorem implementace a třetí stranou (tak jako u prohlášení Sunu). Vezměte též v úvahu Microsoft Open Specification Promise, který pokrývá i OOXML. Vaše obavy tedy nelze než hodnotit jako nedůvodné.

http://www.ecma-international.org/memento/codeofconduct.htm
http://office.microsoft.com/en-us/products/ha102058151033.aspx#2
http://www.microsoft.com/interop/osp/default.mspx

Mimochodem MS si nechal vypracovat právní analýzu od Baker & McKenzie (asi neznáte), která je daleko lepším podkladem, než projevy geeků bez právnického vzdělání. Licencování OOXML zjevně není pro ISO standardizaci překážkou.

Ani katastrofa v podobě ztráty starých dokumentů, ze které tu poslední dva dny děláte pomalu konec světa?

http://holloway.co.nz/can-other-vendors-implement-ooxml.html
Část specifikace vektorového grafického formátu OOXML je patentovaná na Novém Zélandu jako patent 525857. Další problematický patent je novozélandský patent 525484, který se týká XML formátu Wordu.

Samotné prohlášení Microsoftu ohledně patentů ve specifikaci OOXML:

Microsoft-owned or Microsoft-controlled patents that are necessary to implement only the required portions of the Covered Specification that are described in detail and not merely referenced in such Specification.

[n]o other rights except those expressly stated in this promise [respectively, covenant] shall be deemed granted, waived or received by implication, or estoppel, or otherwise.

Také ale záleží na tom, jestli právní oddělení Microsoftu čirou náhodou nebude mít odlišný názor na dostatečnost popsání některého patentu v OOXML specifikaci než některá firma, která OOXML implementuje.

Není to problém pro partnery Microsoftu a velké firmy, které chtějí nabízet closed source programy, ale pro open source vývojáře a malé firmy to problém je, protože vágní formulace toho povolení využívat patenty Microsoftu k implementace povinných částí OOXML představuje příliš velké riziko soudního sporu. RAND licence také může obsahovat non-disclosure agreement, což vlastně vyřazuje všechny open source firmy ze hry. Navíc to povolení opět nepokrývá celou specifikaci, takže úplnou implementaci OOXML stále může provést pouze Microsoft nebo jeho smluvní partner, i když se ze specifikace vyškrtnou nesmysly typu autoSpaceLikeWord95.

To by mě zajímalo, od kdy pro vývojáře open source představuje riziko soudního sporu nějaký problém. Například autoři většiny multimediálních programů pro Linux (mplayer, kodeky) jsou jednou nohou u soudu.

Z právní analýzy nevyšla relevantní právní rizika. Jestli je vidí autoři open source (tedy ne-právníci), asi vidi špatně.

Jinak já nevidím problém v tom, když nějakou technologii není možné implementovat jako open source. Těžko si přece může někdo nárokovat, že má právo implementovat cizí intelektuální vlastnictví pod licencí, kterou si sám vybere. Pokud chce někdo psát open source, freeware, cardware, beerware, dobře mu tak, ale nevznikají mu tím žádná práva.

Tady nejde ani tak o vývojáře, ale o koncové zákazníky. Prakticky všechny distribuce Linuxu dodávají MPlayer bez podpory MP3 a dalších proprietárních kodeků, takže z právního hlediska je vše v pořádku. Samozřejmostí je, že MPlayer funguje i bez těch kodeků, pouze neumí otevřít některé typy souborů. Toto ale u OOXML neplatí a některé patenty (například ty, které jsem jmenoval dříve) mohou bránit implementaci i části povinné specifikace OOXML, bez které budou kancelářské balíky prakticky nefunkční. Pokud chcete nějaké srovnání, tak je to asi jako kdyby někdo měl patent na zobrazování zelené barvy při přehrávání videa.

To není právně v pořádku. Není právně v pořádku ty nelegální kodeky vyvíjet či šířit. Není právně v pořádku je používat. Mplayer se sice bez kodeků dá používat, ale neplní primární účel - přehrávání MP3 a AVI souborů.

OOXML patenty neohrožují, protože se MS zavázal k RAND, a ještě učinil další příslib.

Příměr s patentem na přehrávání zelené barvy je poněkud mimo. Ovšem s tím, že při koupi TV platíte za spoustu patentů, to zase ano. Stejně tak při koupi mobilu, oděvu s některými typy zipů, a řady dalších věcí.

1) Vývojáři MPlayeru kodeky patentovaných formátů nevyvíjí. Používají kodeky, které jsou uvolněné ke stažení, ale kvůli podmínkám jejich licencí není možné je přidat na CD určené k prodeji.
2) Primární účel MPlayeru je přehrávat video a zvuk. Na formátu nezáleží. Nedostupnost WMV/MP3 kodeků vám nijak nebrání přehrávat OGG Vorbis, OGG Theora, WAV, MPEG nebo jiné formáty. Nikde není řečeno, že nějaký kodek je primární a některý je až druhotný.

Přiměřený licenční poplatek mi nijak nevadí. Problém vidím pouze v tom, že o přiměřenosti rozhoduje Microsoft, ne ISO. Problémem zůstávají patenty, které se týkají povinných částí specifikace, ale RAND licence je díky vágnosti onoho patentového prohlášení nemusí pokrývat.

Vývojáři MPlayeru využívají kodeky chráněné autorským zákonem, a patentovým právem. Mplayer je zřejmě odvozeným dílem kodeků stejně, jako jsou drivery pro Linux odvozeným dílem kernelu. Samozřejmě "volně ke stažení" neznamená, že můžete kodek provozovat libovolně.

Samozřejmě Ogg Vorbis a spol přehrávat můžete. Ovšem naprostá většina uživatelů Linuxu přehrává MP3/AVI. A nelegálně.

Licenční poplatky mi také nevadí. Zastánci open source ale křičí, že takové technologie nemohou implementovat pod GPL. Já říkám, že je mohou implementovat pod jinou licencí, a jestli nechtějí, tak nemusí. Poplatek: o výši rozhoduje MS, námitku o jeho nepřiměřenosti může vznést i ISO. U patentů trvám na tom, že nebyla prokázána důvodnost obav. Samozřejmě může být, že na tom visí patent třetí strany, a nikdo o tom neví (totéž u Sunu).

Pokud jsou Linuxové ovladače odvozeným dílem od jádra, tak běžte zažalovat společnosti AMD a nVidia za porušování licence GPL. Mplayer neobsahuje části kódu těch kodeků, pouze je umí používat jako obyčejné sdílené knihovny. A licence těch uzavřených kodeků neurčuje seznam programů, které je mohou používat.

Že nebyla prokázána důvodnost obav je sice hezké, ale ani nebyla prokázána nedůvodnost, což je pro vývojáře mnohem důležitější.

Autoři kernelu tvrdí, že kernelový modul je vždy odvozené dílo, a nelze to obejít. Žalobu na nVidii nikdo nepodá, protože by Linux přišel o jediné slušné video drivery.

Prokázat nedůvodnost obav lze těžko. Když se bojíte, že vás zašlápne fialový slon, těžko dokázat, že je vaše obava nedůvodná. Pokud někdo učiní příslib, a vy přes právní analýzu situace máte pochybnosti, je to podobné, jako s fialovým slonem.

Jistě, ale v případě OOXML mají pořád ještě vývojáři toho fialového slona hned za zády.

To nějak nechápu. Všichni chtěli otevřený formát MS Office, aby mohli číst a zapisovat dokumenty. Teď mají formát nejen dokumentovaný, ale navíc standarizovaný u ECMA, a s ujištěním o duševním vlastnictví. Co ještě chtějí?

Navíc mám za to, že patentové otázky se v ISO považovaly za vyřešené.

Přesněji formulované ujištění, pokud možno ještě doplněné seznamem patentů, které pokrývá.

A vy si opravdu myslíte, že nelze napsat SW, který by dokumenty MSO převedl beze ztrát? Zvláště když máte před sebou 90+% trhu office produktů, a šanci ho velkou část získat? A ano, ztráta starých dokumentů by byla obrovský problém. Možná ne pro vašich pár dokumentů doma, ale pro firmu s milionem dokumentů rozhodně ano.

Ne, to si opravdu nemyslím. Samozřejmě že to je možné. Pouze si myslím, že nemá smysl kvůli tomuto převodu zbytečně vymýšlet datový formát, který imituje všechny chyby těch původních formátů, aby převodní program mohl být mnohem jednodušší.

Samozřejmě omezením je zpětná kompatibilita, nikoliv jednoduchost konvertoru.

Mimochodem, podpora národních zvyklostí muslimských států v OOXML má také k dokonalosti daleko. http://www.noooxml.org/muslims

To je důvod k odmítnutí standardizace? A proč ODF prošel, když mu úplně chybí podpora BiDi, takže v něm nelze arabštinu, hebrejštinu a farsí zapsat?

Hehe, te svedske ostude neni konec. Svedsky normalizacni institut dnes prohlasil sve hlasovani za neplatne, protoze jeden clen hlasoval dvakrat (http://www.sis.se/pdf/OOXML0830_Final.pdf). S velkou pravdepodobnosti do 2.9. nestihnou hlasovani opakovat a Svedsko se tak vzda sveho hlasu v ISO.

Je to rozumne reseni, protoze zhnuseni nad zkorumpovanym hlasovacim procesem bylo ve Svedsku skutecne velike. Cesi by to asi videli jinak (v souladu s heslem "kdo maze, ten jede"), ale Svedove na takhle otevrenou formu korupce nejsou zvykli.

Cool

Taky ze si asi koupil. Na www.groklaw.net se zminuji cast dopisu, ktery Microsoft (podle firmy omylem) odeslal svym partnerum, kde nabada, aby vstoupili do standardizacniho procesu a volili "ano". Ale navic jim poskytl i prefabrikovane "duvody" aby mohli argumentovat proc ma byt OOXML bastl standard - dokonce udajne zduraznoval ze partner nemusi mit technicke znalosti, proto si M$ dovoluje prezentovat podstatne duvody pro prijeti...
... a navic slibil "marketingovou podporu" a "podporu ze zdroju Microsoftu".