ECIS zdokumentovalo antimonopolní chování MS (diskuse)

[Martin]

Spíše by tam mělo být monopolní. Dejte si pozor na překlad.

[Luboš Doležel (Doli)]

Díky, opraveno.

[David Ježek]

tak jsem si to zběžně prolítl a musím říct, že tam je tolik svinstva, že jsem o něm neměl ani tušení. to by snad stálo i za pořádný rozbor bod po bodu s ohledem na chování microsoftu v kontextu rozhodování českých porevolučních vlád (naposledy viz blogpost zde o schvalování OOXML v ČR). dokážu si představit nádherný seriál.

[Pavel]

A to si predstav, ze to je porad nic proti tomu, co se deje a delo u nas ve statnich firmach, ve zdravotnictvi, na komunalni urovni a tak.

[David Ježek]

o tom co se děje v pozadí zdravotnictví něco málo vím.

[Daniel Kvasnička ml.]

přidávání proprietárních rozšíření k existujícím standardům a dalších taktikách.

Tohle dela snad kazda firma na svete a uprimne receno -- ono to ani jinak nejde. Maji snad produkty vsech firem byt ohranicene tim, na cem se nejake konsorcium dohodne? Delam SW, vyuzivam nejaky standard a chci, aby muj program umel neco vic. Nemuze, protoze mi to nikdo neposvetil standardem...? Viz. Google a VoIP rozsireni k jabberu a dalsi...

Delaji to i open source produkty, namatkou treba Inkscape a jejich rozsireni pro SVG. I kdyz tam je teoreticky mozne vzit zdrojaky a zjistit co a jak, temer nikdo to nedela, takze de fakto je to takovy maly free vendor lock-in

[NaiL]

ad inkscape:

- ked to ukladas pise to "inskace svg"

- mozes to ulozit do cisteho svg, program ti povie ze to nemusi dopadnut dobre :)

[pht]

Inkscape SVG používá svůj vlastní namespace, který ostatní SVG prohlížeče ignorují. Ukládá tam věci nad rámec SVG, které jsou třeba vhodné pro další pohodlnější editaci souboru v Inkscape, ale jejich absence nijak neznehodnocuje použití toho SVG. Příkladně velikost a pozici editačního okna, předvolby pro export do PNG a další.

Porovnejte to s tím, kdyby se do Inkscape sekce například ukládaly barvy objektů a navíc by tato sekce byla binární a zašifrovaná. Takže v Inkscape všechno OK, ale všude jinde by bylo všechno bez barev. Tak takto k tomu asi přistupuje M$.

Myslím, že by Vám neuškodilo, než příště napíšete takový výžblebt, se do takového SVG aspoň podívat.

[jozka]

Chapej, naprimo uz tanecky okolo MS a OOXML obhajovat nemuze, tak se na to musi od lesa

[Daniel Kvasnička ml.]

Co myslis temi tanecky? Proces schvalovani? Ten jsem nekde obhajoval?

[Daniel Kvasnička ml.]

Chcete tedy tvrdit, ze Inkscape neuklada do svych tagu nic, co by mohlo ovlivnit vzhled dokumentu pri otevreni v jinem programu? A proc teda pri ulozeni do plain SVG a zavirani dokumentu pise The file "drawing.svg" was saved with a format (SVG Output) that may cause data loss!?

Zkusil jsem vytvorit naprosto primitivni SVG dokument (par krivek, ctverec, kruh a text) a ulozit ho do plain SVG a Inkscape 0.46 neni schopne to precist ani sam po sobe -- nacet mi ten dokument se vsemi objekty sgrupovanymi.

Dale jsem na nektere objekty pridal blur a Inkscape sam, aniz by se me zeptal, zmenil format na Inkscape SVG a to presto, ze blur je soucasti SVG a zadna dalsi rozsireni nepotrebuje! (Inkscape to ulozi za pomoci SVG, ale proc mi cpe vlastni format?)

Ja jsem v Inkscape udelal nejeden web a je to dobry editor (i kdyz na Macu dost razi), jen jsem poukazoval na to, ze vlastni rozsireni ke standardum si pridava kazdy, protoze dneska to jinak nejde. A jak vidite, ani Inkscape v tom neni uplne bez chyby.

Nebo kdyz uz jsme u toho SVG, tak lze zminit to, jak ODF tenhle standard zneuziva. Podrobnosti si urcite najdete sam.

[pht]

Chcete tedy tvrdit, ze Inkscape neuklada do svych tagu nic, co by mohlo ovlivnit vzhled dokumentu pri otevreni v jinem programu?

Ano, viz co jsem o tom napsal v předchozím příspěvku.

proc teda pri ulozeni do plain SVG a zavirani dokumentu pise The file "drawing.svg" was saved with a format (SVG Output) that may cause data loss!?

Asi proto, že ztratíte data specifická pro další editaci v Inkscape.

Inkscape 0.46 neni schopne to precist ani sam po sobe

Udělal jsem podobný pokus, a nepozoroval jsem zmíněný efekt.

Každopádně to je pro naši debatu irelevantní. Jestli inkscape špatně načítá něco co je ve standardním formátu, nebo jestli Vám zlovolně mění defaultní formát, nebo jestli na Vás vyhazuje nepochopitelné hlášky, tak je to problém nebo chyba v Inkscape. Otevřete si tiket na bugzille.

Rozhodně to ale není problém toho typu, že by Inkscape produkoval věci které jdou otevřít jen v Inkscape a všude jinde se "rozhodí", tedy vendor lock-in.

Nebo kdyz uz jsme u toho SVG, tak lze zminit to, jak ODF tenhle standard zneuziva. Podrobnosti si urcite najdete sam.

Problém s namespace jste popsal poněkud bulvárně. Opět v tom ale nevidím nějaký vendor lock-in.

[Daniel Kvasnička ml.]

Problém s namespace jste popsal poněkud bulvárně. Opět v tom ale nevidím nějaký vendor lock-in.

Zdaleka to neni jen problem s NS:

As SVG was inadequete for Openoffice needs ODF has selfcontructed propriety extentions to SVG in it's standard. This means ODF which you claim uses SVG standards actually uses SVG++ which is not exactly compatible with SVG. you can't just copy ODF SVG markup to SVG files as that would require a converter.

http://www.openmalaysiablog.com/2007/06/rick_jelliffe_m.html

V podstate se da rici, ze ODF SVG a SVG maji spolecne nazvy velkeho mnozstvi elementu a atributu. Jiny NS to ma proto, ze je tam ale i dost zcela odlisnych a s SVG nekompatibilnich veci. Jiste, je to otevreny format, vse se da nastudovat, ale je to krasna ukazka toho, co jsem psal -- dela to kazdy a je to bezne, format nevyhovuje, pouzije se z nej jen cast. Kdekoliv tohle MS udelal treba v OOXML (jako ze to tam urcite nekde je), tak je to taky zdokumentovane.

[pht]

Člověče, Vy mě bavíte. Nechcete psát pro blesk nebo živě?

Řekněme, že jsem to špatně pojmenoval, ale je to totéž o čem mluvíte Vy. Pokud se podíváte např. na http://idippedut.dk/post/2008/01/Embrace-and-extend---SVG-revisited.aspx, tak možná o celé situaci pochopíte víc, než z nějakého příspěvku, který jste silně vytrhnul z kontextu.

Problém tkví v tom, že designéři ODF poněkud nešikovně transplantovali syntaxi SVG do ODF. Tudíž by se mohlo zdát, že ODF používá SVG, a že když příslušné pasáže z ODF dokumentu vykopírujeme jako separátní soubor SVG, tak ho otevřeme jako SVG, ale bohužel to tak není.

Jak je popsáno, je to stejná situace, jako bychom si založili formát KvasničkaML, který obsahuje tagy <body> a <p> a jali se tvrdit, že implementujeme, zneužíváme, či dokonce kanibalizujeme HTML.

Ten problém se řeší (právě teď) díky silné iniciativě, aby ODF obsahovalo SVG tak jak stojí a leží a aby tomu byl uzpůsoben OOo, protože ten paradoxně má se soubory SVG velké problémy.

Myslím, že takto postavená situace je stále na hony vzdálená tomu, co dělá microsoft, a o čemž je dokument popisovaný v této zprávičce: vezmeme SVG, naimplementujeme Microsoft Visual Kreslič (tm) který bude SVG umět a konkurovat ostatním SVG editorům, ten rozšíříme do celého světa pomocí různých praktik, a až bude mít nezanedbatelný tržní podíl, tak standard SVG proprietárně rozšíříme na $VG, tak aby věci, které nakreslíme v Kresliči, šly prohlížet pouze v Microsoftích $VG prohlížečích, případně podporu původního SVG vypustíme úplně. A to celé s cílem udržet monopol OS Windows a rejžovat na něm a odstranit jakoukoliv hrozbu. Přečtěte si ten dokument pro celkem zajímavé reálné případy tohoto chování.

Konečně, Váš příměr s OOXML není úplně dokonalý: pokud vím, tak Microsoft zatím strategii EEE u OOXML nepoužil (také nemá proč, když to první E není u OOXML jak uplatnit). Pevně ale věřím tomu, že by toto udělali v případě slibované podpory ODF. Navíc kolem schvalování OOXML byly použity jiná zvěrstva, o kterých jistě víte.

[Daniel Kvasnička ml.]

Problém tkví v tom, že designéři ODF poněkud nešikovně transplantovali syntaxi SVG do ODF. Tudíž by se mohlo zdát, že ODF používá SVG, a že když příslušné pasáže z ODF dokumentu vykopírujeme jako separátní soubor SVG, tak ho otevřeme jako SVG, ale bohužel to tak není.

Jiste, presne tak to je, ovsem vase oznaceni "problem s namespaces" z toho dela jako kdyby stacilo vlastne jen upravit ty NS a otevrem to jako SVG. Kdyby to tak slo, bylo by to celkem bez problemu.

SVG proprietárně rozšíříme na $VG, tak aby věci, které nakreslíme v Kresliči, šly prohlížet pouze v Microsoftích $VG prohlížečích

Jo, a tady je rozdil oproti tomu pripadu s OOo jaky? Jiste, tvurci OpenOffice jsou hodni a nemysleli to zle, ale princip je stejny. Ten vystup z OOo pouziva radoby SVG, ale nikde jinde nez tam ho neotevrete. Ta "nesikovna transplantace", jak vy tomu tak nezky nevinne rikate, je uplne stejny humus. Bylo tu SVG, ktere zvladlo drtivou vetsinu toho, co Draw umi a i kdyby ne, dalo se rozsirit alespon slusne, kdyz uz nic jineho, ale oni to neudelali. Tzn. spekulovat tu muzem jen o motivech (cerne umysly vs. proste lemplovstvi), vecna podstata je stejna jako u MS a miliardy dalsich firem. Vendor lock-in funguje i u firem, ktere nemaji monopol.

Pevně ale věřím tomu, že by toto udělali v případě slibované podpory ODF.

No jestli vas problem nahodou nebude v tom "pevnem vereni"... jiste, svadet je to k tomuto bude, ale ja si pockam, az to vypusti, nez se o tom budu vyjadrovat.

[pht]

Jo, a tady je rozdil oproti tomu pripadu s OOo jaky?

Takový, že SVG je SVG a ODF je ODF. Jsou programy, které umí jen SVG (firefox), které umí jen ODF (openoffice) a které umí oboje (inkscape). Když si někdo založí vlastní formát, místo aby použil existující, tak to není optimální, ale když je ten standard otevřený a lze ho využít ve více aplikacích, tak to NENÍ vendor lock-in.

Vendor lock-in funguje i u firem, ktere nemaji monopol.

Ano, třeba u Apple. Ale ne u openoffice

[Daniel Kvasnička ml.]

Když si někdo založí vlastní formát, místo aby použil existující, tak to není optimální, ale když je ten standard otevřený a lze ho využít ve více aplikacích, tak to NENÍ vendor lock-in.

Jenze kdyz vezmes otevreny standard a pridas k nemu neco, co je sice otevrene, ale neni to poradne zdokumentovane, pak je to de fakto vendor lock-in, protoze temer nikdo nebude investovat do toho, aby to implementoval. De iure to vendor lock in neni, ale to je v dnesnim svete irelevantni.

[pht]

Podle této poučky bychom nikdy nic nezlepšili, protože jakmile bychom začali něco upravovat, tak se ocitáme na zlé straně síly...

[Karry]

ad Google Talk a VoIP. Pokud myslíš protokol Jingle, tak ten byl vymyšlen ve spolupráci s XSF a knihovna libjingle, která jej implementuje je uvolněna pod BSD. Nevím jak přesně to u Googlu funguje, ale jestli má nějakou bránu přes kterou se dá volat i mimo internet, tak na tom nevidím nic špatného.

[Daniel Kvasnička ml.]

V tomto pripade mi slo o to, ze Google to implementoval do produkcniho prostredi drive, nez se XSF byla schopna na tom standardu dohodnout. Plno lidi mu tehdy nadavalo, ze si dela "svoje" standardy k XMPP, ale uz zapominali na to, ze kdyby cekal na XSF, nedocka se....

[Michal Kašpar]

Jenže ten drobnej ale zásadní rozdíl je, že MS obvykle ty změny nezveřejní, takže je nikdo jiný ani implementovat nemůže (respektive občas s použitím reverse engineering atp.).