Vlákno názorů k článku Linux v Mnichově prý nefunguje, opět se uvažuje o Windows od qwertz - No zkušenost praví, že když uživatelům místo MS...
-
qwertz (neregistrovaný)
No zkušenost praví, že když uživatelům místo MS Office 2003 nainstalujete Ribbon MS Office, budou ještě několik let řvát, že se to nedá používat. Tento problém zpravidla vůbec nesouvisí s konkrétním softwarem.
Jinak MS Office nejsou kompatibilní samy se sebou. Občas je lepší ten dokument přeuložit v LO do správné verze MS Office, protože přímý import prostě chcípne :-))))
-
Lael Ophir (neregistrovaný)
Ad MS Office nejsou kompatibilní samy se sebou. Občas je lepší ten dokument přeuložit v LO do správné verze MS Office, protože přímý import prostě chcípne - jak konkrétně docílím toho abych dokument uložil v jedné verzi MS Office, a v novější verzi nešel otevřít? Tipnu si, že způsob nenajdete. Nejspíš jste narazil na poškozený dokument, a nevěděl jste o funkci Open and Repair (je v menu File/Open).
-
j (neregistrovaný)
Lulane uplne jednoduse, a jestli chces odborny skoleni, tak ti poslu proformu, az ji uhradis tak ti to ukazu. Jsou toho totiz nejmin stovky variant, takze zadarmo ti to ukazovat nebudu. Funkce repair je tak leda nahovno, ostatne stejne jako vsechny podobny v provedeni M$, protoze jestlize uz je dokument jeblej, tak tohle ho tak maximalne dorazi.
Poustet tyhle kraviny je zhruba stejne dobrej napad, jako poustet M$ checkdisk.
Apropos, ve ktery verzi opic (teda 2350 nebo 2970) pude otevrit dva excely se stejnym nazvem v jinym adresari (teda pardon, slozce)? A ve ktery verzi budou widle umet fungovat s UTC?
-
Lael Ophir (neregistrovaný)
Aha, takže stovky variant :). Víc než rok vás poptávám o konkrétní reprodukovatelný postup, ale nikdy z vás nic nevylezlo. Vždycky jste se prostě vytratil, jako ostatně vždycky když od vás člověk chce jakoukoliv konkrétní informaci. A teď najednou jsou "stovky variant" jak problém způsobit, a za vypracování postupu reprodukce problému (kde bohatě stačí jeden postup) chcete zaplatit. Samozřejmě víte, že vám nikdo nedá ani korunu. Situace je pořád stejná: prostě nevíte, neznáte a neumíte. Akorát místo toho abyste stáhnul ocas a někam zalezl, jako obyčejně, tak tak to hrajete na "odborny skoleni" a "poslu proformu, az ji uhradis tak ti to ukazu".
Ad ve ktery verzi opic (teda 2350 nebo 2970) pude otevrit dva excely se stejnym nazvem v jinym adresari - v Office 2013 to jde, a mám za to, že jsem to testoval od Office 2007 dál. Jestli chcete odborné školení MS Office, tak vám pošlu proforma fakturu, a až ji uhradíte, tak vám to ukážu ;)
Ad ve ktery verzi budou widle umet fungovat s UTC - systémový čas je ve Windows řady NT vždy v UTC, takže "fungují s URC" odjakživa. Asi máte na mysli RTC, které se u počítačů s BIOSem vždy udržuje v místní časové zóně. V případě UEFI je ta časová zóna uložená v NVRAM, protože tak to vyžaduje specifikace, a zajišťuje to interoperabilitu v případě dual bootu.
Když jsme u těch otázek: ve které verzi se Linux naučí podporu Kaby Lake? A která verze Linuxu zavede API pro takové triviální akce jako je přidání uživatele?
-
j (neregistrovaný)
Nefunguje to samo ani v opicich nejnovejsich, a je to zela vseobecne znama vec uz desitky let.
Stejne jako nefunguje to UTC, a taky odjakziva ... a prave proto treba by default nefunguje ten lulanem zminovanej multiboot. Jo, muzes si to v registrech prepnout ... a pak se ti rozesere polovina systemu do podoby, ze to je zraly na reinstal.
-
Lael Ophir (neregistrovaný)
Ad Nefunguje to samo ani v opicich nejnovějších - ale samozřejmě že to funguje. Potřebujete k tomu dvě instance Excelu. V Office 2013 je spustíte takhle:
https://blogs.office.com/2013/06/03/opening-workbooks-by-running-separate-instances-of-excel/Ad Stejne jako nefunguje to UTC, a taky odjakziva - ale samozřejmě že to funguje přesně jak jsem psal: u počítačů s BIOSem je RTC v lokálním čase. U počítačů s UEFI je v lokálním čase, ale je tu toho zapsaná time zone, takže by vám dual boot měl fungovat (pokud bootujete oba OS přes UEFI).
Ad muzes si to v registrech prepnout ... a pak se ti rozesere polovina systemu do podoby, ze to je zraly na reinstal - ale blbost. Existuje nějaký switch v Registry, který je nepodporovaný a byl určený tuším pro Windows na platformě Alpha AXP. Když si ho nastavíte, tak se sice RTC udržuje v UTC, ale systém může v některých situacích vytuhnout. Nenastane žádné "rozesrání" systému, natož aby byla nutná reinstalace. Když to nebude fungovat (což nebude), tak prostě hodnotu v Registry změníte zpátky. Kdyby to nefungovalo tak že nejde ani zabootovat (což není ten případ), tak to opravíte po bootu z instalačního média. Méně si vymýšlejte, je to průhledné. -
..tak, a nakonec to vsechno sklouzlo k tomu, ze se resi jak otevrit docy v ruznych officech. Proto se vraceji, chybi jim tema, kteremu rozumi kazdy - a se kterym se setkal kazdy, kdo kdy sedel pred monitorem s MS. Tady muze byt kazdy kralem - dejte mi experta, udelejte mi skoleni, rozsirte it oddeleni...pocitace zpusobuji narust prace.
-
Lael Ophir (neregistrovaný)
To bohužel neřeší problémy power managementu. Je smutné, když kernelový vývojář Matthew Garrett doporučuje nekupovat ani systémy se Skylake, protože je rozbitý power management.
https://mjg59.dreamwidth.org/41713.html -
Lael Ophir (neregistrovaný)
Command line utilita není API. Přímý zápis do konfigurace asi také není úplně dobrý nápad. Link na dokumentaci glibs je pěkný. To je přesně místo, kde by to API mělo být popsané, kdyby existovalo. Ideálně by to mělo vypadat nějak takhle:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa370649(v=vs.85).aspxBTW další pěkná věc by byla dokumentace zahrnující glibc, utility, syscalls, X11, Qt, GTK+, OpenGL a řadu dalších core technologií na jednom místě. Koukněte se na MSDN. Ať potřebuji otevřít soubor, přidat uživatele nebo nakreslit krychli, je tam popsané všechno. Ne abych musel hledat dokumentaci na nevím kolika místech, s tím že každá dokumentace má jinou úroveň detailů, a většinou chybí vysvětlení konceptů i příklady použití. Život unixového vývojáře je holt těžký.
-
Ravise (neregistrovaný)
Celkem by mě zajímala tvoje definice API :) Z mého pohledu, API je zhruba sada funkcí, které můžu využít v programu A pro komunikaci s programem B. A jestli volám funkci z nějaké knihovny nebo přímo nějakou exe-binárku už pro mě není podstatné. Nakonec, udělat knihovnu, která volání programů balí do funkcí rozhodně není složité, takže kdyby to bylo potřeba, určitě by se toho někdo zhostil.
Mimochodem, return codeNERR_PasswordTooShortmá v popisu - volně a neuměle překládám: heslo je kratší, než je požadováno. Nebo taky moc dlouhé, nebo taky nějaké z nedávno použitých hesel, nebo taky může mít málo unikátních znaků nebo nesplňuje jiné pravidlo pro hesla. Zkrátka TooShort. -
Lael Ophir (neregistrovaný)
Ad by mě zajímala tvoje definice API - API je Application Programming Interface, tedy funkce která se volá z kódu. Command line utilita je proces, který admin spouští s nějakými parametry, případně se dá použít ve skriptu.
Ad jestli volám funkci z nějaké knihovny nebo přímo nějakou exe-binárku už pro mě není podstatné - to je naopak velmi podstatné. První problém je v tom, že utilita znamená spuštění procesu, což je značný overhead. Vstup musíte předat nějaké textové parametry, pak čekat až proces skončí, a následně parsovat textový výstup. Výstup závisí na verzi utility a lokalizaci.
Druhý problém je v tom, že na Unixech je tradiční konstrukcí pro spouštění procesu fork/exec. Když mám řekněme DB engine, který bere 10GB RAM, tak spuštění utility pomocí fork/exec znamená nutnost buď zkopírovat těch 10GB RAM do nového prostoru, nebo u novějších Unixů (dneska asi u všech) označit stránky v paměti jako CoW, což znamená že to může sežrat až 10GB RAM, a OS tu paměť musí mít k dispozici. Podotýkám že tu paměť nikdy nepoužiju, protože pomocí funkce exec spustím nějakou 100kB utilitu.
Třetí problém je v tom, že z utility nedostanete třeba callback nebo handle.Nepřijde vám to ve srovnání s API jako mimořádná příšernost?
Ad return code NERR_PasswordTooShort má v popisu... - v roce X zavedli konstantu, a v roce X+něco přidali další funkcionalitu. Co byste s tím dělal? A je to problém, když je to popsané? A je to horší než to API vůbec nemít? :)
-
Lael Ophir (neregistrovaný)
Ad kdyz se neco zavola z nejaky knihovny, tak se vubec nemuze pustit dalsi proces, klidne i desitky - no to se sice může, ale většinou k tomu není důvod. A rozhodně není důvod spouštět proces kvůli nějakému přidání uživatele, zjištění stavu daemona/servisu, změně IP adresy síťové karty apod.
Ad to ty netusis vid, ze dll neni nic jinyho nez exe s jinou hlavickou zejo - to vy netušíte, že sice dll mají hlavičku executable, ale používají se úplně jinak. Vaše představy o tom jak funguje OS jsou... řekněme poněkud v rozporu s realitou.
-
" Ad by mě zajímala tvoje definice API - API je Application Programming Interface, tedy funkce která se volá z kódu. Command line utilita je proces, který admin spouští s nějakými parametry, případně se dá použít ve skriptu."
Z kodu muzete volat temer cokoli, a nemusi to byt kod ulozeny v binarni knihovne. I Command line aplikaci. Mozna vas to prekvapi, ale shell scripty jsou take programovy kod a volaji se v nich aplikace naprosto bezne. Ale i naprosto bezne se volaji aplikace napr. z C/C++ kodu. Mozna se budete divit, ale napr jadro pouziva jako sve API dokonce i specialni (magicke) soubory. Za API (nebo spuis jeho soucast) muzete povazovat treba i seznam identifikatoru pro nejaky model RPC, nebo treba komunikacni protokol client/server (napr. D-BUS).
Tedy za API lze povazovat vicemene jakekoliv rozhrani, ktere aplikace pouziva ke komunikaci se svym okolim :)
-
Lael Ophir (neregistrovaný)
Command line utilita je určená pro admina nebo uživatele, který ji používá z terminálu. Nakonec proto má textový vstup i výstup. Samozřejmě se dá volat ze shell skriptu, protože shell skript je v podstatě zřetězená sada příkazů, jako byste je psal na terminál (obohacená o pár řídících konstrukcí).
Pokud trváte na tom že command line utilita je API, tak by nebylo špatné například z C++ a standardních knihoven odstranit všechny operace nad soubory. Vždyť můžete prostě spustit utilitu, je to přece geniální API. Chcete připsat řádek k textovému souboru? Spustíte shell s parametrem echo [text] a přesměrováním do výstupního souboru. Chcete přečíst obsah souboru? Spustíte shell s parametrem cat [soubor], a dokonce můžete použít pipe a vyfiltrovat si co z toho souboru chcete. U binárních souborů se také dá něco vymyslet. Stačilo by napsat pár utilit, které by prováděly čtení a zápis souborů. Vstup i výstup by měl být textový, ale dá se použít třeba base64. Už se těším na Oracle MjA=, který bude tohle API používat :)
BTW dalším krokem může být nahrazení OpenGL pomocí command line utilit. Potřebujete vykreslit trojúhelník? Prostě zavoláte utilitu, protože je to API ;)
-
Cli program je urcen predevsim k pouzivani. Jakym zpusobem a kde bude volana, je program samotnemu burt a muze byt putna i autorovy. Zalezi vzdy na tom, kdo ji chce pouzit ;)
To mate uplne jedno jak je API, ci jeho soucasti implementovano :) Dulezite je ze ma jasne definovene vstupy, vystupy a co ma delat. Dokonce je naprosto jedno jakeho datoveho typu jsou parametry, nebo vystup. Je dulezite aby jste to mohl v aplikaci pouzit. Implementace a forma samotna je naprost vedlejsi zalezitost. Zapomente na predstavy z drevnich widlo-dob. Zalezi jen na tom z jake urovne abstrakce na to pohlizite ;)
Pokud odstranite operace nad soubory nebudete schopen vytvorit ty 'utility'. API ma totiz takovou blbou vlastnost a to tu, ze se vrstvi. tak ku prikladu v Jazyce LUA uprednostnuji vyuziti napriklad programu ls pred modulem LFS (Lua File System), nebo abych se s tim nejak patlal jinak. Dostanu stejna data a jeste navic jsou pekne naformatovana (ci filtrovana) tak jak potrebuji k tomu abych je mohl pohodlne zpracovat a mam to hlavne bezbolestne. Navic externi LUA moduly se dost blbe pouzivaji pokud vyuzivate Lua interpreter jako primou soucast nejakeho programu. Takze je jednodusi zavolat program (existuje-li) ktery danou funkcnost poskytne. Je to jednoduche.
A co treba kdyz potrebuji zpracovavat informace z balickovaciho systemu (dpkg)? Jsou dve moznosti bud budu zpracovavat soubory s daty dpkg a delat si vse sam - cimz ho vlastne obejdu, coz samozrejme neni zadouci. Nebo pouziji proste cli-tools, ktere jsou k dispozici. A v tomto pripade se ty programy stavaji proste API k danemu systemu. Bez ohledu na to jak jsou reseny. (Osobne zrovna v tomhle ohledu volim kombinovanou metodu. Informace o baliccich si vetsinou beru ze seznamu a manipuluji s nimi prostrednictvim cli-tools)
No a posledni vec: Kdyz vytvarite nejakou vrstvu, mate mnoho moznosti, jak ji implementovat. Ano urcite by se nasel nekdo, kdo by treba mohl OpenGl implementovat pomoci cli. Ale... je to vhodna implementace? Tahle otazka vsak nijak nepopira to, ze cli aplikace mohou byt API (nebo soucasti API) k nejakemu konkretnimu celku ;)
Uz dlouho se zabyvam otazkou univeralni desktopove vrstvy pro Linuxove systemy (uz jen proto ze mi na tom vazne WMC). Donedavna jsem si rikal, ze nejvhodnejsi interface pro jeho kompozici do aplikaci bude knihovna. Posledni dobou zacinam z urcitych duvodu menit nazor a zahravam si s myslenkou vyzlouset pro toto system client-server. Mozna rovnou technologii D-BUS.
-
Lael Ophir (neregistrovaný)
Ad ku prikladu v Jazyce LUA uprednostnuji vyuziti napriklad programu ls pred modulem LFS (Lua File System), nebo abych se s tim nejak patlal jinak - aha. Je to sice pomalé a nefunguje to jinde než na Unixu, ale jinak fakt super nápad :)
Ad co treba kdyz potrebuji zpracovavat informace z balickovaciho systemu (dpkg)? - ve Windows prostě použijete API. Na Linuxu opět API chybí. Hrabat přímo do konfigurace se vám nejspíš vymstí, protože každé distro může mít jiný packager (nemluvě o dalších Unixech), a v příští verzi distra může být konfigurace packageru úplně jinde, nebo úplně jiná. To co děláte je ukázková bad practice.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa372463(v=vs.85).aspxAd Pokud odstranite operace nad soubory nebudete schopen vytvorit ty 'utility'. API ma totiz takovou blbou vlastnost a to tu, ze se vrstvi - chyba. Jak myslíte že fungují utility pro system management jako je například swapon nebo ifconfig? Používají nějaké API, typicky syscall. Jde o interní interface který není popsaný v POSIXu, Single UNIX Specification ani LSB. Pak existují i utility které modifikují nějaké soubory podle nepopsaných pravidel apod. Každopádně pokud byste chtěl přístup k souborům řešit pomocí utilit, tak ty by mohly například používat nedokumentované syscalls.
Jinak váš příspěvek je pěkný, ale z command line utility tím API neuděláte. Přečtěte si Single UNIX Specification. Jsou tam kapitoly System Interfaces (tj. APIs) a Shell & Utilities, protože pánové vědí co je API a co je utilita.
-
Ad Lua:
Pane Ophir delal jste nekdy neco v jazyce Lua, nez Hello World? Tak mi tedy, dejte prosim, ukazku jak ve skriptu, v ciste Lue budete volat prime WinApi (bez prime podpory volajiciho - cista Lua). Rad se necham poucit. :-D A propo - i kdyby jste s necim prisel, chcete mi tvrdit, ze volani WinApi je portabilni na jine systemy? Treba Linux?Ad ls:
Je to dostatecne rychle pro pro zpracovani ve skriptu. Nemluve o faktu ze spoustu veci urychli spravny vyber argumentu, tak, aby jste rovnou zpracoval pouze vystup. Nemusite se starat o samotne cteni (prochazeni) FS struktury. Coz v pripade modulu LFS nebo nizkourovnoveho API delat musite.Ad dpkg:
Pane Ophir, vy si plete konfiguraci programu s vstupnimi/vystupnimi daty, ktere ma zpracovat! No jestli takhle to berete v M$, chapu proc jsou jejich dila takova katastrofa. Seznami baliku jsou prave takova data (v podstate cache, i kdyz v pripade dpgkg, se timto slovem oznacuje neco trochu jineho). Stejne data muzete samozrejme ziskat zavolanim odpovidajici cli aplikace. ovsem na rozdil od ls, kde kde pracujete (vetsinou) max jen s par kb ve vystupu, muze velikost dat u balickovaciho systemu vylitnout do deitek kb mozna i vic, v pripade ze chcete podrobne informace o vetsim mnozstvi balicku. Typicky, kdyz vyhledavate podle nejakeho patternu, ci skupinu (treba podle tagu) , nebo z konkretnich repositaru, autora, atd... Nemluve o tom, ze se s nimi delaji dalsi operace. Proto - presne podle pravidla vhodnosti, o nemz jsem vam psal drive - je vyhodnejsi si ty nadat nacist primo, ze seouboru a zpracovat primo. Vsimnete si, ze pisu o nacteni, nikoliv o zapisu. nemohu tedy balickovaci system nijak ovlivnit.ad Windows instaler) - LOL! dpkg a vindows instaler je nebe a dudy!!!! :-D
ad io )
jednak je uplne jedno jak mate io operaci v aplikaci definou, porad ji tam musite mit a musite ji delat pres rozhrani jadra. Nedokumentovane volani (obecne) jsou v pripade Linuxu naprosta pitomost, protoze jich lze vzdy dohledat, alespon ve zdrojacich. Postradfaji tedy naprosto smysl. A i kdyby, byl jste to vy sam (nebusu to hledat - najdete si to, urcite vite co nam tu tvrdite), kdo nam tu tvrdil, ze jak jsou aplikace a volani implementovana nemusi uzivatele/programtora zajimat. Tudiz mi muze byt presne dle vasich slov byt uplne putna, jestli (ne)vola dukumentovane, nedokumentovane, posvedcene, ci jakekoliv jine syscally. Dulezite je, ze ma definovane vstup, vystup a proces. ;)"Jsou tam kapitoly System Interfaces (tj. APIs) a Shell & Utilities, protože pánové vědí co je API a co je utilita."
Premyslim jestli se to da rici i Vas. A nejen v teto souvislosti. ;) -
Lael Ophir (neregistrovaný)
Ad Lua... jak ve skriptu, v ciste Lue budete volat prime WinApi - a jak budete volat Win32 API přímo v Javě? Asi dost špatně. Co z toho plyne? Vůbec nic.
Ad chcete mi tvrdit, ze volani WinApi je portabilni na jine systemy - Win32 je k dispozici na Windows, a existuje pár dalších nekompletních implementací. Cocoa je k dispozici na MacOS X, a existuje pár dalších nekompletních implementací. API Linuxu bohužel není moc definované. Vychází z POSIXu, ale některé věci jsou specifické pro Linux.
Ad Lua, dostatecne rychle pro pro zpracovani ve skriptu, Nemusite se starat o samotne cteni (prochazeni) FS struktury - pokud Lua nemá moduly které by řešily požadavky na procházení souborů/adresářů, tak je to problém Lua. Kupodivu v .NETu, Javě apod. nemusí nikdo provádět shell out, aby získal seznam souborů v adresáři.
Ad dkpg, je vyhodnejsi si ty nadat nacist primo, ze seouboru a zpracovat primo. Vsimnete si, ze pisu o nacteni, nikoliv o zapisu - to je pěkné, ale nic to nemění na faktu, že v příští verzi dpkg (nebo v jiném distru) může být všechno jinak, a váš kód nebude fungovat. Předpokládám že takové detaily vás netrápí.
Ad dpkg a vindows instaler je nebe a dudy - ano, Windows Installer má API.
Ad Nedokumentovane volani (obecne) jsou v pripade Linuxu naprosta pitomost, protoze jich lze vzdy dohledat - nedokumentovaný interface se může bez varování v příští verzi měnit. To je jeho vlasnost.
Ad jak jsou aplikace a volani implementovana nemusi uzivatele/programtora zajimat. Tudiz mi muze byt presne dle vasich slov byt uplne putna, jestli (ne)vola dukumentovane, nedokumentovane, posvedcene, ci jakekoliv jine syscally. Dulezite je, ze ma definovane vstup, vystup a proces - souhlas. Problém je v tom, že na Linuxu pro řadu triviálních akcí neexistuje dokumentované API. Jestli command line utilita použije černou magii nebo nedokumentované volání, to je mi celkem jedno.
Ad protože pánové vědí co je API a co je utilita; Premyslim jestli se to da rici i Vas - vy jste zatím předvedl, že vám ten rozdíl není jasný.
-
BobTheBuilderStříbrný podporovatelTohle jsem naposledy řešil u dokumentu v Office 97 - byl vytvořený v anglické verzi a v české nešel otevřít nijak (havárie). OOo pomohlo. To je obecně problém s .doc soubory - jsou tam bloby a žádné kontroly. docx je na tom podstatně líp (poškození samotného dokumentu se pozná - je to ve skutečnosti ZIP).
-
Max Devaine (neregistrovaný)
Jestli to třeba nebude security nastavením v MS Office? Oni mají totiž takovou super fci, která brání otevírat soubory s příznakem stažení z internetu.
Funkce je to poněkud dementní, protože tě neupozorní na to, že je problém se zabezpečením, ale vyhodí info o poškozeném souboru / nemožnosti otevřít soubor.
Otázkou tedy je, zda tvá zkušenost pramení z neznalosti (přeuložením souboru jsi mu změnil příznak, proto najednou šel v MS Office), nebo zda byl soubor skutečně poškozen?
To už se ale asi nedozvíme.
Osobně mám v jobu Ms Office v těchto verzích : 2003, 2007, 2010, 2013, 2016 a když se vyskytl nějaký problém s otevřením, bylo to vždy v security nastavení MS Office u konkrétního uživatele.
Zdar Max -
qwerrtz (neregistrovaný)
Opakovana zkusenost. Dokument vytvoren v MS Oppice Verze X. Vsem normalne funguje. Jednoho dne dostane jeden uzivatel novy PC a verze MS Oppice X+1. dokument je najednou rozsypany. Vsem ostatnim stale funguje. Reseni? Otevrit v LO (drive OO) preulozit do verze X+1 a novy uzivatel si ho otevre. Obcas uz ho ale neotevrou ostatni s puvodni verzi MS Oppice, i kdyz maji nainstalovan MS Oppice compatibility pack (nebo jak se to jmenuje).
Vyzkouseno X krat za poslednich 10 let mezi ruznyma MS oppicema.
-
Lael Ophir (neregistrovaný)
To ale může mít dlouhou řadu příčin, včetně poškození souboru. To že je možné poškozený soubor otevřít v jedné verzi ještě neznamená, že to půjde i v jiné verzi. A mimochodem problém může být i s dokumenty MS Office vytvořenými nebo editovanými v OpenOffice/LibreOffice.
Jinak řešením typicky bývá právě ten Open w Repair.Každopádně co mě zajímalo je konkrétní reprodukovatelný postup, jak v office verze X uložit soubor tak, aby v office verze X+1 otevřít nešel.
-
"Každopádně co mě zajímalo je konkrétní reprodukovatelný postup, jak v office verze X uložit soubor tak, aby v office verze X+1 otevřít nešel."
Uprime - nevim. Ale co vim, ze proste obcas se stane, dokumenty vytvorene v M$ Office proste M$ Office neotevrou. Jaky konkretni duvod, ci postup k tomu vede me osobne (a vetsinu dalsich uzivatelu) nezajima.
Spis me prijde k smichu zpusob jakym se to da napravit:
Takze podle vas, kdyz mi selze loading dokumentu, musim znovu do nabidky a vybrat si volbu "opravit a nacist"? A proc to neudela ten program rovnou pri nacitani? Nebo M$ neumi detekovat vyjimky? (No vzhledem ke zkusenostem se software z jejich dilen to nikoho asi moc neprekvapi) To se pak nedivim, ze hodne lidi proste potom nevi co s tim maji delat. Hmmm.... Ten ing. ktery tuhle funkci zapracoval do M$ Office by si zaslouzil titul "Tydyt roku" ;) -
Lael Ophir (neregistrovaný)
Ad proste obcas se stane, dokumenty vytvorene v M$ Office proste M$ Office neotevřou - viděl jsem takové dokumenty, a typicky se mi nepodařilo zjistit důvod. Někdy v hex view byly vidět názvy fontů z OpenOffice, takže pak bych věděl :). Jindy dokument v hex view vypadal jako že vůbec není ve formátu MS Office, a prostě jsem z něj nic nedostal. Ve většině případů ale pomohl repair. Pracovní hypotéza je ta že šlo o dokumenty, které se nějak poškodily. Může to být chyba paměti (překvapivě častý problém), pád aplikace během zápisu apod.
Ad kdyz mi selze loading dokumentu, musim znovu do nabidky a vybrat si volbu "opravit a nacist" - v některých případech se repair provádí automaticky, ale netuším za jakých okolností. Jinak minimálně u binárních formátů nejsou tyhle problémy nijak výjimečné. Viděl jsem například dokumenty ve WordPerfectu, které způsobovaly okamžitý pár aplikace, případně pád aplikace při zobrazení konkrétní části dokumentu. WordPerfect tehdy pokud si vzpomínám neměl repair option, takže jediným řešením bylo otevřít dokument ve Wordu a znovu ho uložit.
-
"v některých případech se repair provádí automaticky, ale netuším za jakých okolností."
Vidite, ja take ne a myslim ze vetsina dalsich uzivatelu teke;) No a tom je.
Je naprosto jedno, z jakeho duvodu a proc k tomu dojde a je take naprosto jedno jestli k tomu dochazi u konkurecnich produktu. Faktem je, ze pokud aplikaci selze nejake operace (a nejde rovnou do kytek - to je jiny pripad) mela by na to adekvatne zareagovat. V tomto konkretnim pripade minimane vyflusnout dialogove okno, ktere uzivatele alespon heslovite obeznami se situaci a rovnou jej nasmeruje na mozne reseni. Ci rovnou zavolat operaci, ktera se skryva pod nabidkou "opravit a otevrit" a necekat az ze to "mozna" uzivatel zvladne sam. To ze to nekdy (a nikdo vlastne nevi kdy) dela sam to moc kredit vyvojaru M$ Office nevylepsi - spis naopak ;)
-
"v některých případech se repair provádí automaticky, ale netuším za jakých okolností."
Vidite, ja take ne a myslim ze vetsina dalsich uzivatelu teke;) No a tom je.
Tak byvaly doby, kdy Word pri pokusu o otevreni poskozeneho dokumentu reagoval tim, ze spadl rychlosti svetla. Pokud k tomu jiz nedochazi alespon obcas, je to vyrazny pokrok.
-
Lael Ophir (neregistrovaný)
U XML formátů by to s tím repairem mělo fungovat o něco lépe. Možná později zkusím.
Ad byvaly doby, kdy Word pri pokusu o otevreni poskozeneho dokumentu reagoval tim, ze spadl rychlosti svetla - když se podíváte jak fungují binární formáty, a zkusíte si napsat v C++ aplikaci která ukládá nějaký netriviální dokument nebo netriviální nastavení, tak to není až zase takové překvapení.
-
když se podíváte jak fungují binární formáty, a zkusíte si napsat v C++ aplikaci která ukládá nějaký netriviální dokument nebo netriviální nastavení, tak to není až zase takové překvapení.
Nevim, jak vas, ale me docela prekvapuje, ze multimiliardova firma neumi odchytit vyjimku a misto padu zobrazit hlasku, ze se soubor posral. Jestli se dobre pamatuju, muzete mit ve Wordu otevreno nekolik souboru. Takze padem take uzivatele pripravite o nezasejvovanou praci. Tohle neokecate, takove hovadiny se daji tolerovat leda nejake garazovce z doby programu na ZX Spectru, kde se casto setrilo kazdym bajtem.
-
Lael Ophir (neregistrovaný)
Ad multimiliardova firma neumi odchytit vyjimku a misto padu zobrazit hlasku, ze se soubor posral - OK, zobrazíte výjimku, a pak co? Pokud máte aplikaci v neznámém stavu, tak je často lepší ji prostě ukončit, než zkoušet pokračovat.
Ad uzivatele pripravite o nezasejvovanou praci - to řeší AutoRecover, možná vyjma posledních pár minut práce.
-
Ad multimiliardova firma neumi odchytit vyjimku a misto padu zobrazit hlasku, ze se soubor posral - OK, zobrazíte výjimku, a pak co? Pokud máte aplikaci v neznámém stavu, tak je často lepší ji prostě ukončit, než zkoušet pokračovat.
Ad uzivatele pripravite o nezasejvovanou praci - to řeší AutoRecover, možná vyjma posledních pár minut práce.
Aha. A proc jsou aplikace MS po pokusu o otevreni souboru v neznamem stavu? A proc kvuli tomu mam dela recovery tech nekolika souboru, na kterych jsem delal predtim? Pricemz recovery zachyti jen zmeny, ktere se udaly pred poslednim autosave. Mel bych jit na kafe vzdy, kdyz chci otevrit soubor, abych mel jistotu, ze probehl autosave? A proc treba GIMP nespadne, kdyz chci otevrit poskozeny obrazek, ale jednoduse zobrazi hlasku, ze je obrazek nabourany a nejde otevrit?
-
Aha. A proc jsou aplikace MS po pokusu o otevreni souboru v neznamem stavu?
Začínám mít pocit, že toto není ten původní LO. Toto už je nejméně podruhé v této diskusi, kdy připustil nějaký problém. Poprvé ten registr vozidel (triviální číselníková aplikace pro pouhých 10M lidí a 7.5M aut) a 250 klientů.
Podruhé je aplikace po načtení vlastního formátu v neznámém stavu...
Chceme zpět původního LO, tady ten nějak ztratil na síle.
-
Lael Ophir (neregistrovaný)
Ad proc jsou aplikace MS po pokusu o otevreni souboru v neznamem stavu - protože otevření souboru jaksi z definice výrazně mění interní stav aplikace. Pokud dojde k výjimce, tak se něco nepovedlo. Pro programátora může být opravdu složité zajistit, aby aplikaci znovu dostal do konzistentního stavu. Už tu někdo uváděl, že třeba Oracle také s klidem spadne při špatných vstupních datech. Důvod je prakticky stejný.
Ad recovery zachyti jen zmeny, ktere se udaly pred poslednim autosave. Mel bych jit na kafe vzdy, kdyz chci otevrit soubor, abych mel jistotu, ze probehl autosave - jak často vám Word padá při otevření souboru? U mě to bylo před cca 5-10 lety. Ano, přišel jsem o změny za posledních pár minut, ale pokud se mi taková "tragédie" stane jednou za 5-10 let, tak to skousnu :)
Ad proc treba GIMP nespadne, kdyz chci otevrit poskozeny obrazek - pokud se poškození obrázku správně "strefí" do něčeho co Gimp neřeší, tak vám spadne také. Jenže obrázek je oproti dokumentu MS Wordu dosti triviální datová struktura, takže se dá daleko snáz ověřit, jestli je v pořádku.
-
Petr M (neregistrovaný)
Ne, nemění se stav aplikace. Jenom se načte další modul. Alokuje paměť, vytvoří se v ní objekt pro zpracování streamu a načte se stream z externího zdroje.
Pokud se načítá stream z externího zdroje, jsou třeba dva kroky - validace a parsování. Pokud se jeden z nich nepovede, aplikace nesmí zhavarovat.
Maximální přijatelná škoda je, že se v try/finally zruší příslušný objekt a vrátí se paměť s výpisem hlášení o příčině problému. Za předpokladu, že selže automatická oprava.
Je blbě, když něco, kde je otevřených 10 souborů, kvůli jednomu z nich padne úplně. To můžeš rovnou vypnout celý okres proto, že na jednom úseku VN spadla větev a nějaký idiot nenamontoval pro tu konkrétní větev úsečník. Prostě to děláte blbě.
-
Lael Ophir (neregistrovaný)
Jak jsem už psal: kdyby to bylo tak jednoduché, tak nemá celý obor IT už desítky let problém třeba s buffer overflow :). A jak jsem také psal, validace souborů při otevírání se v MS Office výrazně zlepšila, a Jarda popisuje zkušenosti z devadesátých let, kdy bylo IT ve fázi dinosaurů, a SW se díky omezení na straně CPU i paměti psal trochu jinak než dnes.
-
j (neregistrovaný)
"kdyby to bylo tak jednoduché"
To je zajimavy, ze to zjevne je tak slozity vyhradne a pouze pro M$, protoze zadny jiny aplikace nepadaj kvuli pokusu o otevreni neceho, co otevrit neumej. Ale vono se neni co divit ... ve firme, ktera preklada vzorce ... takze se pak neda tabulka otevrit v jiny jazykovy variante ... pripadne ve firme, ktera pro widle neni schopna pouzivat jazykovej balik, takze kdyz chce korporace jinej jazyk, potrebuje jinou verzi widli ... pripadne pro firmu, ktera neni schopna zalogovat ze system pad nahubu, ale zato loguje kazdou nepodstatnou hovadinu, pricezm u 90% chyb uvadi "tohle hlaseni muzete ignorovat". lol.
-
Lael Ophir (neregistrovaný)
Ad zadny jiny aplikace nepadaj kvuli pokusu o otevreni neceho, co otevrit neumej - ale nesmysl. Už tu dvakrát padl jako příklad Oracle, který s klidem spadne na poškozeném DB souboru. Je to problém prakticky každé složitější aplikace.
Ad firme, ktera preklada vzorce ... takze se pak neda tabulka otevrit v jiny jazykovy variante - vymýšlíte si. Excel ukládá jména funkcí v angličtině, a v místním jazyce je jen ukazuje uživateli. Můžete si to zkusit. Pokud jste někdy narazil na funkci s cizojazyčným názvem která nefungovala, tak to nejspíš bylo makro, které v dokumentu nebylo vložené. Úplně laicky: vložte do dokumentu v českém Excelu makro SpocitejCenu a použijte ho na sheetu. Pak to uložte bez maker, a pošlete německému kolegovi. Pochopitelně uvidí "rozbitou" funkci SpocitejCenu, akorát to není funkce, ale chybějící makro. Tohle je jediný způsob, jak můžete docílit iluze, že se názvy funkcí ukládají lokalizované.
Ad pro widle neni schopna pouzivat jazykovej balik, takze kdyz chce korporace jinej jazyk, potrebuje jinou verzi widli - vymýšlíte si, language packy jsou běžně ke stažení.
https://support.microsoft.com/en-us/help/14236/language-packsAd neni schopna zalogovat ze system pad nahubu - to záleží jak "pad na hubu". Běžně se pořizuje minidump a je hláška v Event Logu. Pochopitelně pokud systém havaruje dostatečně drsně (například odpadne i FS nebo driver diskového řadiče), tak už nic nezapíše.
Ad loguje kazdou nepodstatnou hovadinu, pricezm u 90% chyb uvadi "tohle hlaseni muzete ignorovat" - zkuste si někdy spustit GUI aplikaci na Linuxu z command line. Ty hlášky lezoucí do terminálu vás asi dost překvapí.
-
To je zajimavy, ze to zjevne je tak slozity vyhradne a pouze pro M$, protoze zadny jiny aplikace nepadaj kvuli pokusu o otevreni neceho, co otevrit neumej.
To budou ty dinosauri. Jak okolo dusa Ballmer a podobni, tak se pri tech otresech a revu neda premyslet.
Ale vono se neni co divit ... ve firme, ktera preklada vzorce
Oni kreteni prekladaji cely Visual Basic, co maji pribaleny k Exelu. Uz jsi videl VisualBasic francouzsky? A kdyz takove makro prijde do anglickeho Exelu, tak ten se z toho posere. Asi se to musi prohnat pres Google Translate.
-
Lael Ophir (neregistrovaný)
Ad kreteni prekladaji cely Visual Basic, co maji pribaleny k Exelu. Uz jsi videl VisualBasic francouzsky? A kdyz takove makro prijde do anglickeho Exelu, tak ten se z toho posere - tak na prvním místě se VBA kompiluje do p-code. Na druhém místě jsem fakt francouzský VBA neviděl. Vy ano? Vizte screenshot. Samozřejmě jména proměnných a funkcí můžete mít třeba litevská, ale vlastní jazyk lokalizovaný není. To můžu potvrdit u Excelu 97 a novějšího, ve starších jsem VBA nepoužíval.
http://joel.garbe.perso.sfr.fr/ImagesLogiciels/MacroVBAExcel2007.jpg -
Na druhém místě jsem fakt francouzský VBA neviděl. Vy ano? Vizte screenshot. Samozřejmě jména proměnných a funkcí můžete mít třeba litevská, ale vlastní jazyk lokalizovaný není. To můžu potvrdit u Excelu 97 a novějšího, ve starších jsem VBA nepoužíval.
To bude patrne tim, ze uz i v MS pochopili, ze slapli do opravdu velkeho hovna. Francouzsky Exel s francouzskym Visual Basicem jsem videl na vlastni oci na vlastnim pocitaci. Chtel po mne jeden starik, abych mu zbastlil nebo upravil makro na jeho strasne ucetnictvi v Exelu. On mel tusim anglickou verzi, kterou ja nemel. Valela se mi doma nejaka CD, tak jsem vzal francounzskou verzi a misto select nebo selection nebo jak se to, to chtelo selectioner nebo tak nejak a podobne ostatni klicova slova. Nastesti jsem pak vystrachal verzi ceskou, ktera to mela normalne anglicky.
Netusim, co by se stalo, kdybych to makro prenesl na jinou jazykovou verzi i se souborem, nepamatuju se, jestli jsem to zkousel, je to uz snad 20 let. Ale pamatuju, ze u nej to makro nechodilo, protoze mel jinou verzi Exelu a musel jsem tam na miste jeste neco predelat. V tom jeho Exelu se to, co mi doma chodilo, chovalo jinak.
-
Lael Ophir (neregistrovaný)
Já vím že Francouzi mají svoje "špecifiká". Patří mezi ně anglofobie a snaha všechno za každou cenu lokalizovat. Například v češtině máme ve Wordu na toolbaru (nebo ribbonu) B jako bold, I jako italic a U jako underline; zkratkové klávesy jsou Ctrl+B, Ctrl+I a Ctrl+U. Frantíci nejen že mají G asi jako guillotine, I jako zřejmě inapproprié a S nejspíš jako saboteur, ale mají i zkratkové klávesy Ctrl+G, Ctrl+I a Ctrl+S.
http://www.cnetfrance.fr/i/edit/fo/2013/02/word-pdf-2.pngNašel jsem něco o francouzské verzi Excelu 95, který prý měl mít přeložený i VBA, ale nepodařilo se mi to potvrdit. Český Excel 97 určitě nic takového neměl. Pokud pro frantíky lokalizovali VBA, tak by mě zajímalo, jestli to tehdy bylo kompilované do p-code.
Lokalizovat makro jazyk sice může dneska působit fakt zvláštně. Ale v devadesátých letech byla lokalizace (a globalizace) SW teprve novinkou, což by mohla být částečná omluva pro takovou zběsilost.
-
Našel jsem něco o francouzské verzi Excelu 95, který prý měl mít přeložený i VBA, ale nepodařilo se mi to potvrdit. Český Excel 97 určitě nic takového neměl. Pokud pro frantíky lokalizovali VBA, tak by mě zajímalo, jestli to tehdy bylo kompilované do p-code.
Mozna to CD jeste nekde mam. Jestli se premuzu, muzu zkusit z toho vykuchat help. Treba tam jsou nejake priklady pro pobaveni.
-
Lael Ophir (neregistrovaný)
Jak říkám: obrázek je poměrně jednoduchá datová struktura, takže se lépe validuje.
Ad Word mi spadl. Ano, take tak pred vice, jak 10 lety. Tak dlouho ho totiz uz vubec nepouzivam - no vidíte, a já Word používám každý den, a také mi spadl při otevírání souboru naposledy přes cca 5-10 lety. Takže jsme vlastně oba šťastní :)
-
j (neregistrovaný)
To je zajimavy lulane, ze web neni jic jinyho nez zcela obecna zmet tagu. Kazdej si tam muze napsat co chce a jak chce, a prekvapko ... browsery NEPADAJ. Tak maximalne kdyz je to vazne uz hodne zmrveny zobrazej hlasku, ze tohle nezobrazej. Jo a jen tak mimochodem, soucasti html klidne muze bejt i binarni soubor. Prekvapko co?
-
Lael Ophir (neregistrovaný)
Typicky máte nějakou C++ struct, do které nacpete to co bylo na disku. Pokud je v datech problém, tak vám aplikace může při dalším běhu sletět. Samozřejmě můžete napsat validaci, ale je to dost práce, a těžko vychytáte všechno. Kdyby šlo snadno vychytat všechno, neměl by celý obor IT už desítky let problémy třeba s buffer overflow :)
MS ty validace postupně vylepšuje, takže dneska shodíte Word špatnými daty opravdu velmi vzácně. Jenže Jarda popisuje zkušenosti z devadesátých let, když se ještě v oboru IT proháněli dinosauři :)
-
MS ty validace postupně vylepšuje, takže dneska shodíte Word špatnými daty opravdu velmi vzácně. Jenže Jarda popisuje zkušenosti z devadesátých let, když se ještě v oboru IT proháněli dinosauři :)
Temi dinosaury asi narazite na Ballmera, ktery se jim nejvice podoba. Ale nemela ta validace byt jaksi jednou ze zakladnich veci navrhu? Ne, ze by MS byl jediny, kdo na to dlabe. Ale treba soudruzi bastliri z Garminu se aspon mohou vymlouvat na omezene systemove zdroje GPS. Na Widlich tezko, kdyz prece 640 kB by melo stacit kazdemu.
-
Ivan (neregistrovaný)
Ten format je poplatny dobe kdy vzniknul. Setrilo se pameti i diskovymi operacemi. Navic ten format ma za sebou monoho let historie. Myslim, ze si v MS oddychli, kdyz presli na novy format.
PS: on i Oracle dokaze segfaultovat po restartu behem media recovery, a tak jde o uplne jine penize.
-
Navic ten format ma za sebou monoho let historie. Myslim, ze si v MS oddychli, kdyz presli na novy format.
Toz to nevim, ale MS se na prechod na novy format vubec nechystal. Stary jim vyhovoval, neni na dobry vendor lock-in, ktery se obcas posili nejakymi nedokumentovanymi zmenami, coz zaroven nuti uzivatele k upgradu Oppice.
MS na novy format presel z donuceni, aby mu neujel vlak kdyz se poruznu schvalovaly otevrene formaty pro pouziti ve statnich spravach. Podle toho ten MS format take vypada. 6000 stranek prasaren, ze kterych dodnes chudaci vyvojari sili. A podle toho take vypadal ten schvalovaci proces, ktery byl uskutecnen pomoci najatych schvalovacu z rozvojovych zemi, kteri se vickrat v ECMA neukazali, cimz je cela instituce paralyzovana, protoze k zadnemu hlasovani se nedostavi potrebny pocet clenu.
-
Lael Ophir (neregistrovaný)
Ad MS se na prechod na novy format vubec nechystal - Excel měl XML formát od roku 2000, Word od roku 2002. Standardizace ODF začala v roce 2001.
Jinak XML formáty mají svoje výhody, ale i nevýhody. Například když máte 400-stránkový dokument a připíšete v půlce dvě slova, tak u binárního formátu můžete snadno připsat změnu na konec souboru. U zipovaného XML musíte celý dokument znovu serializovat do XML a zazipovat, což je výrazně delší operace. Podobně otevírání velkých souborů je ve srovnání s binárním formátem výrazně pomalejší, protože je prostě potřeba to veliké XML parsovat.
-
Lael Ophir (neregistrovaný)
Jde to, ale dře to. Nevím jak to má dneska LibreOffice, ale u OpenOffice svého času uživatelé popisovali, že otevírání a ukládání velkých spreadsheetů bylo na minuty. Samozřejmě se to dá optimalizovat (například MS Office je poměrně rychlý a navíc ukládá soubory na pozadí), ale výsledek bude nutně vždycky horší než u binárního formátu. XML je stejně nakonec character soup nečitelná pro člověka, je velkou otázkou, jestli přínos XML formátů (navíc zazipovaných dohromady s ne-XML obsahem, takže odpadají výhody XML) převažuje jejich nevýhody. Je to otázka k zamyšlení, i když odpověď nakonec může být "ano".
-
Jde to, ale dře to. Nevím jak to má dneska LibreOffice, ale u OpenOffice svého času uživatelé popisovali, že otevírání a ukládání velkých spreadsheetů bylo na minuty.
No, jestli minuty, tak to musela byt opravdu stara plecka a asi do toho pocitali i start LO/OO. LO/OO jsou dost pomale, ale zas tolik tragicke to nei. Co ale dost zpomaluje, je kdyz se to pri loadu musi konvertovat z MS formatu. To pak by ty minuty byly mozne.
-
Lael Ophir (neregistrovaný)
Ne úplně jako log. Text dokumentu je sekvence fragmentů zvaných text run, a nový text run můžete prostě připsat. V případě OOXML je tenhle koncept zachovaný (nevím jak je to s umístěním v souboru, u XML si to těžko představit), jenže vám to moc nepomůže, protože výsledek musíte zazipovat. V případě ODF je tuším dokument podobnější HTML, řekněme plochý.
-
Excel měl XML formát od roku 2000, Word od roku 2002. Standardizace ODF začala v roce 2001.
To je mozne. Patrne dalsi nedokumentovana prasarna od MS, nikoliv OOXML. Ten byl ke standardizaci predlozen r. 2006. ECMA je s tuim vyhodila a museli to predelat. Ke schvaleni doslo r. 2008. Od te doby jiz byly dalsi dve iterace.
-
Lael Ophir (neregistrovaný)
Nebudu hledat specifikaci 16 let starého formátu :), ale popis "nedokumentovana prasarna" bych osobně uplatnil na ODF, které bylo v prvních verzích plné frází "The value of this attribute is implementation specific". Není podle vás nedokumentovaná prasárna uvést formát pro spreadsheety, který přesně touhle frází popisuje vzorce?
Ad Ten byl ke standardizaci predlozen r. 2006. ECMA je s tuim vyhodila a museli to predelat. Ke schvaleni doslo r. 2008. Od te doby jiz byly dalsi dve iterace - nevím jestli s tím ECMA někoho vyhodila, ale práce na standardu je obecně iterační. To že MS vydal další verze specifikace OOXML je přece správně, formát se vyvíjí. Nakonec i ODF má od uvedení dvě nové verze. Za 8.5 roku dokonce ve standardu přibyl i ten popis vzorců ve spreadsheetech. V příští verzi se možná dočkáme i použitelné verze funkce sledování změn, jak jí má implementovanou tuším už Word 95.
-
NULL (neregistrovaný)
Napsal jsem 2 diplomové práce, jednu ve Wordu a jednu v LO a zodpovědně zde prohlašuji, že debilní jsou oba stejně.
Na tenký led se člověk dostává, pokud musí otvírat to samé dílo v obou. Trochu pomohlo schválení ODF evropskou unií, takže se ty mrdky z MS nemohou vymlouvat jenom na ostatní, přičemž co nová verze wordu, to nové specifikace pro ukládání a transfer dat, rovnice z LO otevřeš v dalších programech, ty jejich nikde. Klasické výjeby jak s XML. Ono se to toho vlastně taky trochu týká.
