Připojuji se. Výborný článek! Já se pořád divil, proč u kompu nejsem unavenej a jen co vlezu do postele, tak upadnu v koma. Tohle je pro mě určitě článek roku. Ještě tak sehnat něco pro Win. (Ano, stydím se. :D)
Tak mě napadá, tohle by klidně mohlo bejt součástí OS (místo spousty jiných ptákovin).
Dokud jsem měl počítač v obýváku, kde jsou prosklené dveře do ložnice, tak jsem používal ke změně barev tlačítko na monitoru. Ten můj má 4 přednastavená schemata, přepínání je hned na ráně, žádné hledání v menu.
Co jsem přesunul počítač do pracovny, tak tam už mám rozsvíceno velké světlo a na monitoru už nic nepřepínám.
Mít program, který to přepíná za mne a navíc to umí plynule, je bezesporu výhoda. Ale i tak je to pořád pro oči mnohem horší výsledek, než si v místnosti nechat rozsvíceno 60W žárovkou (používám halogenky).
Tak v tom případě používáte placebo. Sice je lékařsky ověřeno, že modré světlo na některé lidi tak působí, ale musí ho být hodně a dopad to má jen na malé procento populace. Má to cosi do činění s třetím typem receptorů světla na sítnici.
Pokud trpíte nespavostí, bude příčina i řešení někde jinde. Ale co, možná vám to zabere jako placebo, nebo nastane nepřímý efekt (když to začne červenat, tak jdu spát => chodím spát pravidelně ve stejnou dobu).
Ano, to je také jeden z doporučených návyků pro lepší spánek. Alespoň půl hodiny před tím, než jdu spát, přestat pracovat. Od stolu rovnou do postele je to špatně. To je ale poučka z dob první republiky, možná ještě mnohem starší. Platí to bez ohledu na to, zda sedíte u monitoru / knihy / kreslicího stolu / vyšívání / štípete dříví. Takže světlem to asi nebude.
staci nesetrit na monitoru...
TN i IPS delaji modrou mlhu. MVA ma jedina trosku slusne podani barev, ale bohuzel ne ta nejlevnejsi v podobe benq, ktera ma jen 72% gamut. coz v podstate znamena, ze nedokaze zobrazit vsechny barvy spravne a at delate co delate, tak mate na vyber mezi rudou zari nad kladenm nebo modrou mlhovinou, protoze nedokaze zobrazit zelenou v odpovidajici sytosti, aby slo dosahnout prirozenych dennich barev. Netrpi tim jen benq, ale i treba znacky jako NEC v TN panelech apod. Je to LCD mor.
Menšina preferuje bílý text na černém pozadí, většina černý text na bílém pozadí.
Menšina preferuje studené bílé světlo, většina teplé bílé světlo.
Doma mám obojí, úsporkami se studeným bílým světlem svítím jen proto, že mi je líto je vyhodit a budu je používat ještě dlouho, protože je mám jen v místech, kde svítím jen občas. Tím nemyslím WC a koupelnu, ale lampičky v obýváku, v pokojích a v ložnici. Já osobně studenému bílému světlu říkám "nemocniční bílá" nebo častěji "jedovatá bílá", ale neodvážil bych se lidi s jinou preferencí teploty bílého světla nazývat osly.
Proto jsem problém vyřešil tak, že ve FF mám BYM (viz výše) a v noci ho zapínám. V textových editorech a terminálech používám světlý text na tmavém pozadí, jen na slunci nebo na projektoru přepínám do černého textu na bílém pozadí.
antialiasing neni dobre citelny nikdy. truetype/cleartype apod.
oko se unavi zdaleka nejrychleji, kdyz nedokaze zaostrit na presnou hranu. proto tahle graficka gymnastika s vylepsovanim obsahu pri soucasnem snizovani schopnosti/kapacity konzumace je tak akorat na poklepani si na celo.
jedina spravna cesta je bohuzel ta, kterou po velmi dlouhe dobe vytahl z supliku a sfoukl prach apple v podobe nezavislosti rozliseni na rozteci bodu a roztec v pouzivane vzdalenosti pod hranici okem rozeznatelneho uhlu.
Mám problémy s očima a tu ostrou přepálenou bílou fakt nedám. Pět hodin v tahu a mám zánět spojivek, studená bílá přitom není problém. Takže všechny monitory mám na minimální jas, který dovolí slušný kontrast... A problémy se spánkem v noci jenom potvrzuju, když koukám na jasný bílý LCD, je doba usínání asi trojnásobná a ráno je vstávání jak po flámu.
Mě by spíš zajímalo, kdo potřebuje likvidovat oči něčím tak ostrým, že se to v přírodě ani nevyskytuje.
Priznam sa, ze si nie som isty, podla prispevku, ci mate problem s teplou alebo studenou bielou. Ale hadam, ze s teplou. Oboje sa ale v prirode vyskytuje.
Studena biela v polarnych oblastiach a tepla biela napriklad pri horeni ohna. Zapalte si poriadny ohen v jaskyni a budete mat tolko teplej bielej, ze sa z toho Vase spojivky zblaznia.
Vážený pane maze, příjemnost je subjektivní kategorie, pro někoho je příjemnější tamto a pro někoho zcela jiného. Pro někoho je něco hnus a pro někoho super věc. Pokud je jde o zdravotní dopady, tak doporučuji k prostudování tento článek dr. Jana Hollana, jednoho z mála odborníku na světelný smog a noční svícení: Ve zdravém domě zdravou noc!.
prijemnost je subjektivni, a asi se najde par vyjimek kterym je fakt prijmnejsi zluty svetlo. Ale neverim ze "deep down" vetsina fakt preferuje ten umelej, neprirozenej, zlutej hnus.
Ja se snazim vybirat zarovky tak aby se osvetleni co nejvic podobalo dennimu svetlu kdyz je jasna obloha. A i tak moje zarovka s tzv. "chladnym" svetlem je porad o neco zlutejsi...
A pokud jde o spanek tak tam je samozrejme nejlepsi svetlo uplne vypnout...
To se velmi mýlíte. To "bílé" světlo má dost odlišné barvy. Pokud to nevidíte, zřejmě to souvisí s kompenzací barvy okolí, kterou automaticky provádí váš mozek.
Trocha teorie: jak si můžete všimnout na fotografiích v RAW formátu bez aplikace white balance, všechny věci například na fotografii na zelené louce jsou silně ujeté do zelena - jsou totiž osvícené zeleným světlem. Váš mozek to tak nevnímá, protože provádí automatickou korekci. U fotek se provádí automatická korekce barev tak, aby průměr celé fotografie byl neutrálně šedý.
http://en.wikipedia.org/wiki/Color_balance
V průběhu dne se barvy výrazně mění. Při svítání je světlo typicky nejprve červené, poté přechází do žluta, a později je bílé; při stmívání opačně. Když je pod mrakem, je světlo naopak modré. Ještě víc je modré v zasněžené krajině.
http://en.wikipedia.org/wiki/Sunrise#Colors
http://en.wikipedia.org/wiki/Atmospheric_optics#Sky_coloration
http://en.wikipedia.org/wiki/Sky
Bílé světlo neexistuje. Je to směs barev různých vlnových délek. Sluneční spektrum není zrovna homogenní a hodně s tím zamává i průchod atmosférou.
To důležité je však to, že každý člověk vnímá "bílé světlo" jako jiné spektrum. Co jednomu přijde spíše do žluta, jiný vnímá jako do modra. Není to nesmysl, protože v tom světle jsou obě vlnové délky a holt každý reaguje na různé vlnové délky trochu jinak. Ono vlastně té modré ve slunečním světle až tolik není, zato žluté je tam nejvíce. Mít "vyvážené" oko, tak slunce vnímáme zeleno-žluto-oranžové.
Úplně naprd to začne být ve chvíli, kdy nějaký výrobce zářivek začne "simulovat" bílé světlo pomocí poměrně nespojitého spektra, to pak může být vnímání u různých lidí velmi odlišné.
Nespojité spektrum osvětlení má celkem zajímavé důsledky v textilním průmyslu. Barvy látek jsou pochopitelně stavěné na subtraktivním míchání barev - když smícháte všechny barvy, bude výsledek černý. Jenže v praxi je například černá barva tvořená několika pigmenty, které pohlcují poměrně úzkou část spektra. U umělém osvětlení s nespojitým spektrem se to občas nesejde, a barva oblečení pak vypadá dost divně. Dražší barvy mívají většinou konzistentnější výsledky v různém osvětlení; zřejmě využívá více pigmentů, nebo jsou vhodněji vybrané.
Potvrzuji. Nejen textil, ale i plasty se barví takhle levně :-)
Mám černý batoh na notebook. Ale v místnosti osvětlené zářivkami má části lehce fialové. V jednom hotelu to šlo až do extrémně světlé křiklavě fialové, takže jsem se v první chvíli lekl, že jsem si na letišti batoh s někým vyměnil.
Ono to nepostihuje jen barviva v textilu a plastech.
Dokonce i některé starší barevné fotopapíry (třeba Kodak Professional Digital) prodávané ještě před érou zákonem předepsaných světelných zdrojů s nespojitým spektrem ujíždějí v zářivkovém světle výrazně do fialova.
Jev je dávno známý, říká se mu metamerie. Viz obrázky na konci http://www.root.cz/clanky/uvod-do-teorie-barev/
Nejaky pan Kruithof se tim zabyval uz docela davno a zjistil, ze pro kazdou intenzitu osvetleni je jako prijemna vnimana jina barevna teplota, viz en.wikipedia.org/wiki/Kruithof_curve (nevim, jestli a jak se daji vkladat prokliky).
Takze ano, je to samozrejme individualni, ale dulezitejsi je, ze neprimerene slaba zarovka se barevnou teplotou 6000 K pripada hnusne modra vsem a neprimerene silna s 2500 K zase vsem pripada hnusne zluta. Prvni pripad se v domacnostech vyskytuje mnohem casteji ;-)
Pokud vám to uniklo, tak unixová filosofie se na Linuxu týká prakticky výhradně administrace systému, která je prostě opsaná z půl století starých klasických unixů. Kdyby se Linux téhle filosofie držel, nikdy by nevznikly projekty jako OOo, Gimp, KMail, KDE a Gnome, které prostě tvoří velký funkční celek. Pro pobavení bych chtěl vidět projekt typu OOo v designu podle unixové filosofie :D
Klíčem k úspěchu systému je jednoznačně user-centered design (vizte Windows, MacOS, Android). Snaha je vidět i na Linuxu. Jenže vzhledem k příkrému rozporu nebo unixovým a user-centered designem je z toho takový nedovařený kočkopes. Otázkou je, jestli katastrofální neúspěch Linuxu na desktopu není právě důsledkem tohoto základního rozporu konceptů.
Toto je asi vec nazoru, respektive toho, ako siroko chapeme "jednu vec."
IMHO je Gimp editor obrazkov, a to je ta jedna vec, ktoru robi dobre. Proti filozofii by siel, ak by k tomu renderoval video alebo pocital tabulky.
Bolo by mozno zaujimave rozbit ho na sadu utilit, pre kazdu operaciu kus, ale uprava obrazkov je podla mna jedna z mala veci, ktore sa naozaj robia najlepsie mysou :)
Jsou veci, ktere je lepsi udelat jako CLI+ frontend a veci, ktere se tak radsi nedelaji. U malych veci typu Redshift je CLI+fronend dosti vyhodne. Mohl byste si treba zbastlit skript, v nem zavolat nejakou geolokaci a podle momentalni polohy si pustit redshift s prislusnymi parametry. Kdyz nekdo cestuje mezi casovymi pasmy a neni to zrovna v Africe, kde geolokace chodi treba s presnosti na pet set kilometru, nebude muset furt nekde klikat jak pako, jako ve Widlich. Kdyz si to dobastlite do bashrc nebo nekam, tak akorat pustite masinu a je to. A ted se pochlubte, jak byste to resil ve Widlich tak, abyste kvuli tomu nemusel napsat celou aplikaci znovu.
Zkurvená, zkurvená a ještě jednou zkurvená antispamová ochrana.
http://pastebin.com/download.php?i=QZmFjuMX
Ano, je to tak strasne pomale, ze to bezi mnohem rychleji, nez Widle XP na stejnem HW. A uplne nejhorsi je, ze po zapnuti nemusim pul hodiny a vic cekat, nez se zupdatuje kdejaka sracka a zacne to byt pouzitelne. Blbe je i to, ze se to v Linuxu bez problemu probouzi z hibernace treba i po nekolika tydnech bez restartu, zatimco ve Widlich kazdou chvili nenajede WiFi a pomuze jen restart. Clovek tim prijde o tolik srandy. Namisto restaru a reseni kokotin to funguje.
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ě
>- Použití Registry nevyžaduje reboot po změně nastavení
Jiste, reboot je vyzadovan pouze systemem, ktery jinak nedonutite nacist nove hodnoty. BTW, porad jeste se dlazdicove Widle musi rebootovat i kvuli takove kokotine, jako prerazeni do jine workgrupy?
>- 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? :)
Prijde na to. Bud tam najdu starou verzi nebo se to jeste stihne zapsat. Pokud se to posere, tak obnova jednoho konfiguraku je mnohem mensi pruser, nez obnova lehle registry db.
>- 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)
Cekal bych, ze admin ve firme nebude prase a hodi tam nejaky komentar. Pokud ne, urcite to najdu snaze nez to, kdo kdy zmenil nejaky klic v registry.
>- U konfiguráků také po odinstalaci nevíte, co kde zbylo
Jednou za rok pustim v konzoli prikaz, ktery zbyle konfihuraky zlikviduje a ziskam tak nekolik kB mista.
>- U konfiguráků se také hromadí bordel
Kde, proboha! To abych to honem mohl uklidit.
>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.
To jsou aplikace konfigurovane pres GUI. Nikdo je nekonfiguroval rucne ve vasem oblibenem vi, tak tam nenapsal zadne komentare. Podivejte se do konfiguraku treba od pdnsd nebo kismetu - schvalne, jestli tam najdete komentare.
>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ů).
Jeste se mi nejak nestalo, ze bych nevedel, co k cemu patri. Jaksi se to pozna podle jmena nebo podadresare, ve kterem to je v /etc.
>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
To se stava dost bezne i na certifikovanych strojich, ktere byly s Widlemi prodany.
>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ě
Jiste se rad podelite o zdroj svych statistik.
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.
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.
>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.
No, tak kdyz budu s nb prechazet mezi sitemi ruznych lidi a pres sit si s nimi vymenovat soubory a jednou jsou v mshome, jindy ve wg, pak ve workgroup...., tak budu pokazde rebootovat. Pokud tedy nemam n stroji Linux. Pustim si treba Krusader a ten na worgrupy kasle, necha me delat treba s nekolika najednou.
>který příkaz vám vybere a odstraní konfiguráky?
dpkg -l | awk '/^rc/ {print $2}' | xargs dpkg -P
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ů/administrá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.
Ne, klice nejsou rozsety nahodne, ale Registry je tak neprehledne, ze v konecnem dusledku to neni prehlednejsi, nez kdyby nahodne rozsete byly. Popsana struktura vas take moc nevytrhne. Registry nejsou vec, kde na jednbom miste najdete kompletni konfiguraci napriklad nejake aplikace. Ta konfigurace je rozhozena v ruznych vetvich Registry a to bez komentaru a dokumentace o vyznamu klicu. Vyznam tech klicu muzete obcas jeste nekde vygooglovat, pokud se tykaji Widli samotnych. U aplikaci uz to byva horsi a muzete jen hadat podle nazvu klice, pricemz mnozinu moznych hodnot a vyznam jednotlivych hodnot neznate.
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\CurrentControlSet\Services. 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
Konfiguraky jsou typicky v /etc. Konfigurace jedne aplikace je budto v jednom souboru, ktery typicky, v rozporu s vasim tvrzenim, je okomentovany. V nekterych pripadech konfigurace je v podadresari v /etc, obvykle proto, ze je ulozena ve vice souborech - rovnez okomentovanych. Komentare casto (mozna i obvykle) obsahuji i seznam moznych hodnot. Pokud ne, je ke konfiguraku man stranka. Vyjimky jsou vzacne, pak obvykle pomuze Google.
Uzivatelska konfigurace je podobnym zpusobem ulozena v uzivatelove home adresari. Pokud toto je to, co myslite tim, ze je konfigurace ulozena v ruznych vetvich FS, tak ano, mate pravdu. To same se ale tyka Widli, kde uzivatelska vetev registry je v uzivatelove profilu.
Na Widlich v registry ale nenajdete ani klice jedne aplikace nekde v nejake vetvi typu HKLM\Software\AplikaceBFLM, jako na NIXech vsechno pokupe v /etc. Kdyz je clovek obcas nucen hrabat se v te registry tragedii, tak zira, na kolika moznych mistech se klice mohou objevit a jedinym "komentarem" k nim je jejich jmeno a intuice.
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?
>No a ve Windows máme prostě GUI "na všechno"
Jenze tohle proste neni pravda. Mate GUI na vsechno, s cim MS pocital.
>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?
Tak si vyberte nejaky soft, ktery mate ve Widlich a podivejte se, kde vsude ma klice. Treba vycisteni prasacke instalace, ktera si po sobe neuklizi, urcite neudelate vymazanim jednoho klice i s podklici. Stravite pul hodiny hledanim, kde vsude je to rozesrane a premyslenim, jestli si muzete dovolit prave tohle vymazat, aniz by se vam posraly Widle.
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/app/whatever.whatever), 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\Classes\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í.
Docela ma tesi, ako stale omielate konfigurak zrovna z OpenOffice. Ten totiz vznikol "preportovanim" konfiguracie zalozenej na Windowsackom registry do multiplatformoveho XML suboru. Este tusim verzia 3 si nastavenia na Windowsoch ukladala do registrov, takze na nejake komentare akosi neostalo miesto :)
Podobne to riesi Steam, ktory k tomu dokonca poskytuje API pre jednoduche portovanie. Vysledny konfigurak je skutocne "pohlad".
"Registry" { "HKLM" { "Software" { "Valve" { "Steam" { "InstallPath" "/home/user/.local/share/Steam/" }}}}}
Je to mor a siri sa to.
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.
> Tím na studeno máte na mysli, že žádná část LO není v cache?
Ano.
> Navíc LibreOffice používá by default quickstarter
V Linuxe to zjavne nieje potrebne. Okrem toho, moj stroj nestartuje zrovna by default :)
> Na Windows podobné problémy s výkonem u konfigurace řešit nemusíme, protože používáme Registry.
Mate Vy, clovece nestastny, vobec predstavu, kolko trva studeny start MS Wordu? :)
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.
>LibreOffice má samozřejmě quickstarter i na Linuxu. Pokud jsem správně četl, v recentních verzích je by default zapnutý.
Asi jste cetl spatne nebo doslo k sumu na lince. Libreoffice sice volbu spusteni Quickstarteru ma, ale u me je defaultne vypnuta. Krome toho by nekdo musel vyzkouset, co to vlastne dela. Jestli to natahne pul Libreoffice, jako na Widlich nebo to jen dela systray ikony pro rychly pristup ke spousteni aplikaci.
Mno a teraz, ciste pre moje osobne pobavenie, plus teda preto, ze tato diskusia nikam nevedie... Realna ukazka textak VS registre :)
Tento skriptik v PS dokaze 3 veci. Za prve, vypisat zoznam instalovanych aplikacii a ich "Uninstall path" citanim z registra. Za druhe, vyexportovat tento zoznam do komentovaneho INI suboru. A za trete, citat a parsovat tento INI subor.
Na mojom stroji citanie trva 698ms z registrov a 482ms z textaku. Mozete pouzit Measure-Command { .\regtest.ps1 -reg } a Measure-Command { .\regtest.ps1 -read }
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.Windows.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é.
Scenar samozrejme zmysel ma, hrat hru pri stlmenom displayi je problematicke a vypinat to rucne sa mi nechce. Nastastie to bol v podstate one-liner.
> Nejjednodušší je ale samozřejmě použít takovou utilitu, která má požadované chování vestavěné.
Presne tak. Alebo pouzit funkcie, ktore ma PS vopred vstavane. Nad objektami, ktore musia byt zas len vopred definovane. S pouzitim rozhrani, ktore budu pre kazdy ten objekt celkom ine. Ak ked nieco z toho nieje k dispozicii, ma clovek skratka smolu :)
Preto je PS a jeho pristup len smutnou nahradou za 40 rocne unixove utility a ich vystupy v obycajnom, lahko parsovatelnom a univerzalnom texte.
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.
Ale kludne...
xev -root -event substructure | while read ; do if (xwininfo -id $(wmctrl -l | grep "$GAME" | cut -d " " -f 1) | grep "Viewable") ; then enable_flux ; else disable_flux ; fi done
V reale to mam samozrejme rozpisane do 4 riadkov.
> V PS samozřejmě můžete používat externí moduly.
Pisat externy modul do PS a pisat pipelajnu na spracovanie vystupu su dva celkom odlisne levely sialenstva a ja fakt neverim, ze by sa niekto podujal na to prve len pre to, ze je lenivy nahanat ikonku v trayi.
Plus teda, vlastnosti PS objektu, narozdiel od normalneho textu nieje za normalnych okolnosti prilis vidiet. Takze clovek najvacsie uspechy jeho pouzivania radi zistenie, ze k get-member existuje skratka.
> Ty "vestavěné" (tj. včetně kompletního .NET Frameworku) mají tu zajímavou vlastnost, že jsou k dispozici na každé instalaci PowerShellu.
PS ma dovedna tusim 4 verzie, kazdu s inou sadou cmdletov. Ak by sa stabilizoval zajtra, stale bude minimalne 20 rokov pozadu :)
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.FromHandle().
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 SetMonitorColorTemperature 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
> Ano, PowerShell má čtyři verze, a jsou samozřejmě backward compatible. Ta vaše "stabilizace" je ve skutečnosti stagnace.
To mi je ale na dve veci, ak rano sedim za masinou s W8 s PS4 a vecer za Vistou s PS1. Nad tym, ze by nebol kompatibilny ani spatne som ani neuvazoval.
> Navíc pokud tomu správně rozumím, tak hooknete všechny X11 events...
Je mozne, ze filtrovanie eventov pribudlo niekedy nedavno, ale v tomto pripade na tom nezalezi, da sa nahradit jednym grepom.
Pokial sa nezacne diat nieco vyslovene sialene, eventov nad xroot-om nebude 1000 za sekundu. Nebude ich ani 10 :) Xroot dostava eventy len, ak nejake okno zmeni vlastnosti, zmizne alebo sa vytvori. A s filtrom len pri miznuti a vytvarani, cize presne pri tom, co potrebujem. Zvysok len testuje, ci som (od)minimalizoval to spravne okno, sposobom, ktory mozno nie je najefektivnejsi mozny, ale zas sa lahko pise z pamati.
> Jak totéž udělat ve Windows:
Vase priklady maju par dost vyraznych chyb. NativeWindow podla vsetheko nepripichnem na okno cudzieho procesu a UI Automation dokonca predpoklada, ze proces hry zo skriptu spustim. To ale nieje automatizacia, ak mam povedla hry startovat skript, ci dokonca hru skriptom pustat, mozem rovnako dobre flux ci redshift rucne vypinat.
> Na rozdíl od vašeho slepence v shellu je to čisté
Problem je, ze ste zjavne vobec nepochopil, k comu sa shellskripty pouzivaju. Shellscript nieje programovanie ani sutaz v efektivite, aj ked sa urcite efektivne skripty pisat daju.
Skript clovek pouzije, ked ma pred sebou automatizovatelnu ulohu, ktoru poklada za stratu casu. Skript sa pise narychlo, idealne z hlavy, ladi sa volnym okom a ked po 3 minutach zbehne za 5 sekund a usetri tak hodinu, vyhlasi sa za uspech a ostane zabudnuty v /tmp.
Keby som to chcel robit cisto a poriadne, obetujem 10 minut, napisem to v pythone a dostanem nieco v zmysle
Xlib.Display().root.set_event_mask(X.SubstructureMask) for event in Xlib.Display().root.events() : if "Hra" in event.window.title: if event.type == X.UnmapNotify: flux_disable() elif event.type == X.MapNotify: flux_enable() (nazvy metod si pamatam velmi matne)
Skratka a dobre, PS sa sice tvari ako shell, ale v skutocnosti je prapodivnou nahradou za python. Ostava len dufat, ze bude MS v tom znovuobjavovani Unixu este nejaky cas pokracovat :)
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.FromHandle() 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é.
> doipředná kompatibilita je ve světě SW dost neobvyklá. Těžko být kompatibilní s něčím co ještě neexistuje.
Preto je vhodne, aby bolo nieco tak zakladne, ako shell navrhnute dobre hned na zaciatku a nie postupne doplacavane 20 rokov pozadu.
> NativeWindow.FromHandle() by měl fungovat i na cizí proces. PS cmlet Get-UIAWindow umí parametr -ProcessName.
Google mi tvrdil nieco ine, ale mozno len zle chapem. NativeWindow.FromHandle berie handle okna, nie handle procesu - The handle must already be owned by another NativeWindow in the current process; otherwise, null is returned.
Odhliadnuc od toho vsetkeho, nevidim sposob, ako sa k tomu handle dostat, teda okrem moznosti, ze by skript kazdych X sekund prechadzal vsetky existujuce okna a hladal podla titulku.
> 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 (...)
Tieto aplikacie zrejme ziaden CLI interface neposkytuju, ale na na manipulaciu s CSV a OO formatmi existuju ine CLI utility, ktore by som pouzil. V nastaveni Firefoxu nevidim problem, staci skopirovat predpripravene sablony alebo skriptom upravit jeho konfigurak.
Ako by ste pracu s KMailom, OO Calcom a OO Writerom (nie s ich MS alternativami) riesil z PS?
> Souhlas, skripty jsou často divoké slepence. Ovšem ten co jste předvedl je dost síla i na můj vkus.
Nepripada mi nijak zvlast komplikovany a hlavne, dostatocne efektivne riesi moj problem. Vase riesenie v PS nemalo ani jednoduchost shellu, ani eleganciu pythonu (perlu, ruby, atd) a zatial sa mi nezda ani, ze by mohlo realne fungovat :)
> Mimochodem vám moc nevěřím, že by root window dostávalo tak málo zpráv.
Dakujem za, nepochybne opodstatneny prejav dovery. Pokojne si to mozete vyskusat.
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.FromHandle berie handle okna - vizte Process.MainWindowHandle
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
> http://www.openoffice.org/udk/common/man/tutorial/office_automation.html
Zaujimave, o tom som nevedel. V kazdom pripade, rovnake bindy existuju aj pre python ( http://stuvel.eu/ooo-python ), takze ich pouzitie zo shellu je sice absolutne sialene, ale technicky mozne.
$ python3 -c "import OOoLib ; print (OOoLib.getDesktop().getCurrentComponent().getSheets().getByIndex(0).getCellByPosition(0, 0).getFormula())" =7*6
Pre castejsie pouzitie by som si asi urobil alias :D
> Pokud vám připadá jako dobrý nápad běžet na pozadí skript, který spouští pět procesů
Mate daku averziu na procesy, alebo je tu iny, mne unikajuci problem? Skript nezatazuje CPU ani len na tolko, aby sa objavil vo vypise prikazu top.
> linkoval jsem dokumentaci X11R7.7, kde to filtrování není popsané
Nech sa paci, man aj s -eventom: http://www.straightrunning.com/tools/xev.html
V kazdom pripade, male mnozstvo eventov pre root window plati aj bez filtrovania. Mysacie eventy odchytava okno plochy a okrem nich sa s root window prilis cvicit neda.
> NativeWindow.FromHandle berie handle okna - vizte Process.MainWindowHandle
Ale podla dokumentacie neberie handle okna *cudzieho* procesu. A stale ostava otazka, ako sa dostat k Process objektu danej hry.
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.
> otázka je, proč si radši nepořídíte shell ze současného století.
Neviem. Riesili sme bash, tak som pouzil bash. Ono viete, zacinam mat pocit, ze si objektovo orientovany shell predstavujete ako daky revolucny vynalez Microsoftu... Dufam, ze nie, to by bola strasna hlupost :)
OO shelly maju v Unixe nie prilis vyraznu, ale dlhu historiu. Ostatne, aj taky python sa da pouzit ako shell a shellov kombinujucich jednoduchost *shov a moznosti niektoreho unixoveho OO jazyka poznam niekolko. Nieje o ne ale prilis velky zaujem a zatial sa neujali.
> Má to obrovský overhead. Musíte pokaždé zavést binárku a vytvořit proces, plus provést marshalling
Preco by sa robilo nieco tak zbytocne? Fork nieje doslova no-op, ale jeho rezia je minimalna a binarka bude po 2-3 spusteniach v cache pribita hodne na pevno. Predstavujete si to ako Windows :)
> Upřímně se mi to nechce psát, protože pro ten kód nemám využití; experimentovat snad můžete sám
Ani static constructor, ani UI Automation mi neda moznost sledovat vlastnosti okna cudzieho procesu, nehovoriac o tom, ze handle toho procesu nemam. Zatial ste mi neukazal nic, co by nejak smerovalo k rieseniu a ja mam pocit, ze sa ten one-liner do dakeho efektivneho kodu pre Windows previest neda.
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á.
> K tomu objektovému shellu byste totiž potřeboval i dostatečně rozšířený, dobře použitelný a široce implementovaný objektový model.
Nemyslim, ze by v unixovom svete existovalo nieco, k comu nie su bindy aspon na python, ruby a perl :) Plus teda, nieviem ako tie dva, ale python vie volat ceckove API rovnakym sposobom, ako sa mi tu snazite predviest v PS.
> 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
Preboha preco? Fork pamat nekopiruje a exec uvolnuje aj to, co sa pripadne zapisalo. Spotrebuje sa pamat na nazov exacu a argumenty, ani o bajt naviac.
> budete muset vytvořit proces - relokovat kód, alokovat stack a heap, a provést spoustu další inicializace.
Kod uz mam v pamati a ostatne je porovnatelne s prekladom typov a volanim cudzej funkcie. Naviac, nakolko volam optimalizovane binarky miesto interpretovaneho kodu, pravdepodobne to budem mat hotove skor :)
> 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
new-object NativeWindow mi skonstruuje okno s handle nastavenym na NULL. Mozem sice volat AssingHandle, ale, citujem, The handle to assign cannot be in a different application process. Nula bodov.
UI Automation som si skusil. Vidim 3 problemy. Je neuveritelne pomala (a CPU hori) Vyzaduje admina. A stale nedava ziaden sposob, ako zistit, ze ziadane okno existuje, teda ziaden iny okrem toho, ze by som volal Get-UIAWindow v nekonecnom cykle. SetWindowsHookEx jakbysmet.
> Představa že nejde ve Windows provést hooking window messages cizího procesu mi přijde dost vtipná.
Nevidim na nej nic vtipe. Windows je hodne obmedzeny system, ktory na Unix skratka este nedorastol. Uz len to, ze 3 dni chodite okolo niecoho, co v Linuxe predstavovalo no-brainer na 1 a pol minuty hovori za vsetko :)
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.
>Máte snad kalkulačku, OpenOffice nebo KMail rozdělený na GUI a command line utilitu? Asi ne.
Minimalne u kalkulacky si to umim predstavit. Jestlize napriklad mate nastroj na presne vypocty na X desetinnych mist, kde X je velke cislo, proc byste se patlal s celou arirmetikou+GUI, kdyz muzete pouzit frontend?
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.
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 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.
Chapem ako to myslite a vobec sa Vam nedivim, nemate ale celkom pravdu. Hovorime totiz o Windows ;)
Ak sa takyto skript vykona v PS *bez* dealokovania excelovskeho objektu, tento ostane v pamati dokonca aj po zatvoreni shellu a hlavne, zostane otvoreny aj excelovsky subor. To znamena, ze subor nemozete otvorit v inom programe, ani presunut alebo zmazat. A ak nahodou o tejto vlastnosti PS neviete, pri hladani priciny sa celkom pobavite.
"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.
Je uplne jedno, jak to bude realizovane, dulezite je, ze to jde. A nekdy se to hodi, kdyz treba potrebujete nejakou GUI funkcionalitu k necemu, co ma jen CLI a nechce se vam travit cas vyvojem neceho, co uz je vyvinute po mnohalete praci do uspokojiveho stavu nebo upravou tak, aby to slo zapasovat do vasi GUI aplikace. Treba prave zminena presna aritmetika nebude tak uplne trivialni vyvinout a vy si usetrite dost prace, kdyz si akorat nekde naklikate GUI o par kB. Namisto abyste stravil dva roky vyvojem presne aritmetiky udelate stejne funkcni vec treba za par dni.
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=$objExcel.Workbooks.Open("C:\Users\Lael\Documents\My Document.xlsx")
$objWorksheet = $objworkbook.Worksheets.Item(1)
if ($objWorksheet.Cells.Item(1,1).text -eq "Hi there") {$objWorksheet.Cells.Item(1,1) = "Hello World"
>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.
Hm, vy asi na te kalkulace umite datlovat opravdu rychle, ze vas to omezuje.
Frontend + backend se pouziva tam, kde to ma smysl. Treba u Nmapu to ma sve vyhody. Existuje vice frontendu. Vyberete si ten, ktery se vam libi, naklikate, spustite. Frontendy se meni, Nmap je porad stejny. Uz vidim, jak by jinak nekdo vyvijel Nmap v kdovi kolika verzich s ruznymi GUI. A to, ze je tam nejaky overhead, je vsem, krome vas, uplne jedno. Stejne se na vysledek Nmapu musi cekat a jestli dojde k par milisekundam zpozdeni navic, je uplne putna.
BTW, mate OS, jehoz instalace se dnes nevejde na DVD a mluvite o overheadu.
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)
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.
Nás už ani nepřekvapuje tvoje zabedněnost. Asi jsi si nepřečetl, že je k dispozici redshift-gtk nebo plasmoid pro KDE. To aby i klikači měli pohodlí. ALE JE TAM MOŽNOST VOLBY! Což je heslo který Microsoftům vytváří kopřivku. My tě chápeme, docela nás tvoje návaly i těší ale furt s tím nepruď.
Jasně, možnost volby je zásadní. Máte v autě volant trojhranný, čtyřhranný, šestihranný, nebo kulatý? A kola šestihranná, 12-hranná, nebo kulatá? A kurzor myši se vám při pohnutí myší směrem nahoru pohybuje nahoru v úhlu 5 stupňů, 45, stupňů, nebo prostě přímo nahoru?
Cože, oni vám v těch věcech fakt nedali na výběr? No to je prostě skandální :D
Trochu vážněji: možnost volby je do jisté míry vítaná. Problém to začíná být ve chvíli, kdy jde o nutnost volby. Víc vám k tomu řekne Sheena Iyengar, která se možností volby důkladně zaobírala.
http://www.ted.com/talks/sheena_iyengar_on_the_art_of_choosing.html
Ano, nedáme možnosť voľby a povieme, že keď sa dlaždice výborne osvedčili v kúpeľni, tak ich dáme aj do spálne. Ba sú také skvelé že ich začneme dávať aj do postelí namiesto matracov. (Podobnosť s operačnými systémami je čisto náhodná prispievateľ za to nenesie žiadnu zodpovednosť.)
Mě překvapuje, jak může někdo nechápat užitečnost CLI, když i na jeho oblíbených Windows se každá druhá aplikace přes CLI, alespoň částečně, ovládat dá a často se to používá při scriptování(typickým příkladem jsou třeba aplikace od Vectoru, které se používají v automobilovém průmyslu).
Je prostě vidět, že pro samé PR ani v těch Windows nic nedělá...
Pamatuju si, jak widlaři vždycky řvali, že něco není klikací, že se to musí pracně řešit z CLI. Před pár lety jsem pak měl tu „čest“ účastnit se školení na Active Directory, kde se pan evangelista dmul pýchou, jak MS vymyslel administraci z CLI a jak je to skvělé, že se to nemusí klikat.
Takže když vidím widlaře psát o CLI, vždycky se směju.
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ě LmCompatibilityLevel (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.
Protože u toho přemýšlí. Programy bez CLI mají výrazně omezenou využitelnost, pokud zrovna nejde o čistě interaktivní věc, což v tomto případě ani náhodou není.
Navíc někoho baví (tj. umí) low-level věci, umí napsat knihovnu a CLI, které něco skutečně dělají. A jiného baví (tj. umí) grafika, low level záležitosti jej nezajímají, ale rád napíše ke knihovně/CLI nástroji GUI.
Navíc řešení formou knihovny/CLI umožňuje tu funkcionalitu využít i ve spoustě jiných projektů. Stále vidím ty chudáky, kteří když si chtěli automatizovat přepínání konfigurace zvukovky ve win, museli si napsat makro, které klikalo na konkrétní souřadnice na obrazovce, protože ke klikacím okýnkům "ovladače" výrobci zásadně nedodávají žádné využitelné API, natož aby bylo aspoň trochu standardizované.
Kde je u téhle utility problém s GUI? Spustíte, nastavíte lokaci a teploty, a necháte běžet. Ve Windows bych viděl dva způsoby, jak to napsat:
A. GUI aplikace běžící na SysTrayi (ta může akceptovat parametry i na command line).
B. COM komponenta provádějící vlastní nastavení barev, a k tomu GUI aplikace běžící na SysTrayi (ta může akceptovat parametry i na command line). To umožňuje funkcionalitu použít i bez GUI. Ale upřímně jde o pár volání API, takže dělení na back-end a front-end nemá moc smysl, zvlášť pokud dáte k dispozici zdroják.
Na Unixech je ale nejspíš problém v tom, že "GUI aplikace běžící na SysTrayi" se řeší v každém prostředí jinak. Ovšem vázat front-end a back-end pomocí command line je
Přepnutí defaultního sound device ve Windows nemá podporované API, a to záměrně. MS totiž celkem správně dospěl k názoru, že výběr defaultního zařízení by měl být pod kontrolou uživatele, a nikoliv aplikací. Samozřejmě aplikace může pro přehrávání vybrat jiné zařízení. A samozřejmě můžete pro přepnutí default sound device použít nepodporované API:
http://www.daveamenta.com/2011-05/programmatically-or-command-line-change-the-default-sound-playback-device-in-windows-7/
> Na Unixech je ale nejspíš problém v tom, že "GUI aplikace běžící na SysTrayi" se řeší v každém prostředí jinak.
http://standards.freedesktop.org/systemtray-spec/systemtray-spec-0.2.html
Proč bych měl při každém startu systému něco ručně spouštět? Snadno zapíši do startup skriptu a hotovo. Navíc tu aplikaci mohu zaintegrovat do čehokoliv, co potřebuji.
GUI je jen nadstavba nad funkcionalitou, rovnou funkci natlačit do GUI aplikace bez možnosti ovládání jiným způsobem by v tomto případě byla pěkná čuňárna. Stejně by to někdo z takové aplikace vytáhl a vytvořil pořádnou knihovnu nebo alespoň binárku s pár parametry. Přesně od toho open source je.
Ad ty zvukovky - vůbec nejde o výběr defaultní zvukovky, ale např. o její přepnutí na externí hodiny pro lidi, kteří mají DAC s interními hodinami vyvedenými do zvukovky. Na takové funkce win ovladače žádné API nemají, výrobce nabízí max. čudlík na omalovánkách. Takže tihle nešťastníci si při startu foobaru spouští ještě nějaká uložená makra v obskurních utilitkách, která jim na ten čudlík kliknou. Možná to i dokonce funguje i po přesunu okna "ovladače". Pěkný humus.
Proč bych měl při každém startu systému něco ručně spouštět - to fakt netuším. Tu GUI aplikaci bych samozřejmě spouštěl automaticky při přihlášení.
To chcete každou trivialitu, která se stává z pár volání API, rozkládat na back-end a front-end s voláním přes CLI? To volání přes CLI je čuňárna, navíc to vylučuje obousměrnou typovanou komunikaci. Knihovna je lepší, ale nejlepší je samopopisná komponenta - ve Windows COM nebo .NET.
U GUI nad CLI je pak velikým problémem kvalita toho GUI. CLI aplikace mají jiný koncept ovládání než GUI, takže pak vaše GUI může dopadnout katastroficky. Na ukázku wGetGUI, které odradí snad každého:
http://www.jensroesner.de/wgetgui/wgetgui_simple.png
http://www.jensroesner.de/wgetgui/wgetgui.png
Upřímně popisovaný scénář s kliknutím na čudlík (mimochodem dělá se to tak, že pošlete zprávu s ID prvku, na který se "kliklo", takže to většinou přežije i do nové verze GUI - neposílají se souřadnice kliknutí, jak si asi myslíte) mi připadá stejně "elegantní", jako volání command line utility. Obojí je v principu proces který neumožňuje typovanou obousměrnou komunikaci. Prostě to chce API.
A to API samozřejmě existuje. Nebo myslíte, že ta aplikace od výrobce funguje na principu kvantově-vlnové holistické esoteriky? :D Pokud vám to neřekne výrobce v dokumentaci ani po dotazu na support, stačí se kouknout, jaké moduly ta aplikace natahuje, nastavit si v debuggeru pár breakpointů, a hned víte, jak se daná věc přepíná. Pak už je triviální si napsat utilitu na deset řádek.
BTW trochu mi uniká smysl. Pokud chcete mít zvukovku řízenou externími hodinami, tak prostě nastavíte fixní sample rate a použijete externí hodiny - vždy a pro všechny aplikace. Proč to přepínat při startu jednoho přehrávače?
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?
A proč psát vždycky aplikaci s GUI, když to je často nepoužitelný?
Máme tady v práci i experty jako jsi ty, bohužel. Pro release software máme utilitku, která poslepuje binárky do balíku, který pak jede na servery pro field update. Tu utilitku psal jeden takový moula jako ty. Díky tomu, že je to potřeba naklikat ručně v okýnkách, je release software na cca dvě hodiny, člověk to musí dělat ručně, kontrolovat podle check listu,... Pro update, pro factory release, testovací verze,... Proti možnosti napsat si třeba hloupý dávkový soubor, který to udělá naprosto přesdně a během dvou minut je efektivita GUI a odolnost proti chybám naprosto evidentní.
Pokud jde o utilitu která se nepoužívá interaktivně, tak by samozřejmě neměla být závislá interaktivním uživateli. To nevysvětlujte mě, ale jejímu autorovi :). Kdybych to psal já, tak buď ta GUI aplikace umí načíst parametry z XML specifikovaného na command line, nebo je rozdělená na non-interactive back-end a GUI front-end sloužící k editaci toho XML.
Zkurvená, zkurvená a ještě jednou zkurvená antispamová ochrana.
http://pastebin.com/download.php?i=QZmFjuMX
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á.
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
Tesi me, ze ve Widlich problemy s escapovanim resit nemusite. Ale mezery v nazvech jsou svinstvo jak na Widlich, tak na Linuxu. Nevim treba, jak budete resit treba parsovani vystupu nektere te genialni utilitky z Resource Kitu, kdyz mate ve vystupu nazvy souboru s mezerami. To jste v riti, jak Bata s drevakama. V Linuxu ty utilitky mivaji vystup alespon tak inteligentne formatovany, ze se to da odchytit alespon podle pozice. Co jsem videl v RK, tak ani nahodou.
> 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ářů.
Ciste pre potesenie publika :)
http://www.securityfocus.com/columnists/301
Toz, zabavne to je, ale prakticke pouziti bude dost omezene. Zapis do root adresare je defaultne nemozny. Nekdo by musel rozorat defaultni prava nebo si dat Widle na FAT.
Spis by se dalo doufat v nalezeni vyuzitelneho klice se spatne nastavenymi pravy. V tom bordelu registry nikdy admin nemuze overit, jestli tam neni dira, ale cyberlump muze mit stesti.
Jinak na Widlich si porad funguje stara dobra DOSova ficura, ze se spoustene programy vyhledavaji nejdrive v aktualnim adresari. Cili staci nastrcit vhodny program vsude, kde se da a doufat, ze si to admin pusti.
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\Manufacturer\App\image.exe", a nikoliv C:\Program Files\Manufacturer\App\image.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.
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/
To je moje oblíbený řešení, konfiguraci do souboru pro konkrétní projekt a jenom předat nástroji ve skriptu odkaz.
Problém je jenom v tom, že tady dělám kustomizace. Tzn, když chce zákazník něco změnit, přidat novou funkci do existujícího produktu, upravit GUI podle sebe,... Na přepssání nástroje nemám čas a manažer ani nedá peníze. Tenhle nástroj dělali ti, co vymysleli původní aplikaci a dělali jenom tři testovací releasy a jeden finální, tam se to v té roční práci deseti lidí nějak ztratilo. Jenomže když mám týden až dva na úpravu softu včetně testu a release ve dvou lidech (já + tesťák), už je to docela poznat. A pokud se při testu najde chyba, už je to podstatná kompilkace...
Navíc 2/3 času nesežere kontrola a nastavování, ale fakt, že ten pitomec neošetřil výjimky. Stačí jeden překlep, vyskočím z edit boxu a spadne to celý...
Flux som poznal, pri praci na pc je to trochu zlozitejsie, vacsinou tam byva aj iny zdroj svetla.
Ale ten Twilight je fajn.
Clovek vacsinou v posteli siahne po smartfone alebo tablete, napriklad pred spanim. Pre taketo zariadenia urcite nie je problem rozsirit aplikaciu aj o sledovanie vonkajsej intenzity osvetelenia pomocou zabudovanych senzorov ako je to pri automatickom nastavovani jasu a tym vyriesit na zaciatku spominany problem.
Koncne vim, na co ten Redshift je. Kdysi jsem to nainstaloval do Bubuntu a po spusteni gtk-redshift to akorat krachlo. A i nyni v poslednim LTS to porad jeste nefunguje, jen kratce blikne prazdne okno. Tak hlavne nekdo zase napiste, jak je Ubuntu stabilni distro. Kdyz to nefunguje, nebude to fungovat ani za pet let.
Tohle sice funguje, ale nepripada vam smesne mit "frontend", ktery musite spoustet z prikazove radky, a ktery neumi nic jineho, nez Toggle a Quit? A proc tedy takovy frontend vubec pri instalaci zarazuji do menu aplikaci, kdyz to odtamtud nejde spustit, protoze tomu chybi parametry? A proc, kdyz to spustim z konzole, tak to vypise hlasku o tom, jak to krachlo a ne hlasku, kde by se to dozadovalo parametru?
Pokud tenhle fronend nedela vic, nez Toggle a Quit a pritom se neda ani normalne spustit bez predbezneho vyzkumu na Google, nemel byt do distra vubec zarazen a mel tam byt jenom program pro prikazovy radek. Tohle je nejaka pre-alfa, ktera asi vyvojari utekla omylem nebo co.
Unixové CLI je jednoduché? Vám to používání vi asi vypálilo mozek :). Jinak COM ani .NET samozřejmě nepadá a není nenažraný. Tyhle výtky se mohou týkat leda konkrétních objektů, stejně jako na Unixech konkrétních command line aplikací. Když třeba používáte Word přes OLE Automation, asi to bude chtít trochu paměti.
Z nějakého důvodu je nutné první vytvořit konfigurační soubor ~/.config/redshift.conf. Bez něj to padá s touto hláškou. Třeba zde o tom píše: http://jan.culik.net/problemy-s-kubuntu-12-04-a-jejich-reseni/
JardoP ty už zase perlíš.
Já ti nevím čím to je, aby to nebylo náhodou tvými šikovnými chapadly. Ale jsem to nainstaloval do svého LTS 12.04 kde je mnoho dalších "serepečiček" a ono to nekrachlo. A dokonce to i funguje.
Sice nejsem úplně přesvědčen o funčnosti, ale vyzkouším to. třeba to opravdu bude rozumnější. Než svítit dalšími světly.
Uvidíme.
Nicméně k tvému "výkřiku" bohužel u mě (a asi i u jiných co mají tebou zvané Bubuntu) to funguje.
Ďakujem za článok.
Ešte by to mohlo upravovať farbu podľa počasia, keďže pri zamračenom počasí je teplota svetla tiež nžšia ako pri slnečnom.
Podľa "man redshift" to asi neupravuje jas, iba farbu. Môj monitor upravuje jas automaticky, takže to je OK, ale pre monitory ktoré túto funkciu nemajú by to bolo možno užitočné.
No, to uz je pak lepsi imho udelat programek ktery zapne webkameru, zkalibruje ji, precte kalibracni parametry, stahne z ni obrazek a pouzije ho na mereni intenzity a barvy svetla. Neco podobneho (jen na intenzitu svetla) mam nastavene pri zapnuti notebooku (odladene pouze pro svoji webkameru).
Nainstalováno, díky, uvidím časem, jestli se osvědčí. Trochu mě na takových aplikacích štve (f.lux), že nepopisují technický princip fungování, takže kdo by měl třeba pečlivě nastavené křivky v ovladačích, tak než si to uvědomí, přemlaskne se mu to. Já mám křivky přímo v monitoru a v ovladačích to mám default, takže mi to nic neprovede, po vypnutí budu na svém.
Do mobilu jsem to původně dávat nechtěl, nekoukám do něj dlouho aby to mělo smysl, ale napadlo mě s tím zkusit vyřešit navigaci, nevyhovují mi noční schémata, tak jen snižuji jas + tohle by to mohlo zlepšit.
Tak oprava, f.lux nezničí křivky nastavené v ovladačích, on jen vypne řízení barev pomocí ovladačů, začne je řídit sám a aplikuje svoje křivky. Problém ale je, že když f.lux deaktivuji (třeba pro práci s foto), tak jen zresetuje křivky do neutrálního defaultu, ale nepředá/nezapne zpět řízení barev v ovladačích (dokonce to ani neumožní zapnout), tj. křivky tam máte nastavené, ale nejsou aktivní. Musí se úplne ukončit f.lux, pustit control panel od ovladačů a aktivovat řízení barev. Takže pro práci s grafikou POZOR! (testováno na w7pro 64bit, AMD Catalyst 13.9, f.lux 3.10)
snížit jas/kontrast je asi velmi sofistikované řešení, které v moderních technologiích progresivního jednadvacátého století plné chytrých koncových zařízení neplní asi už svůj účel, navíc, když vědci a experti zjistili, kolik máme druhů světel a až za pár let přibude měkké a tvrdé světlo, budeme zase o krok před nimi
Ten Twilight nefunguje prakticky úplně stejně. Zřejmě kvůli omezením v Androidu to nemění barevné podání, ale prostě udělá přes displej poloprůhlednou červenou vrstvu. Takže barvy jsou trošku teplejší, ale třeba černá kvůli tomu "zesvětlí" na tmavě červenou a vypadá to strašně.
Nesouhlasíš a přitom píšeš o úplně něčem jiném. Funguje to přesně jak píše rypec, popsal jsem to kousek výše. Výsledkem je, že černá už není černá, taky mi to nesedí, ale budu testovat víc nastavení (kombinaci podsvětlení, barvy, ztmavení) a pak se rozhodnu, možná to budu pouštět jen na delší práci (čtení, navigace).
Redshift beru jako zajimavost, ktera muze mit ale jenom marginalni vliv na zrakovou zatez a pouze v individualnich pripadech.
Daleko zasadnejsi jsou napr. obnovovaci frekvence monitoru, hustota pixelu, stabilita obrazu, citelnost fontu, prestavky(!).
Chci videt ty zastupy lidi s poskozenym zrakem a chronickymi migrenami, kteri podlehnou dojmu ze po kalibraci do teplych barev muzou travit vic casu pred obrazovkou. Vdyt o tom prece psali na Rootu i v Blesku ;)
Čiernobiele Elementary icon set:
http://gnome-look.org/content/show.php/?content=134260
Super, zdá se, že konečně něco, co mi pomůže od mé únavy u PC :). Úleva prakticky okamžitá, uvidíme, jak to bude s časem.
Menší problém ale je, že se ukázalo, že můj monitor na horní části obrazu zobrazuje výrazně více červené, než dole - není taky na to kalibrační nástroj?
A mimochodem, jak to, že ukazatel myši to nebarví? :D Teď je takový modrý...
>> Jinými slovy: když mozek vidí bílé světlo, pozná podle něj, že je pořád ještě den a nezačne se připravovat na noční spánek. Vydržíte sice déle a nezačnete podřimovat s obličejem na klávesnici, ale o to hůř se vám bude usínat později v posteli. Může to vést až k narušení spánkového rytmu.
Tak tohle můžu potvrdit. Mám v kanclu studeně bílé LEDky a často jsem ve čtyři (i v pět) ráno totálně "fresh" a jdu spát jenom proto, protože vím, že od deváté hodiny začne zvonit telefon...
Před nějakým časem jsem udělal překlad, který autor přijal, ale zatím to není moc vidět, protože to nenahrál na místo, kam vede odkaz na zdrojové soubory umístěný na kde-apps.org. Říká, že uklízí kód apod., tak to tam ještě nedal, aby nemusel řešit nějaké konflikty - aby tak bránil střetům při slučování.
Další možnost je snížit softwarově jas, u mě třeba příkazem:
xrandr --output DVI-0 --brightness 0.7 --output DVI-1 --brightness 0.7
Nevýhody
- horší rozeznávání tmavých přechodů
Výhody
- nezkresluje barvy
- u tmavého obsahu (některé weby) není problém okamžitě přejít z jasu 0.7 na 1.0, oči z toho nebolí
- stačí xrandr
Protože používám quake-line terminál (Tilda), tak změna jasu obnáší vyvolání terminálu, zadání například texti "jas 8" a odentrování. Řeším to následujícím skriptem, který spouštím přes alias:
#!/bin/bash
jas=`echo "$1/10" | bc -l`
xrandr --output DVI-0 --brightness 0$jas --output DVI-1 --brightness 0$jas
A samozřejmě svítím v okolí monitoru studeným bílým světlem, protože:
- teplá bílá je mi nepříjemná
- monitory poté vyzařují jen minimum světla a nedráždí oči jako ve tmě
Ten jsem nezkoušel, xrandr se mi spouští při startu aby roztáhnul plochu přes dva monitory, tak mi rovnou i shodí jas. Mám v plánu udělat si klávesovou zkratku na zvyšování/snižování jasu a časem i čidlo do místnosti, podle kterého se bude jas regulovat sám ;) Samozřejmě i s plynulým přechodem.
Zatím mi ale stačí napsat do terminálu "jas 10" a jsem na 100% jasu, "jas 7" pro 70% a tak podobně :) S terminálem dělám běžně a napsat těch pět-šest znaků mě nezabije
No nevim nevim, ja bych si teplotu monitoru nemenil, protoze bych pak produkoval netisknutelne fotky ;-)))
Obecne vzato, lide maji radi teple barvy, takze na NB si dam treba jen teple barvy, ale dociluji toho za pomoci barevne sondy ;-))
Ale mnohem lepsi je mit svetlo, co da CRi 90 (kvalita svetla b % viditelneho spektra), lze koupit CRI LED, ta co se mi libi jde koupit jen v USA, nebo ma jinde jiny nazev, i kdyz panel vyrabi v Cine CREE ;-)) ... ma myslim 650lum 5000k a CRi 90
Takze S-IPS/PVA panel nebo jejich 6bit nahrady a kvalitni neblikajici okolni svetlo ... ona ani halogenka neni od veci, ta ma CRI 100 ;-))
Právě jsem vyzkoušel tu androidovou aplikaci.
Šla rychle pryč. Můj čtyřjádrový tablet není dostatečně výkonný, aby tam běželo barvítko, které by bylo se svými skoro 50MB paměťově nejnenažranější rezidentní aplikací.
Navíc, aplikace nemění barevnou teplotu, ale dělá jakési podivné operace. Černá byla před tím černá, teď je jakási růžovošedá.
No a oznamovací lištu neztlumí, takže tlačítka na ní zůstávají jasně bílé.
Volby „Celá obrazovka“ a „Používat grafickou kartu“ mají vliv jen na vyskakovací menu lišty tabletu. Samotná lišta svítí vždy plným jasem (a černá je na něm černá), a nejde s ní nic udělat. Je to Asus Transformer TF700T a Android 4.2.1 od výrobce.
Stejný problém má na tomto tabletu třeba i aplikace Screen Filter. Je to zřejmě problém Androidu. Staré API na přístup k tabletové liště v ICS a JB nelze použít, a nové API je až v KK.
Ono to nezpomaluje. Jen to trvale obsadí paměť. Dokonce nejvíce paměti ze všech rezidentních služeb.
Ještě jednou jsem se podíval, a ten červený závoj na černé vypnout opravdu nejde.
Podotkneme, ze clovek, ktery napsal f.lux, je docela prase. Instaluje se to do uzivatelskeho profilu, po nabehnuti clovek musi zavrit okno, ktere potrebuje leda tak pri prvnim spusteni a pri dalsich uz leda jen otravuje a konfigurace je ulozena v souboru v podadresari runtime. Cili kdyz to clovek z bezpecnostnich duvodu prestehuje do Program Files, musi nastavit pravo modifikace na ten jeden soubor a pochopitelne nelze vytvorit konfiguraci pro kazdeho uzivatele zvlast. Nobelovu cenu bych autorovi nedal.
F.lux jsem nezkoušel. Našel jsem ho když jsem hledal ukázku reálného použití toho API, které jsem linkoval. Jestli je autor prase, tak je prase.
BTW nevidím důvod SW přesouvat do Program Files, pokud se instaluje do profilu.
BTW2 když SW přesunete do Program Files, pustíte ho pod uživatelem a dojde k pokusu o zápis do Program Files, UAC to přesměruje. Místo do "C:\Program Files\appname\settings.ini" se to přesměruje na "C:\Users\username\AppData\Local\VirtualStore\Program Files\appname\settings.ini".
Článek má několik nepřesností:
Denní světlo má proměnnou teplotu v závislosti na poloze slunce nad obzorem a také mracích. 5500K je typická hodnota používaná jako standard v USA. V Evropě se používá 6500K, protože si to prosadili seveřani jako lépe vystihující jejich typické podmínky pro prohlížení fotek.
LCD displeje mají nativní barevnou teplotu často hodně přes 6500K. Levné NTB často mají výchozí barevnou teplotu nastavenou na nativní někde kolem 7500K, proto svítí nepřizoreně namodrale.
Samostatnou kapitolou jsou displeje podsvícené LED, které sice mají velký barevný gamut, ale výsledkem je, že barevné podání v hodně aplikacích je naopak dost mimo.
Stačí snížit si barevnou teplotu displeje někam mezi 5500 až 6500K a v místnosti mít osvětlení podobné teploty, jak už se v ostatně v diskusi psalo. Fotografové to mají navíc kalibrované.
A nespavost je většinou důsledek přepracování.
Už dlouho používám program SunsetScreen. Kdysi mi ho někdo doporučil na Github, když jsem si stěžoval na nefunkční RedShiftGUI. No a od té doby ho používám, a mám jej radši, než f.lux. V něčem je f.lux lepší, v mnoha věcech však horší. SunsetScreen je pouze pro windows, asi od srpna 2015 i pro win 10. Hlavně umožňuje víc nastavení, a klávesové zkratky. Naopak nepodporuje automatické přenastavení podle geografické polohy, což jsem ale potřeboval - ne vždy chci hned po západu slunce mít červený monitor, ale třeba plynule až po dvou hodinách. SunsetScreen mi toto umožňuje.
http://www.skytopia.com/software/sunsetscreen/