Názory k článku Vifm: správce souboru á la Vim

Problémy s dlouhými názvy souborů, problémy s češtinou, problémy s terminály, a aplikace typu vi - to je vlastně stručný problém nectností unixů z pohledu uživatele. Naštěstí svět nejsou jen unixy.

Zajímavé, žádných problémů s dlouhými názvy souborů jsem si nevšiml - kromě CD vypálených na Unixu, která na Windows mají jen krátké názvy, protože Windows neumí Rock Ridge a do Joliet se ty skutečně dlouhé názvy jaksi nevešly. A Vim si můžete koneckonců stáhnout i pro Windows - třeba programátoři v Microsoftu, kteří používají GVim, ho určitě nepoužívají v Linuxu. ;-)

Jestli máte tyhle problémy, tak si nedělejte nic z toho, že si neumíte poradit, a prostě nepoužívejte Unix. Naštěstí pro Vás existují i Windows.

Zato já si všiml řady problémů. Například mezery v názvech řada skriptů nezpracuje, protože autoři s mezerami nepočítali (nedodělek). Podobně s češtinou v názvech souborů, která působí tolik problémů, že jí uživatelé unixů raději nepoužívají. A sám můžete vidět, že řada uživatelů unixů dodnes píše příspvěky a maily bez diakritiky (což s FS pravda nemá mnoho společného).

Takže ano, i já mám tyhle problémy. Ani já nemůžu nainstalovat Oracle do adresáře "oracle 10i", a dokonce ani v Oracle sqlplus použít příkaz spool "my file.txt", nebo dokonce "můj soubor.txt". Windows sice podobné problémy nemají, ale Oracle na Windows (coby port z unixu) bohužel ano.

Děláte, jako kdyby programátoři MS pracovali v GVimu. V MS možná existuje člověk, užívající *vi (možná dokonce pár lidí), ale zdaleka nejde o běžnou věc. Nakonec jste si mohl všimnout, že MS měl vlastní unix, portoval na unixy nějaký svůj SW (včetně MSIE a WMP), a občas pro unixy něco píše. A kdo je unixem dostatečně infikovaný, musí samozřejmě používat vi (a musí mu to připadat jako skvělý nápad).

Linux má samozrejme editorov hromadu, vrátane tých skvelých GUI ... niekomu vyhovujú viac, niekomu menej, a o tom to je - nútiť každého používať to Jediné A Správne Rozhranie (TM) je absurdné.

Inak je to zvláštne, ale mne napríklad tento 30+ rokov starý editor vyhovuje oveľa viac, a efektivita práce je v ňom pre mňa podstatne vyššia, než v prípade všetkých tých moderných IntelliSense a auto-refactoring a ja-neviem-čo-všetko záležitostí.

Třeba kulaté pneumatiky jsou daleko lepší, než hranaté. Nikdo nikoho nenutí používat Jediné a Správné Kulaté Pneumatiky (TM), ale je poněkud nesmyslné používat ty hranaté.

Pokud vám vyhovuje editor, který nemá nabídku, ve kterém nemůžete udělat věc pro kterou neznáte konkrétní příkaz, a který nemá vizuální odezvu akcí, tak je to opravdu zvláštní. Spíše si myslím, že jste strávil velkou spoustu času a úsilí učením se něčeho naprosto zbytečného, a teď tu investici obhájit. Ve Visual Studiu když najedete myší na proměnnou, tak se vám zobrazí datový typ, IntelliSense vám doplňuje nejen vestavěné prvky jazyka, ale i jména vašich proměnných, tříd a metod, máte k dispozici GUI designer a integrovaný debugger, máte podporu pro makra a doplňky, a ovládání z klávesnice je realizované velmi dobře. Nemyslím, že by práce ve vi mohla být efektivnější, a to ani když strávíte absurdní spoustu času jeho učením. Předpokladem samozřejmě je, že umíte ovládat GUI z klávesnice (například umíte vybírat bloky z klávesnice), a naučíte se pár klávesových zkratek popsaných v menu.

Ty pablb, na rozdiel od teba on asi vie pouzivat obidva editory a dokaze si vybrat ten spravny. Ty o VI nevies vobec a mudrujes tu. To ze si ty nevies nieco predstavit nic neznamena pretoze nemas prehlad.

Tak v tom případě je asi jedině dobře, že Vim má grafický kabátek, nabídky, vizuální odezvu akcí, progamovatelné doplňování kódu, podporu pro makra a doplňky a hlavně velmi dobré ovládání v klávesnice, dokonce natolik dobré, že i někteří lidé v Microsoftu používají ViEmu ("Preventing carpal tunnel syndrome since 2005! :-]). Tohle je obzvláště zajímavé:

While I was at Microsoft, I hardly ever used Visual Studio. I edited my C/C++ code with Vim, I compiled and linked it with the NT Build Environment and I debugged it with WinDbg/ntsd/kd. I was hardly alone in this. In the Windows division, your code has to build with the NT build environment, and the Windows debuggers are much better supported than the Visual Studio debugger for developing the OS.

:-)))

Jestli máte na mysli GVim, tak ten mě také neoslovil.

Hm, jinými slovy bývalý zaměstnanec MS, který je 20 let nadšeným uživatelem vi/vimu, ho údajně používal i v MS, a podle vlastních slov prý nebyl sám. To je jistě pěkné, ale jistě uznáte, že je to stejně o ničem, jako kdyby bývalý zaměstnanec MS napsal, že v MS pil čaj s koňskou močí. Má to totiž podobnou vypovídací hodnotu v tom, jak je či není dobrý koncept UI vi/vimu.

No a jeden Lael Ophir zase kolem dokola tvrdí, že v MS nepracuje, ale že Windows jsou skvělé a my socky bychom si je už taky měli konečně pořídit. To má totiž asi podobnou vypovídací hodnotu v tom, jestli je skutečně potřebujeme nebo ne. :]

Plánujete sa zúčastniť súťaže o najabsurdnejšie prirovnanie ? ;) Prirovnávať Visual Studio k hranatej pneumatike, mno ... ono to VS zas -tak- zlé nie je, s trochou sebazaprenia sa s tým robiť dá ... :)

Viem že ste to asi mysleli opačne, ale proste som neodolal.

Ono vec, ktorú zjavne nie ste schopný pochopiť (alebo sa úmyselne tvárite, že ju nechápete) je, že občas proste existuje viacero možností, ako niečo môže fungovať, nie je tu (našťastie) len Jediný A Správny Prístup Veľkého Billa k Editovaniu Súborov :)

Prečo sa tak dobrovoľne zbavujete vlastného názoru ? Prečo si stále myslíte, že všetko, čo prišlo od jednej konkrétnej firmy, je dokonalé dielo božie o ktorom sa proste nediskutuje, a všetko ostatné je akosi pochybné ? Je to dosť zvláštne. Bolo by zaujímavé vedieť, či tým polopravdám a skresleným faktom, ktoré tak rád používate, fakt veríte, alebo ste motivovaný inak - finančne ? Ale pravdu o tomto mi samozrejme nepoviete.

Veľkú hromadu času som učením sa vi rozhodne nestrávil - vlastne poznám len základy - a napriek tomu je moja práca v ňom efektívnejšia než v týchto "inteligentných" nástrojoch (uvodzovky sú tam zámerne, keďže tieto vlastnosti sú často skôr na zlosť). Vim je neuveriteľne mocný nástroj - niekedy by ste si ho mali vyskúšať a pokúsiť sa ho pochopiť, nech aspoň viete, čo vlastne kritizujete.

Pokiaľ ide o absenciu menu a podobne - nedávno som na túto tému čítal zaujímavý článok, ktorý hovoril zhruba to, že používateľské rozhrania sú určené na *používanie* - nie na *učenie sa*. Dobré rozhranie je preto také, v ktorom môže efektívne pracovať človek, ktorý sa ho naučil, nie také, ktoré sa tvári, že sa ho učiť netreba, ale na serióznu prácu je nevhodné.

Všetky tie ukazovania typov premenných a zoznamov funkcií a ja neviem čoho všetkého - musím povedať, že toto všetko mi je absolútne na nič, a myslím si, že ide o nástroje vhodné pre nie veľmi schopných alebo začínajúcich programátorov - mne teda aspoň nerobí žiaden problém pamätať si, čo je daná premenná zač, prípadne si to zistiť tam kde je definovaná - neprogramujem ako prasa, takže to viem zistiť rýchlo a efektívne. Vo vašom prípade to asi bude inak, podľa toho, čo hovoríte.

Inak k tým prirovnaniam. V niektorých situáciách je vhodnejšie IDE, v niektorých efektívny textový editor typu vim. Preto v každej situácii použijeme to, čo sa nám zíde viac. Pripomínate mi človeka, ktorý zistil, že kombinačky sú nesmierne užitočný nástroj - a práve s nimi usilovne zatĺka klince. Kombinačky samozrejme sú užitočný nástroj, ale kladivo je občas predsa len vhodnejšie :) A s editormi je to podobné.

Uff, to som sa zase rozpísal.

Můj názor je takový, že interface, ve kterém nevidím nabídku akcí, a mohu udělat jen to, o čem naprosto přesně vím, jak se dělá, je špatný. A za takový názor mě nikdo platit nemusí, protože k tomu dojde každý, kdo není zdeformovaný tím, že vi/vim používal řadu let.


Souhlasím, že vim má řadu možností. Bohužel má naprosto zoufalý interface, vz výše.

Já jsem četl spoustu článků, a řada z nich byly bláboly (a to nemluvím o zprávičkách na root.cz). Zkuste si představit například word processor typu Word, a to že potřebujete rozepsat adresy na obálky. Protože adresy na obálky běžně nerozepisujete, není problém - najdete v menu nebo helpu co je třeba, a práci uděláte. Pokud to budete dělat každý den, budete už vědět, že použijete CTRL+tohle, Alt+tamto, stisknete dalších pár kláves, a je hotovo. Tak vypadá dobrý interface. Špatný interface vypadá tak, že adresy nerozepíšete, pokud nemáte naučený správný příkaz. Totéž platí ale třeba o naformátování zdrojáku, používání záložek, debuggování aplikace atd.

Ve spoustě případů je dobé rozhraní, které se na vážnou práci nehodí. Když chcete, aby si vaše babička byla schopná vypálit audio CD, nebo sestavit DVD s fotkami z dovolené, musí to být takový interface. Ovšem interface který má MS Office, nebo Visual Studio, je velmi dobře použitelný pro začátečníky i pro profesionály.

Funkce typu ukazování detailů po najetí na proměnnou (datový typ, možnost z kontextového men přejít na deklaraci) jsou velmi užitečné. Umožňují vám soustředit se na jiné, důležitější věci, a co může dělat stroj, necháte na něm. Podobně byste totiž mohl tvrdit, že vám není k ničemu přehled kontaktů v mobilu, protože kdo si není schopen kontakty zapamatovat, neměl by ani mít telefon. Jenže když se nestaráte o pamatování kontaktů, nebo o pamatování schůzek (protože máte plánovací kalendář), můžete se věnovat jiným věcem. Pochopitelně pokud tyhle možnosti nemáte, je třeba tvrdit, že jsou ty hrozny stejně kyselé.

Samozřejmě standalone editor má mnohdy opodstatnění. Například nevidím důvod editovat ve Visual Studiu 3-řádkový konfigurák, protože na to stačí Notepad.

Když nevím, jak se co ve Vimu udělá, použiju Google. To je lepší než menu, které grafická verze Vimu má taky.

Pssst, hlavně mlčet o existenci Creamu, to by nezapadalo do LOova obrazu světa. ;-]

Používat Google místo menu je vtip, nebo to myslíte vážně? I když vzhledem ke kvalitám GVimu je možné, že použít Google je lepší nápad ;)

Vzhledem k tomu, že o možnostech GVimu toho očividně moc nevíte, tak to asi opravdu je lepší nápad.

GVim jsem měl na stroji několik let, a párkrát jsem ho i použil. Jde v principu o terminálovou aplikaci obalenou GUI, a výsledek je velmi podivný. Ale rád se nechám poučit, jestli jsem něco přehlédl.

Milý Laeli, Vim je textový editor, nepoužívá se k tisku na obálky ani neumí vařit kávu. Pokud hledám nějakou funkci, existují v zásadě tři scénáře.

1. Tento editor musím použít z nouze a prakticky nic o něm nevím. Pak si, jak někdo správně poukázal, vystačím s jeho vestavěnou dokumentací, protože pro zeditování konfiguráku apod. toho moc nepotřebuju.

2. Chci použít některou mně dosud neznámou funkci editoru. V tomto případě si ji prostě někde najdu, ať už v menu (typicky práce s okny, tisk, nastavení zvýraznění syntaxe) nebo v dokumentaci nebo pomocí Google. Protože takovou funkci budu zřejmě používat znovu a znovu, zapíšu si ji nebo hned zapamatuju - Vim se člověk učí inkrementálně a zapamatovat si jednu fintu není těžké. Kdybych ji měl hledat pořád dokola v menu, nemělo by to moc smysl.

3. Nelíbí se mi standardní chování, chci si ho změnit. Pak si najdu, jak na to a zapíšu si to nastavení do konfiguračního souboru a už nikdy to nebudu muset znovu hledat, ať už pomocí Google nebo jinak. Konfigurační soubory si migruju ze stroje na stroj. Je to dnadné, je to rychlé, je to univerzální.

Nevidím důvod nad takovýmto způsobem práce ohrnovat nos a neberu nepoučené výtky od člověka, který tento editor nepoužíval alespoň půl roku den co den.

Je mi záhadou, jak chcete v textovém vi/vimu pracovat s menu, které nemá. GUI verze (GVim) menu má, ale program se ovládá podobně příšerně, jako v textové verzi.

Samozřejmě standardní ovládání si můžete změnit i ve Visual Studiu nebo MS Office, stejně jako exportovat a importovat nastavení. Vystavujete se tím ale problémům, jakmile potřebujete používat program někde, kde nemáte svou konfiguraci k dispozici.

Tvrdíte, že výtky má právo vznášet jen ten, kdo pooužívat vi/vim den co den půl roku. Jenže takoví lidé prakticky nejsou. Abyste tak příšerný interface používal půl roku, musíte k tomu být donucen, a toho půl roku se ho den co den učit. Děkuji, nechci - vystačím si se slušným GUI, pohybem kurzoru a prací s myší; zbytek mě aplikace naučí sama.

Samozřejmě jsem mluvil o Gvimu, protože prakticky každý, kdo používá grafické prostředí (99% programátorů nebo i více), používá grafickou verzi.

Pokud nemám někde svou konfiguraci k dispozici (což, pokud budu často chodit od počítače k počítači, bude maximálně u strojů nepřipojených k síti), si můžu nejdůležitější volby nastavit i tak - je jich minimum a pamatuju si je. Furt nevím, proč sem taháte MS Office, dokonce i moje pračka a rychlovarná konvice jde přenastavit, ale to je trochu off topic.

Však já Vás nenutím používat (G)Vim, používejte si, co je Vám blízké. Vim má význam zejména pro lidi, kteří znají jeho přednosti a používají jej pravidelně. Já taky neobcházím lidi a neříkám jim "nepoužívej Eclipse, JEdit, Kate, jedině s Vimem dojdeš spásy". Pokud ale někdo přijde a začne hanět Vim (obecně, ne ve stylu "pro mě je moc složitý, líp se mi pracuje s jiným editorem"), řeknu mu ve vší slušnosti, že je trouba, protože kecá do věcí, kterým nerozumí. A že Vás aplikace něco naučí sama? Jo, naučí, když víte, co od ní můžete čekat. Jinak zůstanete pořád lamičkou, která umí pár procent možností a to ještě neefektivně.

Ano, dobrá GUI aplikace uživatele naučí sama, ale pokud je neschopný, tak aplikace sama nepomůže. Když je člověk neschopný, nepomůže totiž vůbec nic. Ale pointa je v tom, že když je uživatel alespoň trochu schopný, tak se nemusí memorovat stovky příkazů a tisíce klávesových zkratek, přesto může aplikaci používat, a časem ho aplikace naučí ji používat efektivněji. Tohle vi/vim neumí. A o tom to celé je.

Ale sama ho to nenaučí. Jednu dívku jsem nedávno připravoval na pracovní pohovor a chtěl jsem jí pomoci osvěžit základy používání (MS) Office (paradoxní, protože MS Office jsem v zásadě nikdy pořádně nepoužíval), které se měla naučit na střední škole. V životě neviděla polovinu věcí, které jsem jí ukazoval, včetně používání stylů; jsem zvědavý zda a kdy je začne skutečně používat. Pořád ještě ale na tom byla suprově oproti ženským, které si myslí, že na konci každého řádku se musí stisknout Enter, překlep neopravují na místě, ale pomocí Backspace smažou všechno, co za překlepem leží a všechno píšou do jednoho souboru.

S používáním plaintextového editoru je to podobné - pokud se jednou naučíte neefektivní návyky, těžko se přeučují a sama aplikace to za nikoho neudělá.

Nevím, jak vypadá dnešní vim, ale když jsem ho naposledy viděl, bylo to vylepšené vi, a menu jsem fakt nenašel. Možná je menu v textovém vimu novinka?

Otázka je, proč se učit hromadu příkazů a klávesových zkratek? Když potřebuji editovat na úrovni Notepadu, stačí mi použít Notepad, použít myš a kurzorové klávesy. Navíc nesouhlasím, že by práce ve vi/vim byla výrazně efektivnější, než v GUI. Kdybyste si vynaložil setinu úsilí na to, abyste se naučil pracovat s GUI, dosáhl byste velmi dobrých výsledků. Je zvláštní, že někteří lidé nemají problém se naučit 538 příkazů a 1000 klávesových zkratek, ale text v GUI vybírají jen myší, protože neumějí použít ani klávesu CTRL+SHIFT+Left.

Vy zase nečekejte, že bude někdo brát vážně obhajobu interface vi od jeho zaníceného uživatele. Nedostatky (menu, vizuální odezva, obtížné učení) vidí i slepý. Údajnou výhodou je vysoká efektivita, ale jak jsem psal výše, podle mě jde spíše o iluzi.

Řeč byla původně o vi. Ono totiž vi musí být z nějakého obskurního důvodu v každém unixu, kdežto vim, mc apod. nikoliv. Na Linuxu je vi údajně jen převlečeným vimem, ale nemám tu teď testovací systém.

CTRL+SHIFT+Left je pěkná a efektivní metoda. Nepotřebujete znát více, než funkci kurzorových kláves (ta je na nich nakleslená či napsané, což mimochodem u hjkl tvrdit nelze), a funkci modifikátorů Ctrl a Shift. Down - o řádek níže. Shift+kurzorová klávesa - rozšiř označení. Home,Shift+Down - označ ředek včetně znaku konce řádku. Home, Shift+End - označ do konce řádku, bez znaku konce řádku. Ctrl+kurzorová klávesa - posun o více jednotek daným směrem. Ctrl+Shift+Down - rozšiř označení do konce odstavce.

Nepoužívám Eclipse, ale zajímalo by mě, jestli s viPluginem také píšete .PropertyValue namísto tečka-p-tab, jako kolega Rejpal, a také si u toho libujte, jak jste efektivní?

Proboha, ještě že jsem neztratil rok drahoceného času učením vi. Kdybyste ten rok místo patlání se v vi nějak produktivně pracoval, tak byste si vydělal na pěkný sportovní vůz. Ale možná to byla dobrá zábava (mě to tak nepřijde).

ano, Perl považuji za otřesný jazyk. Jeho zastánci samozřejmě tvrdí, že Perl je nejlepší, a dá se v něm napsat cokoliv. Osobně mě jímá hrůza, když vidím kód, který vypadá, jako kdyby se autorovi zasekl shift na klávesnici. Sice jsem napsal v Perlu tisíce řádků, ale k srdci mi nikdy nepřirostl. Jsem zvyklý na výrazně odlišné koncepty. Například když mám string, tak je to string, a nikdo mi do něj nehrabe. Chápu, že když napíšu $s=~ s/a/b/i;, že jde o regexp. Můžeme rovnou přeskočit diskuzi na téma jestli je použítí regexpů vždy a všude dobrý nápad, protože se regexpy špatně učí, špatně píší, a jsou naprosto nečitelné (po půl roce mnohdy i pro autora). Co mě ale šokuje je, když provedu $s=~s/$a/$b/i;. Podle všech svých zvyků považuji "s/$a/$b/i" za string, a protože jde o Perl, tak se $a nahradí za obsah stringu. Ale proč když je ve stringu $a psáno \\abc\ne, tak se to zmrší na \abc[LF]e? Já samozřejmě znám důvod (a vy předpokládám také), ale chci, abyste viděl, že je to naprosto odlišný princip, než jaký používají ADA, BASIC, C, C#, Java, a většina dalších civilizovaných jazyků. Samozřejmě tak pobaví, že $a="\další\obrázky" nevyhodí chybu neplatné escape sekvence, a v pohodě projde. Tomuto typu zhůvěřilostí vděčíte na unixech za problémy s podporou názvů souborů s češtinou, s mezerami atd.

S tím blábolením brzděte, nebo to přeženete. Chceme přece udržet diskuzi slušnou.

"Nepoužívám Eclipse, ale zajímalo by mě, jestli s viPluginem také píšete .PropertyValue namísto tečka-p-tab, jako kolega Rejpal, a také si u toho libujte, jak jste efektivní?"

Už zase lžete zcela viditelně. Dávejte si na to pozor. :-p

To byl pouze předpoklad. Ale řekněte mi, jak píšete .PropertyValue ve vi? Pokud tedy nepoužijete jazyk, kde místo toho napíšete něco jako ~@$$A^&4?

ctl+n?

Samozřejmě chápu, že regexpy jsou pro uživatele unixů dost zásadní. Co nechápete vy je fakt, že se regexpy nadužívají. Pro jednoduché vyhledání nebo replace substringu je daleko lepší použít běžné funkce pro práci se stringy, protože replace(co, za-co), případně s.Contains(co), je na rozdíl od regexpu snadné zapsat i přečíst. Samozřejmě regexy mají jisté využití, a občas je používám v C#. Neštěstím je ale cpát je vždy a všude jako základní prostředek, a to pro obtížnost jejich učení, obtížnost jejich psaní, a jejich nečitelnost.

ja uz jsem na to prisel, vy budete delat asi do marketingu. ti maji taky ve zvyku mluvit chytre o vecech kterym vubec nerozumi.

(zarovicka) tip dne: vite, ze bezne funkce pro praci s retezci jsou take regularni vyrazy.

prejete si dalsi tip dne?

ano, ano!

(zarovicka) tip dne: vite, ze editory jako vim, nepotrebuji rozlisovat jestli se bude pouzivat bezne vyhledavani nebo vyhledavani podle regularniho vyrazu. dokaze tohleto vas pan sponka?

Replace(co,za-co) je regexp? Že jsem si toho nevšiml.

Nemám tu (naštěstí) vim, ale přesto se rád přiučím. Jak vim pozná, jestli vyhledávám regexpem, nebo ne? Když hledám například string [pP]wd, jak ví, jestli má hledat [pW]wd, nebo pwd a Pwd?

MMCH pan Sponka byl výsledek spojení Billa Gatese a Melinda French, se kterou se později Gates oženil. Melinda pracovala v týmu vyvíjejícím rozhraní MS Bob, a pan Sponka byl jediným přeživším výsledkem tohoto projektu. Domnívám se, že Sponka se dostal do Windows a Office právě díky vztahu Melindy a Billa ;)

Velice snadno. Záleží na nastavení proměnné magic. Když mám nastaveno
:set nomagic
najde to [pW]wd, když je nastaveno
:set magic
najde to pwd. Pokud chci při hledání přepnout, dám na začátek \m, resp. \M. A pokud jsem BFU, nastavím si
:nmap / :pro^M
a pak mi to nabídne vyhledávací dialog pro BFU. GVim je úžasně konfigurovatelný a záleží jenom na mně, jak si ho nastavím. Jenom když chci hledat \, musím zadat \\, což je ale pro fanoušky MS systémů určitě velmi přirozené. ;-)

A jak to koresponduje s tvrzením, že "editory jako vim, nepotrebuji rozlisovat jestli se bude pouzivat bezne vyhledavani nebo vyhledavani podle regularniho vyrazu", na které jsem reagoval?
http://www.root.cz/clanky/vifm-spravce-souboru-a-la-vim/nazory/215641/odpovedet/

Už ste počuli pojem "dokumentácia" ? To je ten hypertextový dokument, ktorý si môžete prečítať, a všetky tie funkcie čo nepoznáte tam nájdete. Taktiež tutorial a všetko.

V podstate váš argument je zhruba takýto: nechcem sa NIKDY učiť nič nové, pretože učenie je zlé, áááno? A kto ma núti niečo sa učiť je zlý, áááno? Radšej budem pracovať menej efektívne, ale prosím prosím nenúťte ma naučiť sa niečo nové !!!

Takže když edituji soubor, tak místo kouknutí do menu otevřu dokumentaci, a budu v ní hledat funkci, o které ani nevím, jestli tam je. Až jí najdu, tak si jí zapamatuji, nebo napíšu na papírek-helpáček. Super, skvělé. Máte další nápady, jak učinit práci efektivní? Třeba užíváním husího brku namísto laserové tiskárny?

Nikdo neříká, že by se člověk neměl učit. Ale důležité jsou principy - tedy CO lze udělat, a jak to FUNGUJE (počítač má účty, lze je přidávat, odebírat, měnit hesla, existují doménové účty). Samotné JAK to konkrétně udělat (kliknout sem, napsat příkaz X) je nedůležité. Všimněte si, že na unixech, stejně jako ve vi, nerozlišujete CO a JAK. Ve skutečnosti se jen memorujete JAK, a znalost CO s tím možná časem přijde.

Ehm, a aký že to prosím je rozdiel medzi hľadaním v dokumentácii a hľadaním v menu ? Samozrejme hovorím o -dobrej- dokumentácii, nie o nejakom paškvile typu dokumentácia produktov firmy Microsoft (MSDN je svetlá výnimka, ale aj tá má medzery).

Alebo mi vážne chcete tvrdiť, že pri zakúpení nového elektronického prístroja začnete náhodne stláčať tlačítka s tým, že niečo sa snáď stane, namiesto toho aby ste si prečítali návod na obsluhu ? Zaujímavý prístup, mno ale keď vám to tak vyhovuje ...

To s tým unixom je samozrejme nezmysel, ale to, že unixu absolútne nerozumiete, ste už vraveli veľakrát.

A na záver zopár nadčasových citátov.

"Unix is simple. It just takes a genius to understand its simplicity." – Dennis Ritchie

"Those who don't understand UNIX are condemned to reinvent it, poorly." – Henry Spencer

Takže podle vás je ten proces efektivnější, než "kouknu do menu, a když se tam dívám potřetí, tak si zapamatuji klávesu"? A je také pohodlnější?

Když jsme u toho, proč si myslíte, že vi nepoužívá prakticky nikdo? Nepoužívá ho téměř nikdo mimo platformu unix, a ani unixáci, kterým ovládání vi nacpali ve škole do hlavy násilím, se k němu mohdy nehlásí. Proč jste naprostou výjimkou, když vám jeho ovládání vyhovuje?

Máte nějaké konkrétní poznatky o efektivitě práce s vi? Jak jsem psal, někteří lidé nemají problém se naučit stovky příkazů vi, ale nenaučili se slušně zacházet s GUI.

A mohu se zeptat, proč je efektivnější otevírat dokumentaci, něco v ní hledat, a memorovat se to (nebo nedej bože používat papírek helpáček), než se prostě podívat v menu?

Statistiky používání editorů jsem nehledal. Ono stačí se podívat okolo sebe. I když pokud se díváte po tom 1% uživatelů Linuxu, tak možná vidíte něco jiného, než ostatní lidé.

Já nejsem líný se učit. Jen si myslím, že jednoduché věci se mají dělat jednoduše, a mám nechuť se učit zbytečnosti.

Jako příklad bych uvedl přenosné telefony Siemens (tuším první série Gigaset?). Ty kdysi měly B/W LCD display s klasickými 8-segmentovými číslicemi. Když jste chtěl telefon zamknout, odemknout, změnit heslo, zapnout přesměrování hovorů apod., "prostě" jste namačkal něco typu "klíč-hvězdička-883141", a ono to něco udělalo. Kupodivu se tyhle telefony moc neprodávaly. Když Siemens převzal klasické ovládání mobilů, tedy s menu ze kterého se dá vybrat, byla to velká změna. Kupodivu můžete pracovat podobně jako s původním ovládáním (jako na většině mobilů) - stisknete "menu-3512", a je hotovo. Rozdíl je v tom, že když nevíte, jak danou věci uděláte, najdete jí v menu. Když vás bude trápit rychlost, podíváte se na displayi na zkratku, a příště jí použijete.
Vy byste ovšem používal to původní ovládání, přestože je vysloveně debilní, kriptické, a nevhodné k používání člověkem. Řekněte mi: proč proboha? Má to smysl? Možná si pak připadáte, že jste se něco užitečného naučil. Ale není lepší investovat úsilí do něčeho smysluplného?

Ja si tiež myslím, že jednoduché veci sa majú robiť jednoducho ... len sa zdá, že sa nezhodneme na tom, čo pojem jednoducho znamená ... on problém s GUI vôbec nie je to, čo píšete, klávesové skratky a podobné veci sa naučia ľahko - problém s GUI je, že robí jednoduché veci jednoduchšími ... a zložitejšie veci zložitejšími. To mi nepripadá ako dobrý kompromis.

Vi/vim samozrejme šípky používať dokáže - zistite si fakty.

Čo robí vi mocným je jeho flexibilnosť a rozšíriteľnosť spôsobmi, aké by v GUI boli nemožné. Veci ako hľadanie v histórii použitých príkazov aj s parametrami, opakovanie a reťazenie príkazov, a tak ďalej a tak ďalej. Je toho dosť.

Ale pokiaľ trváte na tom, že program je použiteľný jedine v prípade, že ho dokáže pochopiť cvičený šimpanz, tak môžem akurát povedať, že vás ľutujem.

Inak tie vaše výlevy o perle sú dosť úsmevné - dobrý programátor samozrejme napíše čitateľný a udržiavateľný kód v takmer čomkoľvek, čo prekvapivo zahŕňa aj perl - je ale zjavné, že to váš prípad nebude. Osobne keby som bol mizerný programátor by som to teda asi do sveta nevykrikoval, mno ale každému čo jeho jest.

Počítače umí dělat spoustu věcí. Ty věci, které se dělají často, se musí dělat jednoduše. A o tom je UI.

Netvrdil jsem, že vi/vim neumí používat šipky. Samozřejmě ten předpotopní terminálový systém občas vede k tomu, že šipky nefungují (aby ne, se stovkami typů terminálů), a pak se hjkl hodí. Někteří hardcode uživatelé vi tvrdí, že je přehmatávání až na kurzorové klávesy hrozně zdržuje :)

O cvičených šimpanzích viz první odstavec. Jednoduché věci se dělají jednoduše. Popisoval jsem jinde ten interface přenosných telefonů Siemens. Co si o tom myslíte vy?

Já nejsem programátor, a v Perlu píšu pouze v sebeobraně. Ovšem podle vás je mizerný programátor každý, komu se nelíbí Perl, že? Pletete si to s něčím jiným. Já nesouhlasím s tím klasickým tvrzením, že unixy jsou übercool a zábavné. Jednoduché věci jednoduše, počítač jako mikrovlnka či mobil. Jiní lidé naopak tvrdí, že počítače nemají ovládat cvičení šimpanzi, a kvůli pitomé editaci textovách souborů se člověk má naučit stovky příkazů, tisíce klávesových zkratek, a ztratit minimálně měsíce času. Děkuji, nechci - mám pro čas lepší využití.

Já nejsem programátor, a v Perlu píšu pouze v sebeobraně.

huh, aha.

zasadni otazka, co vlastne jste?

mám pro čas lepší využití

fakticky?! nelzete?! ...nebo vedete tak nudny zivot, ze prudeni v diskuzich je to nejlepsi vyuziti vaseho casu, ktereho jste schopen?

Co jsem, to si s dovolením nechám pro sebe.

Delší diskuze na rootu jsou spíše důslekem toho, že se občas nechám unést. I když dnes se trochu nudím. V Bruselu není moc zábavy. Naštěstí jsem tu jen na skok za kolegy.

Ve věci využit času jsem měl na mysli samozřejmě čas pracovní. Přemýšlím, jestli bych si raději uřízl ruku, než se učil vi v době svého odpočinku. Nakonec si říkám, že bych se raději učil vi, než obětoval ruku.

Zdravím Vás, pane Špidlo. :-D

Jen to ne :). Mimochodem je zajímavé pozorovat české evropské úředníky na cestě do práce. Někteří jsou schopní se porvat kvůli upgradu do business class. Naštěstí už s nimi nelétám.

Zato já si všiml řady problémů. Například mezery v názvech řada skriptů nezpracuje

Tento problém neznám, asi vám ty skripty píší nějaká děcka?

Podobně s češtinou v názvech souborů, která působí tolik problémů, že jí uživatelé unixů raději nepoužívají

Lež jako věž :D

A sám můžete vidět, že řada uživatelů unixů dodnes píše příspvěky a maily bez diakritiky

Asi to jsou programátoři, na rozdíl od mraku sekretářek na Windows.

Takže ano, i já mám tyhle problémy.

Mnohem větší než tušíte...

Tuhle jsem zkoušel po létech něco na Windows, musel jsem spustit jeden "konzolový" program, a ono tam nefungovalo ani "cd Dokumenty". Šílený :D

Jistě, Oracle píšou malé děti. A čeština v názvech souborů? Před časem se to tu diskutovalo, a převažující názor uživatelů unixů byl ten, že používání mezer a diakritiky v názvech souborů je "prasárna", protože to působí řadu problémů.

A že by to mohlo být třeba tím, že si uživatelé Unixu (v průměru technicky zdatnější než průměrný uživatel Windows) jsou vědomi, jaké problémy to může například dělat některým síťovým protokolům při přenosu, Vás nenapadlo? Kdo píše Oracle, to bych se radši neptal. Asi by to byla podobná odpověď, jako v případě SAPu, Windows a spol.

Já měl za to, že FS povoluje názvy souborů s mezerami, i s diakritikou. A opravdu mě nenapadá, který síťový protokol by měl mít problémy s dlouhými názvy.

Kdo píše Oracle jsem řešit nechtěl. To jen kolega tvrdil, že skripty které, nepracují s dlouhými názvy, píší děti.

S dlouhými názvy asi žádný, ale o tom jsem přeci nemluvil, že? ;]

Dlouhé názvy jsou taková ta věc delší než 8.3, a s národními znaky. Jednak předpokládám, že znáte běžnou terminologii, a potom to bylo zjevné z kontextu.

No tohle rozhodne neni bezna unixova terminologie :-).

Co se tyce prenosu znaku s diakritikou, tak treba FTP ci starsi (a stale prevazne rozsirene) verze SFTP. Ty snad nedefinuji kodovani prenasenych souboru, takze pri prenosu mezi ruznymi systemy muze dojit k poskozeni diakritiky.

A co se tyka chyb v implementacich, tech je pozehnane. Napriklad z MS Outlook Expressu me stale prichazeji maily, ktere maji chybu v implementaci MIME encoded words a posilaji nevalidne kodovana jmena priloh, pokud ve jmenu souboru (prilohy) byla mezera a diakritika.

Ono vzhledem k tomu, že kódování názvů souborů na unixech není dané ani na lokálním disku, tak je nějaké (S)FTP už celkem nuda.

Pokud jsem si všiml, tak dlouhé názvy v mailech z Outlook Express jsou ve skutečnosti problémem Mozilla Mailu, nebo čeho. Dost divoce se to diskutovalo tady i na abclinuxu. Ale moc jsdem to nesledoval, klidně mě opravte.

Opravuji, nejedna se presne o chybu v MIME encoded words, ale v chybnem pouziti parametru u Content-Disposition.

Priklad z mailu posleneho z Outlook Express:

Content-Disposition: attachment; filename="=?iso-8859-2?Q?Provoz_o_V=E1noc=EDch.doc?="

Tedy v atributu filename je hodnota zakodovana pomoci MIME encoded word.

RFC 2231 (z roku 1997 !)uvadi:

(2) MIME headers, like the RFC 822 headers they often
appear in, are limited to 7bit US-ASCII, and the
encoded-word mechanisms of RFC 2047 are not available
to parameter values. This makes it impossible to have
parameter values in character sets other than US-ASCII
without specifying some sort of private per-parameter
encoding.


A definuje takove kodovani (v sekci 4), podle ktereho by to melo vypadat takto:

Content-Disposition: attachment; filename*=iso-8859-1''Provoz%20o%20v%E1noc%EDch%2Edoc

Outlook Express neimplementuje RFC2231 pro odesílání příloh. Zřejmě začali psát SW ještě před rokem 1997 :)

Nejenom, ze neimplementuje RFC 2231, ale to, co dela se jmeny s diakritikou, zcela evidentne porusuje RFC 2047 5/(3).

Coz tedy znamena, ze Outlook Express (asi prevazujici mail klient pro Windows) neumoznuje korektni posilani souboru s diakritikou ve jmene. Neni to jasna ukazka toho, ze (z pohledu uzivatele) davat do jmen diakritiku je zbytecne koledovani si o problemy?

Implementace RFC2231 přece není povinná. Navíc Outlook Express je už 4 roky mrtvý produkt. Pokračovatelem jsou Windows Live Mail (v XP) a Windows Mail (ve Vistě).

Nemám čas to příliš zkoumat, ale je pravděpodobné, že RFC 2047 je v OE implementováno a porušeno (alternativně není implementováno, a RFC 822 ani 2183 porušeno není). Otázka je, koho to mrzí, když bylo/je klientů s OE ve stovkách milionů, a tedy o tom každý ví. Samozřejmě se tak každý může naučit názvy parsovat. Není to první ani poslední standard, který autoři SW porušují (a nad důvody by se dalo jistě diskutovat).

Dávat diskritiku do jmen souborů není na Windows problém. Mail poslaný z Windows na Windows ty názvy zachová, a naprostá většina ostatních klientů dávno ví, co jak OE posílá názvy souborů. Navíc zachování názvů souborů ani není v RFC vztahujících se k MIME požadováno - filename je pouze doporučením pro cílový systém, see RFC 2183 chapter 2.3.

Za daleko větší problém považuji fakt, že na unixech není zachování korektního názvu souboru zaručeno ani na lokálním systému, protože se názvy v různých kódováním mohou volně míchat na FS. To když nehovoříme o bugách/buzích/bugěch (proboha) ve skriptech i aplikacích.

"Samozřejmě se tak každý může naučit názvy parsovat. ... Mail poslaný z Windows na Windows ty názvy zachová, a naprostá většina ostatních klientů dávno ví, co jak OE posílá názvy souborů." Tzv. "standard de violentia"? :-D A proč teda IETF máme?

Za daleko větší problém považuji fakt, že na unixech není zachování korektního názvu souboru zaručeno ani na lokálním systému, protože se názvy v různých kódováním mohou volně míchat na FS."

Že by PEBKAC? Pokud mi nějaký program uloží na disk soubor s non-UTF-8 názvem, tak jakmile opadne moje počáteční chuť zabít jeho autora tupým předmětem, poletí ten program vesele z disku. Zatím se tak ale nestalo. S mapováním názvů z oddílů Windows tak nějak problémy taky nemám.

Řekněme stadard de facto.

Starší SW není psaný s podporou Unicode. Těžko tedy může psát názvy souborů v UTF-8 (až na výjimky kde daný SW názvy v UTF-8 můžete nakrmit - v GUI to ale nepřipadá v úvahu).

Starší SW ve Windows taky nemusí být psaný s podporou Unicode, nebo aspoň ještě před pár lety jsme v práci s některými aplikacemi měli problémy. Přinejmenším v případě GNU softwaru je ale podpora UTF-8 doplňována, takže zase *tak* krizově bych to neviděl. Nové aplikace si takhle už nikdo napsat nedovolí, protože by se mu pak v komunitě právem smáli. :-)

Samozřejmě starší SW psaý pro Windows nemusí mít podporu Unicode. Rozdíl je v tom, jak je zajištěná zpětná kompatibilita. Ve Windows máte názvy souborů na disku vždy v Unicode. Total Commander psaný bez podpory Unicode (stejně jako jakákoliv obdobná aplikace) bude schopen vytvořit soubor s češtinou v názvu, a ta bude vidět ze všech ostatních aplikací korektně. Obdobně taková aplikace uvidí zcela korektně soubory, které mají češtinu v názvu. To vše proto, že volání starých aplikací jsou překládána z code page do Unicode. Zavoláte CreateFileA, předáte pointer na char; systém to přeloží na řetězec z wcharů, a zavolá CreateFileW. Tomu se říká kompatibilita. Naopak unixech se názvy v různých kódováním mohou volně míchat na FS.

> že na unixech není zachování korektního názvu souboru zaručeno ani na lokálním systému

Ale je, z filesystemu vyzvednes presne takovy nazev, jaky jsi tam ulozil.

> protože se názvy v různých kódováním mohou volně míchat na FS.

Samozrejme ze muzou. Kdyz jeden uzivatel preferuje jedno kodovani a jiny uzivatel jine. Proc by jim mel operacni system spolecne kodovani vnucovat?

Operační systém možná ne, ale já jako admin to udělám velice rád. :-> BOFH! :D

Jenže já bych byl radši, kdybych v aplikaci A viděl názvy souborů tak, jak jsem je v aplikaci B zapsal. Ono je to tak nějak lepší pro manipulaci se soubory, a pro jejich přenos. Další otázkou potom je, co udělají UTF-8 aplikace (Qt, GTK), když narazí na neplatnou UTF-8 sekvenci. GTK by to možná mohlo rozdýchat (string zpracuje jak byl), Qt těžko (pokusí se o převod stringu do UTF-16, což neprojde, a pak nevím).

Copak uživatelé. Je to spíše o starém SW, který neoperuje v Unicode. Nakonec si vzpomeňte, že ještě v druhé polovině devadesátých let se na Linuxu řešila čeština a podpora 8859-* code pages. Unicode se začal řešit někdy před pár lety. Ale srovnání řešení situace na Windows a na unixech tu už několikrát bylo. Unixy mají holt podporu Unicode řešenou špatně.

AUX a další jsou rezervovaná jména. Zkuste si uložit dokument v Notepadu pod jménem aux, a on vám vysvětlí, že jde o rezervované jméno zařízení. Když jsme u toho, jména zařízení jsou pozůstatkem unixových konceptů.

10 let staré Windows 98? Já ve Windows 95 ukládal do adresáře tisíce souborů, a problém jsem nepostřehl. Ale bavít se dnes o 10+ let starém systému je naprosto mimo.

Kolik je tech rezervovanych jmen ?

Chapu ze nemuzu vytvorit /dev/aux, ale klidne vytvorim /tmp/aux /Aux /aUx atd.

1)
Na M$Win nevytvorim celou neznamou mnozinu souboru :-), protoze soudruzi z Redmontu
maji "dev" asi vsude :-)))

2)
Je mi jedno jak jsou 98 stare. Je to v provozu, potreboval jsem seznam souboru, ktery jsem dostal neuplny. Potreboval jsem ho cely.

Takze na zaklade 1) a 2):
M$WIN LIBOVOLNE VERZE NEUMI ZAKLADNI PRACI SE SOUBORY
tecka.

1) Snad umíte hledat v dokumentaci, ne? CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9
http://msdn.microsoft.com/en-us/library/aa365247.aspx

2) Mě je jedno, co jste před 10 lety údajně potřeboval, a co tehdejší Windows údajně udělaly. Mám vám vyprávět, jak jsem před 10 lety zkoušel rozchodit USB tiskárnu pod Linuxem?

1) Na tom odkazu je pekne zhrnuto co to vsechno (oficielne) neumi, diky.

No dost slabucky souborovy system. Obcas se hodi i linky.

2) Ten system je v provozu ted, s temi 10 lety si zacal ty.

Nemam cas objevovat, zaplatovat, nedej boze zkouset jine verze WIN.
2.1) ten stroj by to neutahl
2.2) aplikace na jine verzi by nemusela vubec jet
2.3) ten system tak jak je vicemene funguje - az na to, ze jsem si nemohl stahnout
seznam souboru s jednoho adresare za pomoci nastroju M$

Tipuji na chybu v implementaci dosovske utility "dir".

No nic tak tam s USB nabootuju nejaky opravdovy OS a ten seznam dostanu.

1) Omezení se netýká file systému, ale operačního systému. Toto omezení je zavedeno z důvodu zpětné kompatibility. Jinak NTFS umí být case sensitive, umí hardlinky, a umí jakékoliv názvy souborů (třeba s hvězdičkou v názvu souboru). Vrstva Win32 je case insensitive, hardlinky umí až recentně, a názvy souborů omezuje popsaným způsobem.

2) Vy máte živý systém s Windows 98? Pěkné :). Bohužel dávno nemám ani virtuální stroj s Windows 9x, takže ani neověřím, jestli popsaný problém existuje.
Ano, přečíst disk z jiného OS je celkem dobrý nápad. Pokud má stroj USB port, nebo (funkční) CD mechaniku. Upozorňuji, že ukládat na FA více než 100 souborů do jednoho adresáře přináší problémy s výkonem, a jde tedy o špatný design aplikace.

No to je veselé. :-) Takže Unix tzv. "neumí" (samozřejmě umí) dlouhé, mezerovité a diakritické názvy souborů, které uživatel chce, zato ve Windows je údajně vše v pořádku, ale nakonec se dozvíme o tuctu "rezervovaných" názvů. A ještě svede se to na Unix, který zřejmě může za všechno špatné na Windows - "jména zařízení jsou pozůstatkem unixových konceptů" - přitom Unix nikdy nic podobného nedělal, názvy zařízení jsou úplně normální názvy souborů v jednom adresáři a nijak neovlivňují to, co si můžu udělat v domovském adresáři. Upřímně obdivuji Váš žaludek, aby ustál takovýhle doublethink, musí být skutečně medvědí. :]

Jak jsem psal dříve, dlouhé názvy souborů (mezery a diakritika) na unixech působí řadu problémů. Typicky na nich havarují skripty, ve kterých autoři zapomněli takové názvy ošetřit. Jestli vy takovou zkušenost nemáte, tak já ano. A když se podíváte na zdejší diskuze, tak se dozvíte, že dlouhé názvy jsou prasárna, kterou slusny unixak prece nepouziva.

Rezerované názvy zařízení prostě existují, těžko s tím něco udělám :). Koncept souborového interface pro zařízení je původem z unixů. A můžete si všimnout, že DOS neměl žádný adresář s device files, nakonec na začátku snad ani podporu adresářů.

> Jak jsem psal dříve, dlouhé názvy souborů (mezery a diakritika) na unixech působí řadu problémů.

Zjevne je, ze nazvy souboru s mezearam a diakritikou pusobi problemy vsude. At uz jde o neosetrene shellove skripty v Unixu, nebo o programy pouzivajici ANSI rozhrani ve Windows (treba Total Commander).

Jediny rozdil je v tom, ze dle Laela Ophira je neosetreny skript v Oracle jasna ukazka, jak to v Unixu nefunguje, zatimco druhy pripad je pouze bug v programu a ve Windows vsechno funguje idealne.

Bohužel v případě Linuxu nastává tento problém už s řadou skriptů či aplikací, které jsou součástí distra.

Mezery v názvech souborů nejsou ve Windows problém, snad s výjimkou Oracle coby portu z unixu. Teď jsem počítal dokumenty obsahující mezeru v názvu, a mám jich ve svém home 1189 kousků. Nakonec dokumenty mám v adresáři "My Documents", a programy v "Program Files". Kdyby s tím byl problém, asi bych si všiml :)

Diakritika není problém ani v ANSI aplikacích, například v Total Commanderu. Výjimkou jsou znaky mimo primární znakovou sadu systému (tedy v ANSI1250 prostředí třeba azbuka). Total Commander je bohužel aplikace psaná idiotem, který si existenci Unicode ve Windows řady NT neuvědomil ani po 15 letech. Ale co chcete od člověka, který ukládal nastavení do adresáře, kde má jeho aplikace binárky :(. Bohužel idiotům nelze zabránit v psaní aplikací; už myšlenku certifikace driverů považuje spousta čtenářů root.cz div ne za fašismus. Upozorňuji, že TC není součástí Windows.

> A když se podíváte na zdejší diskuze, tak se dozvíte, že dlouhé názvy jsou prasárna, kterou slusny unixak prece nepouziva.

Informovany uzivatel vi, ze bugy tohoho charakteru jsou vsude (viz treba ty prilohy v MS Outlook Express, ci soubory v Total Commanderu) a usetri si praci tim, ze soubor pojmenuje bez diakritiky a s _ misto mezer. Neinformovany (nebo extremne tvrdohlavy) uzivatel to tak nedela, a pak se rozciluje nad zabugovanymi programy.

Viz zde: http://www.root.cz/clanky/vifm-spravce-souboru-a-la-vim/nazory/216216/

Cim musi clovek intoxikovat svuj organismus, aby dokazal vyplodit podobnej blabol?

Srovnavat +/- 20 rezervovanych vyrazu s tremi rozsahlymi mnozinami na to snad musi mit clovek vskutku pokrivene vnimani reality.

Nejsíš Windowsama, tento "systém" se základním věcem teprve učí, ale člověka dovede otravit docela rychle.

Naštěstí se vi(m) a podobným excesům dá na unixech vyhnout.

co takhle funkce v .bashrc nebo co ja vim kde:
cd() {
builtin cd "$1"
ls -la
}

No, ale vi bude neergonomické prakticky podle jakéhokoli měřítka...

Pro lidi, kteří mají problémy s myší, zřejmě ne.

Windows se dají kompletně ovládat bez myši, a to daleko lépe, než linuxová GUI. Když se naučíte používat klávesu context menu, a zjistíte že stiskem Alt+podtržené-písmeno-z-mnu to menu otevřete, a tabem se přesouváte mezi prvky v dialogu, tak vám toho už moc nechybí. Srovnejte se učením vi.

Editor vi porušuje zásady tvorby UI, a nic na tom nemůže změnit fakt, že byl nejspíš napsán před vznikem těchto zásad. Samozřejmě kdo je masochista, dobře mu tak. Když jsme u toho, jaký konfigurační balík Vimu splňuje požadavky?

Připomínky k SLES lze jistě zanášet do bugzilly, ale to bych nedělal celé dny nic jiného. Stejně Novell ani nikdo jiný ve světě open source nemá dost prostředků, aby bylo GUI slušně udělané. Celkově neergonomický se týká třeba členění dialogů a plýtvání místem v nich.

Když říkáte, že stačí problém lépe popsat, zkusím to. Po startu SLES 10 SP1 dostanu hlášku, že X11 server nenastartoval. Nabídne mi to logy, ve kterých xserver hledá S3 Trio 64, nenajde ho, a umře. Když se poté přihlásím v textu, a napíšu xstart, xserver najede bez problémů. V YaSTu (který na to spouští sax2) je jako zařízení vybráno SVGA, a předpokládám, že po bootu xserver používá stejný konfigurák, jako při puštění startx (resp nevidím důvod, proč by to mělo být jinak).
Jak jsem psal, jistě se v tom dá hrabat, a problém nějak vyřešit. Ale dávám přednost tomu, když věci prostě fungují.

mate pravdu. GUI v Linuxu je nedodelek. Bohuzel to tak ale *navzdy* zustane protoze dodelat to GUI poradne by stalo nekolik let prace a vynalozene financni prostredky by se nevratili ponevadz vase konkurence muze diky GPL vyuzit vysledky vasi prace zcela zdarma. Kdo by to tedy delal?

Ja taky davam prednost vecem ktere funguji, ponevadz se pocitac pouziva jako pracovni nastroj a nikoliv samoucelne. V linuxu musite resit spoustu veci, ktere ve windows proste funguji, stoji to cas, ktery vam pak chybi ponevadz se misto svemu byznisu venujete nefukcnimu pocitaci.

Stejne je to s kancelarskymi baliky. Spravna otazka je, proc ma linux (nebo open office) jen 1% zastoupeni prestoze je zadarmo. Protoze zadarmo neznamena nejlevneji.

Víte, vy tu stále argumentujete BFU. Ale já i přes veškerou skromnost nejsem BFU a se mnou tisíce jiných. Co vyhovuje BFU nemusí nutně vyhovovat zkušenějším či vyhraněnějším lidem. A UI je přesně jednou z těchto věcí. Pro mne je jednodušší a přirozenější zadávat počítači příkazy, jež mají nějakou logiku a dají se skládat v složitější celky, podobně, jako se dají skládat elementy lidského jazyka. Taková forma komunikace mi připadá mnohem přirozenější, nežli nějaké klikání po obrazovce s myší, kdy si práci můžu ulehčit maximálně tím, že si mohu zapamatovat pro ty nejelementárnější příkazy jakési, často nelogické, klávesové zkratky, nebo si jich pár vytvořit."

Na tohle téma mě napadá jeden moc pěkný citát... "A picture is worth 10K words - but only those to describe the picture. Hardly any sets of 10K words can be adequately described with pictures." Jakékoli grafické ovládání stylem [podstatné_jméno] sloveso (což je asi tak maximum, co klasické windowsoidní GUI umi, i po započtení klávesových zkratek) bude žalostně neúplné proti složitosti úkonů, které ve skutečnosti chce člověk dělat. Pro příklady určitě není třeba chodit daleko. :]

Jenže GUI v 70. letech vznikalo především ve snaze přiblížit počítače obyčejným lidem a dětem. Cílem nemělo být vyhlášení GUI za jediné správné dogma. Závislost pracnosti ovládání na obtížnosti řešeného problému je u GUI inverzní funkcí k "CLI" (nebrat úplně doslova, proto ty uvozovky) - u CLI příznačné "těžko na cvičišti, lehko na bojišti", u GUI přesně naopak.

Já jsem zastáncem používání GUI na místech, kde to má své opodstatnění. Navíc nejhorší, co se může stát, je podřizovat funkčnost programu jeho ovládání. A to je přesně model, který s sebou použití GUI obvykle přináší z hlediska programátora. Tahle věc se snad poprvé objevila u TurboVision či VisualBasicu a od těch dob zbytostněla tak, že ji už mnozí považují za normální a přirozenou.

Nechci vypadat jako člověk, který paušálně odmítá GUI jako takové. Nicméně, když si vybavím některé formuláře GUI, často se mi vybaví ono lidové "dej blbci funkci a vymyslí lejstro". Já opravdu po počítači nechci, aby simuloval komunikaci mezi mnou a jím pomocí lejster či aby svým vzhledem napodoboval ovládací panely různých zařízení typu hifi věž, kancelářský stůl (se svým nepořádkem) apod. Já naopak chci využít tu obrovskou možnost, že počítač se mnou dokáže komunikovat na úrovni, jež je o několik řádů blíže psanému slovu lidského jazyka, nežli lejstro na úřadě. Jazyk se taky nejdříve musíte naučit a není to zrovna zpočátku nic intuitivního, ale získáte mnohem víc, než kdybyste se po zbytek života omezili na komunikaci pomocí kreslení obrázků. Přesně, jak praví ten váš citát...

Já přeci taky GUI paušálně neodmítám. :-) Váš přístup mi přijde velmi rozumný, cítím to hodně podobně.

Od sedmdesátých let se také výrazně změnila skupina lidí, která počítač používá. Dnes nikdo nechce dělat IT, stejně jako nikdo nechce dělat mzdy nebo účetnictví. IT je věc, která firmy stojí peníze, a generuje náklady. Účelem je, aby IT poskytlo co nejvíce služeb za co nejméně peněz. Náklady na lidské zdroje jsou toho důležitou částí. Proč mít liftboye (takový ten hoch ve výtahu, co ho obsluhuje, jestli si pamatujete), který stráví půl roku tím, že se učí editovat textové soubory? Navíc ve chvíli, kdy vlastní editace souborů není primární pracovn náplní daného člověka?

Já jsem necitoval, ale mohu říci tolik, že command line interface, natož třeba Perl, není přirozené komunikaci nijak blízko. Může vám to tak připadat poté, co se naučíte zpaměti stovky příkazů vi, další stovky příkazů shellu (plus jejich syntaxi), tisíce zkratkových kláves, umístění stovek konfiguráků, a až to celé budete pár let používat. Potom to ovšem není tak, že by s vámi počítač komunikoval na úrovni mluveného slova, ale tak, že vy komunikujete s počítačem na jeho úrovni. Na rozdíl ode mne si zřejmě nemyslíte, že jsou to stroje, kdo má pomáhat v práci lidem, a m se jim pizpůsobovat, a vidíte to zcela opačně.
Otázkou je, proč výše uvedené memorování absolvovat, když totéž zvládnete jen se znalostí *principů* (co, nikoliv jak), a se základní znalostí nástrojů.

...command line interface, natož třeba Perl, není přirozené komunikaci nijak blízko.

To je zajímavé, Perl navrhl profesionální lingvista, a jako programovací jazyk založený na přirozeném způsobu komunikace ho navrhl zcela úmyslně. Zajímavé, že i Microsoft něco z toho převzal. :-)

Zato Vám přijde jako přirozenější způsob komunikace myš a ikonky. Mně tedy ne, já si svého času přestal hrát s omalovánkami v pěti letech a v sedmi jsem začal programovat. Nikoli ovšem myší. Jiní lidé třeba neprogramují, ale mluví česky, nikoli piktografickými posunky.

One evening, Master Foo and Nubi attended a gathering of programmers who had met to learn from each other. One of the programmers asked Nubi to what school he and his master belonged. Upon being told they were followers of the Great Way of Unix, the programmer grew scornful.

“The command-line tools of Unix are crude and backward,” he scoffed. “Modern, properly designed operating systems do everything through a graphical user interface.”

Master Foo said nothing, but pointed at the moon. A nearby dog began to bark at the master's hand.

“I don't understand you!” said the programmer.

Master Foo remained silent, and pointed at an image of the Buddha. Then he pointed at a window.

“What are you trying to tell me?” asked the programmer.

Master Foo pointed at the programmer's head. Then he pointed at a rock.

“Why can't you make yourself clear?” demanded the programmer.

Master Foo frowned thoughtfully, tapped the programmer twice on the nose, and dropped him in a nearby trashcan.

As the programmer was attempting to extricate himself from the garbage, the dog wandered over and piddled on him.

At that moment, the programmer achieved enlightenment.

:-)))

Zkuste předložit zdroják v Javě, C# a Perlu člověku, který nemá zkušenosti s počítači, a zeptejte se ho, který z nich mu přijde blíže lidské řeči. Perl to nebude :)

V sedmi letech jsem také začínal. A někdy okolo 17 let věku jsem zjistil, že jednoduché věci je lepší dělat jednoduše. Na vás to nepřišlo?

> To je zajímavé, Perl navrhl profesionální lingvista, a jako programovací jazyk založený na přirozeném způsobu komunikace ho navrhl zcela úmyslně.

A lide by si z toho meli vzit ponauceni a profesionalni lingvisty priste radsi k navrhu formalnich jazyku nepoustet :-) .

V tom případě je dobře, že Perl je velmi neformální jazyk. :-) (Ty jsi Bash-only? ;-))

> Ty jsi Bash-only?

Unixovy shell povazuju za druhy vyznamny a pametihodny odstrasujici priklad z historie programovacich jazyku.

Ne ze bych ho tedy nepouzival, ale tak na veci do deseti radku. Zpracovani textu delam vetsinou v AWKu, komplikovanejsi veci ve Scheme (SCSH nebo Guile).

Takže používáš Emacs? ;-) Teda Guile nemusím, to už radši Gauche. :-] Ale Scsh beru, to je sympatická věc.

Pouzivam.

Tak to jo, já dosud myslel, že jsi vimař. :-)

Já mám stále pocit, že mi nechcete rozumět. Já netvrdím, že se nezměnila skupina uživatelů. Co tvrdím, je to, že stále existuje významná skupina uživatelů, pro něž počítač není nepochopitelný stroj, který je nezbytné vybavit takovým ovládáním, že to pochopí i člověk s IQ 50. Tak mi necpěte do mého počítače to vaše ovládání šité na míru průměrnému uživateli, který počítač ovládá na zcela jiné úrovni, nežli já, a ani si na víc nedělá ambice. Pro mě je takovýto způsob práce s počítačem vysoce neefektivní a nepohodlný a na druhou stranu mi nedělá nejmenších potíží zvládnout pár desítek příkazů a pochopit jednoduchou gramatiku, jež je svazuje dohromady a vytváří z nich komunikační a ovládácí nástroj o několik řádů silnější a robustnější, než vaše GUI vymyšlené na míru technickým antitalentům.

Takže - pokud editace textů pro někoho není důležitou součástí pracovní náplně, tak ať nepoužívá textový editor šitý na míru účelům profesionální a efektivní editace textů. Nikdo ho k tomu nenutí.

Pro VÁS třeba není příkazový řádek přirozený. Pro MNE ano. To, že něco není přirozené pro vás, přece neznamená, že se nenajde někdo jiný, pro něhož to přirozené je.
Pokud jde o vi, tak vás ujišťuji, že žádné stovky příkazů jsem se nikdy učit nemusel. Ty nejzákladnější spočítáte na prstech, další domyslíte z logiky těch základních a zbytek je jen logickou kombinací jednodušších a jejich parametrů v komplexní celky. Vyhledání nějakých specialit v dokumentaci v tomto případě není o nic složitější, než vyhledání dané funkcionality kdesi v hloubi hierarchie menu a formulářů GUI orientovaných editorů, kde se to stejně často bez nápovědy neobejde.
Totéž u shellu - nedal bych tu z hlavy snad ani padesátku příkazů.
Tisíce klávesových zkratek si opravdu, ale opravdu v CLI nebo vi pamatovat nemusíte. Ono jich tam dohromady víc jak 5 sotva bude, dá-li se tomu vůbec říkat klávesové zkratky. Tato prostředí žádné klávesové zkratky totiž ke svému ovládání nepotřebují.
Stovky konfiguráků? Tak třeba v Linuxu ty stovky konfiguráků jsou obvykle umístěny s trochou nadsázky na jednom místě. Je pro mne mnohem jednodušší na tom místě konfigurák najít a zeditovat, než se proklikávat kdesi formuláři a menu, než narazím na to, co potřebuji, a než mi GUI postupně, pomalu poodhalí, co vlastně všechno můžu měnit. Obvykle to právě v GUI bývá rozhozeno na více místech a nezřídka tam, kde by to člověk nejméně čekal. V konfiguráku je vše na jednom místě a pohodlně to v něm najdu. V GUI se to často podobá bloudění bludištěm.
Pokud jde o to, kdo má komu pomáhat, tak jsem přesvědčen, že sednul-li byste si vedle zkušeného uživatele vi a měl se s ním poměřit v rychlosti editace (vy samozřejmě ve vašem oblíbeném GUI editoru), tak to pro vás skončí fiaskem. U mne byl pohled na práci takového člověka důvodem, proč jsem přestal vi(m) nenávidět a začal ho obdivovat. Takže by se jasně ukázalo, že to, co preferuji já, uživateli nakonec pomáhá mnohem více, než vámi preferované přístupy. Jen narozdíl od těch vašich vyžadují určitou počáteční mentální a časovou investici, která se ovšem mnohonásobně vyplatí.

Takže odpověď na vaši poslední větu je jednoduchá - protože se mýlíte. Není tomu tak. Oba přístupy mají své silné a své slabé stránky. Naklikat elektrické schéma je pro mne snažší s pomocí GUI než v nějakém textovém popisu, naproti tomu vytvořit 300 uživatelů na novém serveru na podkladě informací v databázi je pro mne jednodušší s pomocí CLI, nežli se uklikat k smrti (zkušenost s WinNT v polovině 90. let).

Rozdíl mezi oběma přístupy bych charakterizoval asi tak:
- GUI je postaveno na intelektu a předvídavosti jeho autora; uživatelův intelekt a schopnost učit se téměř zcela ignoruje/nevyžaduje; výhodou je prostředí, v němž je extrémně jednoduché na první pohled pochopit, jak dělat jednoduché věci; daň je z mého pohledu nepřijatelně vysoká - razatní omezení extenzibility doprovázené masivním nárůstem komplexity
- CLI naopak spoléhá na tento intelekt a schopnost učit se a dává uživateli do rukou nástroj, jímž může jednotlivé složky systému kombinovat téměř neomezeně do výkonných či datových celků přesně podle uživatelových představ; to vše při zachování jednoduchosti a nenáročnosti

Z toho také plyne, kterým cílovým skupinám bude vyhovovat jaký přístup, nebo - lépe - kterým cílovým skupinám bude který přístup nevyhovovat. Skupina, jíž jsem členem já, nevidí důvod vzdávat se při ovládání počítače své lidské přirozenosti učit se a myslet, ale naopak - tyto schopnosti chce zkombinovat se schopnostmi počítače. CLI mi v tomto ohledu obecně dává mnohem větší prostor, nežli GUI.

Takže si myslíte, že když jednoho uživatele zakládám z GUI, a 300 uživatelů pomocí Excelu, tak je pro mě počítač nepochopitelný stroj? Nebo myslíte, že třeba ovládání MS Office, AutoCadu, Photoshopu, Visual Studia a dalších GUI aplikací je stavěné pro lidi s IQ 50? LOL podruhé.

Zajímalo by mě, jak používáte stovky příkazů, když jste se jich naučil méně než 20 (pokud netrpíte mnohoprstností), a tisíce zkratkových kláves, když jste se jich naučil 5 (ty stovky a tisíce tu někdo uváděl, moje spojení je pomalé, tak to teď nebudu hledat).

Ano, je možné, že po letech deformace unixovými shelly, ovládáním vi, a podobnými příšernostmi, vám připadá logické otevřít konfigurák ve vi a nastavit v něm hodnotu. Mě to připadá jako vyhozený čas, a rozšíření GUI nástrojů (nakonec i na unixech - YaST, SAM, smit a další) mi dává zapravdu.

Jak jsem psal v prvním odstavci, GUI musíte umět používat. Uživatele můžete založit třeba v Excelu, nebo nakonec skriptem stejně jako na unixech (net add user, příkazem for /f tomu nacpete data).

Náš pohled na GUI vs CLI je rozdílný, ale přesto se v něčem shodneme. Já mám za to, že GUI umožňuje dělat jednoduché věci jednoduše. Nevidím důvod, proč by třeba admin měl jednoduché věci dělat složitě jen proto, že je schopen se ty složité věci naučit (viz to ovládání telefonů, o kterém jsem dnes psal). Na druhé straně je pravda, že velmi neobvyklé akce (a mezi ně založení uživatele opravdu nepatří) se GUI dělaj obtížně. Pak je třeba mít buď velmi dobré GUI, nebo použít jiné nástroje. Skriptování, programování i používání command line pak má dobrý smysl. Nakonec já používám i ve Windows command line rád a často. Ovšem jako podpůrný prostředek pro neobvyklé akce, ne pro běžné aktivity.

Ty vaše "výkonné celky" jsou ve skutečnosti triviality, které začínají a končí na command line. Když zkusíte tímhle způsobem provést jakýkoliv task z reálného světa (tedy mimo administraci unixů), tak brzo dojedete. Zaúčtujte faktury z command line, opravte červené oči na fotce (pokud možno lépe, než v tutorialu Gimpu tady na rootu), spočítejte kalkulaci nákladů na zakázku v tabulkovém kalkulátoru a vložte výsledek do dokumentu word processoru, založte emailový účet v KMailu, vyrobte zákazníkovi náhled střihů vlasů podle dodané fotografie (to dělají kadeřníci), zarezervujte si letenku. zjistíte, že v unixech naprosto můžete se skvělou efektivitou... administrovat unixy, což je v podstatě zbytná činnost, které bychom se jako IT obor nejraději zbavili (myslím administrace celkově).

Ano, někdy mi to tak připadá. Ovládání MS Office je z mého pohledu skutečně ENORMNĚ nepohodlné a neefektivní. Přesně, jak tu někdo poznamenal - jednoduché věci dělá ještě jednoduššími, složité ještě složitějšími. Od lidí jakou jsou sekretářky se asi nepředpokládá rozsáhlé využívání všelikých možností, jež MS Office nabízí - jednoduché věci jsou tedy ještě více zjednodušeny. Čím to je, že 90% uživatelů nepoužívá více jak 10% funkcí MS Office? Těch 10% je přesně ta část, která je jednoduchá.
Jinak opravdu nevím, jak byste pomocí Excelu chtěl ve WinNT 3.něco nebo kolikátá to byla verze přidat 300 uživatelů, když jediná možnost přidání uživatele byla pomocí formuláře pro vytvoření jednoho uživatele. Cosi jako unixový /etc/passwd jistě existoval i zde, ale byl binární a jeho formát nezveřejněný.
A pokud jde o AutoCAD, tak jsem speciálně na téma CADu upozornil jako na vhodný případ použití GUI v minulém příspěvku. Jenže pokud jde konkrétně o AutoCAD, tak tam autoři velice správně pochopili, že spoléhat se pouze na GUI je příliš omezující a to, co dělá z AutoCADu skutečně mocný nástroj, je možnost rozšiřovat ho v LISPu. A snad je vám jasné, do které kategorie UI tento prostředek jednoznačně patří.

No a jsme u toho - prostředky GUI by taková věc byla zřejmě tak náročná, že i tvůrce GUI na ni raději rezignoval a ponechal to v CLI. Které ovšem u WinNT v polovině 90. let bylo na takové úrovni, že jeho praktická použitelnost byla v podstatě vyloučena.

Jak vidím, tak v pohledu na GUI se shodujeme víc, než jsem si dříve myslel. Můj názor je, že je vhodné obojí vyváženě kombinovat. I při tom klikání schématu ocením, když na příkazovém řádku můžu napsat "bus A(0..24)" místo toho, abych takovou strukturu musel zdlouhavě naklikávat. Zkrátka GUI na běžné jednoduché věci, CLI na speciality. Jenže současný trend je spíše CLI osekávat a do GUI nacpat úplně všechno, a co je přirozeně nevhodné pro GUI, tak složitě "ochcávat", aby to nějak na to GUI napasovat šlo (typicky veškeré konstrukce, vyžadující turingovskou úplnost prostředku k jejich popisu).

Pro administrátora unixů je administrace unixu "task z reálného světa" :-) A takový administrátor Windows pak může promakané CLI nástroje svých unixovýxh kolegů jen tiše závidět. Tedy nevím, jak je to dnes, ale v dobách, kdy jsem se musel potýkat s NT jsem tyto pocity zažíval často. Pokud jde o ty faktury - pokud jich máte na konci kvartálu účtovat tisíce, tak už stojí za popřemýšlení, jak na to ;-) Zvláště, jsou-li na jedno brdo a je třeba u nich měnit jen nějakou položku a ta položka se vyskytuje třeba v databázi skladníka. Pak výhodu CLI nad GUI vidím naprosto markantní. To samé u těch rezervací letenek - pokud by jich bylo třeba rezervovat spousty (což je práce pro letištní personál celkem obvyklá), pak to taky na celou věc vrhá jiné světlo. Tabulkový procesor bych viděl jako jedinečný příklad zdárného propojení GUI a CLI, kdy jednotlivé objekty GUI jsou vzájemně propojeny objekty CLI (tedy výrazy apod.). Ovšem je třeba si uvědomit, že počítače ulehčují práci především při zpracování mnoha dat. Vystavit jednu fakturu bych mohl klidně i bez počítače, v podstatě pro mne pak počítač nepředstavuje žádný větší přínos (kromě archivace). Tu práci mi počítač výrazně ulehčí v okamžiku, kdy jich je hodně a tam taky naplno vystupují možnosti CLI.

U toho vi záleží, co považujete za příkaz. Zda povel, který napíšu v příkazovém módu, nebo ty elementy, z kterých svůj povel sestavím. Pokud to první, pak má vi příkazů teoreticky nekonečně, pokud to druhé, tak si s těmi dvaceti příkazy bohatě vystačím. Vi žádné klávesové zkratky nemá, vi má příkazový mód, kterým klávesové zkratky nahrazuje. Jediné, co by se dalo nazvat klávesovými zkratkami, jsou povely pro přecházení mezi těmito dvěma základními režimy (typicky klávesa ESC a INS), možná by se dalo přijít ještě na něco, nevím, nikdy jsem nad tím nepřemýšlel. Filosofie ovládání je ve vi diametrálně odlišná od "klasických" textových editorů, včetně myšlení u toho - v klasickém editoru je text nahlížen spíše z grafického pohledu (m. řádek, n. sloupec...), zatímco ve vi je preferován kontext (začátek/konec slova, řádku, odstavce, stránky, jiného sémantického bloku (dvojice závorek stejného typu, uvozovek...) apod.) Je mi jasné, že to je šok pro někoho, kdo je zvyklý na ten přímočarý přístup klasických editorů, já jsem nebyl výjimkou. Po prvním seznámení se s vi v učebnici Unixu jsem přemýšlel nad tím, na čem autor takové zhůvěřilosti jel (jestli to bylo LSD nebo něco ostřejšího). Teprve s odstupem času, když jsem odhodil staré předsudky a hlavně na vlastní oči viděl, jakým způsobem se dá s pomocí vi pracovat s textem, když to někdo umí, jsem se o něj začal více zajímat.

Pro vás je editace konfiguráku vyhozený čas, já takovou editaci provedu za nepoměrně kratší dobu, než průměrný člověk s pomocí GUI. Zvláště když danou věc konfiguruji popáté. Nebo když je třeba konfiguraci nějak zautomatizovat, což GUI v podstatě zcela vylučuje. Důvod uvedení GUI nástrojů do unixového prostředí je dle mého názoru stejný, jako jinde - kvůli zvýšení atraktivity pro uživatele, kteří nejsou ochotni se nic učit. Já souhlasím, že takových je dnes většina a byznys je byznys. Ovšem jestli to stačí jako důvod k odstranění klasického negrafického UI, to bych se hádal. Oni totiž ti BFU těžko nějak zásadně počítače mohou dále rozvíjet a pro experty je omezení se na GUI opravdu omezující. Přirovnal bych to k situaci, kdy většina lidí neumí číst a psát - pro ně je určitě vhodnější použít piktogramy "záchod", "východ", "pitná voda" apod., než je nutit učit se číst a psát jen lvůli tomu, aby si mohli přečíst to, co se dá snadno namalovat. Ale pro samotné autory zařízení takto "popsaných" by asi komunikace v piktogramech nebyla příliš šťastným řešením.

Celkem by mě zajímalo, proč vidíte ovládání MS Office jako extrémně nepohodlné. GUI Office 2007 je designované podle Fitts's law (viz wikipedia), přehledně tříděné do záložek, a dá se velmi efektivně ovládat z klávesnice. Třídění na záložky proběhlo na základě sběru dat, který zkoumal užívání funkcí Office u veliké hromady uživatelů. Usability testy vykazují vynikající výsledky. Jediný problém je v tom, že předchozí verze měly ovládání jiné, a lidé si neradi zvykají na novinky.

Jak jste přišel na to, že se od sekretářek neočekává rozsáhlé využívání všelikých možností MSO? Naopak při pozorování schopné sekretářky uvidíte, že MSO neumíte používat zdaleka tak dobře, jako ona. Totéž zjistíte u Excelu, když uvidíte, co s ním provádí finanční ředitel.

Proč si myslíte, že 90% uživatelů MSO využívá jen 10% funkcionality? Máte k tomu nějaké podklady, nebo je to jen urban legend, nebo to soudíte podle sebe? Ono to bude psíše něco typu 60% uživatelů používá jen 40% funkcí. Problém je v tom, že u každého uživatele jsou to jiné funkce, takže nelze ořezat "zbytečné" funkce".

Pokud jde o AutoCad, tak ten se dá rozšiřovat hlavně ve VBA. VBA je jednodušší, lépe se učí, a je rychlejší. Navíc VBA umí v podstatě každý pokročilý uživatel MS Office, což se o LIPSu říci nedá. Viz třeba zde:
http://www.contractcaddgroup.com/VBA/visible/vsibility.htm
Obdobně samozřejmě můžete rozšiřovat MS Office a family (Publisher, Visio), Corel Draw a další. Z VBA můžete používat COM, i řadu funkcí Win32 API, a tvořit UI, takže si můžete vyhrát
(problém je, že řada lidí si hraje dost příšerně, protože umí programovat, ale neumí zacházet s platformou, pro kterou píší, tedy třeba s MSO). Vyjma toho máte možnost rozšiřovat aplikace pomocí pluginů (COM objekty), nebo je skriptovat z externího kódu (VB, C++, .NET, obdobně jako z VBA). Tyto možnosti bych rozhodně nepopisoval jako CLI interface ;)
Windows nejsou unix, a proto umí přidat uživatele více způsoby. Máme dokumentované API pro přidání lokálního i doménového uživatele, máme command line utilitu, a máme GUI.
V Excelu přidáte těch pár set uživatelů mnoha způsoby. Jakožto příznivce unixů může spustit command line utilitu, můžete použít COM objekty (http://www.microsoft.com/technet/scriptcenter/scripts/default.mspx?mfr=true ; http://techtasks.com/code/viewbookcode/378), nebo zavolat Win32 API (NetUserAdd). Vše je samozřejmě dokumentované. Problém je v tom, že neznáte nástroje, které by měl znát každý lepší Windows admin (příkaz net byl ve Windows NT zřejmě od první verze, API NetUserAdd také, ty COM objekty jsou použitelné minimálně od NT4 a možná i dříve).

Uvedený příklad s nástrojem pro opravu DB jsem popsal proto, že pro zřídka používané funkce nestojí za to dělat GUI. Nicméně zkuste scanpst.exe a scanost.exe (je součástí MSO, a nebojte, oboje vyžaduje potvrzení po spuštění), obojí je v GUI. Stejně tak backup, restore a repair MS SQL Serveru děláte komplet v GUI. Je to rychlé a pohodlné. Pro offline defrag Exchange (který by neměl být třeba) ale GUI nejspíš pořád neexistuje.

CLI nástroje ve Windows jsou pochopitelně slabší, než na unixech, protože nejde o primární interface. Ve stutečnosti jsou ale daleko výkonnější, než si myslíte. Usuzuji tak z toho, že ani nevíte, jak založit uživatele z command line. Potom musím předpokládat, že neznáte ani rozšířené options příkazů for, if a set. Útěchou vám může být, že nejste zdaleka sám.

Administrace opravdu NENÍ task z "reálného světa". Administrace je obdobou údržby vozového parku firmy - tedy aktivita, kterou firma sice nechce dělat, a ráda by se jí zbavila, ale nemůže, protože auta musí jezdit, a systémy musí fungovat.

Pokud řekněme generujete faktury, budete to zřejmě dělat v IS, který to má na starosti. Kupodivu z command line neuděláte nic. Když budete faktury vystavovat ručně, skončíte zřejmě u Excelu nebo (v horším případě) Wordu. Kupodivu ani tady s command line nepochodíte. Když budete potřebovat vystavit ručně stovku faktur, nejlépe to půjde, když si vytvoříte template faktury v Excelu, a pomocí Excelu vytvoříte potřebné dokumenty, vyplníte do nich data z DB (pomocí VBA a ADO) nebo z Excelového sheetu, uložíte, vytisknete... Výsledek může v pohodě používat i osoba počítačů neznalá. Command line opět nula. Podobně s ostatními tasky z relálného světa. Až někdo si zarezervujete letenku z command line, dejte mi vědět ;). Bohužel je faktem, že na unixech z command line efektivně jen administrujete unixy.

Počet příkazů a shortcutů vimu tu někdo uváděl v této diskuzi (hledejte "spočítal", možná bez diakritiky, protože to byl unixák). Pokud se vám zdá, že "klasické" editory preferují řádek/sloupec, tak je neumíte používat. Vždyť můžete používat CTRL+kurzor pro pohyb po slovech, řádkách, odstavcích, stránkách, a se shiftem pro označování těchto jednotek (bohužel to řada lidí neumí, protože jsou neschopní se takovou trivialitu naučit). Celý soubor je CTRL+A, mezi závorkami se přechází CTRL+}, se shiftem se opět označuje výběr. Přiznávám, že matching závorek nepoužívám, protože vystačím s pohybem po řádcích a slovech - nestojí mi to za ty dva tři ušetřené stisky klávesy.

Vy rychle zeditujete konfiurák po roce učení se vi, za předpokladu znalosti jeho umístění a jeho obsahu. Já za všech okolností zkonfiguruji věc přijatelně rychle v GUI, a ušetřím si rok a více učení; místo toho se můžu učit principy (co chci dělat, nikoliv jakým příkazem to dělat), protože na těch opravdu záleží. GUI akce se samozřejmě dají automatizovat. Například pomocí Group Policy (nastavíte danou věc z GUI, pro vybrané skupiny uživatelů nebo strojů), nebo pomocí skriptů (včetně command line - viz reg.exe). Jde o to, abyste uměl používat možnosti, které máte, a hlavně o nich věděl. Unixy jste se musel léta učit, ale kupodivu to vypadá, že jste se při administraci Windows nenaučil 4 nejdůležitější příkazy.

Já bych to s tím GUI přirovnal k ovládání těch telefonů, které jsem tu popisoval (podívejte se, psal jsem i o tom, jak to omezuje zkušené uživatele). Účelem je, aby se běžné věci dělaly snadno. To, že neobvyklé věci nelze dělat triviálně, je holt už taková feature počítačů. Ani pro neobvyklé věci ale není třeba se učit vi, bash, awk, hromady příkazů, umístění a obsah konfiguráků, C, a kdo ví co ještě.

Autor vi možná byl na drogách, ale svého času to nebyl špatný interface. Dnes je dobrým interfacem Visual Studio, nebo UltraEdit. Chápu, že takové věci na unixech nejsou.

Jako hlavni nevyhodu ruznych 'klikacich' rozhrani vidim v tom, ze obvykle cloveka nepripravuji na reseni obtiznejsich uloh. Zatimco na unixu se clovek system nauci pouzivat na jednoduchych ulohach a tim ziska znalosti, ktere muze pouzit pro reseni slozitejsich uloh, V GUI systemech tomu tak neni - slozitejsi ulohy se tam resi uplne jinymi nastroji nez jednoduche ulohy a znalosti ziskane resenim jednoduchych uloh jsou k nicemu pro reseni obtiznejsich uloh, cimz vznika bariera.

Jako priklad uvedu zakladani uzivatele - v Linuxu pouziju adduser, kdyz chci vytvorit system, ktery zaklada uzivatele a dela spoustu dalsich veci na zaklade vlastnich konfiguraku, tak proste vyuziju znalosti adduser a spojim ji se znalosti obecneho skriptovani. Kdyz se ve Windows naucim pres GUI pridat uzivatele, a pak chci udelat system zakladajici uzivatele a delajici spoustu dalsich veci na zaklade vlastnich konfiguraku, tak k tomu ziskane znalosti o zakladani uzivatelu pomoci GUI jsou k nicemu a musim pouzit uplne jiny postup.

Ano, máte v podstatě pravdu, jde o nevýhodu GUI. Všimněte si ale, že je to první skutečná nevýhoda GUI, která se v diskuzi objevila.
Existují ale i jiné argumenty. 1) díky GUI můžete dělat věci bez znalosti stovek příkazů, ovládání vi atd; 2) s GUI se snadno naučíte, a se můžete soustředit na principy (co a proč), a ne na konkrétní příkazy (jak). Když se naučíte "co a proč", cestu "jak" už pak snadno najdete.

Když jsme u toho, unixy (POSIX) z nějakého důvodu nemají API pro přidání uživatele. Ono bohužel těch API chybí více. Například pro získání seznamu procesů, správu síťových připojení, správu deamonů atd. Řada věcí je POSIXem definovaná jen na úrovni utilit, a oficiální API neexistuje. Nepovažujete tohle za problém?

To jste si toho všiml brzo. Až když vám to někdo napsal "na plnou hubu". Protiargumenty opakujete pořád ty samé, napůl nesmyslné - co neustále máte s těmi stovkami příkazů? Žádné "stovky příkazů" umět nemusíte. Navíc přístup GUI funguje jen v případě, že to vaše "co a proč" je dostatečně jednoduché. Už vám to tu říkalo spousta lidí, včetně mě, a váš předřečník v tomto vlákně to konečně napsal tak jasně, že jste to dokonce pochopil a uznal. Ale pak jste zase nasadil svou ohranou písničku.

Ne, neexistenci přidávání uživatelů na úrovni API skutečně za problém považovat nelze, jelikož Unix definuje seznam uživatelů na úrovni textových souborů a pro práci se soubory má API dostatečné. Podobné se dá říci i o ostatních vámi zmiňovaných věcech. Z mého pohledu je to řešení mnohem elegantnější a úspornější, nežli těžkopádná řešení ve stylu Windows, snažící se pro každý problém poskytnout nějaké speciální volání API, který velmi omezuje možnost znovupoužitelnosti na základě podobnosti. Proto je taky Windows oproti unixům takové komplikované, těžkopádné, neprůhledné, nespolehlivé monstrum.

Na stránkách The Open Group (ti spravují známku UNIX, a speficikují POSIX compliance test) jsem našel 160 utilit. K tomu přičtěte utility specifické pro daný operační systém, pro X11 atd. Berte v úvahu, že pokud neznáte jméno konkrétní utility, tak jí nemůžete použít. Navíc je součástí seznamu vi, awk a pdobné lahůdky, které se člověk nenaučí za večer (typicky se unixy učí několik semestrů, a znalost studentů je přesto mnohdy tristní).
http://www.unix.org/version3/apis/cu.html

K tomu GUI jsem se vyjadřoval zde: http://www.root.cz/clanky/vifm-spravce-souboru-a-la-vim/nazory/215784/ , viz předposlední odstavec. GUI je omezené stejně jako command line, uvádím tak příklady. To, že command line vám dává nějakou "absolutní svobodu", je jen velká iluze, která končí na první věci, na kterou vám někdo nepřipravil utilitu (viz rezervace letenek, nebo přehrání videa na systému bez podpory multimédií). A jak jsem konstatoval v linku, rozdíl je v principu hlavně v tom, že GUI vám umožní dělat ty předpřipravené věci opravdu jednoduše.

Jestli vám jako těžkopádné řešení připadá například mít API pro poskytování informací o systému (včetně seznamu procesů), ktežto jako elegantní vám připadá v případě potřeby prostě zavolat shell a příkaz ps, tak máme velmi odlišný pohled na věc. Obdobně když máte manaer deamonů (ve Windows service manager), tak můžete z jakékoliv aplikace zjistit stav služeb, zastavit je, změnit kontext ve kterém servis poběží, nastavit akci která se má provést v případě ukončení servisu atd. zdá se vám to nevýhodné proti klubku skriptů, které jsou na každém unixu jiné, a které prakticky vylučují jakýkoliv management služeb? Ono je to spíše tak, že unixy nezavedly věci, které měly zavést už před 25 lety. Uživatelé jsou obětí unix wars :(
Windows mají daleko čirší záběr funkcionality, než unixy, takže jsou logicky komplikovanější. Na druhé straně mají lepší interface, lepší a novější design, a díky tomu se nakonec pužívají daleko lépe (stejně jako komplikovanější auta nebo telefony se kupodivu používají lépe). Po letech používání unixů vám tyto možná přijdou průhledné, ale to mě Windows také. A spolehlivost... ta je dnes spíše o HW (a v případě Linuxu o nedodělcích, a špatných koknceptech typu OOM Killeru).

Jestli vám jako těžkopádné řešení připadá například mít API pro poskytování informací o systému (včetně seznamu procesů), ktežto jako elegantní vám připadá v případě potřeby prostě zavolat shell a příkaz ps, tak máme velmi odlišný pohled na věc.

To by samozřejmě bylo těžkopádné, proto to nikdo nedělá, a používá se tradiční kernelové API, které používá sám nástroj ps. :-) Více viz 'man 5 proc'. Mimochoem, jen tak bokem - co Vás vede k představě, že exec() spouští nehjprve shell a až potom spouštěný program?

"Tradiční kernelové API" bohužel není POSIXové, takže to bude fungovat tom unixu na kterém jste to použil, a jinde jen pokud máte štěstí. Otázkou je, proč tohle (a řadu dalších věcí, jako nahrazení pa-systému terminálových sekvencí, grafiku, správu deamonů a další) neřeší POSIX již 20+ let.

> Nepovažujete tohle za problém?

Neco ano, neco ne. To, ze nektere rozhrani neni standardizovano na urovni POSIXu, ale je standardizovano na urovni Linuxu (treba ziskani seznamu procesu a jejich parametru), za vyznamny problem nepovazuju.

Co se tyce toho vytvoreni uzivatele, tam je to proto, ze uzivatele vytvari administrator - ten to nebude volat z C, ale z shellu (protoze bude mit vlastni skripty pro vytvoreni uzivatele a na to navazane akce) a pro volani z shellu je optimalni.

Když už člověk píše SW pro platformu unixů, což je podle mě z obchodního i technickéo hlediska neštěstí, neměl by ho psát je jeden jediný konkrétní unix, nemyslíte?

Administrátor může používat SW, kterým bude uživatele zakládat. Navíc uživatele může zakládat HR oddělení, stejně jako jim dělá průkazky a karty, zařizuje školení, podepisuje s nimi smlouvy atd.

Administrátor může napsat skript nebo program, který otevře /etc/passwd a provede příslušné změny. Může k tomu použít awk, perl, C, Fortran, Pascal... a v každém z nich se to udělá stejně, jako jakákoliv jiná modifikace souboru. Připadá mi to mnohem logičtější a jednodušší, než u systémů, kde musí luštit, jaké volání API se k modifikaci systémové databáze uživatelů vlastně používá, jaké má parametry, v jakém souboru je k němu interface a jaké knihovny musí kvůli tomu připojit.

Pokud jsem si všiml, tak uživateli v /etc/passwd nenastavíte heslo. Také v /etc/passwd nezaložíte doménového uživatele. A pokud byste editoval soubor /etc/passwd na serveru (pro názornost zkusme editaci páté řádky, nikoliv přidání řádky k souboru), budete muset nějak zajistit, aby ho někdo nepoužil ve chvíli, kdy do něj zapisujete. Při čtení souboru během modifikace totiž systém nedostane kompletní obsah. A v případě, že se s někým sejdete při modifikaci souboru, zřejmě ztratíte část jeho obsahu. To jsou ale obecné problémy konfiguráků, které zdůvodňují použití API.

Přidávání uživatelů lze provést přes COM, a ať si vyberete COM, .NET nebo Win32 API, knihovny už máte.

budete muset nějak zajistit, aby ho někdo nepoužil ve …
Jo to api se už léta jmenuje vipw :)

Protože vám kašlu na záložky a formuláře, byť by byly zorganizované sebelépe! Při psaní textu se odmítám přehrabovat v záložkách a formulářích, jež jsou, jak sám uznáváte, koncipované pro většinového uživatele. Můj způsob uvažování je diametrálně odlišný od toho většinového uživatele. A nejsem sám. Při prohledávání umístění dané funkcionality v menu často musím přemýšlet ve stylu "kdybych byl autorem, kam bych to asi před uživatelem schoval". A když to nenajdu a prohledávám nápovědu, tak si zase musím říkat "kdybych byl autorem, jak bych to asi pojmenoval" když např. selže pokus o vyhledání staletí zavedeného typografického pojmu.

Tak to mi teda ty schopné sekretářky ukažte. Moje zkušenost se sekretářkami je taková, že jim nikdo neřekl, že existuje cosi jako "styl dokumentu" a že by to mohly používat. Pokud musejí editovat dokument, který této vlastnosti využívá, pak se připravte na lavinu stížností, že mají pokažený počítač, protože jim to tam skáče a mění písmo samo od sebe a támhle jim nejde ani odřádkovat. Průměrná sekretářka používá k formátování textu v MS Word tabelátor, mezerník a enter.
Co provádí váš finanční ředitel s Excelem pro mne údajně tak nepochopitelného by mne opravdu zajímalo.

Tak principiálně vzato je lhostejné, jde-li o Lisp či Basic. Obojí je založeno na psaní jazykových konstrukcí, neboli na příkazovém interface.

Pokud jde o ta NT, tak ani telefonát na technickou podporu tehdy nepomohl. Škoda, že jsem tehdy neznal vás, jistě byste mi s tím byl pomohl. Pokud si rozumíme, tak by vám mělo být jasné, že ani ten vámi navrhovaný příkaz daný problém řešit nedokáže. Jediné řešení by pravděpodobně bylo napsat utilitu v nějakém běžném programovacím jazyku a ten příkaz z něj volat analogií Turbo Cčkovského system() či přes API. Opravdu esence elegance a jednoduchosti...

Takže podle vás údržba vozového parku je nepodstatná věc? Nebo jak to mám chápat? Dokud na mnou zmiňovaném pracovišti běžel Unix, tak tam kvůli němu byl v podstatě jeden správce na půl úvazku. Po přechodu na NT tam už byli dva na plný a jejich výplata rozhodně byla za reálné peníze z reálného světa. Právě to, že se vám něco nechce, ale dělat to musíte, je samo o sobě dokladem, že jde o dostatečně reálný problém.

U faktur jste zase u příkazového rozhraní (VB). Neboli opět vyvracíte sám sebe a dáváte zapravdu mně.

U těch editorů mne opět podceňujete. To co tu tvrdíte pochopitelně všechno vím a než jsem začal používat vim, tak jsem toho i hojně využíval. Váš problém bych přirovnal k tomu, že vaše mysl se pohybuje v N rozměrném prostoru, zatímco moje v N+1 a proto neustále nejste schopen ze svého omezenějšího úhlu pohledu pochopit, co mám na mysli. Všechno co tu jmenujete lze podobně triviálně dělat i ve vi a řekl bych, že ty vaše klávesové zkratky jsou také odvarem toho nejzákladnějšího, co lze s textem při editaci dělat (mimochodem jste se je taky musel naučit zhlavy, pokud jste nechtěl neustále hrabat po myši a následně se přehrabovat v menu). Jenže se dá dělat ještě mnohem víc, jen vy si to prostě nejste schopen uvědomovat, nebo vám naučení se používání i jiných "triků" připadá zbytečně, neboť se toho dá dosáhnout i pomocí té "klasické" podmnožiny. No dá, ale dá to víc práce. Ovšem vám to evidentně nevadí - jsou lidé, kterým to vadí. A ti používají např. vi. Ovládání vi bych přirovnal k psaní všemi deseti poslepu nebo ke hře na piáno - když to neumíte, tak vám to může připadat komplikované (než rozluštíte noty, než najdete jednotlivé tóny k zahrání akordu, než si uvědomíte, který prst musí zůstat zmačknutý a který už má hrát zas něco jiného) - prostě nepředstavitelné, že by se tímto způsobem něco dalo zahrát. A vidíte, dá, a je toho hodně a tím víc, čím líp to umíte, neustále můžete zlepšovat svou techniku. Nikdo vás ke hře na piáno nenutí, ale vy se nepodivujte nad tím, že někdo věnoval čas, aby se to naučil, místo aby si jen tak zazpíval nebo zahvízdal, jak to třeba děláte vy, když máte náladu nebo se to povás chce - to je přeci tak intuitivní a jednoduché.
Ostatně i samotná klávesnice je tak neintuitivní, ta písmenka jsou na ní tak podivně rozházená; oč by to bylo jednodušší, kdyby to byla jen jedna řada 26 písmen od A do Z (+pár dalších znaků a řídících kláves). Začátečník by na ní okamžitě našel každé písmeno! Jen pochybuji, že by na tom písaři byli schopni udělat tolik úhozů za minutu, jako na současných klávesnicích.

Základní ovládání vi mi opravdu rok netrvalo. Řekl bych, že průměrně inteligentnímu jedinci na to stačí odpoledne. Pokud by vám to trvalo rok, tak to chápu, že by to pro vás bylo nepohodlné. Jenže pak byste měl vycházet z toho, že vaše schopnosti jsou značně omezené a že se tudíž najde spousta lidí, která vás mnohonásobně svými schopnostmi převyšuje a že tudíž ovládání šité na míru lidem na vaší úrovni jim zřejmě vyhovovat nebude. Neberte to prosím osobně, já také neberu vážně, že by vám zvládnutí vi trvalo rok.

Co pořád máte s těmi léty učení? Vám by trvalo naučit se ovládat Unix léta? Stejně jako vi? No to máte asi opravdu nějakou poruchu učení, jenže takovou poruchou já opravdu netrpím. A myslím, že zdaleka nejsem sám.

Ne, nemáte pravdu! Není to žádná "feature" počítačů. Je to pouze vlastnost vámi preferovaného typu rozhraní. Existují jiné typy rozhraní, které touto vlastností netrpí, nebo zdaleka ne v takové míře. A to je to, co stále odmítáte připustit.

Nedá se říct, že interface VisualStudia by mi vyhovoval. Že vyhovuje vám ještě neznamená, že musí vyhovovat každému.

Takže interface je špatný prostě proto, že se dobře používá běžnému většinovému uživateli? To mi přijde jako dost špatný argument. Stává se tedy pro vás interface vhodný právě tím, že se většině lidí používá špatně? A jak vypadá interface vašeho mobilu - je skvělý proto, že ho nikdo jiný neumí používat?
Když jsme u toho, váš způsob uvažování je odlišný proto, že jste strávil mnoho let tím, abyste si způsob uvažování odlišil, a to tím, že jste se memoroval hromady příkazů, učil ovládání vi, umístění konfiguráků, skriptovat v bashi, awk, perlu atd. Bylo by až s podivem, kdyby to na vás nezanechalo žádné následky. Já k tomu ale tvrdím, že jste mohl ušetřit čas a úsilí, naučit se malý díl konkrétních postupů, a dosáhl byste podobných výsledků. Nakonec vidíte, že se vyjma těch stovek příkazů stejně musíte učit ještě zacházet s GUI aplikacemi, protože v reálném světě s administrací unixů moc daleko nedojdete.

To, co popisujete, jsou špatné sekretářky (moc bych senedivil, kdyby psaly dvěma prsty). Je to jako bych vám psal, že restaurace je místo, kde od vchodu cítíte toaletu, po jídle skončíte v nemocnici, a když se budete tvářit nespokojený, obsluha vás zmlátí. Samozřejmě je možné, že si slušné sekretářky nemůžete dovolit, nebo je prostě nepotřebujete.
Finanční ředitel vám možná předvede ukázku lineárního programování (předpokládám, že víte, že s psaním kódu to nemá nic společného), citlivostní analýzu, předpovědi trendů, vytahá data z DB a bude s nimi dále pracovat. Makléř vám ukáže jak tahat kurzy z webu, používat custom funkce pro analýzu, a jak pracovat s databází. Dobrá účetní vám ukáže, jak generovat bez práce doklady z jiných dokladů, a jak ověřovat konzistenci dat, která by jinak musela procházet dlouhé hodiny ručně (špané účetní tráví většinu času činnostmi, které volají po automatizaci). Další vám ukážou, jak generovat v Excelu reporty vytížení pracovníků, knihy docházky z přihlašovacích dat, jak lze v Excelu vést projekty, plánovat zdroje atd.

O skriptování bych netvrdil, že jde o "příkazový interface". To byste nakonec mohl tvrdit, že Visual Studio je vlastně command line :)

V první půlce devadesátých let bych vám s Windows asi moc nepomohl, tehdy jsem měl raději unixy (než jsem zjistil, že totéž, levněji a pohodlněji lze udělat ve Windows; od té doby jsem je naštěstí téměř zcela zapomněl). Přidání uživatelů jste určitě mohl triviálně řešit spouštěním příkazu "net add user" z Excelu (tlačítko, na něm cyklus do while ... loop, který spouští funkcí shell(command) utilitu net). Minimálně od NT 4, ale nejspíš i dříve, fungovaly ty COM objektové příklady s CreateObject a GetObject. Vyjma toho jste mohl použít Win32 API pomocí Declare Function ve VBA makrech, nebo volat Win32 API přímo v buněk Excelu (CALL("Kernel32","GetTickCount","J!")).

Údržba vozového parku je věc, kterou firma dělat nechce, a jen na ní tratí zdroje. Ideální by bylo, kdyby žádná udržba vozového parku nebyla třeba. Bohužel nějaká třeba je, a tak se auta udržují. S administrací je to podobně: nikdo jí nechce, je to nutné zlo. To samozřejmě nevylučuje relativně vysoké výdělky na takovém trhu ;).
S přechodem na NT máme odlišné zkušenosti. Moje zkušenost je taková, že unixoví admini hledá do zelených obrazovek, cosi kutí, nikdo neví co (možná právě v lynxu píší root), je jich spousta, a požadavky firmy na IT jsou jim poměrně volné. Windows adminů typicky stačí méně, a při zřízení diskového sdílení se méně zaobírají kompilací, editací konfiguráků a integrací s doménou, takže zvládnou mimo jiné s klíčovým uživatelem navrhout strukturu adresářů, založit jí a nastavit na ní permissions. Možná je to pro ně menší zábava, než se samoúčelně rýpat ve strojích, ale dělají to, co firma potřebuje.

U faktur jsme u skriptování. Jak jsem psal výše, za chvíli budete tvrdit, že Visual Studio, nebo C++, jsou "příkazové rozhraní", a tedy vlastně command line :)

Ano, základy editace textu jsem se musel naučit. Konkrétně double click, používání menu, modifikátory Ctrl (pohyb po větších kusech), Shift (označení) a Alt (plus písmeno z menu). Vsadím se, že jste se to musel naučit také. Rozdíl je v tom, že jsem ušetřil ten rok učení se vi a stovek příkazů. Já se dokonce rozhodl, že se takovou příšernost, jako vi, prostě nechci nikdy naučit. Bohužel unixy v základní výbavě lelší editor nemají (co bych dal za MS edit.com), takže se umím pohybovat v textu, mazat, přepisovat a vyhledávat. Fuj, znečistil jsem se tím :(, já fakt nechtěl :((. Když mě bylo trapné tahat ty soubory na notebook, a editovat je v Notepadu.
Nějak mi není jasné, co více se dá dělat ve vi. Zlepšovat techniku můžete v čemkoliv. Já spíš myslím, že deonstrujete takový ten zápal pro věc, který vykazují modeláři u letadýlek, pejskaři u pejsků, nebo pedofilové u dětí. Samozřejmě to také znám, ale vi mě zrovna nebere.
Překvapuje mě, jak popisujete práci s vi. Já samozřejmě vídám lidi pracovat ve vi, ale nepřijde mi, že by byli efektivnější, než já. Nemají IntelliSense, takže s dnešními ukecanými jazyky by se upsali k smrti (zato jistě efektivně). Při editaci textů občas vidím, že udělají o eden dva údery na klávesnici méně, a někdy si naopak říkám "bum klávesa", a oni udělaji chord stylu "bum tss tss bum". Nedaří se mi v té rychosti přesně identifikovat akce, ale třeba zrušení řádku je rychlejší ve vi (esc dd), kdežto zrušení předcházejícího slova ve Wordu či VS (CTRL+backspace). Mám za to, že vi je pomalejší, když je třeba opakovaně přecházet mezi režimy. Nicméně buďme upřímní, dobře napsaný text není o rychlosti. Spisovatelé ani programátoři nepíší zdaleka tak rychle, jako sekretářky nebo písařky.

Klávesnice by na tom mohla být lépe. Například optimalizovaný layout Dvorak se neujal, i když je zjevně lepší, než QWERTY (nebo nedej bože QWERTZ, AZERTY, ITSUKE či QRATV). Klávesnice v jedné řadě není dobrý nápad, protože těch 101 kláves vedle sebe by nebylo nic moc, na hudební klávesnici to by bylo 8.5 oktávy :)

Zvládnutí vi na úrovni, kterou umí, mi zabralo několik desítek minut. Abych se ve vi naučil slušně pracovat, potřeboval bych minimálně několik měsíců. výsledkemm by bylo, že bych nemohl používat IntelliSense, neměl kontrolu pravopisu a gramatiky, a zabil spoustu času učením se něčeho naprosto zbytečného. To snad raději budu studovat dějiny (proč nám sakra neříkali na základní škole, že bájný Minotaurus vznikl pářením dámy jménem Pasiphaë s bílým býkem? o tom bych si tehdy udělal i referát).

Zkuste se podívat, jak budete z command line rezervovat ty letenky, nebo generovat faktury. Jak jsem říkal, na command line můžete efektivně leda administrovat unixy, a to ještě jen pokud dobře umíte konkrétní příkazy. Obecně cokoliv, co nemáte předpřipravené (ať ve formě GUI, nebo formou nějaké command line utility) se dělá obtížně, což uvidíte právě na té rezervaci letenek z command line. Obdobně pokud budete potřebovat řídit projekt (typicky za pomoci Gantt chartu), zjistit vývoj fluktuace zaměstnanců, nebo přehrát video, budete bez správné utility prostě nahraný - na command line, stejně jako v GUI. V tom je velká pravda, kterou většina uživatelů unixů nevidí - jejich naučené znalosti začínají a končí administrací unixů, což oni ve své slepotě vidí jako "můžu udělat cokoliv". Pointa je v tom, že GUI (omezené ve své podstatě obdobně, jako command line) vám umožní ty předpřipravené věci alespoň dělat jednoduše.

S unixy umím do té míry, že udělám cokoliv potřebuji. Nelíbí se mi ale ten koncept. Když to může být komplikované a uživatelsky nepřátelské, tak to tak udělejme, protože čím hůře pro uživatele, tím více je to unix. Když je to profi unix, přidejte "a k ceně na Wintelu připište nulu, ať vidí, že je to unix". V případě Linuxu zase člověk neustále naráží na hromadu věcí, které zjevně nefungují, jak by měly. Obcházet chyby je nakonec know how unixového admina. Například ty dlouhé názvy (mezery a diakritika) působí řadu problémů (viz též moje kritika perlu), i když jsou technicky zcela v pořádku, a každý unixový admin tedy ví, že jejich používání je vlasně děsná prasárna. Když takový název způsobí problém, je to samozřejmě chyba toho prasete uživatele, a ne daného systému či produktu, protože uživatel je vždy až na posledním místě snažení. Sorry, ale počítače jsou tu pro lidi, ne naopak.

Neustále mě překvapuje, s jakou energií jste schopen z názorů a omezených osobních zkušeností schopen destilovat absolutní pravdy... :o) Neustále něco o IntelliSense(TM), jako kdyby "doplňování kódu" a "IntelliSense" byla dokonalá synonyma, a zjevně si tudíž mylíte, že nic jiného než Visual Studio člověku doplňování nenabízí, přestože to není pravda, neustále tvrdíte, že Unixy mají problémy s diakritikou a mezerami v názvech souborů, pžestože to není pravda, a tak dál, neustále tvrdíte, že uživatelé Unixu nedokáží používat GUI, přestože to není pravda...

Doplňování nabízí více IDE. Ani nevím, jestli VS bylo první.
Unixy mají velké problémy s mezerami a diakritikou v názvech souborů. Viz fakt, že Oracle nelze nainstalovat do adresáře s mezerou v názvu. Velká spousta skriptů i alikací je špatně napsaná, takže na mezerách či diakritice zhavarují. A co se stane, když Qt aplikace dostane název souboru zapsaný v ISO 8859-2 (tedy dostane neplatnou UTF-8 sekvenci, přičemž Qt počítá se všemi názvy souborů v UTF-8, a převádí je do UTF-16), to mi také nikdo nevysvětlil.
Uživatelé unixů mě trvale přesvědčují, že s GUI neumí zacházet. Kolikrát jsem jen tady v diskuzi četl věci typu "s vi vyberu jednoduše text mezi závorkami, v GUI bych musel sundat ruku z klávesnice a označovat ho myší", a všichni mohutně přikyvovali. Kolikrát jsem tu četl věci typu "když chci v GUI přidat 30O uživatelů, tak se uklikám, kdežto na command line si napíšu skript", i když v GUI vám ty uživatele ze seznamu založím během pár minut.

Unixy mají velké problémy s mezerami a diakritikou v názvech souborů. Viz fakt, že Oracle nelze nainstalovat do adresáře s mezerou v názvu.

Oracle je Unix? Jestli ne, co z jeho vlastních problémů vyplývá pro Unix? Znám aplikace, které doporučují ve Windows, aby se neinstalovaly do adresářů s mezerou v názvu, znamená to snad, že i Windows mají velké problémy s mezerami?

A co se stane, když Qt aplikace dostane název souboru zapsaný v ISO 8859-2 (tedy dostane neplatnou UTF-8 sekvenci, přičemž Qt počítá se všemi názvy souborů v UTF-8, a převádí je do UTF-16), to mi také nikdo nevysvětlil.

V tom případě má uživatel závažně rozbitý setup a možná by bylo dobré, kdyby si spravil?

Uživatelé unixů mě trvale přesvědčují, že s GUI neumí zacházet. Kolikrát jsem jen tady v diskuzi četl věci typu "s vi vyberu jednoduše text mezi závorkami, v GUI bych musel sundat ruku z klávesnice a označovat ho myší", a všichni mohutně přikyvovali.

Jednak nechápu, jak můžete vidět, jak mohutně kdo přikyvuje, a jestli vůbec kdo přikyvuje, jednak mě udivuje, že dokážete ignorovat takhle jasný selection bias. Lidé, kteří se takhle ozývají, težko budou reprezentativní skupina, protože *tolik* uživatelů Vimu dneska zase není ani mezi unixáři. Na přidání tří set uživatelů - to jen tak mimochodem - není zapotřebí psát skript. Na to bohatě stačí one-liner tak na dvě minuty, a dokonce k tomu člověk ani nemusí být uživatel Vimu.

A vzhledem k tomu, že cílem není ani umět jenom GUI, ani umět jenom CLI (obojí jsou jen nástroje, ne náboženství), ale udělat potřebnou práci v co nejkratším čase, tak mi asi uniká pointa. Většina rozumných lidí včetně mně pro každý úkol používá nástroj, co je nejrychleji dopraví k cíli, jestli je to zrovna CLI, tak použijí CLI, a jestli to volá po GUI nástroji, použijí GUI. Z toho, jak zlomek uživatelů zakládá hromadně účty, extrapolovat, jak všichni uživatelé dělají všechno ostatní a jak snad i vaří kafe, mi přijde trošku odvážné.

> V tom případě má uživatel závažně rozbitý setup a možná by bylo dobré, kdyby si spravil?

Nemusi mit. Nevim jak QT, ale treba GTK implicitne ignoruje locale a predpoklada, ze jmena souboru jsou v UTF-8, i kdyz uzivatel ma jiny locale.

A i kdyby mel, tak to neni duvod, proc by mel program selhat, zvlaste kdyz s tim jmenem vnitrne vubec nemusi pracovat (kdyz ho treba jen predava z jednoho syscallu do jineho, jako treba filemanager, ktery kopiruje ci maze stromovou strukturu).

> jak snad i vaří kafe

Nevim jak na vareni kavy, ale na vareni caje se hodi oneliner:

sleep 180 ; while true ; do /bin/echo -e \\a ; sleep 1 ; done

Nevím jak GTK, ale Qt pracuje s UTF-16 wide chary. Veškeré souborové funkce je vracejí. U názvů souborů na disku se předpokládá, že jsou v UTF-8. Otázka je, co se stane, když jsou například v 8859-2, protože převod do UTF-16 nebude možný.

Samozřejmě i v GTK budete potřebovat název zobrazit, editovat, změnit příponu, a kdo ví co ještě. Problém je tedy v principu podobný.

Jádro problému je potom v tom, že se unixy nijak nestarají, jestli aplikace jede v UTF-8, nebo 8859-cokoliv. Pokud je aplikace stará a neumí Unicode, jede v 8859-cokoliv, a na disk píše názvy, které ostatní aplikace nepřečtou.

> Zkuste se podívat, jak budete z command line rezervovat ty letenky

Kez by se tak internetove obchody mohly ovladat emailem namisto pres web! Podobne, jako se treba objednavaji veci pres SMS.

> Jak jsem říkal, na command line můžete efektivně leda administrovat unixy, a to ještě jen pokud dobře umíte konkrétní příkazy. Obecně cokoliv, co nemáte předpřipravené (ať ve formě GUI, nebo formou nějaké command line utility) se dělá obtížně, což uvidíte právě na té rezervaci letenek z command line.

Hlavni rozdil je v tom, ze u command-line prikazu existuje glue (v podobe jazykovych moznosti shellu), ktery umoznuje efektivne kombinovat predpripravene utility a tim si snadno vytvaret nastroje vhodne pro konkretni situaci.

No, bohužel to nejde.

Ano, na command line můžete lepit. Bohužel mnohdy nemáte hotové nástroje pro běžné činnosti, nebo jsou ty nástroje velmi obtížně použitelné (viz třeba to vi), a bez znalosti konkrétního nástroje se o něm ani nedozvíte (command line vám ho na rozdíl od GUI neukáže). V důsledku toho se musíte hodně učit, abyste pak slepovat nástroje pro triviality. V GUI samozřejmě také můžete lepit, jak jsem ukazoval na příkladu Excelu, Corelu, AutoCadu, a řady dalších produktů. Jenom máte připravené nástroje, se kterými jednoduché věci děláte jenododuše. Na command line děláte vše složitě. A jak jsem psal, omezení jsou v principu stená - když nemáte vhodný nástroj (ať už v GUI nebo na command line), tak je další postup vždy obtížný.

Jenze je tu obrovsky prostor uloh, kterou v unixu vyresim elementarnim slepenim zakladnich nastroju, zatimco kdybych byl omezen na GUI, tak me nezbyde jen hledat presne nastroj na miru (anebo to vlastne vubec nemuzu udelat, kdyz bez znalosti konkretniho nastroje se o nem nedovim :-) ).

Já nemsylím, že by těch úloh bylo tolik. Navíc je otázka, kolik z těch úloh jsou neproduktivní "úlohy pro úlohy", typu administrace systému.

V GUI, jak jsem psal, máte možnost lepit nástroje. Nemyslím, že by byly možnosti slabší, než na command line. Máte k dispozici skriptování, COM objekty, a hromady nástrojů. Mimo jiné si můžete koupit komponenty. Ve výsledku když chcete vkládat čárové kódy do faktur, což neuděláte na command line ani v GUI, tak si koupíte COM komponentu, a za půl hodiny je můžete vesele vkládat pomocí makra, volajícího COM objekt. Na command line neuděláte ani tu fakturu (protože začnete a skončíte admnistrací systému), takže vás čárové kódy nebudou trápit.

Ve výsledku když chcete vkládat čárové kódy do faktur, což neuděláte na command line ani v GUI

Teď jsem napsal zypper in barcode barcode-devel a během deseti sekund jsem měl nainstalovaný generátor čárkových kódů jednak jako knihovnu, jednak jako konzolový nástroj. Proč by kvůli tomu měl člověk kupovat komponentu? :-)

To je případ, kdy vám někdo předem připravil utilitu. Když vám jí nepřipravil (třeba u té rezervace letenek), máte smůlu. Zkuste místo barcodů třeba OCR. Pro Windows koupíte OCR s COM a .NET interfacem během pár minut, a můžete ho použít v čemkoliv počínaje VBS a konče C# (někde mezi tím je také PowerShell). Obdobně můžete koupit medicínský imaging, integrační komponenty v podstatě pro cokoliv, atd. Slovo "koupit" není sprosté, protože autoři SW zaslouží odměnu.

Když jsme u toho, jak výsledné čárové kódy budete vkládat třeba do těch faktur? Zřejmě v GUI, tedy na Linuxu v OOo Calcu. Tam to uděláte jak (v Excelu máte VBA, a bar code generator bývá typicky COM prvek, tedy je to triviálně použitelné)? Nebo budete pracovat s fakurami na command line?

> Navíc je otázka, kolik z těch úloh jsou neproduktivní "úlohy pro úlohy", typu administrace systému.

Jedna z veci, kterou jsem si trivialne napsal v shellu, bylo tagovatko souboru mp3. Jeden skript prosel mp3 soubory v adresari a vygeneroval textovy soubor s tagama, ten jsem v editoru upravil a druhy skript upravil soubory podle tohoto textoveho souboru. Me takove rozhrani mnohem vic vyhovuje, nez vsechny editory tagu, ktere jsem kdy videl.

> Máte k dispozici skriptování, COM objekty,

V okamziku, kdy skriptujete, tak proste nepouzivate GUI, ale CLI. Z definice. A je uplne jedno, zda tim CLI je unixovy shell nebo interpret prikazu VBA.

Takže jste ochoten tvrzení zobecnit tak, že dobrým způsobem editace mp3 tagů je naučit se skriptovat bash, administrovat unixy, a pak si napsat skript? A doporučil byste tento způsob svým rodičům, nebo kolegyním v účtárně?

Kdybych už takovou věc chtěl provádět já, tak napíšu makro ve VBA, které slízne názvy souborů a tagy, uživatel si je může upravit, a pak je nacpe zpátky. Náročnost výroby bude podobná, zásadní rozdíl bude v tom, že výsledek bude schopný použít i člověk, který command line v životě neviděl (protože takových je bohužel většina).

Skriptování je algoritmizace, programování. Command line je taková ta věc s kurzorem, kde napíšete příkaz, stisknete enter, a on se provede. Jsou to dvě různé věci.
Smutným faktem je to, že naučit se skriptovat (programovat) je poměrně náročné, a tedy to umí jen profesionálové. A ani u těch není důvod, aby ztráceli čas psaním skriptů pro věci, které se běžně používají. Co se totiž dělá běžně, pro to už má být nějaký kód napsaný. Příkladem ze světa unixů budiž tasky při správě počítače typu založení uživatele, management swapu atd. V GUI jde v podstatě o funkčně stejný kód, jen vhodněji připravený pro uživatele.

> Takže jste ochoten tvrzení zobecnit tak, že dobrým způsobem editace mp3 tagů je naučit se skriptovat bash, administrovat unixy, a pak si napsat skript?

Ne. Dobre je umet nejaky skriptovaci jazyk, aby si clovek mohl automatizovat bezne delane ukoly na PC. To by melo patrit k zakladni znalosti prace s PC na urovni stredoskolskeho vzdelani. Jestli jde o Bash, Python ci VBA, to uz je skoro jedno.

> zásadní rozdíl bude v tom, že výsledek bude schopný použít i člověk, který command line v životě neviděl (protože takových je bohužel většina).

Proc by ten muj nemel byt schopen pouzit takovy clovek? klikne na ikonku, pusti se mu prvni skript, objevi se mu ikonka reprezentujici textovy soubor, klikne na ni a zedituje si ji v notepadu a klikne na dalsi ikonku.

> Skriptování je algoritmizace, programování. Command line je taková ta věc s kurzorem, kde napíšete příkaz, stisknete enter, a on se provede. Jsou to dvě různé věci.

V kontextu teto diskuse bych to chapal tak, ze jde o spor mezi dvema koncepty - ovladani pocitace pomoci formalniho jazyka (nepresne CLI) vs. ovladani pocitace mimojazykovymi prostredky (nepresne GUI). Pri techto definicich to CLI zahrnuje jak command-line v Unixu, tak editaci textoveho konfiguraku (at uz ve vi nebo v notepadu - nejde o editaci, ale o to, ze ten konfigurak je formalni jazyk), tak skriptovani v VBA.

> Skriptování je algoritmizace, programování.

Skriptovani je vetsinou algoritmu-proste

> Smutným faktem je to, že naučit se skriptovat (programovat) je poměrně náročné, a tedy to umí jen profesionálové.

Naucit se programovat na dobre urovni je narocne. Naucit se programovat na elemtentarni urovni nutne k prevazne vetsine skriptu je trivialni. Stredoskolaci se bezne uci v matematice resit goniometricke rovnice, to je IMHO obtiznejsi nez elementarni skriptovani dostatecne na mnoho uloh.

> A ani u těch není důvod, aby ztráceli čas psaním skriptů pro věci, které se běžně používají. Co se totiž dělá běžně, pro to už má být nějaký kód napsaný.

Pokud je uloha dostatecne jednoducha, jazyk dostatecne high-level a uzivatel ma jasnou predstavu, co chce, tak je casto proste jednodussi a rychlejsi si to naprogramovat, nez ztracet cas hledanim takoveho programu na Internetu a probiranim se mez mnozstvim podobnych programu aby clovek nasel takovy, ktery se dostatecne podoba tomu, co chci.

> Příkladem ze světa unixů budiž tasky při správě počítače typu založení uživatele.

Jiste, samotne zalozeni uzivatele je jednoduche, proto to je take elementarni operace v 'shellovem jazyku' (implementovana programem adduser). Mam treba server a kdyz tam zridim uzivatele, tak chci take zridit mu dve FTP konta (verejne a privatni), HTTP konto, emailovy alias, registrovat SSH klic a zridit soubor s hesly k nekterym sluzbam. Napsat skript, ktery udela vsechny tyto kroky, je trivialni (vyrazne jednodussi nez studovani nejakeho integrovaneho systemu pro spravu uzivatelu) a mohu si ho snadno upravit pro sve potreby. Pak pro zadani noveho uzivatele jen zavolam skript.

Naprostá většina populace skriptovací jazyk neumí, a nikdy umět nebude. Smiřte se s tím, prostě to tak je. Podobně naprostá většina populace není schopná postavit ani náznak technologické linky, nebo provést triviální chemický pokus. Když jsme u skriptování, je to samozřejmě algoritmizace. Už jen zřetězení instrukcí patří do této kategorie. Natož porovnávání, podmínky, skoky, cykly.

Ano, úprava MP3 tagů jak jí popisujete je možná. Ovšem to, co jsem popisoval já, bylo daleko komfortnější. A protože o uživatele jde až na prvním místě... Dál to znáte.

Kdepak, spor je mezi jinými koncepty. Já tvrdím, že počítače mohou dělat spoustu věcí, ale ty často prováděné věci musí být jednoduché. Vy tvrdíte, že má každý nejprve strávit hromadu času a úsilí studiem příkazů a konfiguráků, aby potom dělal jednoduché věci složitě. Praxe jasně ukazuje, kam jde vývoj. Nakonec předpokládám, že tenhle příspěvek vidíte v GUI, odpovídáte na něj v GUI, v GUI čtete a píšete maily, v GUI si zakládáte mailové účty, rezervujete letenky, píšete důvodové zprávy, vystavujete faktury, přehráváte multimédia atd. A z nějakého důvodu tvrdíte, že právě pro administraci systému jedině a pouze CLI. Nezdá se vám to samotnému trochu divné?

Nepodsouvejte mi něco, co jsem neřekl. Já jsem ani jednou v celé diskusi nenapsal, že GUI je špatný interface. Já jsem jen tvrdil, že se k některým věcem hodí lépe a k jiným hůře. Už po několikáté vám říkám, že je mi ukradené, co se líbí většině lidí. Já jim svůj interface necpu. Ovšem této většině se nehodlám přizpůsobovat, neboť svůj typ interface jsem zvládnul na takové úrovni, že nevidím ze svého pohledu v rozhraní pro většinového uživatele žádnou výhodu.
Víte, jaké rozhraní je podle mého názoru skvělé? Takové, s kterým se mi dobře pracuje. Nic víc, nic míň. Nežádám po něm, aby mi lehké věci ještě více ulehčovalo, ani aby se pokoušelo myslet za mě, dokonce ani aby mě nutně muselo ušetřit určité dávky úsilí k jeho pochopení. Nechci aby mě omezovalo, pokud k tomu není objektivní důvod. Chci, aby prostřednictvím něho bylo možné rychle a efektivně realizovat co největší množství mých myšlenek. Zkrátka aby bylo tak jednoduché, jak je to jen pro daný problém nutné, ALE NE JEDNODUŠŠÍ!
Všechno co píšete mne rozhodně nestálo takové úsili, jak by se vám mohlo zdát, ale zato se toto úsilí jeví ještě mnohem nepatrnější oproti tomu, co mi to přineslo. Já nevím, že se vám to zdá tak nepochopitelné, ale mně skutečně nedělá potíže se něco učit. Zvlášť když nejde o žádné biflování, ale učení se praxí.
Jinak do styku s obojím přístupem UI jsem přicházel už od prvního kontaktu s počítači. GUI představoval systém GEOS a zbytek to ostatní (např. CP/M). Jenže příkazový přístup mi prostě vyhovoval více.

Finanční ředitel ani makléř mi očividně nepředvedou nic, z čeho by mi spadla čelist na zem. Nebo co by nešlo udělat i skriptem ;-) A pravděpodobně efektivněji, neboť by se na každou věc mohl použít skutečně specializovaný nástroj - na statistiku, na lineární programování, na řešení okrajové úlohy eliptické rovnice, na Monte Carlo výpočet a co já vím co ještě...

No jistě že programování (ano, zatím ještě i to "vizuální") je příkazový interface :-) Snad proboha nechcete tvrdit, že ne.

Takže přes Excel... Máte pravdu, dostal jste mne. Přidávat uživatele do systému pomocí tabulkového procesoru by mne doopravdy nenapadlo.

No s tou údržbou to je pravda. Proto by měla být co nejlevnější a nejméně pracná.

Opravdu jsou naše zkušenosti rozdílné. Přechod na NT doprovázela neustále nažhavená linka na technickou podporu, jež se nám ovšem při veškerém úsilí na obou stranách drátu nedostávala. Nějakou dobu u nás přebýval i odborník přímo od MS, jehož nejčastější odpovědí bylo "to nejde". Žádosti o řešení provázání s ostatními produkty po týdnu snažení končívaly doporučením nahradit danou věc řešením od MS. Po zakoupení dané věci a marných pokusech o dosažení podobných funkcionalit, jako u předešlého softwaru, k nám byl vyslán expert MS číslo 2 (postupně až N), který konstatoval, že "to nejde". Pokud se přeci jen něco nakonec podařilo, bylo to obvykle podobně krkolomné řešení, jako to přidávání uživatelů přes Excel. Kromě toho se ukázalo, že starý HW nestačí novému OS. Takže po roce snažení jsme měli nové Windows NT a k tomu spoustu SW od MS, jenž jsme původně vůbec neplánovali kupovat, nový HW, rozpočet překročený asi tak dvojnásobně, přičemž nový systém v souhrnu nedosahoval schopností toho starého, jeho spolehlivost byla mizerná a při sebemenším problému bylo prakticky vyloučeno najít řešení svépomocí, a to i pro dva lidi na plný úvazek, prošlé příslušným školením MS. Pokud řešení existovalo, obvykle bylo realizováno expertem z MS, který si celý zákrok draze vyinkasoval a řešení provedl jakýmsi tajemným, s sebou přinešeným MS-interním SW, který ho bez znalosti administrátorského hesla pustil i do míst, o jejichž existenci se nezmiňují ani ty nejdetailnější referenční příručky (určené pro zákazníky).
Mimochodem - na jaké chemikálii byl závislý v MS člověk, jehož napadlo překládat jména excelovských funkcí do národních jazyků? ;-)

Proč za chvíli? Skriptování, C++ apod. snad není podle vás příkazové rozhraní? A co to tedy podle vás je? GUI asi ne.

Zase ta ohraná písnička o stovkách příkazů a roku učení. Nebudu se opakovat, komentováno dříve a ne jednou.
Bylo vyzkoumáno, že lidé obvykle nezmáčknou dvě klávesy najednou, ale že modifikující klávesa je stisknuta o chloupek dříve (často je ten chloupek třeba sekunda) a taky ji o chloupek později uvolní (tady ten chloupek bývá už podstatně kratší). Takže vaše CTRL+klávesa je často na stejné úrovni, jako u vi ESC+příkaz. S tím ovšem, že základní režim vi je editační, takže když zrovna nepíšu nový text, nebo když je příkaz kombinací více povelů, je editace rychlejší. Cvičení techniky u vi je přesně to, že čím dál méně přemýšlím nad tím, "jak" tu editaci provést (najet sem, označit odsud až tam, vystříhnout, najet támhle, vlepit, atd...) a místo toho se soustředím jen na to "co" chci provést (řádek se slovem "for" vrazit před řádek, kde je nebližší "=" nad ním; následující 4 řádky vykomentovat pomocí "//" a na předchozích pěti komentář "//" na začátku řádek naopak zrušit atd...).
IntelliSense už bylo komentováno tuším Rejpalem. Nehledě k tomu, že do vim se dá spousta věci doinstalovat či dodělat svépomocí, když mi to tam chybí. Inteligentní doplňování je jednou z nich.
To byste koukal, jak některým programátorům či administrátorům létají prsty po klávesnici! Já vím, mohli si ušetřit čas potřebný ke zvládnutím této schopnosti, kdyby důsledně používali GUI ;-) (aby ho pak mohli tisíckrát více ztratit ze stejného důvodu :-)

Klávesnice pro univerzální použití je dost těžké vymyslet, vzhledem k tomu, že každý jazyk má trochu jiné vlastnosti. Dvorak je stavěná na angličtinu, QWERTZ je snad výhodnější pro němčinu a u nás taky zdomácněla... vzhledem k tomu, že píši sice rychle, ale ne všemi deseti (tedy všemi deseti ano, ale ne správným prstokladem), tak nedokážu posoudit, jestli je z písařského hlediska lepší QWERTZ nebo QWERTY. Pokud je mi známo, tak uspořádání kláves bylo zvoleno s ohledem na technické možnosti psacích strojů (optimální střídání ramének s literami, aby nevznikaly "zácpy"). Nicméně to vše nemění nic na faktu, že lineární klávesnice podle abecedy by byla velmi intuitivní (ale dost nepohodlně prakticky použitelná).

Záleží, jak intenzivně byste v tom vi pracoval. K tomu dalšímu už jsem se vyjadřoval a jiní též - záleželo by na vás, chcete-li to. Jsem-li nucen něco napsat ve Wordu, pak kontrola pravopisu a gramatiky je tou první věcí, kterou vypínám. A tou úplně první je automatické doplňování, zvětšování písmen po tečce a naopak zmenšování písmen po velkém písmenu a podobné hovadiny, které mne neskutečně rozčilují. Protože stisknout shift když chci velké písmeno a uvolnit ho když chci malé ještě opravdu zvládnu.
Dějiny se klidně učte. Patří to k všeobecnému rozhledu. Nám zase na hodinách literatury nikdy neřekli, jakým způsobem vlastně v Eposu o Gilgamešovi tento tyranizoval své poddané a urucké ženy a proč tím tolik proti sobě popudil bohyni Aruru a jakým způsobem zvítězil nad bytostí Enkidu, poštvanou na něj touto bohyní. A proč tuto operaci s Enkiduem, kterou provedla Šamchat, nazývají polidštění. A jaké že to ta Šamchat uměla vlastně řemeslo...

Tak tedy o té rezervaci letenek - bylo jednou jedno letiště a na něm kdysi v 70. letech přišli na to, že by letenky mohli organizovat pomocí počítače. I koupil se počítač, terminály, operátorky se poslaly na školení a systém začal fungovat. V 90. letech se rozhodli, že provedou rozsáhlou modernizaci. Nový systém byl narozdíl od toho původního uživatelsky přívětivý a operátorky už taky nepotřebovaly zdlouhavé školení - firma ušetřila spoustu peněz a času. Studená sprcha přišla až ve chvíli, kdy se ukázalo, že produktivita práce operátorek výrazně klesla. Otázka zní - hádejte proč? ;-)

Já v Linuxu používám dlouhá jména s diakritikou bez problémů. Ty nastávají až v okamžiku, kdy to vypálím na CD nebo na flashku a chci se na to podívat ve Windows :-) Mýlíte se, když vymýšleli Unix, tak měli na mysli uživatele na prvním místě. Narozdíl od předešlých systémů. Jen holt nepředpokládali, že uživatel nebude ochoten vyvinout ani minimální úsilí se něčemu naučit a něco pochopit. Právě proto, že počítače jsou tu pro lidi a ne lidi pro počítače mne tak strašně rozčiluje, když se mě UI počítače snaží přechytračit, poučovat, navádět mě někam, kam si myslí, že já chci, ale přitom to tak není a tvářit se, že jinak to nejde a že já jsem ten blbej. A já jsem nucen s ním bojovat a hledat různé okliky, jak dosáhnout toho, co chci já a ne toho, co si počítač myslí, že chci (jako s tím přidáváním uživatelů přes Excel).

Takže vaše CTRL+klávesa je často na stejné úrovni, jako u vi ESC+příkaz.

Já hlavně nechápu, proč se absence CTRL+Backspace zmiňuje jako nevýhoda Vimu, když Cream to umí a v "plain Vimu" jsem si to nakonfiguroval a namapoval tak maximálně za patnáct sekund. Vim *umí* CUA, pokud to někdo chce.

Dějiny se klidně učte. Patří to k všeobecnému rozhledu. Nám zase na hodinách literatury nikdy neřekli, jakým způsobem vlastně v Eposu o Gilgamešovi tento tyranizoval své poddané a urucké ženy a proč tím tolik proti sobě popudil bohyni Aruru a jakým způsobem zvítězil nad bytostí Enkidu, poštvanou na něj touto bohyní. A proč tuto operaci s Enkiduem, kterou provedla Šamchat, nazývají polidštění. A jaké že to ta Šamchat uměla vlastně řemeslo...

Pche, Sumerové...ale takoví Egypťané, panečku. :o) Ale do svého Gardinera zatím jen smutně koukám. ;/ Chvílemi mi přijde, že na semitské jazyky jsem tupý. (Rozhodně víc, než na anglosaštinu.)

> Backspace je vlastně na terminálech to stejné jako Ctrl+H

Bylo, kdysy davno. Pak doslo ke 'Great backspace/delete shift' a moderni terminaly generuji ASCII 127 na backspace a nejakou escape sekvenci na delete.

Ctrl+H pro mazani znaku pred kurzorem nekde funguje, ale z uplne jinych duvodu nez driv - aplikace nekde emuluji stare chovani a maji na Ctrl+H nastavene mazani znaku pred kurzorem (zatimco mazani pomoci backspace a driv pomoci Ctrl+H je reseno na urovni terminalove vrstvy v jadre).

Aha, zmatl me pritomny cas v te vete.

Jů, tys' nám povyrostl... :-)))

?

U systému terminálů v unixech mi nikdy nedošlo, proč nebyl zrušen před 20 lety. Základním interfacem by mělo být API pro pár akcí typu přesun kurzoru, změna barvy popředí a pozadí, výpis textu, a možná vyplnit pole znakem dané barvy. Místo toho mají unixy definice desítek až stovek terminálů, ke každému terminálu hromady sekvencí, backspace/delete problém, a výsledkem je neuvěřitelný bordel a hnus. Asi i proto řada aplikací "oficiální" definice terminálových sekvencí ignoruje, a managuje si je po svém (třeba mc). Výsledkem je ale ještě větší chaos.

Bohužel váš oblíbený interface vám připadá skvělý až poté, co jste se naučil ty stovky příkazů, včetně ovládání vi. Veliká investice, jejíž jediným výsledkem je to, že jste schopen administrovat unixy (tj. přidávat a odebírat uživatele, měnit ACL, a analyzovat logy). Věci z reálného světa nakonec stejně musíte dělat v GUI, se kterým pak typicky neumíte efektivně zacházet. U toho mi tvrdíte, že vás podceňuji, ale na druhé straně vás překvapí ukázky použití GUI. Je mi ale jasné, že když jste provedl tak vysokou investici zcelku zbytečně, musíte nyní najít způsob, jak jí obhájit.

Ty stovky příkazů jsem někde popisoval - v Single Unix specification je jich uvedeno 160, a to včetně těch vysoce obtížných typu vi a awk. K tomu přičtěte utility pro managament daného OS, X11 serveru atd.

Jak jsem právě napsal o kus vedle, programování je algoritmizace. Command line interface je věc s kurzorem, kam napíšete příkaz, stisknete enter, a příkaz se provede. Jde o dvě různé věci.

O Excelu jsem tu psal opakovaně i v této souvislosti. Proč ne přes Excel? Umožní vám zapsat data, a umožní nad ně pověsit skript. Je to jednoduché, efektivní, a nesmírně silné (i ve srovnání s command line). Výsledek lze zabalit tak, že ho může používat i idiot. Co tomu chybí? Excel je z mých oblíbených aplikací.

Ano, máme odlišné zkušenosti. Jenom zkusím z vašeho vyprávění vypíchnout několik věcí, které se mi nezdají. 1) Microsoft ČR má odjakživa naprosto minimální počet zaměstnanců, a okolo toho spoustu partnerských firem. Velká firma totiž není moc flexibilní (starý známý problém, viz IBM), a malí pružní partneři to dokáží kompenzovat; je to velmi úspěšný model. Z toho důvodu považuji za nepravděpodobné, že by k vám přišel někdo přímoz MS. 2) Protože se v oboru pohybuji nějaký pátek, tak vím, že interní SW, který vás pustí do utajených míst, kde můžete provést tajemné věci, je nesmysl. Jde pouze o neznalost na vaší straně, a o neochotu vám ukázat, o co opravdu jde.
K tomu "nejde": systémy typu Windows umožňují dělat běžně věci jednoduše. Méně běžné věci jsou o dost složitější, což je na command line stejné (jak jsme si ukázali - nemáte utilitu, tak končíte, stejně jako v GUI). Pokud jsou věci složitější, lidí rádi říkají, že "to nejde". Také to říkají v případě, kdy daná věc není dobrý nápad. Například pokud chcete, abyste na stroji měl nasdílené adresáře v závislosti na přihlášeném uživateli (na unixech s představte NFS exporty podle toho, kdo je přihlášený na konzoli). Spousta lidí bude říkat "to nejde", protože je to z jejich hlediska blbost. Ti, kdo umí (a těch je na světě minimum - zřejmě máte tu čest se mezi takové lidi počítat) vědí, že to jde, a jak to jde. Pak je otázkou, jestli řeknou "to nejde", protože je to blbost, nebo jestli řeknou "myslím, že je to blbost, ale za cenu XYZ to máte mít". Když totiž řeknou to druhé, tak vás zřejmě zákazníka zavedou do bažin jeho vlastních nesmyslných a protichůdných požadavků, ze kterých se pak budete těžko vymotávat.

A když jsme u zkušeností, tak přidám svojí zkušenost. V organizaci, kde jsem pracoval, řádila společnost Digital Equipment Corporation. Proto vše jelo na Ultrixu. Když se zkoušely PC servery tehdy s Novellem a Lantasticem, upozornili pánové z Digitalu odpovědné pracovníky, že tyhle PC servery jsou pěkný šmejd, a díky tomu mohou způsobit blíže neurčené problémy na síti, které by se potom odstraňovaly velmi draze ("víte, měli jsme již takový případ... velmi drahé..."). Tomu se říká FUD, a jde o formu biče. Pravidelná pozvání pana IT ředitele na kongresy do USA potom byly jistou formou cukru. Doba se pohnula, přišlo OSF/1 (rozdílem byl hlavně xterm a xclock), a s ním nová verze file serveru Digital Pathworks. Servery byly o řád dražší, než PC servery, a nakoupilo se jich cca 20, aby mohly být potroušené po té naší domovině, a složit jako file a mail servery. Bohužel klienti Digital Pathworks se od serveru samovolně odpojovali, což u tehdejších DB systémů založených na FoxPro a dBase IV nedělalo moc dobrotu. Digital následně vydal asi 10 patchů, které měly jako jediný výsledek to, že se problémy logovaly (některé revize problém logovaly, jiné ne, občas se drobně změnila hláška). Protože tehdy nebyly všechny servery síťově propojené (kvůli mailu se ale propojení časem plánovalo), těch cca 10 revizí znamenalo pro adminy hromady cest po republice. S příchodem Windows 95 u Digital Pathworks dokonce fungovaly dlouhé názvy, ale bohužel bez češtiny. Na potvoru české Windows 95 zakládaly nový adresář vždy jako "Nová složka", a ten Pathworks sežraly, ale už nevrátily, takže na síťových discích byly desítky až stovky adresářů "Nová složka (číslo)". Podpora Unicode předpokládám nakonec ani nepřišla. Samostatnou kapitolou byl vývoj serverových aplikací, přece jen FoxPro není ideální prostředí. Ovšem Oracle Forms k němu má také daleko (krásný terminálový interface, zastánci unixů by si přišli na své). Vyjma šílené ceny se jako problém ukázala náročnost vývoje. Co trvalo ve FoxPro napsat jeden den, trvalo v Oracle Forms minimálně týden, ale spíš déle. Výsledné aplikace byly samozřejmě výrazně méně komfortní, a uživatelé je odmítali používat (nebylo jim to nic platné). Vzniklo oddělení o cca 10 lidech se zkušenostmi se sálovými počítači (programátoři, vedoucí, sekretářka, testerka), které non-stop vyvíjelo informační systém, nutno říci bez velkých úspěchů. Mezi tím se staly populárními prostředky typu Visual Basic, MS Access, Delphi, Oracle for Widows, MS SQL Server; file servery a print servery se dávno přesunuly na Windows NT, zahraniční firmy v ČR běžně jely NT 4.0. Nicméně Digital se statečně držel, a za směšně nevýkonné unixové stroje se platilo o řád více než za stroje na Windows. Několik místních poboček bylo examplárně potrestáno za nákup PC serverů značky Compaq.
Zbytek té historie by byl asi dost nudný (včetně neprokázaných povídaček o úplatcích), nakonec jsem prostě utekl. Uvádím to jako svoji zkušenost s dodavateli unixových systémů, a s unixy jako takovými. Jestli to považujete za odstrašující, nejste sám.

Lokalizace funkcí v Excelu je dost drsná věc. Naštěstí se mě týká jen na jednom stroji, kde jsem si omylem objednal českou verzi MS Office :(. Lokalizace je pro běžné uživatele potřeba, zvláště v ČR kde lidé jazyky neumí, ale pro mě prostě není. Pravda, k anglickým verzím Windows i Office se dají nainstalovat lokalizační moduly, což potěší mezinárodní firmy.

Osobně nemusím cvičit techniku vi, abych nemusel přemýšlet nad editací textu stylem "najet sem, označit odsud až tam, vystříhnout, najet támhle, vlepit". To jsou přece po čase naprosto automatické úkony, které vůbec nevnímáte.
IntelliSense bylo komentováno, a závěr byl ten, že vim toho nenabízí zdaleka tolik, jako VS. Navíc osobně nevidím důvod, proč bych měl dopatlávat takovou věc, jako automatické doplňování. Na to snad nikdo nemá čas.
Mě také létají prsty po klávesnici, a opět k tomu nepořebuji command line, ani vi. Jindy mi létají prsty po myši.

QWERTZ klávesnice u nás zdomácněla proto, že se k nám původně vozily německé psací stroje, kde byla jedna typa nahrazena mrtvou klávesou háčku/čárky. Zatím co na malá písmena a české umístění závorek, uvozovek apod jsem si zvyknul, na QWERTZ ne. Samozřejmě anglický text, kód a administraci vždy jen na US layoutu. Lineární klávesnici můžete vidět u blokových klávesnic s abecedním pořadím, zákazníci to nemají rádi.

Když píšu něco ve Wordu, kontrolu pravopisu a gramatiky samozřejmě používám. Je dost trapné mít v textu překlepy. Automatické doplňování a opravy mají někdy smysl, a jindy ne. Například nahrazování uvozovek za okrouhlé je velmi užitečné. U těch méně užitečných je zcela zásadní, aby šly rychle a pohodlně vypnout. Od uvedení smart tags v Office 2003 to naštěstí jde.
Ano, Epos o Gilgamešovi je zrovna poměrně zábavný. Bohužel školy mají neuvěřitelný talent měnit víno ve vodu. Když jsme například u práva první noci, která má i v na našem území jistou tradici, tak je to věc pohledu. Z hlediska držitele tohoto práva to může být poměrně zajímavé, a kdyby bylo drženo i dnes, stálo by za úvahu nechat se zaměstnat v komunální sféře. Přece jen práce, to jsou i jiné benefity, než peníze. Stravenky, auto, mobil, právo první noci... Ke stáru už jsem pravda monogamní, takže bych dal přednost soukromé sféře. Hrozná je naopak představa, že by nešlo o právo, ale povinnost. No a z hlediska ženy? To bych asi spáchal sebevraždu. Z hlediska muže takové ženy? To by určitě skončilo úplatkem nebo vraždou.

Kupodivu letištní přepážky dnes fungují převážně v GUI. Samozřejmě problémem je interface navrhnout tak, aby byl dostatečně efektivní. Když se to ale udělá správně, nemusíte operátory tak dlouho školit, operátoři dělají méně chyb, a efektivita práce je vyšší. Zdůrazňuji, že může být lepší dobrá command line, než mizerné GUI. Na Linuxu to je vidět dost často.

Vy asi s řadou věcí nemáte problémy. Mě se pravidelně stávalo, že skripty i aplikace havarovaly na názvech souborů obsahujících mezery. Jako příklad jsem uváděl instalaci Oracle, Oracle klienta sqlplus, a velké procento skriptů.
Data na flash disk zřejmě ukládáte na FAT. FAT má dlouhé názvy v Unicode (i na Windows 9x), takže s nimi není jediný problém. Na Linuxu ale není výjimkou vidět experty, kteří si přimountují FAT s code page ANSI1250 (asi někde tu zkratku uviděli, a chytli se toho), a pak na ní zapisují názvy souborů v UTF-8 nebo 8859-2. Výsledkem je, že se znaky v UTF-8 nebo 8859-2 považují za znaky v ANSI 1250, které se pak převedou na Unicode UFT-16. Uznejte ale, že tohle není problém Windows, ale 1) problém uživatele, 2) problém unixů a jejich zacházení s Unicode.
U CD je to zřejmě podobný příběh. Joliet extension používá file names v Unicode, a není důvod, aby dlouhé názvy nefungovaly. Typické chyby neznám, protože jsem na Linuxu nikdy CD ani DVD nepálil.

Jak jsem psal již dříve, chápu, že uvažujete jinak, než jak je navržené GUI. Ale vy zase chápejte, že jste se léta snažil uvažovat jinak, a byl jste holt úspěšný. Lze tedy předpokládat, že vám vyhovují věci, které jsou pro zbytek světa naprosto nepoužitelné. Otázkou je, jaké z toho vyplývá poučení. Třeba "netrapte se učením vi, protože po pár letech takové deformace budete tak mimo, že vám běžné GUI bude připadat jako příšerně neergonomické"?

Ten závěr je subjektivní, ale připadá mi, že o něm není pochyb.

Mame stesti, ze pred tisici lety jeste nebyli usability experti. To bychom asi dodneska psali obrazkovym pismem.

:-D

Já jim říkám "Jů, zabili to!"-experti... :o)

Běžte to vyprávět miliardě Číňanů, plus Japoncům a Korejcům ;)

Upřímně si myslím, že i command line má své místo na tohle světě. Command line aplikace se lehko tvoří, a pro méně obvyklé úkony je jistě lze použít. Méně obvyklým úkonem ale není změna rozlišení obrazovky, nebo přidání uživatele. Může jím být třeba spuštění utility, která opravuje nekonzistentní DB, a která se tedy běžně nepoužívá.

Tak zrovna Číňané přestali psát obrázkovým písmem před pěti tisíci lety. Japonci a Korejci ho nejspíše nikdy ani nespatřili.

Ehm, beru to zpátky. To Egypťané napsali zřejmě první ideografické znaky (nikoli pouhé "obrázky") ve třiatřicátém století před naším letopočtem, již v předdynastické době. Je to nález Güntera Dreyera, pouhých deset let starý, takže se možná do učebnic ještě ani nedostal, ale posunul laťku prvenství ve vynálezu regulérního písma do takového dávnověku, že ani Sumerové se na to už nechytají. U Číňanů to asi proběhlo ještě o nějaké to tisíciletí později. V čínské chronologii se vyznám mnohem méně, než v té egyptské. :-)

Já měl na mysli dnes užívané logografické systémy. Samozřejmě historie je historie, čest památce hieroglyfů, čest památce unixů.

> čest památce unixů.

Jež byly dle vašeho názoru překonány čím?

VMS, OS/2, Windows řady NT, MacOS (který má pravda díky technologické idiocii společnosti Apple unixové vnitřnosti, protože sama nebyla schopná dát dohromady nic lepšího), do budoucna Singularity.

Já jsem tušil, že vaše odpověď vzbudí úsměv. Nezlobte se na mne, ale tvrdit, že OS/2, Windows NT či MacOS překonávají Unix je skutečně pošetilé. Naopak si troufám tvrdit, že v podstatných rysech nepřinášejí vůbec nic nového a pokud ano, tak je to snaha originálně řešit věci, jež vyřešili autoři Unixu dávno před autory vámi zmiňovaných produktů. Nutno ovšem říci, že autoři Unixu se toho zhostili s mnohem větším úspěchem.
Já netvrdím, že Unix je zázrak všech dob a nic lepšího nemůže být dáno dokupy. Ovšem OS/2, NT, či MacOS mohou Unixu konkurovat jen ztěží, a už vůbec nemají ani v nejmenším potenciál na jeho překonání. Ze stínu Unixu nemají a nikdy nebudou mít šanci vystoupit.

Totéž můžete úspěšně tvrdit o unixu, který také nepřináší nic zásadně nového. Vždyť Unics byl započat jako koncepčně zjednodušené pokračování Multicsu.

OS/2, Windows a Mac změnily svět, a dostaly počítač na každý stůl. Unixové workstation s vi se to kupodivu nepovedlo. Windows řady NT navíc přišly s výrazně novější technologií (včetně zabezpečení, GUI a grafiky), a porazily unixy na trhu. Můžete si všimnout, že Windows dávno počtem instalací daleko předčí unixy (samozřejmě i na serverech).

Z historického hlediska jsou dnes unixy ve fázi posledního výprodeje zdarma. Jak jinak chcete říkat tomu, že tržní podíl unixů od uvedení NT neustále padá, a situace došla tak daleko, že je unix (Linux) už dokonce zdarma? A co vás více přesvědčí, než fakt, že lidé dávají přednost placenému OS před unixem zdarma?

Z historického hlediska jsou dnes unixy ve fázi posledního výprodeje zdarma. Jak jinak chcete říkat tomu, že tržní podíl unixů od uvedení NT neustále padá, a situace došla tak daleko, že je unix (Linux) už dokonce zdarma?

Unixy byly odsouzené ke ztrátě velké části tržného podílu především proto, že jejich dodavatelé byli arogantní náfukové. Proto ani Windows, ani Linux neměly problém se zabráním slušné části serverového trhu. Podobně to přeci dopadlo i na poli hardwaru - kdo vyloženě nemusí, koupí PC server, a k iSeries nebo podobným strojům se sahá vlastně v případě nutnosti.

A co vás více přesvědčí, než fakt, že lidé dávají přednost placenému OS před unixem zdarma.

A o čem by nás měla přesvědčit skutečnost, že firmy vyžadují určitou úroveň podpory, který je placená? To zní skoro jako tautologie. :-) To u systému zdarma samozřejmě nedostanete, pokud si to nezařídíte třeba u dodavatele HW, jak to nabízí Hewlett-Packard s Debianem. Jinak firmy většinou samotný OS kupují.

Unixy především zastaraly. V půlce osmdesátých let to ještě pořád byly super systémy. Tehdy byl čas na zavedení managera deamonů, API pro správu systému, postupné zavádění grafiky, zrušení předpotopního systému terminálů, implementaci bezpečnostních features, a opravu bezpečnostních děr (jistě pamatujete vlnu buffer overflow útoků). Díry se podařilo zalátat (byť je jich pořád požehnaně v celém SW průmyslu). Bohužel reforma unixů nepřišla, a výrobci raději bojovali o velké peníze, které z unixy přinášely. Potom přišel MS, a nabízel stroje se snadnou správou, novější technologií, a za desetinu ceny či levněji. Kupodivu vyhrál, přes uplácení a šíření FUD ze strany výrobců profi unixů.

Intel HW je masově produkovaný, a ty objemy jsou takové, že cenou nemůže konkurovat prakticky nikdo. Unixy proto zbyly prakticky jen tam, kde se nic jiného nebylo možné nasadit. V první polovině 90. let to byly velké DB, v druhé polovině 90. let už jen 64-bit stroje. A dnes existuje jen málo aplikací, na kterých by bylo technicky nutné nasadit ne-Intel HW. Unixy tedy na pár místech pořád musí být, na některých místech je drží zvyk, a na dalších místech nulová pořizovací cena.

Podpora obecně není schopná zaplatit vývoj. Aby se totiž vybralo tolik peněz, jako prodejem licencí, musela by být podpora neúměrně drahá. Pokud by si kupil podporu každý desátý zákazník (dost optimistické číslo), musela by být průměrná cena podpory 10x vyšší, než cena licence SW, abyste měl stejné výnosy (ceteris paribus); a k tomu ještě přičtěte cenu té vlastní podpory. Samozřejmě podporu může u open source poskytovat každý, a nemusí platit drahý vývoj, takže by vaší drahou podporu nikdo nekoupil.

Na kolik stolů dostal počítač OS/2, systém, který Microsoft opustil a IBM úspěšně pohřbila? ;-)

to je dobrý point ;)

To bych tedy v žádném případě netvrdil. Buď neznáte Unix, nebo Multics. To byly dva naprosto odlišné projekty. Především po koncepční stránce.

No zajímavé kriterium kvality OS. Neřekl bych, že to byla zrovna zásluha kvalit MS-DOS či Windows, co dostalo počítač na každý stůl. A OS/2 jste zřejmě mínil jako vtip. V tom případě by se dalo říct, že software ZX Spectra a C64 svými kvalitami drtí Unix, jelikož jen C64 se prodalo 30 milionů. To se totiž unixové stanici taky nepovedlo. A řekl bych, že se to nepovedlo ani IBM PC s MS-DOSem či MacOS na Applech.

Windows NT bezpečnější než Unix? Že by další pokus o vtip? GUI bylo převzaté z Windows 3.1.

Proč by Linux nemohl být zdarma, když byl od samého počátku produkován nadšencem pro potěšení jakožto freeware? Jak to souvisí s marketingem? Víte, tohle opravdu nefunguje jako když má Kaufland výprodej ;-)

Multics: protection rings (dokonce 8 jich bylo), shared memory multiprocessor, memory mapping, dynamické linkování, access control listy, deamony, terminálové UI, hot swapping (aka on-line reconfiguration), podpora více procesorů, hierarchický FS, symlinky, kvóty, nebyl psaný v ASM, měl monolitický kernel. Co tedy unix přinesl tak převratně nového? Byl jste to vy, kdo psal o NT : "v podstatných rysech nepřinášejí vůbec nic nového a pokud ano, tak je to snaha originálně řešit věci, jež vyřešili autoři Unixu dávno před autory vámi zmiňovaných produktů". Opravdu vám nepřipadá, že totéž lze říci o vztahu unix-multics?

NT měly od začátku access control listy, a od začátku používaly challenge/response autentizaci. Unixy v té době používaly systém rwx bitů, telnet, FTP, a NFS "zabezpečené" UID a GID.

Linux není vyvíjen nadšenci zdarma. Jak jsem uváděl v jiných diskuzích, například Linux Foundation dostává miliony dolarů ročně od společností IBM, Oracle, Intelu, Fujitsu, AMD, Motorola a dalších. Vývoj Firefoxu zaplatil částečně Netscape, částečně AOL/Time Warner, a nejvíce zřejmě Google. Vývoj OpenOffice platí Sun Microsystems, a nalil do něj v přepočtu miliardy korun. To vše jsou fakta, která lze lehko dohledat (zdroje jsem uváděl i tad na rootu v dikuzích).

"Co tedy unix přinesl tak převratně nového?"

Praktickou použitelnost? Aneb proč tedy pracovní stanice a servery v osmdesátých a devadesátých letech okupoval spíš Unix než Multics?

Já měl za to, že praktickou použitelnost přinesly právě ty Windows, OS/2 a MacOS. Ale řeč byla spíše o technologii.

Jde spíš o to, že Multics přinesl spoustu skvělých nápadů, ale prakticky nikdo ho nemohl používat. Na začítku vývoje měl na hardware takové nároky, že pokud člověk neměl high-end mainframe, měl smůlu. Pak z toho pár firem vycouvalo a nakonec z toho rozhodně obchodní trhák nebyl. Ostatně byl velmi neohrabaný. Třeba PL/I opravdu nebyl zrovna brilantní nápad. Dnes bychom s kompilátorem pro něco takového asi neměli takové problémy - ostatně dnes jsou lidé ochotni používat i C++ - ale to i DEC měl se svým BLISSem víc rozumu, přestože BLISS nakonec porazilo Cčko (což mi je trošku líto).

To všechno je samozřejmě pravda. Ale nic to nemění na to, že Unix je Multicsem velmi inspirovaný. Když mi někdo tvrdí, že Windows NT nepřinesly v podstatě nic radikálně nového, nejvýše nově řešily věci které unixy již nějak řešily dříve, nemůžu nepoukázat na to unix vs multics.

...že Windows NT nepřinesly v podstatě nic radikálně nového...

V mnoha směrech nic nového nepřinesly, spíš uřezávaly. Ale protože ten systém, ze kterého bylo uřezáváno, byl VMS, tak jim to na použitelnosti jen prospělo. (Pokud Unix považujete za systém, který se člověk musí rok učit, než přidá uživatele, co řeknete na VMS? :o) VAX jsem svého času bez manuálu ani nedokázal nabootovat...) Já tedy WinNT nepovažuju za špatný systém, to jen aby nedolo k nedorozumění. :-)

VMS jsem viděl jen zdálky. Původně mě zajímaly 8-bity, CP/M a technologické počítače, od roku 86 PC, od roku 90 unixy, od roku 94 postupně Windows.

Jo a díky za ten poslední odstavec, budu na něj odkazovat lidi na Živě, až se budou smát, že linuxový kernel flikují studenti po večerech. Známému expertovi na Windows snad budou věřit. :o)

Nemusí věřit, mohou se podívat na členy Linux Foundation, a podívat se na výši členských příspěvků (Platinum Members USD 500 000 ročně).

> Linux není vyvíjen nadšenci zdarma.

Podle rozboru od Grega KH je zhruba 20 % vyvojaru nadsenci, 80 % placeni firmama.

> Linux Foundation dostává miliony dolarů ročně

Zrovna Linux Foundation mnoho vyvojaru neplati, vetsina vyvojaru je primo placena tema firmama.

To je možné. Jenže je otázkou, jaký rozsah kódu kolik commitů zaplatí firmy, a jaký napíší nadšenci, kolik je to v počtu řádek, které věci jsou důležité a které jsou vata, atd.

Vidíte, miliony dolarů, a podle vás je to jen malá část financování.

Běžte to vyprávět miliardě Číňanů, plus Japoncům a Korejcům ;)

Upřímně si myslím, že i command line má své místo na tohle světě. Command line aplikace se lehko tvoří, a pro méně obvyklé úkony je jistě lze použít. Méně obvyklým úkonem ale není změna rozlišení obrazovky, nebo přidání uživatele. Může jím být třeba spuštění utility, která opravuje nekonzistentní DB, a která se tedy běžně nepoužívá.

Běžte to vyprávět miliardě Číňanů, plus Japoncům a Korejcům ;)

Upřímně si myslím, že i command line má své místo na tohle světě. Command line aplikace se lehko tvoří, a pro méně obvyklé úkony je jistě lze použít. Méně obvyklým úkonem ale není změna rozlišení obrazovky, nebo přidání uživatele. Může jím být třeba spuštění utility, která opravuje nekonzistentní DB, a která se tedy běžně nepoužívá.

Editor vi máme proto, že v sedmdesátých letech byla taková potřeba, viz například editace souborů přes 75 Bd linku. Dovolím si tvrdit, že dnes jde o přežitek.

Nie je to prezitok. Efektivnejsie je editovat vo VI. Ja som editorov vyskusal viac a VI vychadza najlepsie. To o VI nic nevies tak sa k tomu nevyjadruj.

Netykáme si.

Také jsem zkusil více editorů. Ty, které nemají vizuální interface, jsou samozřejmě vyřadil. Jak jsem několikrát psal, pokud ve vi/vim neznáte konkrétní příkaz, tak danou akci nemůžete použít (a zůstane vám navždy utajená). V GUI stačí vědět, co chcete udělat, a najdete to v menu. Pokud to v menu hledáte často, naučíte se zkratkovou klávesu. Ve výsledku rychle a efektivně uděláte to, co potřebujete často, a s trochou hledání uděláte věc, o které přesně nevíte jak se dělá. Přechod z fáze "hledám to" do fáze "znám to" je přitom automatický a bezbolestný. Srovnejte s vi, které jste se musel pracně učit, a abyste ho používal "intuitivně", musel byste v něm pracovat léta (berte také v úvahu, že mimo svět unixů není editace textových souborů hlavní náplní práce admina).

Koho sa tu snazis presvedcit o com? Stale iba prezentujes svoj nezmyselny nazor pretoze s danou vecou nemas skusenosti. Nie je ti neprijemne sa takto znemoznovat?

Ještě jednou: netykáme si. Jak se řekne slovenky "slušnost" a "vychování"?

Proč je můj názor nesmyslný? Jaké požadavky máte na interface? Abyste mohl dělat jen akce u kterých znáte příkaz, aby nebylo na obrazovce vidět co děláte, a aby program bez školení nešlo ani korektně ukončit?

Pokud jsem to pochopil správně, tak právo posuzovat vi/vim má jen ten, kdo jej používá denně po dobu 5 let a více?

Tvoj nazor je nezmyselny lebo o danej veci nic nevies. To ako keby si prisiel za pretekarom od Ferrari a zacal mu rozpravat aka je Skodovka skvele auto a to jeho Ferrari nestoji za nic lebo to nema poriadny kufor a ze ty sa predsa nemozes mylit lebo si to myslis. A tych gombikov co je na volante a ked neviete ktory co robi lebo to na nom nie je napisane to je ale debilny interface. A naviac to robis na fore kde chodia iba vodici formul.
Fakto to nevidis ako sa strapnujes?

Zkuste se třeba vyjádřit k tomu, co jsem psal. Takhle se jen ztrapňujete.

No, v podstatě bych se pod tohlea si podepsalo dost lidí. V jednodušším programu se vždycky dost pracuje. A to, že Vi(m) bez manuálu dokonce nemáte šanci ani ukončit(!) asi nemůžete popřít. Dost začátečníků si to samo vyzkoušelo. Osobně je tenhle dinosaurus první věcí, kterou vyhazuju z nainstalovaného systému. Kdysi na PP06 a 486SX (když ještě po trojhmatu smrti automaticky nevyskakoval eNTéčkový task manager) jsem si osvojil averzi k věcem, které se nedají ukončit jinak než restartem...

Ano, vidím to stejně..

Vi(m) bez manuálu dokonce nemáte šanci ani ukončit(!)

ja vam nevim, kdyz spustim vim, tak to pise:

type  :q<enter>               to exit

kdyz dam ctl+c

Type  :quit<enter>  to exit Vim

a kdyz dam F1, tak se doctu

Close this window:  Use ":q<enter>

nicmene, myslel jsem, ze schopnost cist (a psat) je docela zasadni prekondici pro pouzivani textoveho editoru

To víš, LOovi není v argumentaci nic svaté, leckdy ani pravda nepřežije konfrontaci s jeho vehemencí. :]

Není to nějaká opačovaná verze? Nejsu slepé jak aptrona (úplně). Taky je možné, že to za ten rok a půl, co mi to naposled vytřelo zrak, konečně trošku zcivilizovali :)

Tohle je tam minimálně od pětky, jestli mě paměť sakra nešálí. :]

Nejspíš ano.