Vlákno názorů k článku Ohřejte studené světlo svého monitoru a šetřete oči od Lael Ophir - Myšlenka je to pěkná, a pokud pro uživatele...

Gimp bude v souladu s filozofií Unixu vidět pouze člověk, který by viděl soulad s filozofií Unixu u command line utility kombinující sed, awk a grep. V duchu "dělá jen jednu věc, zpracování textu".

Jasně. Takže v důsledku máte pomalé čtení konfigurace, ultra-pomalé změny konfigurace, nefunguje vícenásobný přístup, používáte spoustu formátů konfiguráků... Ale jinak to určitě má samé výhody, akorát se mi žádné zrovna nevybavují.

Rozhodně bych netvrdil, že práce s konfigurací je na Linuxu rychlejší než ve Windows XP :)
BTW vám se Linux bez problému probouzí z hibernace? Mě se out-of-the-box neprobouzela ani jedna instalace, některé se ani nehibernovaly. A když se mi podařilo hibernaci rozběhat, nefungovala po probuzení řada zařízení, včetně toho WiFi.

Co je jednoduššího a rychlejšího,vý­hodnějšího a spolehlivějšího na jednotné konfigurační databázi, kde
- stejně nejsou daný pravidla, jak konfigurovat program a každý programátor si to ve své části stromu řeší podle sebe
- kde se bez extra aplikace (regedit) nedá nic dělat
- kde po změně nastavení systému člověk ztratí půlhodinu rebootem
- kde je všechno v jedné hromadě a při poškození jednoho souboru chcípne 20 aplikací
- kde se vyplní podstatná část RAMky daty z registrů, kde je klidně i konfigurace aplikací, který neběží a registtrace tříd COM, který nejsou v paměti
- kde se místo načtení a parsování 100 řádků textu matahuje 50MB databáze
- kde po instalaci programu není šance dohledat, co všechno program překopal
- kde po odinstalování programu stejně člověk neví, kde zbyl jaký bordel
- kde se jenom hromadí binec a nikdo nemá odvahu to počistit
- kde dodavatel systému zakazuje změny
- kde není žádná dokumentace ani k elementárním věcem
?????
Tučňák má textový konfiguráky. Každý je možná v jiným formátu. Ale jsou tam komentáře, popis, co ta volba dělá a parsování malýho texťáku je rychlejší, než u velké binárky. Když otevřu konkrétní soubor, vím, že nastavuju konkrétní program. A můžu každou spuštěnou službu nezávisle restartovat s novým nastavením. A pomocí cp si můžu soubor zazálohovat a hned obnovit bez desetiminutovýho vytváření bodu obnovení nebo exportu binární databáze do textovýho souboru (!!!) s příponou .reg

A co se spinkání týká, tak měl jsem widle doma na pěti strojích, verze 98 (na Cyrixu 233 a Duronu 750), XP Home (C2Duo) a XP Pro (Athlon 64 dvoujádro ,FX4) a ani jeden se nebyl schopný dostat z úspornýho režimu. VŽDYCKY SE NAŠLO NĚCO, PROČ SE NECHYTLA SÍŤ, GRAFIKA, PŘIPOJENÝ USB ZAŘÍZENÍ,... a končilo to tvrdým restartem (cca v 98% případů). Asi to je featura jenom pro vyvolený. S tučňákem se ještě nestalo, že by se neprobudil a že by se něco po probuzení nechytlo...

- Jak si představujete "pravidla, jak konfigurovat program"?
- Samozřejmě Registry můžete používat přes API, z command line (reg.exe, v PowerShellu přes namespaces HKLM: a HKCU:), pomocí regedit.exe (který funguje i z command line), ale hlavně pomocí administračního GUI dané aplikace
- Použití Registry nevyžaduje reboot po změně nastavení, a pokud vám boot trvá půl hodiny, děláte něco velmi špatně
- Registry má transakční mechanismus a Last Known Good Configuration, takže na rozdíl od konfiguráku jen tak nechcípne. Co se asi stane, když zapisujete do nějakého 1MB konfiguráku (koukněte na konfiguraci OOo), a vytrhnete napájení z zásuvky? :)
- RAM se neplní daty z Registry o nic víc, než se u konfiguráků plní RAM daty konfiguráků, které nikdo právě nepoužívá
- Místo 100 řádků textu natahujeme 50MB DB? Wow. Vy těch 100 řádků máte dost možná na 1TB blokovém zařízení, na kterém je FS. A natahujete snad to block device při čtení konfiguráku do paměti? :D
- Jak v konfiguracích poznáte, co kdo překopal? U Registry máte alespoň možnost auditu (o které ovšem admini-lamy nevědí, i když je v NT minimálně 15 let)
- U konfiguráků také po odinstalaci nevíte, co kde zbylo
- U konfiguráků se také hromadí bordel
- Změny v Registry nikdo nezakazuje
- Dokumentace samozřejmě existuje, jen o ní nejspíš nevíte. Nicméně úkolem konfigurační DB je skladovat konfiguraci, ne ji popisovat.

Na Linuxu mají klasické konfiguráky komentáře, protože neexistuje žádné (rozšířené a jednotné) administrační GUI. Koukněte ale do XML konfiguráků OOo, nebo do konfigurace KMailu, Gimpu a dalších. Fakt jsou tam všude poznámky? Ne, nejsou.
parsování malýho texťáku je rychlejší, než u velké binárky - doporučení: jděte někam učit informatiku, nejlépe datové struktury a výpočetní složitost :)
Když otevřu konkrétní soubor, vím, že nastavuju konkrétní program - pokud víte, který konfigurák přísluší ke kterému programu (BTW řada jich ovlivňuje více programů). U Registry je situace úplně stejná.můžu každou spuštěnou službu nezávisle restartovat s novým nastavením - stejně jako s Registry
pomocí cp si můžu soubor zazálohovat - stejně jako můžete provést zálohu registry do .reg souboru (mimochodem i z command line)

měl jsem widle doma na pěti strojích... ani jeden se nebyl schopný dostat z úspornýho režimu - nestavějte si počítač ze šrotu s necertifikovanými drivery
S tučňákem se ještě nestalo, že by se neprobudil a že by se něco po probuzení nechytlo - vidíte, naprostá většina lidí to má přesně opačně

Pánové a je to tu znovu: linux obecně měl tolik let, aby nás všechny přesvědčil, že je lepší než všechny ostatní OS na trhu. A pořád nic :(

Prosím vy všichni linuxáci, přestaňte dělat forky a udělejte jednu jedinou distribuci, která bude konečně pro BFU, do té doby by bylo lepší se nehádat, která platforma je lepší nebo ne.

Díky za informaci, je to hodně obecné - mohl bych poprosit o nějaké veřejné statistiky (to není rýpání, rád bych si o tom něco nastudoval) z oblastí využití:
- na desktopu
- na serveru
- chipy, domácí zařízení, ostatní
Díky :)

BTW, porad jeste se dlazdicove Widle musi rebootovat i kvuli takove kokotine, jako prerazeni do jine workgrupy?

Ano, samozřejmě.

reboot je vyzadovan pouze systemem, ktery jinak nedonutite nacist nove hodnoty - nesmysl. Restartujete servis nebo aplikaci, a načtou se nové hodnoty.

rebootovat kvuli prerazeni do jine workgrupy - nevím, workgroups jsem nikdy nepoužíval. Workgroupu ale nejspíš měníte jednou za život počítače, takže vás to nemusí trápit.

se to posere, tak obnova jednoho konfiguraku je mnohem mensi pruser, nez obnova lehle registry db - jenže Registry kvůli takové blbosti nelehne, protože je transakční, a navíc má tu LKGC. BTW ve Windows máte možnost udělat i transakci se změnami na FS, v Registry a v DB, a pak to všechno najednou commitnout nebo rollbacknout. Unixy se možná za pár dekád naučí transakční zápis konfigurace :)

admin ve firme nebude prase a hodi tam nejaky komentar - jo, v konfiguraci KMailu nebo OOo je těch komentářů spousta :D

Jednou za rok pustim v konzoli prikaz, ktery zbyle konfihuraky zlikviduje - který příkaz vám vybere a odstraní konfiguráky?

Kde (se také hromadí bordel), proboha - zkuste si nainstalovat nějaký SW, nechat ho založit konfigurace v home directory, a pak ho odinstalovat. Konfigurák zůstane.

konfiguráky OOo, nebo do konfigurace KMailu, Gimpu, to jsou aplikace konfigurovane pres GUI - souhlas. A ve Windows je prostě všechno konfigurované přes GUI.

konfigurák přísluší ke kterému programu, se to pozna podle jmena nebo podadresare, ve kterem to je v /etc - u jednoduchých aplikací, kde víc jejich částí nesdílí nastavení. Například nastavení jednotlivých částí balíku OOo také nebude ve všech případech triviální oddělit. Jinak v Registry je situace stejná, struktura je jasně daná.

Problém s hibernací na certifikovaných strojích - těch mi prošla rukama veliká spousta, a neviděl jsem nikdy problém.

Zkurvená, zkurvená a ještě jednou zkurvená antispamová kontrola. Tímto děkuji redakci :D
http://pastebin.com/download.php?i=fMRbjvHH

Když už citujete dpkg, tak byste měl vědět, že v debian-based distribucích lze získat seznam souborů (včetně konfiguráků) a příslušných aplikací. Takže pokud chcete čistit, máte se čeho chytit. Soubory vytvářené automaticky se dnes již dávají prakticky jen do podadresářů /var/, a jen výjmečně nelze u takových souborů určit balíček (skupinu balíčků) ke kterému patří již podle jména souboru nebo adresáře.

A co se týče transakčnosti registru - uložený soubor se může pokazit více způsoby, než jen pádem aplikace nebo vypnutím proudu. Na dnešních desktopech se sem tam vyskytují chyby HW, linux i windows mají pár chybiček v jádře (typicky v málo testovaných ovladačích), které mohou přepsat zrovna ten kousek paměti, který se má právě zkopírovat na disk... Pokud se rozsype struktura binárního souboru, potřebujete na jeho slepení tu strukturu znát, což z vás dělá téměř vývojáře microsoftu. Pokud se něco málo přepíše v textových souborech, dá se to snadno najít okem, a případně opravit. V debianu máte navíc možnost podle md5 souboru zjistit které konfigurační soubory se liší od toho, co bylo dodáno v balíku, a navíc lze balík znovu stáhnout a konfigurační soubor s originálem diff-nout, což pomůže nejen při obnově rozbité konfigurace.

Ale abych to shrnul, myslím, že je zbytečné abychom my říkali, že texťáky jsou lepší a vy, že registry jsou lepší. Prostě v linuxu se to dělá určitým způsobem, který má dlouhou historii, a tudíž byla na spoustu problému již nalezena řešení, a pro windows platí víceméně totéž, jen způsob řešení je jiný, protože (původní) cílová skupina uživatelů/admi­nistrátorů je jiná.

Takže s jistou pravděpodobností víte, k čemu konfigurace patří, pokud autor není prase. No to na Windows přece taky.

Pokud na disku dochází k memory corruption při zápisu na disk, tak jsou konfiguráky nebo Registry tím posledním, co by mě trápilo. Přijdete totiž pochopitelně o FS. Tedy pokud používáte takovou nebezpečnou binární strukturu, jako je FS :)
Podobně byste mohl argumentovat, že máme místo DB používat textové soubory, protože by se DB taky náhodou mohla rozbít díky chybě HW nebo driverů. Jinými slovy váš argument považuji za slabý a čistě hypotetický.
BTW ve Windows máte možnost aplikace nechat opravit, včetně opravy konfigurace. Navíc při čtení z Registry můžete určit default value, takže program nemusí padat jen proto, že mu chybí konfigurace.

Myslím že fakta jsou jasná: konfiguráky se na Unixech se používají jen tam, kde se neprovádí konfigurace přes GUI, a poznámky v konfiguráku pak to GUI suplují. Má to dlouhou řadu nevýhod, ale protože žádné rozšířené GUI pro administraci neexistuje, a konfigurace pomocí konfiguráků a poznámek má tradici (stejně jako třeba vi), zůstává to takhle zacementované. Tedy vyjma nových GUI aplikací, které píšou člověkem prakticky nečitelné XML konfiguráky (OpenOffice), případně mají rovnou binární konfiguraci podobně jako ve Windows (rpm DB).

Co se týče té DB, tak pokud nepožaduju výkon DB, nebo vybírání dat relačním způsobem, tak je opravdu lepší použít texťáky, obnova dat a offline agregace, či zjišťování rozdílů zálohy oproti aktuálnímu stavu, je jednodušší, pokud nejsou data v binární formě. Ostatně na agregaci logů používám csv, a až teprve zagregovaná data strkám z toho csv do DB, protože jednoúčelová agregační utilitka je rychlejší a snadnější na správu, než kdybych dával každou řádku do databáze (byť formou update).

A s konfigurákama je to stejné. Kdokoliv kdo umí naskriptovat základní práci s textem, což se hodí k různým věcem*, umí naskriptovat změnu konfiguráků.

*) parsování logů, pokročilejší prohledávání zdrojáků, práce s daty v textovém formátu, přímá interakce v internetových protokolech (FTP, HTTP, SMTP, IMAP ...), nebo vyhledávání v logu komunikace v těchto protokolech. A to vše patří k běžné činnosti administrátora internetového serveru. V minimální variantě mu na to vše stačí sed, grep, awk, find (a pro ty internetové protokoly ještě třeba netcat aby se spojil na socketu). Ale pokud chce použít něco jiného (python, perl, ruby, ...), nic mu v tom nebrání, a software takto zpravovaný tomu nemusí být nijak přizpůsoben.

V prostředí komerčních desktopů ale není prioritní informace snadno získat, zpracovat a případně upravit, ale naopak prodat uživateli klikací nástroj v sexy balení, aby z toho bylo co nejvíce peněz. Proto tam unixové prostředí prostě není v kurzu. Na serverech je naopak GUI nejen zbytečné, ale navíc, tam kde je k dispozici pouze GUI, tak zabraňuje propojení aplikací skriptíky, které může správce psát bez hlubší znalosti API (a jazyka ve kterém to API zrovna má bindingy) nebo způsobu uložení konfigurace. To jsem měl namysli dovětkem. Prostě cílová skupina uživatelů byla jiná. Dnes už se celkem dá dostat Windows do stavu, že se dají (jako server) spravovat vzdáleně přes SSH a linux se dá dostat do stavu, že se dá používat jako desktop. Ale je u obojího znát, že historie takového použití je kratší, a tudíž je tam více nedořešených problémů.

Takže pokud nebudou mít žádné další požadavky na aplikace/cenu/..., dám na domácí desktop rodičům Windows, a sobě na server linux. Kdybych to prohodil neuměl bych ani jedno uspokojivě spravovat.

Pokud jste si toho nevšiml, Registry má popsanou strukturu, a klíče zdaleka nejsou rozeseté náhodně.

Konfiguráky nejsou vec, kde na jednbom miste najdete kompletni konfiguraci napriklad nejake aplikace. Konfigurace je rozhozena v ruznych vetvich FS, v různých formátech, a to často bez komentaru a dokumentace. Vyznam jednotlivých souborů a hodnot muzete obcas jeste nekde vygooglovat, ale většinou muzete jen hadat podle nazvu, pricemz mnozinu moznych hodnot a vyznam jednotlivych hodnot neznate.

Jinak konfiguraci aplikací máte v HKLM\Software pro stroj, v HKCU\Software pro uživatele, a konfigurace servisů je v HKLM\SYSTEM\Cu­rrentControlSet\Ser­vices. Je to obdoba /etc, ~ a /etc/rc.d. A když jsme u binární konfigurace, tak tu máte na Linuxu také. Například RPM má binární databázi. Na rozdíl od Windows Registry jí ale celkem snadno zboříte.
http://en.wikipedia.org/wiki/RPM_Package_Manager#Local_RPM_installation_database

Konfiguráky jsou komentované prakticky jen v případě, kdy je primárním interfacem pro jejich editaci textový editor. Naopak konfiguráky OpenOffice a dalších aplikací, které se nastavují primárně přes GUI, pokud vím komentáře většinou postrádají. A popis konfiguračních hodnot OpenOffice budete hledat dost těžko. Nakonec proč se tím zabývat, když máte GUI. No a ve Windows máme prostě GUI "na všechno", a postupujeme obdobným způsobem.

Ve Windows samozřejmě najdete konfiguraci přesně tam, kde jsem vám psal (HKLM\Software\, resp. totéž pod HKCU). Kde jinde tu konfiguraci podle vás najdete?

Proto jsem psal "na všechno" v uvozovkách.

Stravite pul hodiny hledanim, kde vsude je to rozesrane - to není tak úplně pravda. Některé věci nelze mít v konfiguraci aplikace. Například pokud vaše aplikace na Linuxu implementuje daemon, určitě ho nesmažete s hlavním souborem konfigurace (/etc/author/ap­p/whatever.wha­tever), protože to bude v /etc/rc.d (případně jinde, podle distra). Ve Windows vám podobně může zbýt v Registry položka ve větvi Services. A pokud vaše aplikace například používá integraci do shellu (řekněme že něco dělá na pravé tlačítko myši v nějakém file manageru, případně má položku ve Start Menu), pochopitelně musí něco zapsat do konfigurace toho file manageru. Osobně nevidím možnost, jak tyhle věci řešit výhradně v konfiguraci dané aplikace. A pokud aplikace nejsou izolované a mají spolupracovat, zápisu konfigurace na různá místa se prostě nevyhnete.

Nicméně neplatné registrace komponent (HKLM\SOFTWARE\Clas­ses\CLSID) se ignorují a nemají vliv na nic. Podobně shell ignoruje extensions, které nelze instancovat. Problém je snad leda u Services, kde přebývající položka vede k upozornění po startu, že daný servis nelze nastartovat.
Takže to vaše půlhodinové čistění je cargo cult daný neznalostí.

V OpenOffice psali konfiguraci do Registry hlavně proto, aby to fungovalo rychle. Pomalý start OO je do značné míry způsobený právě používáním konfiguráků. Ono to totiž není pár hodnot - máte tam například pár konfiguraci tisíců tlačítek na toolbarech. Pak je samozřejmě ultra-skvělé, když to máte v jednom velkém konfiguráku, a potřebujete do něj například zapsat naposledy otevírané soubory, a celý konfigurák kvůli tomu musíte přepisovat. Nedej bože pokud by šlo o konfiguraci nějaké sdílené komponeny, kterou používá víc aplikací. V rámci projektu OO se sice konfigurace optimalizovala, ale pořád je to zdechlé jak mršina. To jsou ty skvělé výhody konfiguráků, o kterých tu pořád básníte. Ve srovnání s tím máte ve Windows Registry s rychlým čtením i zápisem.

Jinak technicky není problém mít v konfiguraci OO komentáře. Akorát to prostě nemá smysl, protože se v těch megabytech konfigurace stejně nikdo nehrabe ručně.

Tím na studeno máte na mysli, že žádná část LO není v cache? Navíc LibreOffice používá by default quickstarter, tedy faktické zavedení LO do paměti při startu/přilogování.

Jinak o problémech s náročným parsováním konfigurace si můžete přečíst tady:
https://wiki.openoffice.org/wiki/Performance/Configuration

Jak jsem už psal, autoři OO provedli optimalizaci (a podle všeho ne jednou), takže výsledek je méně tragický, ale přesto ve srovnání s MSO mizerný. Na Windows podobné problémy s výkonem u konfigurace řešit nemusíme, protože používáme Registry.

LibreOffice má samozřejmě quickstarter i na Linuxu. Pokud jsem správně četl, v recentních verzích je by default zapnutý. Předchozí verze ho měly zapnutý ve verzi dodávané s distry, a vypnutý v generické instalaci (tarball, kompilace). FYI MS Office žádný quickstarter už řadu let by default nepoužívá (v posledních verzích ho tuším ani nelze doinstalovat).
https://wiki.debian.org/LibreOffice

U mě trvá studený start Wordu cca dvě vteřiny, bez quickstarteru.

Děláte si benchmark ve skriptovacím jazyce? Jo, to opravdu pobavilo :D

To je mizerné znovuobjevení? Na rozdíl od unixů nemusíte spustit nevím kolik utilit (které mohou a nemusí být nainstalované, mohou házet lokalizovaný výstup, nemusí být v cestě atd), a parsovat jejich výstupy.

Popisovaný scénář nemá smysl, takže bych to nedělal. Kdybyste to dělat chtěl, tak musíte řešit následující oblasti:
- Řešit jestli aplikace běží a okno není minimalizované. Samotné zjištění, jestli je okno minimalizované, je trivialita (get-process, property MainWindowHandle, Window.FromHandle, property WindowState). Ale pokud nechcete být prase které používá spinning, tak budete muset interceptnout window message, případně použít namespace System.Window­s.Automation.
- Budete muset předat utilitě informaci o tom, že má provést restore barev. K tomu máte spoustu IPC, případně lze použít window message.

Nejjednodušší je ale samozřejmě použít takovou utilitu, která má požadované chování vestavěné.

A hodíte sem ten "v podstatě one-liner", nebo ho alespoň popíšete?

V PS samozřejmě můžete používat externí moduly. Ty "vestavěné" (tj. včetně kompletního .NET Frameworku) mají tu zajímavou vlastnost, že jsou k dispozici na každé instalaci PowerShellu.

Text se poměrně snadno parsuje, k vlastnostem objektů se ale přistupuje ještě výrazně lépe. Navíc umí i jiné typy než string, nehrozí problémy způsobené lokalizací, umí metody a callbacky, není potřeba spouštět na každou blbost hromadu procesů, a hlavně lze PS používat i mimo svět command line. S PS totiž není problém například založit soubor Excelu a zapisovat do něj data, o čemž si s klasickými shelly můžete nechat leda zdát.

xev z X11R7.7 podle man pages nezná parametr -event.
http://www.x.org/archive/X11R6.8.1/doc/xev.1.html
http://www.x.org/archive/X11R6.8.1/doc/xwininfo.1.html

Navíc pokud tomu správně rozumím, tak hooknete všechny X11 events, ty necháte pomocí xev přeložit na text, a vždycky když přijde nějaký event, tak spustíte wmctrl a grep, abyste zjistil id okna, a pak xwininfo, abyste zjistil jeho stav. Těch X11 messages můžete mít tisíc za vteřinu, takže pak tisíckrát za vteřinu vytvoříte tři procesy, které parsují binární strukturu, překládají ji na text, a ten text pak parsujete. To mi přijde jako výborná ukázka toho, proč takové věci rozhodně nedělat v unixovém shellu.

Jak totéž udělat ve Windows:
- Vytvoříte si instanci NativeWindow podle ukázky na MSDN (dole na stránce), akorát instanci NativeWindow vytvoříte buď jako application domain-wide, nebo pomocí NativeWindow.From­Handle().
http://msdn.microsoft.com/en-us/library/system.windows.forms.nativewindow(v=vs.110).aspx
- Filtr si nastavíte zřejmě na WM_ENABLE nebo WM_SHOWWINDOW ; můžete si to vyzkoušet pomocí Spy++, což je utilita, kde můžete v GUI filtrovat window messages.
- Pokud je okno aktivováno nebo deaktivováno, zavoláte API SetMonitorColor­Temperature s příslušnými parametry
http://msdn.microsoft.com/en-us/library/dd692962(v=vs.85).aspx

Na rozdíl od vašeho slepence v shellu je to čisté a nepovede to ke spouštění tisíců procesů za vteřinu. A jak jsem psal, můžete použít UI Automation. V .NETu, nebo klidně z PowerShellu. Koukněte v prvním linku na sekci Event handling, v druhém na příklady.
http://uiautomation.codeplex.com/documentation
http://uiautomation.codeplex.com/SourceControl/latest#samples/UIAutomation/Events/WindowOpenedEvent.ps1

Psát cmdlety pro PS má smysl jen pokud chcete rozšiřovat jeho funkcionalitu. A podobně jako psaní utilit s textovým výstupem to není úplně triviální - musíte trochu vědět, co děláte.

Ano, PowerShell má čtyři verze, a jsou samozřejmě backward compatible. Ta vaše "stabilizace" je ve skutečnosti stagnace.

Errata: man pages jsem nalinkoval ze staré verze X.org, ale v nové xev parametr -event také nezná.
http://www.x.org/releases/X11R7.7/doc/man/man1/xev.1.xhtml

rano sedim za masinou s W8 s PS4 a vecer za Vistou s PS1 - to ještě není nic proti tomu, když ráno sedáte u AIXu a večer u Linuxu :)

ze by nebol kompatibilny ani spatne som ani neuvazoval - doipředná kompatibilita je ve světě SW dost neobvyklá. Těžko být kompatibilní s něčím co ještě neexistuje.

NativeWindow.From­Handle() by měl fungovat i na cizí proces. PS cmlet Get-UIAWindow umí parametr -ProcessName. Ty ukázky samozřejmě spouštějí nějakou kalkulačku nebo podobnou blbost, aby bylo na čem demonstrovat, a chytají okno z objektu procesu.
http://uiautomation.codeplex.com/wikipage?title=Getting%20a%20window&referringTitle=Documentation

Souhlas, skripty jsou často divoké slepence. Ovšem ten co jste předvedl je dost síla i na můj vkus. Mimochodem vám moc nevěřím, že by root window dostávalo tak málo zpráv. Pokud si pamatuji, tak root window je desktop na daném monitoru, a x11 eventy dostane i když po desktopu projedete myší. Navíc v daném scénáři by vám to mělo jet na pozadí non-stop, nikoliv pět minut, a tam už efektivita hraje značnou roli.

Více ke skriptování: práce na počítači dávno nespočívá v děrování štítků nebo honění kurzoru ve vi klávesami hjkl při editaci konfiguráku. Zkuste si v klasickém shellu naskriptovat vytvoření účtu v KMailu (řekněme že to potřebujete pro tisíc stanic), otevření CSV v OOo Calcu a překopání dokumentu podle nějakého vzoru, změnu výchozí velikosti papíru v OOo Writeru, odstranění speaker notes z dokumentu OOo Impress, nastavení konfigurace na defaultní volby ve Firefoxu atd. Klasické unixové shelly se hodí jen pro to parsování textů. Na věci, které se na počítačích dělají dnes, jsou ale krátké.

Proto se tam nastavuje ta maska SubstructureMask, která znamená, že vás zajímají pouze události, kdy se nějaké okno připojí nebo odpojí.

je vhodne, aby bolo nieco tak zakladne, ako shell navrhnute dobre hned na zaciatku - PowerShell také je dobře navržený od začátku. Samozřejmě je dobře, že MS přidává cmdlety a další features.

NativeWindow.From­Handle berie handle okna - vizte Process.MainWin­dowHandle

Tieto aplikacie zrejme ziaden CLI interface neposkytuju - a kdyby poskytovaly, tak vám to nepomůže. Nechcete totiž předat pár parametrů; potřebujete obousměrnou komunikaci. Prostě to chce API.

Ako by ste pracu s KMailom, OO Calcom a OO Writerom (nie s ich MS alternativami) riesil z PS? - OOo umí COM Automation, takže bych to dělal stejně jako u MS Office. KMail pokud vím neexistuje pro Windows, natož aby uměl OLE Automation.
http://www.openoffice.org/udk/common/man/tutorial/office_automation.html

skript co jste předvedl je dost síla; Nepripada mi nijak zvlast komplikovany - to není o to jestli je komplikovaný. Pokud vám připadá jako dobrý nápad běžet na pozadí skript, který spouští pět procesů (pokud správně počítám) při každé X11 event - byť by ty eventy měly být filtrované jak píšete - tak zřejmě užíváte nějaké velmi kvalitní drogy.

nepochybne opodstatneny prejav dovery - linkoval jsem dokumentaci X11R7.7, kde to filtrování není popsané. Takže jistě chápete, že vám to moc nevěřím. Zkusit to nemůžu, protože nemám po ruce žádný Linux. Poslední jsem smáznul tuším Ubuntu, když jsem čekal na nový disk a nebylo místo.
http://www.x.org/releases/X11R7.7/doc/man/man1/xev.1.xhtml

Ano, u OOo existuje binging pro Python. Jinak technika "spustím interpret jazyka s one-linerem v parametru" je pěkná, ale otázka je, proč si radši nepořídíte shell ze současného století.

Samozřejmě že mám averzi ke zbytečnému a opakovanému spouštění procesů. Má to obrovský overhead. Musíte pokaždé zavést binárku a vytvořit proces, plus provést marshalling. Jestli ten overhead ve srovnání s použitím API nevidíte, tak to není problém na mé straně.

Děkuji za link. Asi nemá smysl se ptát, proč ten parametr není v oficiální dokumentaci X11R7.7; odpověď by zněla "protože Linux".

Ad NativeWindow - je to možné, ale jak jsem psal, můžete použít default constructor (static constructor that initializes application domain-wide message handlers and hash tables), případně UI Automation (linky jste dostal). Upřímně se mi to nechce psát, protože pro ten kód nemám využití; experimentovat snad můžete sám.

Neviem - já bych možná věděl. K tomu objektovému shellu byste totiž potřeboval i dostatečně rozšířený, dobře použitelný a široce implementovaný objektový model. Unixy a objekty si, přes jistou recentní snahu o změnu, moc nerozumí.

Fork nieje doslova no-op, ale jeho rezia je minimalna - jasně. Když budete provádět volání utility například z DB engine, který má alokovaných 6GB paměti, budete jen na ten fork/exec potřeboval dalších 6GB RAM (což je jeden z důvodů, proč má Linux tak doprasenou alokaci paměti tím overcommitingem a OOM Killerem).

binarka bude po 2-3 spusteniach v cache pribita hodne na pevno - to sice bude, ale přesto při jejím zavedení budete muset vytvořit proces - relokovat kód, alokovat stack a heap, a provést spoustu další inicializace. A pak je tu ten marshalling. Znovu říkám, že jestli ten overhead při spouštění pěti procesů per window message ve srovnání s použitím API (kde se použije jeden callback a pár info calls) nevidíte, tak to není problém na mé straně. Je to zjevně rozdíl mnoha řádů.

Nevím jak static constructor (nezkoušel jsem), ale UI Automation vám samozřejmě umožní sledovat i řídit cizí proces - proto ten UI Automation Framework napsali :). Běžte si to zkusit. A pokud vám nevyhovuje ani jedno z navržených řešení, vždycky můžete použít Win32 API SetWindowsHookEx(). Představa že nejde ve Windows provést hooking window messages cizího procesu mi přijde dost vtipná.

su bindy aspon na python, ruby a perl - to nejsou shelly. Ve Windows je také možné prakticky všechno udělat z Perlu, VBS, C# a C++.

Fork pamat nekopiruje a exec uvolnuje aj to, co sa pripadne zapisalo. Spotrebuje sa pamat na nazov exacu a argumenty, ani o bajt naviac - čekal bych, že toho o Unixech více víc. fork operation creates a separate address space for the child. The child process has an exact copy of all the memory segments of the parent proces. Ono to sice na většině dnešních systémů skončí označením stránek paměti příznakem CoW, ale i na to jaksi potřebujete 6GB paměti pro případ, že na to CoW opravdu dojde (a nedej bože, aby se vám shodou okolností těch forků s velkou spotřebou paměti sešlo několik najednou). Následný exec() ten proces sice nahradí jiným (a paměť tedy uvolní), ale to už je trochu pozdě, protože the damage is done. Jak jsem psal, příšerný mechanismus fork/exec je jedním z důvodů, proč autoři Linuxu dojebali správu paměti overcommitingem a OOM Killerem.

Ad NativeWindow - nejspíš asi použijete desktop window, pomocí SetProp s ním asociujete vlastní handler, a pak teprve použijete NativeWindow. Nezkoušeno, ale mělo by to fungovat.
Ad SetWindowsHookEx - boha, četl jste dokumentaci? events are associated either with a specific thread or with all threads in the same desktop as the calling thread ... dwThreadId ... identifier of the thread ... if this parameter is zero, the hook procedure is associated with all existing threads running in the same desktop as the calling thread.

Já jsem vám napsal, kterými směry bych se rozhlížel, kdybych podobný problém chtěl řešit. A také jsem vám řekl, že nic psát nebudu. Nakonec proč, když to nepotřebuji, a navíc to už napsali jiní. Už jsem uvedl, že možností je více.
http://www.codeproject.com/Articles/18638/Using-Window-Messages-to-Implement-Global-System-H

Když jsme u toho, tak ve Windows máte k dispozici Backlight Control API a Monitor Configuration API (to využívá třeba utilita F.Lux). Technicky není problém ta API volat z PowerShellu pomocí Pinvoke.
http://msdn.microsoft.com/en-us/library/aa372656%28VS.85%29.aspx
http://msdn.microsoft.com/en-us/library/dd692962(v=vs.85).aspx

Takže to stejně uděláte nějakým skriptem, který nemá GUI. (Zda to uložíte do registru či souboru už je šumák.) A co u tohoto prasečího řešení uděláte, když se bude poloha pořád měnit (třeba letíte do Číny)?
Dovolil bych si vypíchnout jádro problému, o kterém se tu bavíme: Nástroje se dělají pro CLI, aby došlo k ODDĚLENÍ funkcionality a grafické prezentace!!! V okamžiku, kdy vytvoříte funkcionalitu řiditelnou pouze z GUI (= uživatelem), jste v prdeli, protože už nikdo jiný mimo toho uživatele ji nemůže použít. Co je na tom nejasného?

Pokud se bude poloha pořád měnit, tak existuje několik možností:
- Použít utilitu, která vyjma změny barev také provádí občas geolokaci
- Utilitu občas ukončit a znovu spustit tím skriptem
- Pokud utilita občas znovu přečte nastavení (což ale není moc obvyklé), tak stačí občas spustit ten skript co jsem sem psal
- Nějak utilitě podstrčit nové nastavení. K tomu existuje dlouhá řada IPC nástrojů, které ta utilita samozřejmě musí podporovat. Dají se použít i window messages.

Otázka: proč byste odděloval funkcionalitu od GUI? V některých případech to dává smysl, v jiných ne. Máte snad kalkulačku, OpenOffice nebo KMail rozdělený na GUI a command line utilitu? Asi ne.

No jasně. Calc.exe bude jen GUI, do kterého naklikáte co potřebujete, pak to spustí calc_backend.exe s parametry, naparsuje výsledky, a zobrazí je to. Bylo by to velmi unixové :D

Možná ve Windows, my v Unixu známe roury ;-)

Copak pipes, ty ve Windows známe taky. Ale v daném případě má zjevně smysl jedině API.

Ony toho ty pipes umí trochu víc.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365780(v=vs.85).aspx

pipe se da vzdy socketou nahadit. Takze neni duvod, na systemu, ktery nema nativni podporu pipe, se delat s pipe, kdyz mame sockety.

To co je na unixove pipe sexy neni to, ze se lisi od sockety, ale to, ze shelly maji syntaxi pro spusteni dvou procesu tak aby se vystup jednoho pres pipe nasmeroval do vstupu druheho. Na windows se stdin/stdout (a stderr) moc nenosi, takze tam ani po pipes neni poptavka.

Ja osobne vyhodu pipes oproti API vidim v tom, ze textovy vstup a vystup pripadneho programu muzu oskriptovat "za letu", a nemusim se ucit zadne API. Proste si ten programek zkusim parkrat spustit, a tak jak ho ovladam v konzoli, tak ho pak volam ze skriptu. Ostatne, zvykl jsem si pouzivat konzoli na tolik, ze mysi spoustim jen firefox, mailovy klient a snad jeste konfiguraci site. Vse ostatni bud z konzole, nebo z "command line" meho window managera.

vyhodu pipes oproti API vidim v tom, ... se nemusim ucit zadne API - API určená ke skriptování bývají triviální, a v případě použití komponentového modelu samopopisná.

Já to řeknu takhle. Vůbec nevím, o čem to tady melete, sotva tuším, co to znamená API. Ale vzít si z man stránky programu, jak se v příkazové řádce udělá to či ono, a strčit to do nějakého jednoduchého skriptu, nebo to strčit do Fluxboxu dokážu. A o tom to je...

Tohle mě nepřestane překvapovat. Naučit se stovky příkazů a jejich syntaxi, umístění spousty konfiguráků, regexpy, ovládání vi, skriptování v bashi a nevím co ještě není problém. Ale jak jde o něco jiného, najednou je to hrozná komplikace. Staré psy člověk zřejmě novým kouskům nenaučí.

Jak už jsem psal, nejsem programátor. A vy se na moji úroveň evidentně ponížit nedokážete. Neumím stovky příkazů, neumím bash, je to problém. Ale vygooglit si man stránku programu, který mě zajímá, vážně problém není. A s API se to fakt porovnat nedá. Už 2 měsíce odkládám spojení Mascot + R. To se mám jako kvůli toho učit Perl, Javu nebo Python? To je dost velký rozdíl, než kdybych mohl na příkazovou řádku podle man napsat podnět programu ať udělá to co chci. Vážně to nevidíte?
Ten počítač nepoužíváte jen vy programátoři. A já fakt nemám peníze ani čas kvůli každé blbosti, kterou chci volat někoho, kdo tomu rozumí. A ručně se mi to třeba taky dělat nechce...
Prostě ta možnost ovládat program jednoduše z příkazové řádky má něco do sebe a jakožto BFU to oceňuji více a více...

To se samozřejmě s API srovnat dá, pokud vám to shell dobře umožní. Koukněte na ukázky PowerShellu - podle mě je to logičtější než klasické shelly.
http://gallery.technet.microsoft.com/scriptcenter/bdb59b6d-3368-4c06-bf77-900a68706c5b
http://gallery.technet.microsoft.com/scriptcenter/site/search?f%5B0%5D.Type=ProgrammingLanguage&f%5B0%5D.Value=PowerShell&f%5B0%5D.Text=PowerShell

První příklad obsahuje funkci pro synchronní uvolnění objektu. Jak asi víte, když provedete prostý dispose, díky GC může proběhnout se zpožděním. Podle mě by měl stačit ReleaseComObject.

První příklad především obsahuje 'function'. To je klíčové slovo, které v unixových shellech sice je, ale BFU ho pro krátké skripty vůbec nepotřebuje. Potřebuje snadno přiřadit do proměnné, snadno proměnnou použít (aniž by se musel učit nějaké typy), pak "if", a pak cykly. A aby všechny programy vracely návratový kód který se v případě chyby interpretuje jako false. Zbytek se může učit teprve až to bude skutečně potřebovat. Nicméně ten příklad se snaží otevřít spreadsheet. Pro uživatele je jednoduší dát uložit jako CSV, a pak použít nástroje pro pro práci s textem, které se hodí pro spoustu dalších věcí, než se učit api jedné aplikace.

typicky skript ma tak kratkou zivotnost, ze je jedno pokud se dealokace uplne vypusti. Ostatne neni to tak davno (jednotky let), kdy PHP prakticky nespoustelo garbage collector a nedealokovalo pamet, protoze bezne spusteni na webovou stranku toto proste nepotrebovalo. Kdyz to pak nekdo pouzil v cronu na pipelinove zpracovani velkeho souboru, tak bylo docela prekvapeni, kdyz tomu skriptu dosla pamet. Proste, dokud jde jen o uvolnovani pameti, tak ve skriptech a obecne programech s kratkou dobou behu byva neresit uvolnovani vubec ta nejlepsi strategie spravy pameti.

"Naučit se..."

To není pravda, já všechny ty příkazy neumím. Já umím napsat man <příkaz> a přečíst si dokumentaci. Pokud nějaký příkaz používám častěji a ten opšník používám už řekněme po šesté, tak mi sám zůstane v paměti. Pokud ho použiju jen pětkrát, je zbytečné abych se ho učil. Výhoda unixového přístupu je zde právě v tom, že dokumentace je na jednom místě a chybějící dokumentace je stejnou chybou jako chyba aplikace. Je pravdou, že google poslední dobou tu výhodu jednoznačného umístění dokumentace trochu stírá.

Takže musím umět jen syntaxi shellu (která také není bůhvíjak složitá), regulární výrazy se hodí na více věcí (viz můj příspěvek ke konfiguraci), pár standardních příkazů pro práci se soubory a zbytek se dá dohledat, většinou offline (to se v serverovně u serveru, jehož chybou je rozbitá konfigurace sítě, hodí). A co se týče shellu - mohu použít shell, který se mi líbí nejvíc.

Jasně. Je jedno že to napíšete jako prase, hlavně že to nějak funguje.

Pokud máte nějakou utilitu s CLI, a máte k ní zdroják, tak je ideální ji rozdělit na CLI interface a GUI, nebo v horším případě ten zdroják zkopírovat do své aplikace. Vázat front-end a back-end přes CLI je příšernost. Zvlášť pokud použijete tu neuvěřitelně příšernou kombinaci volání fork/exec (BTW celkem překvapí, že autory UNIXu nenapadlo udělat něco jako Win32 funkci CreateProcess).

Ne, to asi fakt nikdy nepochopím. Komunikace přes CLI vyžaduje převod parametrů na string (overhead), spuštění procesu (*veliký* overhead), parsování parametrů v utilitě (overhead), převod výsledků na string (overhead), parsování výstupu ve volající aplikaci (overhead). Navíc to máte omezené na volání a návrat, nejde o obousměrnou komunikaci. Když potřebujete akcí víc, spouštíte proces pořád dokola jako trotl. Jako hřebíček do rakve máte na Unixech kombinaci fork/exec. Když budete provádět volání utility například z DB engine, který má alokovaných 6GB paměti, budete jen na ten fork/exec potřeboval dalších 6GB RAM (což je jeden z důvodů, proč má Linux tak doprasenou alokaci paměti tím overcommitingem a OOM Killerem).

Navíc jak jsem už psal, CLI a GUI aplikace mají velmi odlišný model ovládání. Když autoři na existující CLI aplikaci snaží naroubovat GUI, dopadá to často otřesně:
http://www.jensroesner.de/wgetgui/wgetgui_simple.png
http://www.jensroesner.de/wgetgui/wgetgui.png

Myslím že kdybyste na Unixech měli dostatečně rozšířený, dobře použitelný a široce implementovaný objektový model, sám byste uznal, že CLI je omezující i pro admina, natož pro vývojáře. Samozřejmě pokud jste uvíznul někde před půl stoletím, bez šance na zlepšení (ježto vývoj Unixů už dekády stagnuje), tak můžete tvrdit, že jsou ty hrozny kyselé :D
$objExcel = New-Object -com Excel.Application
$objExcel.Visible = $True
$objworkbook=$ob­jExcel.Workbo­oks.Open("C:\U­sers\Lael\Docu­ments\My Document.xlsx")
$objWorksheet = $objworkbook.Wor­ksheets.Item(1)
if ($objWorksheet­.Cells.Item(1,1)­.text -eq "Hi there") {$objWorksheet­.Cells.Item(1,1) = "Hello World"

Souhlas v jedné věci: Frontend + backend se pouziva tam, kde to ma smysl. Je ovšem nesmysl vázat frontend + backend přes CLI, protože to má obrovský overhead a skoro nic to neumí. Od toho je tu odjakživa API.

BTW instalačky Windows mají dnes okolo 3.1GB, takže si nevymýšlejte.

Kalkulačka: primitivní kalkulačka asi ne, ale ty lepší třeba používají jako backend Octave (pro výpočty) nebo Gnuplot (pro grafy)

OpenOffice: ty asi ne, ale KOffice jsou dělené do mnoha samostatných utilit

KMail: samozřejmě, spam filtr je command-line utilita (SpamAssassin), stahování řeší utilita (KIO IMAP), mejly parsuje utilita (Nepomuk Mail Feeder) a databáze je také externí (Akonadi)

Modularizace samozřejmě má v řadě případů smysl. Ale ty lepší kalkulačky nejspíš nepoužívají Octave nebo Gnuplot přes CLI. Místo toho používají knihovny nebo komponenty, jedním slovem API.

Používají roury :-)

Takže si na každé straně budete psát serializaci a deserializaci. Super nápad. Hlavně žádné API, to může kousat :D

Ono to API není o moc lepší, taky většinou používá úplně jiné struktury, než zbytek vaší aplikace, takže nějakou (de)serializaci dělat musíte. Akorát na rozdíl od rour nejde používat z CLI, přes síť nebo třeba z PHP.

Když píšete GUI nad nějakým API, tak si můžete vybrat, jak budou vaše datové struktury vypadat. A komponentový model (COM, .NET komponenty) můžete samozřejmě používat i z command line, tedy ve Windows.

Pokud z PHP nemůžete používat API, tak to není problém API :). Nakonec se koukněte na ASP.NET.

Knihovny nemají samopopisný interface, takže je to trochu složitější. S komponentou (například COM nebo .NET) je to trivialita.

Those who are too fond of obsolete concepts are doomed to get stuck in them forever. -- Lael Ophir

Zajímavé, že na Windows ten citát sedí. Nejdřív Windows NT, které konečně uměla nějaká oprávnění a nešla sestřelit třemi bajty kódu, potom UAC jako náhrada sudo, potom Power Shell a konfigurace v texťáku ( *.reg) se pro správu používá stále.

Windows NT mají daleko lepší security model, než Unixy. Například ACL místo bitmask, autorizace přes API namísto kontroly hashe hesla proti /etc/passwd (takhle se to opravdu na Unixech dělalo), žádné nezabezpečené NFS, ACL na API namísto "root může vše a user používá utility se suid" atd. UAC není náhrada za sudo. Konfigurace v .reg souboru je leda výsledek exportu.

Je hezké, že Windows NT umí ACL, ale když se tam až do Visty prakticky nepoužívalo, tak to bylo dost k ničemu.

Proto je Kerberos o pět let starší než Windows NT, že? :-)

Pokud chcete NFS šifrovat, dejte si ho do tunelu. SMB/CIFS taky žádné šifrování neumí. Bezpečné ověřování přes Kerberos umí NFS od počátku Kerberosu.

ACL na API dělá právě sudo. Máte pravdu, UAC není tak dobré, protože se nedá téměř vůbec nastavovat :-)

Konfigurace v  *.reg se běžně používá, pokud chcete nějaká pravidla aplikovat na víc strojů třeba přes logon script. A když už to děláte v texťáku, můžete to rovnou i v texťáku ukládat.

Windows NT samozřejmě používaly API dlouho před Vistou. Nevím kde jste na takový nesmysl přišel.

Kerberos bylo před cca rokem 2000 zakázáno exportovat z USA, spolu s většinou šifrovacích technologií.

U NFS mi nejde o šifrování, ale authentication. Jak jste si mohl všimnout, "authentication" se ve starších verzích NFS (které se trestuhodně používají dodnes) provádí pouhým zadáním GUI a UID. Fakt super bezpečnost. Kerberos lze implementovat, ale je pokud vím k dispozici až od NFSv4. Navíc je spojený s řadou problémů, včetně nedostatečné standardizace a problémů s interoperabilitou.

Sudo nedělá "bezpečnost na API". Klasický unixový koncept je ten, že root má přístup ke všem API, a tím to končí (naopak ve Windows jsou na API ACL). Sudo je berlička, která umožní neprivilegovanému uživateli spustit utilitu, která následně použije API; neřeší tedy použití API uživatelem. Mezi tímhle konceptem a UAC jsou dost dramatické rozdíly.

Konfiguraci do Registry můžete importovat například ze souboru .reg, nebo pomocí skriptu. FYI hromadné změny konfigurace se dělají přes Group Policy, nikoliv přes login script.
Ad když už to děláte v texťáku, můžete to rovnou i v texťáku ukládat - WFT?

Windows NT samozřejmě používaly API dlouho před Vistou. Nevím kde jste na takový nesmysl přišel.

Třeba tak, že naprostá většina uživatelů běžela pod administrátorem a tedy měla přístup všude?

Kerberos bylo před cca rokem 2000 zakázáno exportovat z USA, spolu s většinou šifrovacích technologií.

Včetně těch z Windows.

U NFS mi nejde o šifrování, ale authentication. Jak jste si mohl všimnout, "authentication" se ve starších verzích NFS (které se trestuhodně používají dodnes) provádí pouhým zadáním GUI a UID. Fakt super bezpečnost. Kerberos lze implementovat, ale je pokud vím k dispozici až od NFSv4. Navíc je spojený s řadou problémů, včetně nedostatečné standardizace a problémů s interoperabilitou.

Většinou se to dělalo tak, že bez autorizace přes Kerberos se nedalo použít dané UID na NFS. Jednoduché a funkční.

Je vtipné argumentovat omezenou interoperabilitou a jako příklad dobrého řešení navrhnout Windows, které často pořádně nefungují ani samy se sebou (např. sdílení Win2K ↔ Vista) :-)

Sudo nedělá "bezpečnost na API". Klasický unixový koncept je ten, že root má přístup ke všem API, a tím to končí (naopak ve Windows jsou na API ACL). Sudo je berlička, která umožní neprivilegovanému uživateli spustit utilitu, která následně použije API; neřeší tedy použití API uživatelem. Mezi tímhle konceptem a UAC jsou dost dramatické rozdíly.

sudo umožňuje definovat, jaké utility přes něj může uživatel spouštět. Tím dělá v podstatě něco podobného jako autorizaci API, kterou UNIXy nepotřebují, protože místo toho používají CLI.

většina uživatelů běžela pod administrátorem - a co to s tím má společného? Navíc se to týkalo domácích uživatelů. Ti firemní už od dob NT 4.0 běží jako restricted. Tedy pokud admini nejsou úplné lamy.

zakázáno exportovat... Včetně těch z Windows - MS měl ořezané verze krypto knihoven pro export

Většinou se to dělalo tak, že bez autorizace přes Kerberos se nedalo použít dané UID na NFS - omyl. Nasazení Kerbera bylo (a je) ve světě Unixů dost výjimečné, pokud se nebavíme o sídle pár univerzit.

Sdílení mezi Win2K a Vistou samozřejmě funguje. Pokud si vzpomínám, potřebujete tuším SP3 na Win2K, nebo alternativně změnit na Vistě LmCompatibili­tyLevel (což je špatný nápad). Je celkem logické, že se v nových verzích Windows odřezávají staré protokoly, které v mezičase přestaly být bezpečné. Na Unixech je to jinak - NFS většinou dále by default umožňuje připojení s "autorizací" přes GUI/UID. Nicméně i tady jsou vidět pokroky - dnešní Unixy například už většinou nemají by default telnet daemon :D

Na Unixech jsou tradičně na úrovni API dvě úrovně permissions: "root smí všechno" a "nekritické věci smí i kdokoliv jiný". Sudo to řeší v nejlepším případě se spouštěním utilit na CLI, ale už ne pro aplikace. BTW mohl jste si všimnout, že v posledních letech se i na Unixech na úrovni API prosazuje kontrola GID volajícího. Málo a pozdě, ale pokus je to pěkný.

Nasazení Kerbera bylo (a je) ve světě Unixů dost výjimečné, pokud se nebavíme o sídle pár univerzit.

Ano, nasazení Kerbera je omezené. V Unixu totiž každý používá to, co mu v daném místě vyhovuje. Jinde se ověřují uživatelé přes LDAP či SSH a soubory se přenášejí přes SSHFS nebo HTTPS+WebDAV. Akorát ve Windows se používá to, co zrovna prosazuje MS, aby se na to za deset let plivalo :-)

Nicméně i tady jsou vidět pokroky - dnešní Unixy například už většinou nemají by default telnet daemon :D

Posledních skoro dvacet let :-D

Na Unixech jsou tradičně na úrovni API dvě úrovně permissions: "root smí všechno" a "nekritické věci smí i kdokoliv jiný". Sudo to řeší v nejlepším případě se spouštěním utilit na CLI, ale už ne pro aplikace. BTW mohl jste si všimnout, že v posledních letech se i na Unixech na úrovni API prosazuje kontrola GID volajícího. Málo a pozdě, ale pokus je to pěkný.

Na Unixech jsou tradičně dvě úrovně: root smí všechno a ostatní smí to, co jim dovolují jejich práva. Např. rozlišování práv k zařízením pomocí GID je v Unixech od jejich počátku. Mimochodem sudo umí měnit práva i na určitou skupinu nebo uživatele, ne jen na roota.

COM je na správné použití katastrofa a .NET příšerně komplikované, pokud to nechcete psát v C#. Proč myslíte, že se to prakticky nepoužívá? Až nedávno to MS pochopil a přišel s WinRT, aby to alespoň trochu zachránil.

A co takhle na ukázku KDE? ;-)

COM je katastrofa, pokud něco stavíte od začátku bez použití template.
.NET by zamýšlen jako náhrada všech těch VBRUN, MFC a dalších frameworků nad Win32. Komplikovaný mi nepřijde - naopak je to velmi přehledné API. I když je pravda, že ho používám jen ze C#, případně VB.NET.

A co takhle na ukázku KDE? - na ukázku čeho?

Na ukázku GUI nad CLI.

LOL, vedle :)

Proč XML a ne texťák? Protože je to jednodušší. Pokud tady našemu kolegovi trvá pár hodin naklikat hodnoty ve formu a zkontrolovat je podle checklistu, asi jich bude celkem hodně. Psát to v texťáku je na zabití pro uživatele, a parsovat ten texťák je na zabití pro autora. Daleko lepší je naklikat data do formu, a pak je prostě vysypat do XML (které se dá z formu zase načíst). Takže vezmete projekt, zkopírujete ho, odřežete hlavní funkcionalitu aplikace (sestavování toho package), a triviálně to GUI naučíte ukládat a číst naklikané věci do/z XML.
V druhém projektu z aplikace zase odřežete GUI, a prostě jí naučíte načíst interní stav z toho XML; můžete provést copy-paste části kódu z předchozího odstavce.

BTW vy jste nikdy podobné věci nedělal? Tyhle modifikace "motorovou pilou" bývají trošku brutální, ale dá se to nejspíš udělat rychleji než jedna "klikací" session s tou stávající aplikací, a ve výsledku to dělá co má.

Už jsem konečně pochopil důvod k vytvoření PowerShellu. Je to jeden z mála skriptovacích nástrojů, kde člověk nemusí kvůli idiotskému microsoftímu oddělovači cest psát dvě zpětná lomítka za sebou. :-D

Skoro všude lze úplně jednoduše používat dopředná lomítka a funguje to správně :-)

To je primárně problém Unixů, kde se všechno escapuje. To pak máte problém i s mezerami v názvech adresářů. Jo, kéž by se mezery v názvech souborů naučili třeba v Oracle. Chápu že dlouhá jména jsou novinka, asi jen dvacet let stará, ale už by to mohli umět. Totéž u autorů Perlu.

BTW úplně největší humus je psaní regexpů, pokud je musíte escapovat, což se bohužel občas stává. To by pak jeden zvracel. Dlouho a divoce.

BTW v C# umíme verbatim string literals, v C++ jsou raw literals.
string s=@"C:\a\b\c";
http://msdn.microsoft.com/en-us/library/69ze775t.aspx

V shellu jsou apostrofy ;-)

Ještě jsem na Windows neviděl problém způsobený parsováním dlouhých názvů, které by byly ve výstupu utilit. Ono to asi bude tím, že na Windows je parsování výstupů utilit dost vzácné. Máme totiž GUI, API a objektový shell.

Mezery v názvech souborů jsou prostě realita, a z hlediska pojmenování souborů na Unixech ničemu neodporují. Proto doporučuji se s nimi smířit :),

Rozlišení počtu mezer je stejný problém, jako v běžném textu.

Poslední písmeno názvu souboru (ve Windows) nesmí být mezera.

Tohle je popsané v dokumentaci funkce CreateProcess. Situace popisovaná v linku je způsobená tím, že byly na stroji nainstalované services třetích stran, a dlouhé cesty k executables nebyly ohraničené uvozovkami. Tj. při registraci servisu se ImagePath nastavuje na "C:\Program Files\Manufac­turer\App\ima­ge.exe", a nikoliv C:\Program Files\Manufac­turer\App\ima­ge.exe.
Je to popsané chování, ve VS na to Code Analysis for C/C++ hází warning C6277. Pokud to výrobce SW přesto zmrší, není to chyba MS.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/4b4tecce(v=vs.80).aspx

Certification requirements for Windows desktop apps, version 3.1:
10.1 Your app must be installed in the Program Files folder by default

Podobně to najdete v MS dokumentaci už od roku 1995. Mimochodem naprostá většina SW samozřejmě dlouhé názvy podporuje. Výjimkou je například Oracle, který přichází z Unixů, a kde si zjevně vývojáři od roku 1995 dlouhých názvů ještě nevšimli.

Možná Vás to překvapí, ale třeba v Pythonu například používáme taktéž "raw stringy", zejména kvůli regexpům. Žel to je ale zbytečná otrava, která v běžné práci s adresáři není nutná.

Problém s mezerami je především sémantický - v adresáři mohu mít soubory "AAA", "BBB" i "AAA BBB". Co si z toho má shell asi vzít, když napíšu mujprikaz AAA BBB? Má programu předat (mimo argv[0]) jeden parametr, dva, nebo pro jistotu všechny tři?

1. Shell nemá co domýšlet. Je-li tam mezera, musí ji uživatel escapovat.
2. Když dělám designová rozhodnutí - např. jak pojmenovat adresář pro instalaci programů - tak to dělám s ohledem na použitelnost i z příkazové řádky, v konfigurácích apod.
Escapování je otrava, ale v běžném použití jednoduše nemá být potřeba. Mezery, non-ASCII znaky a další speciální znaky prostě zbytečně nikam necpu.

Souhlas.

1. Pokud shell používá escapování, tak máte samozřejmě pravdu.
2. Pokud děláte rozhodnutí jako autor SW, měl byste naopak zkusit program instalovat do cesty s mezerou, a s Unicode znakem v cestě. Ne jako ti patlalové v Oraclu.

Je zbytečná otrava napsat jeden znak navíc, abyste nemusel escapovat? No tak klidně escapujte, jestli vás to baví víc :)

S mezerami problém samozřejmě není. Když je argument AAA BBB, tak jde o dva parametry. Když je to "AAA BBB", tak jde o jeden parametr.

Vizte dokumentaci funkce CreateProcess, kterou jsem linkoval.

Tak si to zkuste přečíst, a dejte vědět.
http://www.root.cz/clanky/ohrejte-studene-svetlo-sveho-monitoru-a-setrete-oci/nazory/486373/