Námitky proti rychlému přijetí OOXML (diskuse)

[alium]

Jedním ze způsobů jak bojovat proti konkurenci, když ji nemůžete koupit je dělat to, co dělá ona. Čili pokud je ODF standardem ISO, zařídí si svůj OOXML jako standard taky. Pak může s klidem podporovat pouze "svůj" standard, čímž bude dál znemožnovat konkurenci vstup nebo případný rozmach. A že se MS nechce podporovat ODF je vidět hezky na molochu v podobě ODF (OpenOffice) pluginu pro své Office... Vždyť nejde o nic jiného než o pár miliard dolarů,že?

[alblaho]

Velmi zajímavý pohled nabídl Miguel de Icaza

http://tirania.org/blog/archive/2007/Jan-30.html

Zkráceně: specifikace od Moftu je velká, protože obsahuje vše potřebné, podle specifikace ODF toho obsahuje míň, což může dělat potíže implementátorům. A když se k ODF přidají nějaké referencované, standardy, bude to s rozsahem podobné jako u Moftu.

Kdyby byly poměry rozsahů naopak, vyčítali bychom moftu, že nechce dát dostatek informací.

Je to těžké.

[Milan Jurik]

Jezisi, on soudi podle mnozstvi stranek, ani se na jejich obsah podival.

[alblaho]

Četls ten jeho článek? On se právě obsahem zabývá. Krom toho je autorem Gnumericu, takže má s moftími formáty bohaté zkušenosti.

[Kyosuke]

Ale Moft přeci nechce dát dostatek informací, vždyť se přímo v té specifikaci píše, že je pro úplnou implementaci nepostačující a že máme používat software od Moftu.

[alblaho]

Ale přesto je _možné_ že ODF specifikace poskytuje ještě míň informací. ODF dost možná neimplementuješ bez toho, aby ses koukl od zdrojáku OOo. Což se ti, pravda, povede jednodušeji, než s MSO.

[Kyosuke]

Předlož důkaz nebo mlč.

[Mikos]

To že ODF používá existující standardy (MathML, SVG, ...) je jen a jen dobře. NIH (Not Invented Here) syndrom kterým trpí MS je přímo úděsný.

Navíc koukal ste se vubec na tu specifikaci? Je to prolezlé samými microsoftismy. Přímo ve specifikaci jsou věci jako mód kompatibility se starými MS Office, který navíc není nijak pořádně definovaný!

Krom toho je ta specifikace extrémně komplikovaná (a to i když neberu v potaz to že duplikuje různé existující standardy), dobře to popsali třeba vývojáři KOffice, doporučuji přečíst si blogpost Let's support OpenXML! Podle jejich jednoduchých propočtů by 5 vývojářům pracujícím obvyklým tempem jen a pouze na implementaci OpenXML v KOffice trvalo cca 12 let (!!!) tuto specifikaci obsáhnout. Přitom implementovat OpenDocument jim v mnohem menším počtu vývojářů trvalo nesrovnatelně kratší dobu.

OpenXML je prostě zlo... je to jen průhledná snaha Microsoftu prosadit svůj velice těžko implementovatelný a s jejich produkty silně provázaný formát na úkor OpenDocument formátu.

[alblaho]

Ok, já jsem ani jeden z návrhů nečetl a osobně Moftu žádné extrémně dobré pohnutky nepřisuzuji.

Jen jsem chtěl poukázat na to, že samotný rozsah OpenXML nemusí být takový problém.

[Poborskiii]

Až na to, že implementace ODF v KOffice je zatím dosti neúplná. Téměř s každým dokumentem vytvořeným v OOo mám nějaký problém při otevření v KOffice (1.6.1) http://koffice.org/filters/1.6/.

[vlasta neubauer]

sic! a jak si myslíte, že bude úplná implementace desetkrát rozsáhlejšího standardu MS?

[Milan Jurik]

Jiste, ze jsem to cetl. A jak jste dale v threadu prokazal, vy naopak neznate to, o cem o polemizuje.

Tak si rikam, zda delat interna v MS nema zasadni dopad na nazory na svet a vubec

[8an]

Specifikace ODF je jednodušší proto že používá jiné už schválené standardy (MathML, z části SVG), zatímco MS má všechno po svém, a i v tech 6000 stránkách některé věci chybí (např. specifikace WMF, kterou OpenXML odkazuje). Podrobnosti viz seznam připomínek.

[Hynek (Pichi) Vychodil]

Miguel de Icaza je těžkej magor, od něho od jisté doby nečtu nic. Speciálně od doby, kdy zkurvil Gnome.

[alblaho]

Přál bych ti aspoň polovinu jeho inteligence

[Hynek (Pichi) Vychodil]

Děkuji, nechci, to radši zůstanu blbej.

[Michal Vyskočil]

On jde hlavně z extrémů do extrémů. Nejdřív začal dělat grafické prostředí v C (ať žije void* a makra) a najednou propaguje Mono, protože C skutečně není úplně nejvhodnější jazyk pro takovéto aplikace. Na druhou stranu ho trochu chápu, C++ je jako když střelíš třídou do struktur Ale třeba se prosadí D, nebo někdo předělá STLko do lwc.

[Milan Jurik]

To ciste C ma par zasadni vyhod ohledne prenositelnosti

Jinak tise doufam, ze MdI se svym Monem zajdou na ubyte, uz takhle Gnome dost zasiraji.

[Michal Vyskočil]

Já si nevšiml, že by C++* programy na tom byly, z hlediska přenositelnosti, nějak zásadně hůř. Je možné, že g++ může na nějaké obskurní platformě chybět, ale že by na ní zároveň někdo portoval Gnome si nemyslím

* bavím se tu o desktopových programech, ne o řadičích s 10kB paměti

[Milan Jurik]

Svet nekonci jen GCC

[happy barney]

svet končí na strane 410 knihy "C++ Programming Language, 3rd edition"

[Kyosuke]

Radši se neptám, co na té straně začíná. Opustíme-li middangeard, můžeme už jen nahoru nebo dolů. Tipuju, že směrem nahoru bude spíš Lisp.

[Michal Vyskočil]

Bavíme se, doufám, stále o tom, že C je pro Gnome nevhodný jazyk? Takže máte pravdu v tom, že je C obecně portabilnější, ale z hlediska požadavků projektu, jako je Gnome, je na tom C a C++ úplně stejně. Teda, nevšiml jsem si, že by takové Qt, nebo KDE mělo, oproti Gnome, s portabilitou nějaké zásadní potíže

[Milan Jurik]

Kolik C++ prekladacu zvladne prelozit Qt? Jak je to s ABI v C++?

[Michal Vyskočil]

Pořád sklouzáváte k něčemu, co jsem neřekl. Já se nebavím o teoretické portabilitě C vs C++, kde je na tom C z historických důvodů skutečně lépe. Já se ptám pouze a výhradně z pohledu požadavků svobodného desktopu Gnome. Takže moje otázka na vás je, jak přesně omezuje jazyk C++ konkurenční Qt/KDE v portabilitě na ostatní platformy?

I kdyby bylo Qt přeložitelné jenom g++, tak pro projekt svobodného desktopu to imo nepředstavuje žádné výraznější komplikace (jako že není). Navíc, používání "fíčurek" z C99 znamená, že velká část C překladačů si na tom kódu vyláme zuby rovněž a většinou se to stejně překládá jako C++ (zdravím moftí překladač)

Binární kompatibilita C++ knihoven je problematická (hezké, když je v normě kde co, ale že by tam někdo napsal, jak exportovat symboly?), sice se dá nějak zařídit, ale kolik částí Gnome je běžně překládáno odlišnými překladači, aby byla binární kompatibilita svobodného desktopu takový problém?

[Milan Jurik]

Kdyz ctu, co jste tu sepsal, tak jste si sam odpovedel Nejde o casti Gnome, ale o aplikace, ktere potrebuji skrze Gnome kooperovat.

P.S.: Uz jsme opravdu daleko od tematu zpravicky

[ivan]

Ja zase doufam, ze se MONO nebo neco podobnyho rozsiri, a na gui aplikace se Cko prestane pouzivat. Vyvoj v Cecku je mnohem pomalejsi a vyslednej kod neni tak prehlednej. Zvlast kdyz si treba glib gtk pomahaji makry pro preprocesor. Resit refaktoring, dedicnost, virtualni metody, typovou kontrolu pres makra je sileny, vzdyt ten zdrojak pak nema ani Ckovou syntaxi. Hledat v necem takovym chyby je fakt lahudka. To ze kompilator kompiluje uplne jinej zdrojak nez ja vidim na obrazovce vede k tezko resitelnym problemum. Kdo nekdy programoval nejaky XPIcko pro mozillu ten mi musi dat zapravdu.
Ten agrument s prenositelnosti chapu. C++ je mene prenositelne, treba kvuli tomu, ze g++ meni ABI. Obsas clovek narazi, kdyz chce neco prelozit na solarisu nebo ve visual C++. Na druhou stranu tu jsou i nekompatibility mezi ruznyma verzema g++. Takovyhle problemy se vetsinou daji velice snadno vyresit.
Mnohem vic me stve, ze si gdb neporadi s programem v C++, ze nedokaze poradne resolvovat symboly nebo volat metody objektu.

[Pavel Čejka]

Ufff... poté, co jsem viděl jaké prasečiny se do specifikace M$ snaží protlačit, tak mne upřímně překvapuje, že těch zemí bylo POUZE 19, očekával bych spíš něco okolo 90%.

[Christof]

podle toho článku je 19 víc, než se obvykle obtěžuje protestovat

[Kyosuke]

…než se obvykle obtěžuje vůbec hlasovat, to je ještě zajímavější, řekl bych.

[Christof]

máš pravdu, já si asi nějak zidealizoval představy, a měl jsem dojem, že hlasují vždycky všichni. Jaký tragický omyl

[Kozuch]

EU musi killnout M$. Jiny realny konec nevidim.

[happy barney]

nemusí, EU stačí začať rozmýšlať. MS má na svedomí aj dobré veci ... snáď