Vlákno názorů k článku
Microsoft zrušil v Office podporu některých formátů od PF - Prej editace registru je netriviální postup :-). To...

  • Článek je starý, nové názory již nelze přidávat.
  • 3. 1. 2008 21:50

    PF (neregistrovaný)
    Prej editace registru je netriviální postup :-). To je přeci základní dovednost uživatele-správce Windows (a WINE samo), to upravovat jej bez nějakého návodu, to už je horší, zlatej /etc a jeho komentované konfiguráky.
  • 3. 1. 2008 22:16

    LO (neregistrovaný)
    Vy jste link na ten návod neviděl? /etc a komentované konfiguráky jsou na Linuxu prakticky jedinou cestou, jak dělat změny v konfiguraci. Pak ještě command line utilitami. GUI utility jsou tak děsivé, že je ani ostřílení admini nepoužívají. Nedivím se. Ve Windows je editace Registry výjimka - jako v tomto případě.
  • 3. 1. 2008 23:00

    Mr.Gentleman (neregistrovaný)
    Existuje i přímo ADM šablona pro Office 2003 SP3, která umožní administrátorům povolit/zakázat toto blokování pomocí skupinových politik. Vzhledem k tomu, že toto budou potřebovat opravdu asi spíše některé firmy, než běžní uživatelé, bude to mít admin jednoduché a uživatel si ničeho nevšimne.

    Viz:
    http://support.microsoft.com/kb/938810/en-us

    http://www.microsoft.com/downloads/details.aspx?familyid=BA8BC720-EDC2-479B-B115-5ABB70B3F490&displaylang=en
  • 4. 1. 2008 9:18

    بطرس (neregistrovaný)
    A budou to mít jednoduché i hackéři, páč a) nikdo nebude záplatovat starší verze Widlows (Micro$hit tenhle krok přeci dělá, aby se zbavil odpovědnosti); b) spousta firem si nebude moci dovolit tyto starší formáty zablokovat. Čili ve výsledku 1:0 pro hackery (anebo pro OO? ;)
  • 4. 1. 2008 8:27

    anonymní
    Ano, souhlasím s tím, že GUI utility jsou většinou příšerné :-) ale vzhledem k tomu, jak jsou okomentované Vámi zmiňované konfigurační soubory, tak mě to nebolí :-). Zase musím uznat, že _většina_ je tak dobře okomentovaná, že prostě _nepotřebuji_ nějaké GUI klikátka - na co taky? aby byla výsledná změna třeba přidání řádku 'FEATURES="parallel-fetch"' do souboru make.conf? To je opravdu _mnohem_ rychlejší to udělat ručně. Na windows mi trochu vadí to, jak jsou registry (ne)zdokumentované. člověk, který přesně neví co dělá, si může velice stylově shodit systém.
  • 4. 1. 2008 11:40

    LO (neregistrovaný)
    Proto se zpravidla nedělají úpravy přímo v Registry, ale používá se GUI.

    Konfiguráky mají řadu problémů. Například na Linuxu se jich používá hromada formátů (včetně těch se sekcemi [section], těch se složenými závorkami, těch bez sekcí, XML), což je dost ostudné. Konfigurák umožňuje nastavit odporující si, nebo nesmyslné hodnoty. Například pokud máte možnost nastavit Security=low|mid|high, s můžete nastavit chybné security=low nebo Security=Kow, což by se vám v GUI nestalo. A pokud je nastavení ParameterA možná nastavit na XYZ jen pokud je Security=mid nebo high, GUI to za vás pohlídá, kdežto konfigurák ne.

    Registry jsou zdokumentované. Někde rámcově, někde velmi podrobně. Spousta věcí je implementation specific, tedy "nehrabte do toho", protože změny se provádějí přes API.
  • 4. 1. 2008 17:21

    anonymní
    Se sekcemi znám jen Xorg.conf, ten je komplet se sekcemi a pak třeba proftpd.conf (část, kde určuji adresáře s jejich oprávněními) a Apache (totéž + moduly). S tímto jsem já osobně neměl problém, většinou to bývá logické, např. pokud mám v FTP dva adresáře a u každého pět parametrů, kde se ve třech jména proměnných shodují, tak jak to řešit jinak? Sekce se jeví jako nejsnažší a nejpřehlednější. Pokud je každá proměnná unikátní, tak se samozřejmě volí metoda PROMENNA=hodnota. To, že konfiguráky _nejsou_ blbuvzdorné je nabíledni. Ale pokud si v make.conf nastavím USW="apache" a zkusím emerge php --pretend tak hned vidím, že apache není v dané proměnné a vím, kde je chyba. Stejně tak, když nastavím USE="apachw". Ve chvíli, kdy je něco takto špatně nastavené, tak je na první pohled jasné kde je chyba, a to mi stačí. Chyba je mezi klávesnicí a židlí, mohu nadávat sobě :)

    Já si mohu zvolit, že _chci_ používat pouze GUI (a jde to - gproftpd jako GUI nástroj pro proftpd, ovládací centrum PC v KDE, atd.) a vím, že tyto aplikace fungují, nemám problém. Ale mám možnost volby - a to je jeden z hlavních důvodů toho, proč ho používám. Ve windows prostě musím používat GUI, i když bych třeba nechtěl a kolikrát je to zdlouhavější. Taky se může stát, že potřebuji něco nakofigurovat vzdáleně - a pokud není na obou stranách rychlé připojení, tak je něco jako "Vzdálená plocha" naprosto nepoužitelné, takže uvítám možnost konfiguračních souborů, které jsem schopný změnit rychle a pohodlně odkudkoliv. Klasický případ - chci vypnout síťové rozhraní. Pro mě je jednodušší napsat do konsole "ifcongig eth0 down", než se klikat přes tři okna, abych se dostal ke kýžené volbě "zakázat"... Také asi proto se ve Vistách začíná objevovat konsole. PowerShell mu říkají? Nevím přesně...

    Rozhodně netvrdím, že je jedna varianta podstatně lepší než druhá - občas se hodí to a občas to, ale odsuzovat konfiguráky jen proto, že mi nepřijdou k chuti je špatné, protože je jasné, že člověku, který je odkojený na Windows, přijdou konfiguráky jako vyloženě špatné :).
  • 4. 1. 2008 17:32

    LO (neregistrovaný)
    Admin GUI na Linuxu jsou tak mizerná, že i já raději použiju command line. Pro vzdálenou správu Windows můžete použít Remote Desktop, který lze použít i na dial-up modemu nebo GPRS (na rozdíl od X11, které je na takové lince nepoužitelné). Plus samozřejmě můžete použít vzdálenou administraci (třeba v regeditu si necháte připojit vzdálený stroj, totéž v konzoli MMC, nebo třeba Performance Monitoru). I ve Windows můžete použít konfiguráky, pokud chcete - stačí si vzít soubor exportu registru (.reg), a změnit hodnoty v něm. Někteří úchylnější jedinci mají .reg soubory s komentáři, změní v nivh hodnoty, a pak soubor naimportují do Registry.

    Klikání přes spoustu oken je třeba jen tehdy, když nevíte, jak danou akci udělat rychleji. Zpravidla existuje content menu, nebo jiná zkratka, kterou časem objevíte. Naopak příkazy na command line neobjevíte, ty se musíte prostě naučit zpaměti. Je to podobný problém, jak vi vs editor v GUI.
  • 4. 1. 2008 21:21

    anonymní
    Jak jsem uváděl - nástroje typu gproftpd a kcontrol jsou docela pěkně napsané, takže s nimi nemám problém změnit to, co je v jejich kompetenci :-). Remote Desktop - to je to, co na pomalých připojení musíte zvolit nějakých 16barev? :-)) (a prosím, neargumentujte, že ne 16, ale 32 :-D). X11, pokud vím, tak ani nebyly navrhované pro takové připojení - koneckonců kdo by se asi připojoval přes Xka jen proto, že potřebuje nastavit v FTP démonovi práva k jednomu adresáři, že?

    ani exportovaný *.reg _není_ konfigurační soubor! Konfigurační soubor = texťák, ve kterém jsou proměnné, které jsou přímo používané a není nutné ho potom _převádět_ do formy, ve které ho může cílový program použít... To co nabízíte vy, je taková náhražka - Windows konfigurační soubory nemají, tak se dají takto nahradit... (Tedy kromě aplikací typu Apache, které si nesou UNIXovou logiku) To je jako když mi nejde nainstalovat nejnovější verze nějakého SW, tak zkusím nižší verzi. Prostě takové šizení - o okomentovaných REG souborech toto platí dvojnásob :-D.

    Ano, toto jsem bral jako příklad, k čemu jsem žádnou zkratku ani content menu nenašel (ano, kromě šidítka typu strčit si zástupce toho připojení na plochu a z něj to pak vypínat). I když mě tak napadá - nedá se ve win. v nějaké nabídce zaškrtnout "zobrazovat ikonu připojení v hl. panelu"? to by pak byla možnost...

    Editor VIM je super věc :-) pravda, konzolovka, ale má své kouzlo :-). Teda když opomenu nevýhodu, že když pracuji s čímkoliv jiným, tak automaticky ukládám sekvencí [esc]wq[enter], což má za následek přidání wq\n do editovaného souboru :-D
  • 5. 1. 2008 12:05

    LO (neregistrovaný)
    Remote Desktop bych řekněme po GPRS neprovozoval v True Color, protože je to za daných okolností zbytečné. Ano, máte pravdu, že X11 nebylo navrhované na pomalé linky. Pro vzdálenou administraci je X11 naprosto nevhodné (i za předpokladu, že byste měl použitelné admin GUI). Jinak ve Windows také nemusíte otevírat RDP session, abyste změnit nastavení. Jak jsem psal, můžete se prostě připojit ke vzdálenému stroji konfiguračním nástrojem (mmc, regedit etc).

    Ve Windows konfiguráky najdete (je pro ně API), ale nejsou primárním úložištěm konfigurace. Exportovaný .reg soubor není konfigurák, ale dá se s ním podobně zacházet (jenom to nedává smysl, když máte kvalitní GUI). Prostě změníte, co chcete aplikovat, a pak provedete import. V Linuxu máte třeba GConf, který je Windows Registry dost podobný.

    Ano, správně, v notification area (nesprávně zvané systray) lze zobrazit ikonu připojení, a pak spojení disablit z kontextového menu.

    Editor vim je především ukázka toho, jak nemá vypadat interface. Takový edit.com má interface daleko lepší (byť pravda jeho features jsou výrazně omezené).
  • 5. 1. 2008 23:21

    anonymní
    Ano přesně jste uhodil hřebík na hlavičku - je to zbytečné. Proč spouštět RDesktop jen kvůli něčemu, co mohu lehce zvládnout přidání dvou řádků do konfiguráku? Právě proto je Xorg na toto nevhodný - prostě se s ním nepočítá jako s nástrojem pro vzdálenou správu. Popravdě v regeditu bych se bál si změnit třeba jen pozadí plochy :-P (nevím, jestli to jde), MMC konsole jsem nikdy nezkoušel.

    Ano, v podstatě ano. Mají příponu ini. Akorát je jich v systému pět a půl. (Tedy myslím takových, jejichž změna pro mě může mít nějaký opodstatněný význam). Něco změníte a provedete import - to je přesně to, co říkám že konfigurační soubor nemá být :-). A GConf může mít možná podobné API, ale rozhodně ne funkčnost - už jen proto, že na Linuxu registry nejsou...

    Editor vim je velice silný nástroj. Právě proto že je konsolový si ho mohu bez problémů spustit kdekoliv i na dial-upu. jako grafická nástavba poslouží balík gVim...

    Tak trochu váhám, jestli pokračovat v diskuzi, vždyť vy nejste schopen uznat to, že nemusíte mít úplnou pravdu. Já jsem už v prvním příspěvku připustil, že konfigurační nástroje Linuxu v GUI pokulhávají, protože vím, jak na tom jsou. Vyzdvihl jsem ale také přednosti konf. souborů oproti registrům, a vy mi pořád podsouváte "šidítko" v podobě editovaných *.reg souborů, což jak sám jistě niterně cítíte je dost rozdílné. Co naopak oceňuji je to, že se naše debata nezvrhla v tupé vyměňování si urážek. Zkuste alespoň trochu připustit, že konfigurační soubory mají své výhody. Vždyť to co jste psal o příspěvek výše - že místo SECURITY="low" mohu napsat "kow" atd. - vždyť přesně to samé můžete udělat vy v registrech. A výsledek by byl v obou případech stejný... Další nevýhoda registrů je ta, že si tam může jakýkoliv program zapsat co chce - bez nějaké kontroly. Tím se registry zanáší a rychlost systému vázne. To jsou výhody, které získám, když používám konf. soubory. Zase nevýhoda je ta, že nemám moc dobrých GUI konfiguračních aplikací. Oboje řešení mají své plusy a mínusy.
  • 6. 1. 2008 13:48

    LO (neregistrovaný)
    Ano, konfiguráků ve Windows najdete pět a půl. Je to věc koncepce, viz dále. gVim vychází z vim, a opět je to ukázka toho, jak interface nemá vypadat. Do Registry si nemůže zapsat kdokoliv cokoliv, od toho jsou permissions na každém klíči (představte si ACL na každé sekci konfiguráku). Registry se jako úložiště konfigurace nezanáší a nezpomaluje, resp. ne více než FS (případné zpomalování není věcí Registry, ale věcí interpretace uložených informací).

    Konzoli MMC určitě znáte. Pravá myš na This Computer, Manage, otevře se Computer Management. Computer Management je sada appletů běžících v aplikaci Microsoft Management Console. Těmi applety jsou správa disků, Event Viewer, Services atd. (je jich více, než vidíte v Computer Management). Prakticky všechny tyto applety pracují i se vzdáleným systémem. Podobně i aplikace Regedit umí připojit vzdálený systém. Ve výsledku není problém například nasdílet na vzdáleném stroji adresáře, vytvořit partition, založit uživatele, defragmentovat disk, založit plánovanou úlohu, spravovat web server IIS atd. To všechno v lokálním GUI, které komunikuje se vzdáleným strojem. Pokud na lokálním stroji nemáte příslušné GUI (například XP asi nebudou mít všechny applety Windows Serveru), lze je nainstalovat, tuším z instalačního CD produktu (Windows Serveru). V době přes uvedením Remote Desktop to byla jediná cesta, jak administrovat vzdálený NT stroj (vyjma PC Anywhere, VNC apod). Mimochodem obdobně si můžete nainstalovat nástroje pro správu SQL Serveru (jsou na CD SQL Serveru) apod.

    Ohledně konfigurace je ve Windows jeden důležitý koncept. Je oddělené úložiště konfigurace (ini soubory, Registry, XML soubory), a administrativní rozhraní. Hodnoty se mají měnit pouze přes konfigurační interface, kterým je GUI (nebo cokoliv jiného, co ví, jak a kam psát do Registry). Obecně by uživatel/administrátor neměl ani zjistit, že má systém něco jako Registry. V praxi je ojediněle třeba zásah přímo do Registry, což je obdobou zásahu do nekomentovaného konfiguráku (takových na unixech najdete také řadu); k tomu by pochopitelně docházet nemělo, nebo ne za běžných okolností.

    Koncept GUI je takový, že GUI je základním interfacem pro práci s počítačem (samozřejmě včetně administrace), a tedy musí běhat stejně samozřejmě, jako v unixech terminál vt100 na sériové lince. Oba ty koncepty jsou celkem logické, a přispívají ke snadnějšímu používání počítače. V unixech je to jiné. Jsou velmi staré, a primárním interfacem je command line. Konfigurační nástroje mnohdy neexistují, a jsou nahrazovány komentáři v konfiguračních souborech. Takový "interface" se samozřejmě velmi levně a jednoduše píše, ale je velmi omezený (špatně se používá; umí jen stringy; nezajištuje ani elementární korektnost konfigurace typu hodnota musí být z výčtu, hodnota musí být integer). GUI je považováno za volitelnou nadstavbu, kterou systém může a nemusí mít, a použitá technologie je mimořádně nešťastná (X11 je špatný protokol).

    Píšete, že konfiguráky a command line mají své výhody. Ano, jistě mají. Jenže tyto výhody byly aktuální před desítkami let. Je jistě příjemné, že mohu administrovat unixový systém přes sériovou linku o rychlosti 300Bd (třeba přes nějaký opravdu pravěký analogový modem). Ale k čemu mi to je dnes, kdy analogové modemy mají 33.6-56kbps, a jsou (spolu s GPRS) dostatečně rychlé i pro plně grafický přístup přes RDP? Vyměním snadnost obsluhy stroje za možnost ho spravovat po 300Bd lince? To bychom se mohli rovnou bavit o tom, jestli se dá stroj ovládat pomocí děrných štítků. O několik řádů důležitější je, že si s užíváním a administrací stroje poradí prakticky každý člověk. Nikdo se už nemusí memorovat příkazy vi, příkazy operačního systému, umístění a obsah konfiguráků. Více se bavíme o tom, CO chce dělat (nasdílet disky), a daleko méně o tom, JAK to udělat (otevřít konfigurák /etc/samba/smb.conf, založit sekci přidat do ní hodnoty comment, path, valid users, public, writable, printable a create mask). To JAK je s GUI o řád jednodušší. A právě za tento fakt vděčíme tomu, že jsou dnes počítače v každé firmě. To opravdu za administraci po 300Bd lince neměňte. Pro úplnost: je pořád nutné se učit tu část CO, kterou řada lidí pohříchu zanedbává, když je to JAK tak jednoduché.

    Pravdivost toho, co popisuji výše, celkem dobře ilustrují snahy doplnit unixové systémy o GUI, a usnadnit administraci. Pokusů bylo mnoho, ale výsledek je pořád rozpačitý. CDE bylo propadákem (typicky v něm běželo pár xtermů a možná jeden xclock). Nástroje typu smit a sam byly jen wrapperem pro spouštění command line utilit, koncept zůstal starý (a navíc byly tyto utility v každém unixu jiné, s výjimkou Solarisu, který pro jistotu neměl žádné). Novinky typu KDE a YaST jsou samozřejmě pozitivní, ale je to pořád málo, velmi pozdě, a hlavně pořád jen tak napůl.
  • 6. 1. 2008 14:15

    Pavel Stěhule

    Pravdivost toho, co popisuji výše, celkem dobře ilustrují snahy doplnit unixové systémy o GUI, a usnadnit administraci. Pokusů bylo mnoho, ale výsledek je pořád rozpačitý. CDE bylo propadákem (typicky v něm běželo pár xtermů a možná jeden xclock). Nástroje typu smit a sam byly jen wrapperem pro spouštění command line utilit, koncept zůstal starý (a navíc byly tyto utility v každém unixu jiné, s výjimkou Solarisu, který pro jistotu neměl žádné). Novinky typu KDE a YaST jsou samozřejmě pozitivní, ale je to pořád málo, velmi pozdě, a hlavně pořád jen tak napůl

    Co takhle Mac Os. Jinak bych doporučoval skutečně více studovat a méně trávit času na netu. Jaksi není žádný důvod editovat smb.conf atd atd. Asi každý děláme s jiným unixem. Všechny aplikace mám přístupné z menu, z ikon.

  • 7. 1. 2008 21:53

    LO (neregistrovaný)
    Co s MacOS? Ten nemá s unixy společného téměř nic. Sice je certifikovaný jako unix, ale to jsou Windows se Services for Unix také. Nicméně MacOS ani Windows s nainstalovanými Services for Unix nemají s unixovou filosofií moc společného.
  • 6. 1. 2008 16:33

    anonymní
    Ano, je to věcí koncepce, souhlasím. Pravda je, že gVim je takový zvláštní kus SW. To je přesně ta koncepce - vim je původně koncipován jako _konzolový_ textový editor. Byl zde pokus jej přiblížit BFU a výsledek je gVim. Ano, to je jistá nevýhoda toho, když se nějaký silný konzolový nástroj zkouší portovat na GUI. Registry bohužel už dávno nejsou jen úložištěm konfigurace, vždyť veškerý instalovaný SW si vytváří vlastní klíče (ne o nastavení, ale už jsou to podrobné informace o daném SW atd), roztahují se i mimo své větve (Dobrý příklad je Alcohol 120% - díky správě virtualních mechanik zapisuje na spousty míst spousty informací) a s přibývající velikostí se počítač zpomaluje. Když nainstalujete na systém 50 programů, určitě nebude stejně rychlý jako bez nich :-). Další problém je to, že ne každý SW má dobře napsaný uninstaller. Takový špatný uninstaller je doslova rána - půlku klíčů z registrů smaže, půlku opomene a máme na světě onen maglajz, o kterém jsem mluvil. (Toto neplatí o serverových mašinách, kde je jedna instalace webového serveru, mailserveru a databáze a nic se nepřidává, maximálně aktualizuje).

    Ano, máte pravdu, jak jste to popsal, tak jsem si vzpoměl. MMC konsole je windows snad nejlepší způsob konfigurace. Ale opět máte pravdu jen zčásti - přes MMC si mohu např. nového uživatele naklikat (víceméně). V konzoli napíšu useradd -s /bin/bash -p heslo pepik. To se mi nezdá o moc složitější (ano, také ho mohu naklikat přes GUI, ale toto je mnohonásobně rychlejší, navíc lehce automatizovatelné). Ano, nekomentované konfiguráky jsou chyba a lenost lidí, kteří vytvářeli daný SW. Naštěstí je 98% okomentovaných, případně existuje konfigurák s příponou .example, který tedy slouží jako okomentovaný konfigurák. To je třeba to co mě osobně přijde takové zvláštní - že by ani admin neměl vědět co se kam zapisuje. Přece jen pokud spravuji nějaký systém, tak _chci_ mít kontrolu nad tím co dělá. A ne že ono se to snad nějak někam jaksi taksi zapsalo... Ano, regedit umí vzdálený systém, ale už v minulosti jsem přemýšlel nad bezpečností takového řešení.

    Zde se naše názory rozchází - GUI je podle mě jen další způsob práce s PC. Pravda - pohodlnější a většinou i výkonější. Ano, primární je command-line - ale ze svě zkušenosti mohu říct, že silnější nástroj, který nabízí tolik možností jsem neviděl. Vždyť i ve Vistách se začíná opět objevovat - PowerShell. Není to bez důvodu nebo jen proto, že by se kluci od MS nudili, tak udělali PowerShell. Udělali to proto, že je to neobyčejně silný nástroj pro ty, kterým nevadí se něco nového učit. Koneckonců kdo ovládne v linuxu příkazový řádek, ovládne celý systém na 100%. To se o GUI říct nedá (aspoň ne úplně). V Linuxu navíc máte několik možných grafických prostředí - ale konzole je pořád stejná. Z toho vyplývá, že pokud umím s konzolí, nakonfiguruji systém, na kterém je jak KDE, GNOME, XFCE, nebo jiný WM. O protokolu X11 disktuovat nemohu, neznám jeho koncepci.

    Opět nesouhlasím - myjí výhodu i dnes - dávkové soubory ve Windows jsou používány dodnes, ale nemohou dosáhnout takové výkonnosti, mají jinou koncepci. Dávkový skript, dobře kombinovaný s editorem SED, nebo rourami (pipes) je doslova zázrak. Není v něm problém jakkoliv spravovat systém, automatizovat prakticky jakoukoliv činnost atd. Pravda je, že aby toto člověk zvládl, chce to umět programovat (nebo aspoň dobré logiscké myšlení, které s tím ůzce souvisí) a chce to taky nebý líný učit se nové věci. Kupříkladu není takový problém napsat SHELLový skript, který zautomatizuje přidávání sdílených adresářů do smb.conf - spustím, zeptá se mě na cestu, zadám, enter a hotovo. To je ta síla příkazové řádky - věci co se dělají často jdou úžasně automatizovat..

    S posledním odstavcem souhlasím, ale pravda je, že poslední rok dělají obzvlášť *buntu distribuce pokrok ve směřování k běžným uživatelům. S nejnovějším Ubuntu jsem se poměrně nedávno setkal a byl jsem velice pěkně překvapen úrovní jeho GUI (administrace, atd). Mě na tomto terndu přibližování se běžnému uživateli vyhovuje to, že se pomalu, ale jistě rozsiřuje nabídka SW pro tento systém.

    Teď jsem si vzpomněl tak pro pobavení: Nedávno jsem dokonce ripoval titulky z DVD přes konzoli :-D. Je to bějakých pět příkazů, takže pohoda, ale nástroj gOCR, který je _konzolový_ mě opravdu rozesmál :-D. Pravdou ale je, že ten, kdo to dělal, byl velice šikovný. I když se může zdát slovní spojení _konzolové ocr_ jako utopie, tak mohu potvrdit že funguje velice pěkně :)
  • 6. 1. 2008 22:47

    LO (neregistrovaný)
    Bohužel ty pokusy o GUI aplikace typu gVim, SMIT a SAM mají společné to, že ukazují, že přenesení konceptů konzole do GUI nefunguje. Dobré GUI je věda, a autoři KDE a Gnome by mohli vyprávět o tom, jak s věcí bojují.

    Registry je úložiště konfigurace. Pravda, vyjma konfigurace aplikací drží také informace o COM komponentách (objemově největší část Registry). Aplikace samozřejmě musí občas hrabat i mimo "svou" část Registry. Například pokud nainstalujete na Linuxu deamon, instalátor zřejmě bude muset zapsat do /etc/rc.d/rc.local (nebo někam jinam), aby se mohl spouštět. A při odinstalaci se zase bude muset odstranit. Nejspíš bude zapisovat i něco do /etc/services (a kdo ví, jestli to po sobě při odinstalaci odstraní). Když nainstalujete plugin pro OpenOffice (představte si třeba intergaci faxového software do Writeru), asi budete muset zapsat do konfiguráku OpenOffice, aby vůbec nějaká integrace mohla nastat. Obdobně to funguje ve Windows.

    Rychlost systému se nemění díky rozsahu Registry, stejně jako se rychlost nemění díky objemu koniguráků v /etc nebo pod home adresářem uživatele. Na odezvu počítače mají vliv například shell extensions, tedy COM komponenty, které se volají například při vykreslování kontextového menu. Bohužel některé kousky jsou zvláště "povedené". Naši přátelé ve společnosti nVidia například už jako součást setupu driveru instalují knihovnu, kterou registrují do kontextového menu video souborů. Tento doplněk po pravém kliku na soubor avi/wmv/mpg do kontextového menu přidá položku Play on my..., a poté seznam monitorů a TV. Seznam zobrazovacích zařízení se sestavuje dynamicky, zřejmě voláním driveru. Bohužel u toho dojde k přebliknutí obrazovky. Fuck, shit, který idiot?! Zdržení je naštěstí poměrně malé. Jiné kousky například nabízejí extrakci ze ZIP selfextraktoru, a tedy po pravé myši na souboru .exe testují, jestli v něm není ukrytý ZIP, což chvíli trvá. To je důvod, proč je systém po instalaci pár podobných aplikací poněkud vláčný. Je asi jasné, že vlastní objem databáze Registry není ten problém. Odinstalace je problém typicky u utilit "z CD časopisu ComputerWorld", které píšou prasata. V posledních 5 letech se ale i tohle zlepšilo.

    Nového uživatele můžete samozřejmě naklikat, a je to poměrně rychlé. Pokud chcete více uživatelů, můžete je naklikat na jednom místě, a je to také celkem rychlé (GUI na to musí být stavěné). Samozřejmě i ve Windows máte možnost použít příkaz "net user franta pepik /add", nejlépe ještě s /domain (na co zakládat lokálního uživatele, měl by být v doméně). Samozřejmě můžu skriptovat jako v unixu, třeba mohu z command line udělat "for /f %i in (jmena.txt) do @net user %i %j /add". Samozřejmě možnosti skriptování s cmd.exe nejsou takové, jako s bashem, ale nepodceňoval bych je. Vyjma toho můžete založit uživatele ve VBScriptu, nebo jakémkoliv jiném jazyce podporujícím COM (viz http://www.microsoft.com/technet/scriptcenter/scripts/ad/users/manage/usmgvb05.mspx). No a kdybych opravdu potřeboval zakládat uživatele často, tak si vytvořím v Excelu sheet, do kterého dostanu jména (napíšu je tam, nebo naimportuji třeba dotazem z HR databáze), a jedním kliknutím myši spustím skript na pár řádek (prakticky loop nad těmi pár řádky z linku výše), který je vytvoří. Ve srovnání se skriptováním téhož na command line je to podobně složité, ale výsledek je *mnohem* lepší (a když na to přijde, výsledek může používat i sekretářka HR oddělení). Samozřejmě, že tohle neumí udělat člověk, který je jen power userem. Ale člověk, který se zvládne naučit unix, musí zvládnout i takovouhle trivialitu (natož Martin, který si na Linuxu umí opravit chybu v driveru). Věřte mi, že ve Windows se dá automatizovat prakticky cokoliv. Údajně i z PERLu, což opravdu není můj šálek čaje. Bohužel v unixech je GUI výrazně chudší (fakt nevím, jak bych v GUI importoval data z HR DB a zakládal uživatele v LDAP). Proto říkám, že na unixech i já používám raději command line.

    Regedit se ke vzdálenému systému připojí se stejným kontextem, ve kterém byste z něj připojil disk. Pokud nemáte doménový účet, nebo nemáte práva na cílovém stroji, nejprve si připojte disk se správným uživatelem a heslem (nemusíte disk mapovat, stačí připojit). Bezpečnost netrpí, je to vše v rámci doménového modelu. Naštěstí ve Windows nemáme nic jako NFS.

    Kdybych potřeboval vytvořit hromadu network shares, opět mohu použít command line (viz "net help share"), nebo si v extrémním případě napíšu Excel sheet, který shares založí pomocí těchto pár řádek: http://www.microsoft.com/technet/scriptcenter/scripts/storage/shares/stshvb01.mspx . U shares by jich ovšem musely být opravdu stovky, aby to mělo smysl, protože GUI funguje celkem fajn (stačí pravá myš na adresáři, který chcete sdílet, a vybrat Sharing). Navíc shares mají typicky odlišné nastavení permissions (na co jich jinak vytvářet více), takže ten overhead použití GUI nebude ve všem tom psaní moc velký.

    PowerShell ještě mc neznám. Koncept je velmi zajímavý, a jde určitě o pokrok proti klasickému unixovému skriptování voláním utilit a parsováním textů. Důvodem pro vytvoření PowerShellu bylo zřejmě postupné opouštění Win32/COM světa, na které se MS připravuje. S použitím PowerShellu pro administraci systému si podle všeho počkám tak do roku 2009.

    OCR/ICR bez GUI je celkem běžná věc. Když zpracováváte třeba formuláře, nemůžete se dívat na každý kousek ručně (to by pak to OCR skoro nemělo smysl). Proto se používá "serverové" OCR. Typicky bývá implementované s command line interface (unixy, windows), COM a .NET interface (Windows), a možná bude něco i pro Javu.

    Silnou věcí ve Windows jsou právě komponenty. Když píšete aplikaci, a potřebujete v ní OCR, za pár minut můžete s kreditkou koupit sadu OCR komponent, a tyto ve své aplikaci použít. Pokud potřebujete rastrovat data ve formátu, který ukládá digitální RTG, kupte si komponentu. Pokud chcete obohatit aplikaci o reporting, můžete ušetřit spoustu práce, když si koupíte komponentu. Trh je veliký. Samozřejmě se vyplatí se rozhlížet, jak při koupi čehokoliv jiného, ale možnosti jsou nevídané. Tomuhle těžko něco konkuruje.

    Shodneme se asi na tom, že Linux udělal za poslední léta na desktopu pokrok. Jenže když chcete víc, než přehrávat MP3 a brouzdat web, co může opravdu nabídnout? Snadný vývoj, dobrou dokumentaci, hromady komponent? Nevypadá to. Dobré GUI, ve kterém se dají dělat pokročilé akce (typu výše uvedeného přidávání uživatelů)? Nemyslím. Dostupnost aplikací typu profi OCR, imagingu, "systému pro management restaurace" (vezměme to jako symbol pro ty tisíce aplikací tohoto typu)? Asi také ne. Technologie typu řízení priority I/O, .NETu apod buď chybí, nebo jsou hotové napůl, nebo se velmi špatně používají. Samozřejmě je dnes Linux lepší, než byl před 10 lety, a třeba KDE je ve srovnání s CDE (děsný zmetek) neskutečný pokrok. Ale nestačí to.
  • 7. 1. 2008 23:51

    anonymní
    Ano, přenést se dají jen velmi těžce - taky proto tvrdím, že apliakce, které jsou _primárně_ pro konzoli by se měly držet své konzolové koncepce, protože to je podle mě to nejlepší co mohou udělat.

    Ano, a nejen konfigurace - až si jednou zase spustím windows, mohu vám nějaké ty ukázkové klíče exportovat. Bohužel Registry už dávno neslouži jen ke konfiguraci... Do Registrů te´d směřuje veškerý balast, který by šel hravě [im|ex]portovat do nějakého textového souboru. Opravdu jsem neměl na mysli konkrétně nVidii :-). I když popisovaný jev bych čekal spíš u změny rozlišení, atd. Mám na mysli hlavně to, že se zvyšujícím se počtem instalovaných aplikací se snižuje rychlost systému. A nemám na mysli takové aplikace typu "mega bomba SW časopisu PCWorld". Ano - samozřejmě je nutné zapisovat data do konfiguráků/registrů. Bez toho bychom byli pořád u děrných štítků. Ale zvyšující objem konfiguračních souborů by neměl (a taky z 99% nemá) mít negativní vliv na rychlost systému jako taqkového, zatímco u windows tomu tak je.

    Ano, naklikat si nového uživatele mohu taky - pokud budete mít zájem, zde je pár screenshotů. [1] [2] Myslím, že uvedené nástroje jsou pěkně napsané a velice dobře použitelné. Ano, také mohu použít podobný cyklus pro import. Ovšem samozřejmě - toto je pouze o preferencích administrátora - já bych třeba preferoval plain-textový soubor, který bych mohl volně dál zpracovávat bez nutnosti mít velký SW balík jen pro čtení. A myslím, že by i sekretářka dokázala uložit na plochu soubor import.txt a kliknout na ikonku Importovat, která se postará o zbytek v případě, že je zminovaný textový soubor má správný formát. Ano, věřím, že to jde - koneckonců kdyby to něšlo, bylo by to opravdu mrzuté, jde jen o subjektivní snadnost. Pro mě je subjektivně snažší za deset minut napsat daný skript a pak ho používat na kterémkoliv systému s tím, že nástroje typu sed apod. jsou prostě všude.

    Ne, neptal jsem se přímo na způsob připojení, ale na jeho bezpečnost - zda je spojení dostatečně zabezpečené, zda je serverová část náchylná na chyby typu buffer overflow, flooding apod. Dále klient - opět to samé. NFS není nepostradatelné - na konfiguraci postačí NIS :-) Případně SSH je v nouzi stále po ruce :-).

    Ano, v linuxu to je podobné - pravé myšítko na adresář -> vlastnosti -> sdílení. Stejně tak pro sdílení - beru Sambu -> není nic snažšího, než přidat pár řádků do /etc/samba/smb.conf... Oprávnění také mohu nastavit pro jednotlivé adresáře na jednotlivé uživatele. Toto podrobné nastavení je bohužel trochu schované, ale není to zas tak hrozné.

    Ano, v základech se mi zdá, že sem tam prosvítá BASH, ale koncepce se mírně liší. PowerShell jsem osobně ještě také neviděl, v této fázi se jedná otakové jemné otestování reakcí uživatelů :-). Osobně se mi PowerShell líbí, už ale méně systém, na kterém je - ale toto (zatím) není diskuze o windows Vista :-).

    Netvrdím, že je unikátní, jen říkám, že pro mě překvapující :-). Do nedávna jsem neměl potřebu na cokoliv používat OCR, takže jsem se s těmito aplikacemi vůbec nesetkal. Ano, trh je veliký, zatím ve velké části desktopů je Windows - je pravda, že něčemu takovému se strašně těžko konkuruje a to staví alternativní OS do značné nevýhody na poli desktopů.

    Ano, shodneme - pokrok to je vskutku veliký. A linux není jen na poslouchání MP3 a brouzdání po webu. S takovým názorem se setkávám s uživateli, kteří viděli linux takříkajíc "z rychlíku", a nemyslím, že vy jste ten případ. Já osobně používám své PC s Linuxem jako multimediální centrum (Muzika + video {editace a poslech}) - stejně tak na běžnou kancelářskou práci, vyvíjím na něm, sem tam si zahraju nějakou hru. U těch her ale sem tam použiji i windows - pokud chci spustit hru typu Diablo II, Sacred a podobné, mám je radši, protože WINE sice v pohodě stačí na klasiky typu StarCraft, CounterStrike, a pár podobných "neumírajících" kousků, ale co si budeme povídat, například Sacred je mírně náročnější hra... S komponentami na Linuxu mám paradoxně menší probém než s Windows. Ano, vím, že je rozdíl mezi XP, vydanými tuším roku 2001 a v aktuální verzi 2004, ale zase na druhou stranu na Windows jsou ke každému kousku HW haldy CDček, a i s nimi je to někdy kumšt. Třeba nedávno - zvuková karta (PCI). Windows ji viděly. Drivery (originální) nainstalovány. přesto byla karta němá. (a ano, nebylo zapnuté MUTE :) ). Pomohlo až přendání do jiného PCI slotu. Osobně nechápu chybu, jakou se toto mohlo stát. S kartou nebylo fyzicky hýbáno, takže mohu rovnou vyloučit špatné usazení... Pokročilé GUI - za to považuji KDE a potom i částečně GNOME. A ano, jde v nich přidávat uživatele stejně efektivně. Aplikace a jejich problémy jsem zmínil už výše - jedná se o zastoupení trhu Windowsy - kdo by také programoval nějakou "spešl" aplikaci jen pro pár lidí? Pravda, i toto se už začíná zlepšovat. Zatím jsou uživatelé linuxu odsouzeni k nástojům typu WINE. Totéž co o .NETu mohu říct o openGL ve windowsech :-). Ano, je lepší než byl před rokem - dělá mílové kroky, abych tak řekl. Bohužel, _zatím_ je to stále málo, ale není to bezvýznamné.
  • 10. 1. 2008 23:33

    bez přezdívky
    Aplikace, které jsou určené primárně pro konzoli, by hlavně měly vymřít. Existují samozřejmě výjimky, kde je použití konzole oprávněné. Nicméně konzole jako primární interface je neodpustitelná příšernost. Ještě, že unixy nepoužívaly jako primární interface děrné štítky. Dnes byste měl stůl plný štítků velikosti SD karty, a tvrdil byste, že je to nejlepší možná věc, protože si skript odnesete fyzicky s sebou, což vám žádný terminál s klávesnicí a monitorem nikdy nedá :)

    Až někdy spustíte Windows, zkuste mi ukázat, které věci v Registry nejsou konfirurace nebo registrace komponent.

    Máte nějaký způsob, jak podepřít své tvrzení, že samotné zvýšení objemu Registry má vliv na rychlost systému jako takového? Nebo jde o urban legend? Zkuste si zvětšit objem Registry tak, že někde založíte řadu klíčů a hodnot. Zkuste si vytvořit opravdu velkou databázi Registry, a pak se dívejte, jak se mění rychlost systému. Zjistíte, že výsledek je podobný, jako když zvětšujete počet a délku konfiguráků. Jenom jsou ty konfiguráky pro vyhledávání hodnot pomalejší, protože musíte udělat slow search, kdežto Registry má index.

    Tvrdil jste, že na Linuxu můžete dělat spoustu věcí z command line. Já tu jen ukazuji, že ve Windows také. Ale když tvrdíte, že můžete použít postup ekvivalentní tomu s Excelem a VBA, zkuste mi ho prosím popsat. Já totiž vím, že unixy bohužel nemají žádné API pro přidání uživatele, takže skončíte spouštěním command line utility. A jistě se shodneme, že to je někde úplně jinde, než postup, který jsem popisoval já. Jinak sekretářka by asi mohla používat textový soubor, nebo psací stroj. Otázka je, proč by něco tak nepohodlného dělala.

    Remote Registry je zabezpečené v principu stejně, jako SMB protokol. Serverová část není náchylná na buffer overflow (určitě ne tolik, jako běžný web server :) ). Navíc Remote Registry používáte za firewallem, ve firemním (či domácím) prostředí. NFS není nepostradatelné, nicméně je velikou bezpečnostní katastrofou (stejně jako telnet, ftp apod).

    PowerShell nemá s bashem moc společného. Důležitým aspektem je fakt, že pracujete s objekty. Například lze získat seznam služeb (deamonů), které právě běží:
    get-service | where-object { $_.status -eq "Running"}
    Nejde o unixové "spusť utilitu, parsuj její textový výstup". Ve výsledku není problém například vytvořit okno, procházet seznam oken, ovládat instanci desktopové aplikace apod. Oproti unixovým shellům jde o první pokrok po velké spoustě let.

    Bohužel přes velký pokrok toho v Linuxu moc nenapracujete. Chybí aplikace, vývoj je obtížný, dokumentace mizerná, lokalizace neúplná a mizerná, platforma úzká a nehotová, komponenty usnadňující vývoj aplikací prakticky neexistují. Dnes pravda už v Linuxu přehrajete DVD, dokonce s menu DVD disku a s titulky (což svého času bylo sci-fi). Nevím, jestli z něj dostanete také vícekanálový zvuk, a mám o tom jisté pochybnosti (natož vícekanálový zvuk u her).

    Kde je ve Windows problém s OpenGL? Hlavně proč OpenGL, když svět jede na DirectX, které nabízí daleko více.
  • 11. 1. 2008 19:40

    anonymní
    Ne, rozhodně nesouhlasím. Aplikace, které jsou pro konzoli jsou snadno využitelné - pak i případné psaní skriptů pro konsoli je mnohem snadnější s nimi.

    Ano, pošlu Vám je - jestli bych mohl poprosit o nějaký mail, či jiný kontakt na Vás, je možné, že toto vlákno bude mírně zastaralé a při zobrazení Vašeho profilu nevidím žádná data...

    Já tak usuzuji ze svých zkušeností - po delším _používání_ se windows sám stává nepoužitelným. Vzhledem k tomu, že na toto mi většinou stačilo nahrát "čistý" registr, usuzuji tak, že to je způsobeno registry. Vyhledávání není problém - vím, že třeba parametry kompilace jsou v make.conf, nastavení apache v epache/apache2.conf apod. Nevím, proč bych měl prohledávat celou složku /etc. Tedy za předpokladu že vím co hledám (dělám).

    Ano, vím, že cmd je na windows také, ale zdaleka není tak multifunkční - nedá se srovnávat. Netvrdím, že je to ekvivalentní. Vy s Excelem a VBA - já místo toho použiji plain-text soubor, a BASH místo VBA. nevím proč bych s puškou na slona měl lovit mouchu :-). Navíc já se svým plain-textem mám jistotu, že ho přečtu v případě nutnosti i za dvacet let - vy s .xls takové jistoty nemáte (ale to je z trochu jiného soudku). Nevidím nic nepohodlného - soubor stylem jméno, heslo na jednom řádku (může být odděleno tabulátorem pro větší přehlednost) a dvojité poklepání na ikonu není nepohodnlnější než ve windows.

    Neptám se na principy a ani na SMB. Ptám se na vzdálený registr, který nesrovnávám s ničím, tedy ani se sambou, NFS apod. Jak jsem již řekl - NFS není jediná variata - stejně jako ftp. Pokud Vám nevyhovuje, použijte něco jiného - taková je filozofie Linuxových systémů. Samba není v systému zakousaná tolik, abych ji jediným příkazem nedokázal ven dostat. Chápu, že asi nejste moc zvyklý na podobný přístup z windows, ale tady to chodí takto.

    já mohu získat seznam spuštěných démonů bez parserování textové aplikace přímo příkazem rc-status (parametr je runlevel [default|boot] pro rozlišení). S objekty BASH sám pracovat neumí.

    Vidíte, já osobně nemám problémy na linuxu pracovat :-). Aplikace sice chybí, ale při troše snahy se dá _většina_ nahradit, dokumentace je zde neobyčejně bohatá (doporučuji příkaz MAN) - chce to jen umět ji používat, lokalizace je mizerná a neúplná... Ano, a nejen to. Nemám problémy jej převést do jakéhokoliv jiného formátu, přepálit, vypálit, editovat zvukovou/video stopu, s titulky nemám nejmenší problém, stejně tak menu, atd atd. Chce to jen nebýt líný a najít si aplikace. Mimochodem co vím, ani ve windows si bez doinstalování kodeků nepřehrajete DVD (win XP - u Visty nevím). Vicekanálovou zvukovou kartu nemám, takže to opravdu nemohu posoudit.

    O openGL se nemohu moc otírat, neorientuji se moc v těchto prostředích. Pokud máte _zkušenost_ s těmito nástroji, pak se prosím vyjádřete v čem nabízí více, ale nezajímá mě ony "urban legends", které jste zmiňoval výše, a ani tak mě nezajímá "ověřená zpráva agentury JPP (Jedna Paní Povídala)".
  • 13. 1. 2008 19:04

    bez přezdívky
    Psaní skriptů je pro vás jednoduché, protože jste se skriptovat naučil. Ovšem většina lidí nemá rok na to, aby se naučila ovládat vi, naučila syntaxi pár stovek příkazů, regexpy, skriptování bashe atd.

    Relevantní výpis Registry přilepte do jakékoliv novější diskuze, kde jste mě viděl. Najdu ho tam.

    Ano, popsal jsem, proč se Windows po instalaci hromady aplikací stávají pomalejšími. Samozřejmě pokud odstraníte reference na komponenty, které zpomalení způsobují, bude odezva opět rychlejší.

    K rychlosti: na prvním místě je třeba říci, že když na FS přidáte další soubor, tak se zpomalí (stejně jako se po přidání položky zpomalí Registry, DB, nebo cokoliv jiného). Tohle zpomalení je ovšem minimální, protože jde o datové struktury, kde počet elementárních operací při vyhledávání roste výrazně pomaleji, než počet prohledávaných položek (viz binary search tree). Pokud v těchto věcech nejste doma, tak si představte, že hledáte v telefonním seznamu podle indexu, který pokrývá více úrovní (nejprve z indexu vyberete N, na nalezené stránce máte další index, z něho vyberete O, atd, až najdete celé jméno NOVÁK).

    Když vyhledáváte hodnoty v konfigurácích, je to pomalé. Představte si konfigurák s milionem řádků. Chcete najít sekci [mojeSekce], a v ní hodnotu mojeBarva. Protože konfigurák nemá žádný binární index (ježto je čistě textový), musíte ho číst řádek po řádku, než najdete, co hledáte. Jde o ekvivalent toho, když otevřete telefonní seznam na první stránce, a čtete jedno jméno po druhém, dokud nenajdete jméno NOVÁK. Tenhle způsob hledání má ten problém, že počet elementárních operací roste stejně rychle, jako počet prohledávaných položek (dvakrát delší seznam budete pročítat dvakrát déle).

    A teď si představte zápis do konfiguráku. V půlce konfiguráku s milionem záznamů máte tu sekci [mojeSekce], a chcete do ní připsat hodnotu mojeVolba. Přidání (nebo změna) jedné řádky znamená přepsat celý zbytek souboru, což je mimořádně dlouhá a náročná operace. V případě binární struktury je přidání záznamu daleko rychlejší (viz opět binary search tree a jeho praktické aplikace, včetně Windows Registry). Milion záznamů konfiguráku jsem použil jako příklad, v praxi bývají konfiguráky kratší. Ale vezměte v úvahu, že textový export Registry běžného desktopu má desítky MB. Je vám už jasné, proč jsou konfiguráky pomalejší, a proč se s růstem velikost zpomalují daleko více, než Windows Registry?

    K přidávání uživatelů a spol: uživatel čeká, že bude mít komfortní interface. Opravdu nevidíte rozdíl? Excelový sheet, kde máte nadepsané sloupce, popisy jsou ukotvené (jsou vždy vidět), lze provést verifikaci zadaných dat. Můžete data vytáhnout z databáze; na má Excel wizard, nebo můžete napsat makro na stisk tlačítka. Jako alternativu nabízíte textový soubor, a skript, který pouští command line utility. Náročnost je dost podobná (byť mi VBA připadne lehčí k učení, než bash), výsledek je v Excelu o řád lepší. Samozřejmě skript můžete použít i ve Windows, ale to není pointa.

    Jak jsem psal, vzdálená datbaáze Registry se připojuje podobně, jako diskové sdílení.

    NFS není jediná alternativa, ale ukázkou unixového přístupu. Navíc NFS je de-facto standardem unixového světa, stejně jako SMB standardem světa Windows. Samozřejmě ve Windows nemusíte mít podporu SMB, a můžete použít jiný protokol (viz ty z dílny Novellu, viz jejich integrace do Windows).

    Ano, seznam deamonů získáte. A co získáte? Textový stream. Ten můžete parsovat a filtrovat. Ve mnou popsaném případě můžete pracovat s objekty. Například v daném příkladu lze použít $_.Stop, tedy zavolat metodu Stop dané instance objektu ServiceController.

    Aplikace na Linuxu opravdu chybí. Problém není s těmi typu browser a přehrávání MP3. Problém je s produktivními aplikacemi, typu CAD, účetnictví, DTP, systémů pro hotely, restaurace, kadeřnictví, řízení projektů, a tisíci dalších věcí. Pokud počétač nepoužíváte jako nástroji pro podporu primárně nepočítačové práce (což ale dělá naprostá většina uživatelů počítačů), a rád se ve věcech šťouráte, tak vám toho možná moc nechybí. Dokumentace stylu man je ve srovnání s MSDN zoufale chudá.

    Ve Windows XP bez instalace MPEG2 kodeku DVD nepřehrajete. MPEG2 dekodér dostanete s většinou DVD mechanik (OEM verze PowerDVD apod), kodek pak může využívat jakákoliv aplikace. Vista má MPEG2 dekodér vestavěný (a mimo jiné má Windows Media Center, pěkný TV-like interface). Linux MPEG2 dekodér vestavěný nemůže mít, protože by to bylo nelegální (ovšem i distra s nelegálními MPEG2 dekodéry asi existují). Jste tedy odkázán na to, že si někde stáhnete pirátský MPEG2 dekodér. Výjimkou je pár komerčních dister Linuxu, které obsahují licencované technologie.

    K OpenGL jste původně něco říkal vy. Důležitým faktem je to, že DirectX je celá platforma pro podporu her (3D a 2D zobrazování, vstup z klávesnice, myši a joysticků, zvuk, komprese a dekomprese audia a videa, high level 3D grafika). OpenGL se stará o vykreslování 3D primitiv, a tím to končí. Pokud rád programujete v C, bude se vám líbil OpenGL. Pokud píšete pro unixy, bude se vám muset líbit OpenGL, jinak máte smůlu :). Pokud píšete v C++, C#, potřebujete obsluhu vstupních zařízení, zvuk, píšete pro XBox apod., zřejmě dáte přednost DirectX. Samozřejmě ve Windows můžete použít i OpenGL.
  • 14. 1. 2008 0:54

    anonymní
    Ne, ono ve skutečnosti skriptovat nemusíte umět. Jde jen o to umět používat manuálové stránky. Ale ani to není stoprocentně potřeba k tomu, aby mi jako uživateli doma jelo ubuntu.

    Okay

    Ne, nemluvím zde o referencích na komponenty typu grafika nVidia atd. Mluvím zde o prostém vyčitění registry do poinstalačního stavu.

    Ano, co se týče počtu souborů, zpomalení je minimální - to jsem přesně říkal. Pokud přidám konfigurák, tak to na rychlosti systému nepoznám. Jsem rád, že jsme našli věc, ve které se jistě shodneme.

    Popravdě - žádný konfigurák nemá milion řádků. To nejsou registry :-D. Konfiguráky mají nejvýše pár stovek řádků... A pokud se jedná o zapsání ~150 řádků _textu_, nečekám, že s dnešními počítači by to měl být nějaký problém. A další poznámka - konfiguráky _nerostou_ - jak už jsem řekl nejsou to registry (samozřejmě vynecháme přidání jednoho slova nebo řádku za rok, tomu neříkám růst :-) ). Roste možná jejich počet, ale pořád nijak dramaticky. Export registrů má desítky MB. Kompletní konfiguráky k systému, kde běží několik serverů mají něco málo pod 10 MB _čistého textu_. Tedy krásně "zazipovatelné"

    Ano, toto je pohodlnější. Ale jak jsem psal v předchozích příspěvcích - je to věc osobní preference. Třeba zmiňované hromadné přidávání uživatelů jsem prováděl jen párkrát a dělal jsem ho já osobně, takže nějaké "vymazlené" rozhraní pro sekretářku, jsem oravdu neřešil :-D. Ale šlo by ho napsat kupříkladu v Pythonu pro zájemce... Tady jde o to, že Windows jsou s produkty Office velice úzce provázané. Toto v je proti základní myšlence Linuxu a jeho svobody... Ale to je opět téma na další vlákno a někam jinam.

    Ano, díky za informaci.

    UNIXový přístup. Tady je zároveň výhoda i nevýhoda systému, který je postaven na tomto řešení. Mám možnost _svoboné volby_ co budu používat, nic není s ničím proprietárně svázáno a obvykle existuje víc řešení různé kvality. Pravda je, že kdyby se třeba vývojáří OOo a kOffice spojili (oficiálně) a soustředili se pořádně na jeden produkt, mohli bychom být někde malinko jinde... Ale jak jsem řekl, toto je ta nevýhoda, kterou s sebou nese možnost svobodné volby.

    Získám textový výpis démonů, kteří jsou zařazeny do dané vrstvy a jejich stav. Na zastavování pak mohu použít k tomu určené skripty ve složce init.d, která se nacházi v /etc. Ano, samozřejmě, že toto není objektové, ale je to univerzální a o to tady jde - aby tento způsob mohl používat kdokoliv, a ne jen SW z dílny toho, kdo si daný systém vymyslí. A jsme opět u provázanosti proprietárních aplikací.

    Ano, zde se víceméně shodneme. PRavda je že _zatím_ mnoho SW vydavatelů neportuje své výrobky na linux, a tady je samozřejmě nasnadně, že člověk, který léta ovládá AutoCAD se nespokojí s řešením typu qCAD. Naštěstí WINE je nástroj víc nežli silný a má velkou budoucnost. Photoshop a podobný software pod ním rozběhat lze, účetnictví také (to dosové snadněji :-) ), se SW pro řízení hotelů a podniků jsem se prakticky nesetkal. Jen letmo, když jsem pro jeden takový podnik spravoval síť, ale to bylo jen její údržba, takže k SW jako takovému jsem se pořádně nedostal. Dokumentaci MSDN neznám... Příkaz MAN je od toho, aby rychle napověděl (třeba syntaxi, parametry atd) není od toho, aby vás naučil krok od kroku daný přikaz používat. Tvůrci man předpokládají u jejich uživatelů alespoň náznak inteligence a pochopení a tedy to _většině_ uživatelům MANu stačí.

    S nelegálností DVD dekodéru u linuxu se neohánějte tak ostře. Někde jsem četl, že soud (někde - nevím kde, ale u nás to podle mě nebylo) došel k závěru, že CSS není ochrana (alespoň ne v pravém slova smylu) a že se tedy jejím "obejitím" nic neporušuje. Jiné to je samozřejmě u BR a HD disků.

    Jak říkám - na toto hřišťátko se pouštějte jen v případě, že se v dané problematice _orientujete_. Podle věty "o vykreslování 3D primitiv" jsem tak nějak dobyl dojmu, že toto pravidlo nesplňujete, a proto bych OpenGL nerad rozebíral dál :-)
  • 14. 1. 2008 13:36

    bez přezdívky
    Vyčištěním Registry do poinstalačního stavu odstraníte přesně to, o čem jsem mluvil - reference na řadu komponent, včetně těch kousků od nVidia (a RarLab, WinZIP, 7Zip, a tísíců dalších).

    Ano, shodneme se, že přidání konfiguráku zpomalí FS minimálně. Pokud přidáte klíč do Registry, dopadne to stejně, a zpomalení nepoznáte.

    Konfiguráky nemají typivky milion řádků, ale pro demonstraci jejich pomalosti je to pěkný příklad. Samozřejmě pokud má konfigurák 10kB, nebo 100kB, je to v principu podobný problém, jen menšího rozsahu. Navíc samozřejmě dochází k fragmentaci konfigurace (prodloužení souboru vede k tomu, že bude na disku uložený nesouvisle).

    Ano, konfigurace Windows je velká. To má dva důvody. Prvním je to, že Windows mají komponentový systém, a informace o COM komponentách se drží v Registry. A druhým je fakt, že se ve Windows dá obrovská spousta věcí nastavit (byť si to uživatelé unixů nemyslí). Navíc pochybuji, že do kompletní konfigurace počítáte databázi balíčkovacího systému (která je u RPM binární), konfiguráky mimo /etc (třeba ty, které píše Oracle ve svém stromu), konfiguráky uživatelů atd.

    Možnost svobody a svobodné volby je zástupné téma. Proč? Podívejme se, co potřebujete, abyste mohl přidat uživatele z Excelu. Na prvním místě systém musí mít nějaké API pro přidávání uživatelů (pokud nechcete z GUI spouštět command line utility a parsovat jejich výstup, což je prostě hnus). Na druhém místě musí Excel nabízet skriptovací prostředí, které umožní toto API volat (tím prostředím je Visual Basic for Applications, ale v principu to může být VBS, PERL, Python, nebo cokoliv jiného). Ani jedna z těchto věcí nijak nesouvisí se svobodou, svobodou volby apod. UNIXy nemají API pro věci typu přidávání uživatelů (získání seznamu procesů, získání seznamu a ovládání deamonů) proto, že takové API v době dřevních unixů nikdo nenapsal, a od té doby se k tomu nikdo neodhodlal, protože se vývoj platformy zpomalil až zastavil. A samozřejmě je to komponentový model, který Microsoft zavedl se svým COM. Ani jeho obdoba na dřevních unixech nebyla, a od to doby se toho moc nezměnilo (byť KDE demonstrujke jistou snahu, viz KOM/OpenParts, KParts/DCOP). Díky COM (resp. OLE) je ve Windows možné do Corel Draw vložit rovnici napsanou v MS Equation Editoru, tabulku Excelu, nebo naopak do Excelu objekt Corel Draw. Díky COM (resp. DCOM) je možné z VBS skriptu spustit objekt (třeba MS Word) na vzdáleném stroji, a používat ho. Nic z toho není v rozporu se svobodami uživatele nebo vývojáře. Je to jen obrovská spousta práce, kterou vývojáři platformy investovali.

    Pro zastavování služeb na Linuxu můžete použít skripty. Bohužel na každém distru (obecně na každém unixu) jsou jinde. Není to objektové, není to použitelné z kódu, a je to velmi nešťastné řešení. Ve Windows máte Service Manager. Když nainstalujete binárku služby, zaregistrujete jí pomocí volání API (to může provést command line utilita, když na to přijde), nastavíte jméno služby, display name, kontext pod kterým poběží, co se má dělat když služba odpadne (například jí restartovat, a když požád neběží, rebootovat stroj, nebo zavolat nějaký program). Service Manager vám řekne, jaké služby v systému jsou, v jakém jsou stavu, a umožní vám je ovládat. API je popsané stejně, jako máte na unixech popsanou libc (jenom zřejmě podrobněji), a samozřejmě ho můžete používat, jako jakékoliv jiné API. Opět tu nikde není problém svobod. Problém je, že dřevní unixy neznaly pojem služba. Daemon byl proces, jako každý jiný, který se spouštěl v nějakém startup scriptu. Žádná registrace služeb a jednotný způsob jejich ovládání tehdy nevznikl, protože ty služby běžely na serveru tři, a server měl 5 administrátorů, kteří okolo něj chodili v galoších a bílých pláštích. Později vznikly skripty, které služby umožňují ovládat, protože situace nebyla dále udržitelná (bohužel na různých unixech různé skripty). Je to slabá náplast. A opět to není o svobodách, ale o dlouholeté stagnaci platformy.

    Wine je způsob, jak se skřípěním zubů rozchodit část funkcí Windows aplikace na Linuxu. Otázka je, proč to vůbec dělat. Obdobně je možné rozchodit unixové aplikace na Windows pomocí Services for UNIX (měl jsem na stroji jednoduchý WM, unixový Gimp a pár dalších aplikací). Demonstrace je to pěkná, ale v praxi je takový přístup krajně nepraktický.

    Pokud neznáte MSDN, zkuste tyto linky (nevím, jestli půjdou z jiného browseru, než MSIE):
    http://msdn2.microsoft.com/en-us/library/aa363858.aspx (Win32 API, funkce CreateFile, obdoba uniuxového open)
    http://msdn2.microsoft.com/en-us/library/system.windows.controls.button.aspx (.NET Framework 3.5, třída Button; všimněte si vlevo ve stromu Methods, Properties atd., a dole v See Also příkladů a konceptů)

    Výše uvedené linky jsou typickými příklady. Jistě uznáte, že srovnávat takovou dokumentaci se stránkami man postrádá smysl. Navíc jde o webovou verzi MSDN. Lokální verze má lepší vyhledávání, filtry obsahu, filtry jazyka (ty můžete viděl i na webu - u Buttonu si nahoře vyberete, jestli chcete vidět i definice a příklady pro J#, VB.NET apod). Man může některým lidem stačit, pokud nepotřebují přehled, vysvětlení konceptů, příklady, komentáře apod. Otázka je, proč by se měli spokojit s málem, když mohou za pár korun dostat lepší dokumentaci a daleko širší platformu, a řádově větší počet potenciálních zákazníků.

    DVD dekodér není jen problémem CSS. Jde také o fakt, že MPEG2 dekodér obsahuje patentované technologie, údajně cca 640 patentů. Každý patent drží někdo jiný, a vy musíte získat souhlas všech zúčastněných (zpravidla placený ;)), abyste směl MPEG2 dekodér legálně implementovat. Firmy zabývající se IP od těchto institucí a lidí odkupují práva k jejich patentům, a nabízejí je pohromadě jako práva k MPEG2. Tady se dozvíte, jaké patenty jsou ve hře, a na kolik vás přijdou.
    http://www.mpegla.com/m2/m2-patentlist.cfm

    S OpenGL jste začal vy. Samořejmě OpenGL je o vykreslování 3D primitiv (nebo máte jiný názor?). Direct3D obdobně. Jenže DirectX je nadmnožina Direct3D.
  • 14. 1. 2008 16:01

    anonymní
    Ne, vyjma těxhto kousků. Záloha registrů je dělána po standartní instalaci základních ovladačů a SW. Nevím, jestli vy na .rar a .zip používáte různé programy, ale já ne. Právě z důvodu toho, že si nechci zasekat systém.

    Ano, pokud přidám klíč, prakticky se nic nestane. Jenže každá aplikace přidává desítky klíčů.

    Ohledně fragmentace jsem někde viděl moc pěkný článek věnující se problematice EXT3 filesystému. Je v angličtine a myslím, že tu snad i byl jeho překlad. Doporučuji přečíst. Pokud nemáte disk zaplňený na 99.9%, tak se v případech kilobajtů není čeho bát.

    Ne, počítám pouze konfiguraci _systému_. Uživatelská konfigurace nemá s touto nic společného a tedy je podle mě mimo cpát ji k systémové. RPM distribuci nepoužívám. Z mých příspěvků je možné vyčíst, že používám Gentoo linux, který binární není. (z velké části - proprietární SW jako třeba drivery od nVidie, či RealPlayer samozřejmě binární jsou).

    Nevím, proč srovnáváte systémy Microsoftu s dřevními linuxy :-). Takové srovnání by ani mě nenapadlo.ta provázanost byla myšlená tak, že k tomu abyste toto mohl udělat, musíte používat proprietární SW z dílen Microsoftu. Nemáte prostě jinou volbu. A pokud jste někdy měl čest s takovou dokumentací k formátu .doc a podobné, jistě uznáte, že i když by Microsoft specifikace těchto komponent prodával (což nevím, nepracuji s jeho komponenty), tak soudě podle kvality zmiňované dokumentace by byl vývoj jiné implementace přinejmenším neskutečně složitý. Ani ne tak složitostí dané věci, ale stylem dokumentace.

    Nevím, jak vy, ale já osobně znám init skripty pouze ve složce /etc/init.d - pokud je tou někde jinak, je to věcí prasat, které tvořily danou distribuci a ne Linuxu jako celku. (Zanedbávám rozdíly v BSD a Linuxu - to jsou v podstatě jiné systémy, které měly společné hlavně předky). Tyto skripty mohu volat externě, není ale samozřejmě tak snadné jako ve Windows. Pokud má systém 5 adminů, kteří nejsou schopni mezi sebou komunikovat není to chyba systému ale těch administrátorů. POpravdě já nemohu jen tak spustit třeba dvě instance Apache - pořád je zde zámek, který určuje, že daný démon běží.

    WINE mi běhá i bez skřípění zubů. Opět je to jen o tom, jak je jeho uživatel-správce šikovný. Špatně nastavený WINE je absolutně nepoužitelný. Jinak ho používám třeba na to, když si chci jednou za čas zahrát svou oblíbenou hru Diablo II, Counter-Strike nebo Starcraft. Nemusím proto bootovat do windows jen kvůi těmto hrám.

    Ano, v Opeře jsou funkční. Jak jsem již psal - MAN slouží k naťuknutí třeba syntaxe, parametrů atd. _není_ (a ani nemá být) to manuál, který by něco dělal za vás. Navíc MAN je většinou používaný k programům, co se týče syntaxe, kterou mi v těchto stránkách předhazujete je trošku jiné kafe.

    Ne, DVD bylo hlavně o CSS. Myslíte, že pokud někdo bude mít patent na auto, a já vyvinu něco, co jezdí a dá se do toho lít benzín, budu muset platit patenty? Ne, pokud nepoužiji patentovanou _technologii_. To že se to dá používat stejně jako auto už nikdo neřeší.

    Prosím, nerozvádějte diskuzi o OpenGL, a už vůbec nezatahujte do hry nějaké subsystémy DirectXu. Pokud považujete 3D za primitivum, zkuste vymyslet něco, co zobrazí objekt alespoň ve 4D. A nebo ne - nestyďte se - ať každý vidí, že se nebojíte, berte rovnou v 5D. Tím teprve trumfnete "3D primitiva" a dokonce i ta "3D primitiva", které umí DirectX :-). Pokud to dokážete, přijďte a já před vámi padnu na kolena. Beze srandy :)
  • 14. 1. 2008 22:29

    bez přezdívky
    Přidávání klíčů v Registry je obdobou zakládání souborů na FS, stejně tak přidávání hodnot do klíčů nebo změna dat (nic z toho Registry výrazně nezpomaluje). U konfiguráků je naopak změna hodnoty nebo přidání hodnoty věcí, která je velmi pomalá, a při prodloužení konfiguráku na dvojnásobek trvá vyhledání hodnoty v něm dvojnásobně dlouho.

    Pokud prodloužíte soubor, je poměrně pravděpodobné, že dojde k jeho fragmentaci. Mimochodem srovnání souborových systémů na Linuxu a ve Windows vyzní pro Linux dost mizerně. Jeden FS umí žurnál a quoty, další umí ACL a žurnál, jeden umí kompresi, další umí šifrování... Ve Windows máme NTFS, které má žurnál, ACL, kompresi, quoty, a umí plně ACID transakce (změna v souboru A, změna v souboru B, update v databázi, změna v souboru C, poté commit nebo rollback).

    Konfiguraci vztaženou k uživateli ukládají Windows v HKEY_CURRENT_USER, což je Registry Hive (řekněme DB soubor), který sídlí v profilu uživatele.

    K tomu, abyste mohl udělat například přidání uživatelů, které jsem popisoval, nepotřebujete žádný proprietární SW (vyjma Windows jako takových). Formáty MS Office jsou založené na technologii OLE Document, což je vyšší úroveň abstrakce, než běžná C/C++ binární struktura (Word neví, jak konkrétně jsou objekty reprezentovány v souboru). Má to své podstatné výhody, stejně jako například kontejnerový formát TIFF. Pochopitelně pokud neumíte rozhraní OLE Document, máte při implementaci celkem problém. Naštěstí to máme také textové RTF, a XML-based OOXML.

    BSD a Linux jsou naopak v podstatě jedna platforma (UNIX), která se časem rozpadla do mnoha různých variant, které jsou jen omezeně kompatibilní. Ohledně 5 adminů jsme si nerozuměli. Když měl systém 5 adminů a 3 služby, nebylo třeba držet seznam běžících služeb (prostě běžel proces), ani je nijak ovládat (každý admin věděl, jak je spustit ručně). Mít nějaký Service Manager by v té době bylo jako jít s kanónem na vrabce. Časy se změnily, ale unixy bohužel ne.

    Apache si drží zámek na aplikační úrovni, pokud si pamatuji. Když ho spustíte, zapíše si do nějakého souboru, že běží, a při případném dvojím startu to z toho souboru zjistí.

    S Wine to je jako, byste tvrdil "moje elektronkové rádio hraje dobře, a je to jen o tom, jak umíte zacházet s pájkou, a jak znáte obvody". Ano, to je jistě možné. Ale stejně jako většina posluchačů rádia nechce pájku ani vidět (pokud už ví, k čemu taková věc je), většina počítačového lidu se nechce hrabat ve Wine. Nakonec všichni chceme používat počítače jako mikrovlnku, mixér, nebo foťák. Tedy až na uživatele vi ;)

    Ne, DVD není jen o CSS. MPEG2 dekodér můžete implementovat "nezávisle", ale přesto použijete patentované technologie.

    S těmi 3D primitivy se nám to nedorozuměním vzrhlo v komedii. Primitivem se v grafice rozumí nejjednodušší prvky, ze kterých se staví další objekty. 3D primitivy na úrovni Direct3D a OpenGL rozumíme body, úsečky, trojúhelníky, a některé jejich jednoduché složeniny (třeba pás navazujících trojúhelníků). 3D akcelerace na PC pracuje primárně s trojúhelníky, protože jsou nejúspornějším způsobem, jak popsat plochu ve 3D prostoru. Pro ilustraci si představte, že složíte 3D model postavy z pár desítek trojúhelníků. Každému trojúhelníku určíte barvy v jeho rozích, a plocha trojúhelníku bude postupným přechodem mezi těmi barvami. Takhle můžete vytvořit už celkem věrný 3D model. O kus dále se dostanete, když trojúhelníky místo jednoduchého vybarvení potáhnete nějakým obrázkem, tedy texturou. Shadery by byly mimo rozsah mého příspěvku. Každopádně Direct3D i OpenGL jsou interfacem, který slouží k vykreslování 3D výše popsaných primitiv, ze kterých se skládají složitější útvary. Když jste mluvil o OpenGL ve Windows, měl jsem za to, že máte konkrétní výhrady k jeho implementaci, jen jste je nesdělil.
  • 16. 1. 2008 18:36

    anonymní
    Vzhledem k tomu, že průměrný konfigurák má cca 100 řádků (jsou i několikařádkové a i tisícové) tak to, že to trva dvakrát tak dlouho neberu - vzhledem k rychlosti dnešních PC. Toto by byl argument na páskách nebo děrných štítcích :-)

    Pravděpodobnost se samozřejmě zvyšuje se zaplnením disku. Pokud nemám disk plný nad 90% je takové "riziko" celkem malé. EXT3 je žurnálovací systém s podporou šifrování - jinak samozřejmě máme i jiné (ReiserFS pro velké množství malých souborů atd).

    Tak s touto větví jsem se osobně nikdy moc nesetkával - vše, co jsem kdy upravoval bylo v HKLM. Jinak díky za informaci, toto jsem nevěděl.

    Varianty jsou kompatibilní plně - pokud se držím v rámci rozmezí typu distribuce (RedHat, Debian) a verze jádra (2.4.* a 2.6.*). Je jasné, že pokoušet se rozchodit RedHatí verzi MySQL serveru z roku raz dva, která je pro verzi kernelu 2.4.x na něčem z dnešní doby na debianím balíkovacím systému, můžu to pojmou jako zajímavou takticko-strategisckou hru s prvky hororu :-) Ovšem z jiného důvodu nevidím smysl něco takto nekompatibilního zkoušet. V rámci jednoho jádra je vše víceméně kompatibilní.

    Já samozřejmě dokáži získat seznam služeb běžících a také je podle potřeby vypínat. Každá služba, která je vedená v RC má svůj ovládací skript v adresáři /etc/init.d - takže vidím, že nejede apache, tak zapínám konsoli a píši /etc/init.d/apache2 start (nebo stop, či restart - záleží na tom co chci udělat). Pokud spravuji server, je toto naprosto postačující - kouknu na rc-status, vidím apache - neběží, a to je vše co potřebuji ke správě služby (rozuměj ZAP/VYP). Konfigurace je o něčem jiném, samozřejmě :)

    Ano, drží si lock. Výhodou je to, že když si služba myslí, že běží, a já _vím_ že ne, tak prostě provedu rm zámkového souboru a jedu.

    Ne, přirovnávat WINE k elektronkovému rádiu může pouze člověk, který ho viděl z rychlíku ve verzi 1.0 beta. Velká část aplikací pod WINE běží rovnou, a jen u specifických aplikací typu IE (a jemu podobných) se musí WINE nastavovat zvlášť. Tudíž pokud nemá uživatel zálibu v extrémě nestandartním SW, nemá problém. Pokud takový problém má, má v zásadě tři možnosti - sehnat si někoho, kdo je schopen WINE nakonfigurovat, zkusit své štěstí a za pomoci Googlu nastavit WINE sám, či rozjet emulované Windows. To třetí řešení je rozumné jen v případě, že máte třeba SW, bez kterého se není váš MP3 přehrávač _připojit_ k PC, a nechce se vám restartovat systém jen kvůli tomu, máte zde šanci. Počítače prostě není možné používat jako mikrovlnku nebo foťák. Do mikrovlnky nebo foťáku se Vám člověk, který tomu danému zařízení nerozumi, nebude strkat. U PC je to naopak - dnes je zde plno samozvaných _adminů_, kteří si podruhé zapli své Windows, nainstalovali ICQ, vypnuli FireWall a hned na to jdou s InternetExplorerem na porno stránky a myslí si, jak tomu systému rozumí. Samozřejmě si myslí, že na PC lze udělat stejně snadno jako nainstalovat ICQ (další > další > další > souhlasím > instaluj) a začnou se šťourat v PC. Pak v nadšeneckém orgasmu stáhnou tweakovací nástroj, "poštelují" si systém následným "pročišťením" registrů a pak se nestačí divit. PC není z principu možné používat jako foťák, je nesrovnale složitější.

    Tady se chci omluvit - poslední dobou mám práce nad hlavu, za celý den se nezastavím, a prostě je toho na mě moc. Váš předcházející příspěvek jsem si jen prolétl očima a porušil jsem zásadu "napřed mysli, pak piš". Ano, díky za výklad, opravdu jsem ujel - omlouvám se. S implementací openGL ve Windows nemám problém. Jen jsem tím mínil to, že kdyby vydavatelé _chtěli_, není problém psát hry v openGL. Třeba klasické AA: operations je (pokud se nemýlím) v Linuxu na openGL. A na tom, že jde o velice vypracovanou hru a grafiku, se jistě shodneme :-).
  • 17. 1. 2008 4:11

    bez přezdívky
    S těmi konfiguráky jsme si možná nerozuměli. Netvrdím, že by byly 2x náročnější, než Windows Registry. Tvrdím, že pokud se zvýší objem konfiguračního souboru na dvojnásobek, trvá vyhledávání hodnoty v něm dvojnásobnou dobu. Je to asi stejný rozdíl, jako mezi použitím databáze (Registry) a textového souboru s hodnotami (konfigurák). U zápisu/změny je to ještě výrazně horší. Ve zprávičkách dnes byl link na wiki openoffice, kde se řeší problémy s výkonem. Jedním z problémů je fakt, že načítání konfigurace trvá dlouho, a konfigurace je rozházená po spoustě souborů. Jetam i nějaký experiment, kde se konfigurace drží v databázi, a výsledek je o dost rychlejší. Netvrdil bych tedy, že konfiguráky nepůsobí problém s výkonem.
    http://wiki.services.openoffice.org/wiki/Performance
    http://wiki.services.openoffice.org/wiki/DbConfig

    S dovolením Ext3 nemá podporu šifrování (ani podporu komprese, ani neumí ACID transakce, ani nemá změnový žurnál, atd).

    Nevím, jak s instalací MySQL, ale instalace desktopových aplikací je zpravidla specifická pro dané distro. Pokud použijete balíček na jiném distru, budou chybět položky ve Start menu, aplikace nepůjde spustit, mohou mít problémy se závislostmi apod. Tedy asi ne v každém takovém případě.

    Ano, pomocí skriptů nakonec ty služby nějak managujete. Bohužel API chybí. Samozřejmě popsaný problém se zámkem ve Windows nemůže nastat. Service Manager ví PID procesu, proces má nějaké entry points (typu metody ZastavSe), a pokud se servis neukončí, nemůže být znovu spuštěn. Ve skutečnosti je to trochu komplikovanější, protože v jednom procesu může běžet služeb více, ale pro ilustraci to stačí.

    Wine toho času implementuje 57% funkcí Windows API, tedy podle vyjádření Wine. Wine je ještě pořád v beta verzi, a první ostrá verze bude kdo ví kdy. Podle wikipedie některé aplikace ve Wine fungují se slušnou stabilitou, a většina s "menšími problémy".
    http://www.winehq.org/site/winapi_stats
    http://en.wikipedia.org/wiki/Wine_%28software%29#Functionality

    Samozřejmě souhlasím, že do počítačů se dnes hrabe hromada lidí, kteří jim nerozumí. Ale také si myslím, že problém je na straně dnešního IT. Vezměte si například hry. Když chcete hrát hru na konzoli, koupíte médium, vsunete do mechaniky, a jedete. Na počítači řešíte instalaci hry, její aktualizaci, řešíte jestli máte nejnovější drivery grafické a zvukové karty, nastavujete ručně ve hře grafické detaily atd. Podobné nesmysly řeší uživatelé každý den. Nefungují tiskárny, neotvírají se soubory, aplikace havarují, útočí viry. A nakonec fakt, že když s browserem vlezete na některé stránky, tak chytíte breberky, je také selháním IT jako oboru, a nikoliv uživatele. Uživatelé jsou tupí, a nezmění se. Budou používat počítače buď "na tupo", nebo vůbec (a když je nebudou používat vůbec, budou mít problémy udělat efektivně svoji práci, a navíc my dva budeme hledat nový job). Naším úkolem jako IT průmyslu je produkovat takové počítače, které se dají používat jako digitální foťák nebo mikrovlnka. Je to složité, ale auto nebo digitální foťák jsou také složité věci.

    S tím 3D si nedělejte starosti ;). Hlavně, že jsme si to vysvětlili.

    Autoři her by samozřejmě mohli psát pro OpenGL. Jenomže je to náročnější. Direct3D přináší na úrovni API některé věci, které se v C++ (a třeba C#) používají výrazně lépe, než OpenGL (které je určeno primárně pro jazyk C). Navíc DirectX poskytuje i služby typu obsluhy vstupních zařízení (x-osý joystick s force feedbackem), 3D zvuku apod. Samozřejmě když píšete něco, co má běžet na unixech, tak nemáte DirectX, a OpenGL spolu s dalšími knihovnami pro zvuk, vstupní zařízení a spol je jedinou volbou.
  • 19. 1. 2008 20:12

    anonymní
    Já tvrdím, že registry jsou lepší v případě, že se jedná o veliký kofigurák (konfigurák ~ 3MB se opravdu načítá/ukládá dlouho) ale jinak ne. Apache má svůj apache2.conf (popř. httpd.conf), FTP má svůj konfigurák atd atd - každý program si zpracovává pouze svůj konfigurák o velikosti ~ 50kB, což už je dobré.

    Máte pravdu, šifrování nemá, spletl jsem se - je však žurnálovací.

    Nebudou - pokud použiji _debianí_ balíček na debian-based systému, nebude nic chybět - ani závislosti - to vše je totiž v kompetenci správce balíčků. Ikonky přibudou jak v KDE tak v GNOME. jiné WM neznám (nebo jen okrajově - window maker - ale nejsou tak používané - tedy určitě ne uživateli, kteří se řídí ikonkami v menu ;-) ). Pokud budu spouštět RPM balík na redhat-based systému bude platit to samé. To co popisujete nastane tehdy, kdy se třeba pokusím spustit RPM v debianu - ano, jde to, ale jsou s tím jen problémy. MySQL server byl jen takový příklad, napadl mě proto, že jsem ho nedávno instaloval na pár strojů.

    Ano, zapínám je a vypínám. Víc nepotřebuji. Navíc jsem už někde nějaké API viděl, ale já osobně preferuji /etc/init.d/xyz {start|stop|restart} - tady se totiž nejedná o nic, na co by bylo API potřeba. Jinak by na něco takového šlo napsat celkem jednoduše. Pokud mi vybyde čas a budu se nudit, zkusím si pohrát třeba v Pythonu a uvidíme :-).

    U Windows jsem se setkal s jiným problémem. Zkusil jsem ukončit službu, ale ta se v polovině ukončování kousla, takže byla ve stavu "zastavování" a nešla ani tam, ani zpět. Pomohl pouze restart systému - což by byl, jak pochopíte, na serveru s garantovanou dostupností mírný problém. Nepřišel jsem jak tuto složbu zlikvidovat a nahodit znova - možná to je tím, že se ve Windows tolik nevyznám.

    Podle mé zkušenosti funguje 90% SW, který potřebuju z Windows - protože na něj není alternativa a/nebo jsem líný se přeučovat ;-). Ty co mi fungují, fungují dobře, jiné tak tak, ovšem pro mě je podstatné to, že v mi v něm jede většina toho, co potřebuji a nemusím tedy virtualizovat Windows, či restartovat systém (domácí :-)) )

    Nejen IT - předně tak - když chci něco jen na hry, koupím si konzoli, ale bohužel tak dnešní uživatelé nesmýšlí. Ono bohužel/bohudík - přesně jak říkáte - museli bychom si hledat novou práci ale zase na druhou stranu PC, které běží týden jen proto, že uživatel je blbec prostě nepotěší. Pochopte, já ač bych rád, nemohu uživateli odebrat Administrátorské oprávnění a zaheslit mu PC (i když bych to kolikrát _moc_ (ani nevíte jak moc) rád udělal). Já jsem placen od toho, že mu nainstaluju systém, zabezpečím, doporučím mu IE7 a nebo FF a tím má práce končí. Pokud je tento uživatel trotl, který se jako _uživatel_ cítí méněcenně a přihlásí se jako admin, načež si s pocitem "já jsem ale king" vypne Firewall, a hned nato antivir, si prostě o problémy přímo říká. Nevím, jestli mám kliku na takové exoty, ale tento příběh (s mírními změnami) se děje velmi často. Takto ani já jako IT nezamezím takové katastrofě, která se jmenuje _uživatel_. Je to téměř nemožné - už jen z principu toho, že s foťákem se dá jen fotit, ale s PC se dá dělat mnohem víc a pokrýt takový počet oborů je víc než zapeklitý úkol. Prostě uživatel-blbec si je sám nebezpečný (a potencionálně i jiným) úplně stejně jako řidič-blbec...

    Jasně :-) DirectX se nemůže rovnat openGL - to už jsem se v začátku špatně vyjádřil. DirectX je něco, co v sobě zahrnuje povícero takových "openGL". Jk jste správně řekl, directX je nadřazená mnohžina openGL. Ale abych vyjádřil svou prvotní myšlenku - je to možné - vím o jedné hře (teď si ale nevzpomenu na jméno), která má prakticky stejný základ, a pak Win a Lin instalátor. Používá ale při tom stejné jádro.
  • 19. 1. 2008 22:12

    bez přezdívky
    Na příkladu OpenOffice je vidět, že konfigurace rozházená do malých souborů je horší, než konfigurační DB. Souhlasím ale, že malé konfiguráky u produktů s pár konfiguračními volbami (což je třeba Apache) nejsou velkou zátěží.

    Pokud použijete balíček z Debian-based distra na jiném Debian-based distru, a máte stejnou verzi kernelu a gcc, je pravděpodobné, že budeme mít problémů minimum. To souhlasím. Je ovšem otázka, jestli to stačí.

    Kdykoliv potřebujete manipulovat se službami z nějaké aplikace (dohledový systém, instalátor), je třeba mít nějaké API. Také je dobré zná závislosti mezi službami, abyste v případě zastavení jedné služby věděl, co dalšího odpadne (a mohl třeba zastavit aplikační server dříve, než shodíte databázi). Další věcí je spouštění služeb, kde se (na rychlém HW) dost vyplatí spouštět je asynchronně, a tedy znát závislosti (to některé unixy neřeší, jiné mají skripty). Ve Windows jsou příjemnou věcí i události nad službami, tedy například automatický restart služby, nebo spuštění dané aplikace, interface a API pro nastavování kontextu ve kterém služba běží atd. Samozřejmě můžete napsat v Pythonu nějaký wrapper nad shell skripty, ale problém to neřeší. Unixy měly už 20 let mít nějaký service manager, který by poskytovatl funkce srovnatelné s Windows service managerem. Podobně je to u řady dalších věcí.

    Ve Windows Service Manager říká službě, že se má ukončit. Pokud služba akceptuje požadavek, je ve stavu Stopping, dokud se neukončí. Pokud binárce například leaknul nějaký resource, nemusí se v některých scénářích ukončit (podobně jako na unixech). Pak je třeba odstřelit daný proces (i když mám za to, že to po nějakých minutách zkusí Service Manager). Odstřelení je třeba provést v kontextu, který k tomu má právo, ale to je mimo rozsah příspěvku (Windows admini vědí). Ukončení procesu zaregistruje Service Manager, a službu je pak možné ovládat běžným způsobem.

    Samozřejmě pokud vám ve Wine běží SW, který potřebujete, jste šťastný. Já osobně řeším opačný případ tak, že mám ve vmware SuSE Linux Enterprise Server, a když potřebuji, tak ho rozběhnu. Běžně je ve stavu paused, takže rozběhnout ho je věc na chvilku. Tedy poslední 3 měsíce se to nestalo ;)

    Souhlas, uživatelé jsou neštěstí. Nezbývá, než stavět čím dál blbuvzdornější systémy a aplikace, a pozorovat, jak počítače používá čím dál více lidí, před kterými je těžké počítač uchránit :). Ale takový už je náš job, za to celý náš průmysl platí. Samozřejmě unixového admina to nemusí moc trápit. Naopak autory Windows Serveru, Windows desktopu, MacOS, dister Linuxu, a autory všech aplikací, to trápí velmi.

    Ano, hry lze napsat multiplatformně. Bohužel to typicky znamená více práce (spoustu wrapperů). Navíc mimo Windows a konzoly není trh, který by zaplatil dodatečné náklady na vývoj a cenu supportu (podpora další platformy není levná).
  • 20. 1. 2008 12:46

    anonymní
    Ano, toto je podobné jako registry - každý program má ve své větvi svá data. Zde má každý program svůj konfigurák.

    Popravdě, GCC se v debianu neřeší - balíčky se nekompilují a verze kernelu stačí víceméně stejné řady (2.4.x a 2.6.x). Ano, toto stačí, protože nový kernel se dá přiřadit k přechodu W95 na W98 (jako příklad).

    Já vím, že zastavením Apache mi nepojede web, zastavením databázového serveru zase DB - mezi servery tedy závislosti nejsou. Pokud zastavím Kerberos či podobnou službu, nepojede mi jen to, k čemu je daná služba. Tady neplatí závislosti typu "Pokud chceš MySQL, musí ti jet Apache" (jen příklad, tyto služby ani ve Windows nejsou závislé). Asynchronně služby spouštět samozřejmě mohu, v souboru /etc/init.d/xyz je napsáno, po čem a před čím se má služba spustit. Jak říkám, stávající správa služeb je vyhovující a dostačující.

    Ano, mohu jí zabít. manager se o to nepokusí (čekal jsem do dvou minut, dál se nedalo jít). Špatné je, že pokud pod daným procesem běží více služeb...

    Ano, je to věc preferencí každého - mě osobně je bližší systém Gentoo než Windows, také ho používám, Windows mám pouze na hry, protože do konzole se mi investovat nechce ;-).

    Bohužel je to pravda, ale mě to přijde uplně zvrhlé.Jako unix. admina mě to netrápí, jakočlověka, který se zabývá také instalacemi uživ. stanic. mě to trápí :-). I člověk, co dělá u soustruhu je vyučený k práce s tím soustruhem, a člověk, který dělá s věcí, která sama stojí >10 000,- a může způsobit statisícové škody není vyučen. Je to sice věcí firmy, ale nemyslím si, že by to nebyl běžný stav. Bohužel školení o základní bezpečnosti se podceňuje.

    Ano, samozřejmě, je to víc práce. Já osobně to dělám tak, že si danou hru stáhnu, zkusím zahrát, zjistím, že se mi líbí a koupím si originál. Stejně bych to dělal na UNIXu, kdyby to bylo možné. Hry, u kterých zůstávám, protozže se mi líbí, za ty zaplatím. Hry, které se mi nelíbí, neplatím. A nemám svůj systém proto, že bych si nebyl schopný (ochotný) koupit licenci. Naopak. Mám ho proto, že se mi líbí jeho filozofie... Myslím (doufám), že stejně smýšlejících lidí je většina. Je samozřejmé, že podpora pro jiné platformy něco stojí, ale nemyslím si, že systém UNIX mají jen ti, kteří jsou neschopní nainstalovat Windows, nebo nemají na jeho licenci :-D. Jsem pro to, aby se za SW platilo, jako vývojář ani jinak smýšlet nemohu :-). I když to je možná ta chyba - kdyby si každý zkusil napsat nějaký ten program, pochopil by, kolik práce do toho vývojář musí dát... Ale to sem také úplně nepatří :-)
  • 21. 1. 2008 2:48

    bez přezdívky
    No, jak říkám, konfigurace v konfigurácích je pomalejší, než v případě Registry. Horší se to s délkou souboru, a podle všeho i s počtem souborů (jak jsem psal u OOo). V praxi to ale není tak kritické. OpenOffice při použití konfigurančí databáze místo více konfiguráků souborů nabíhá o cca 0.5-1.5 sekundy rychleji.

    Windows jsou naštěstí ost dobře zpětně kompatibilní. Vyjma aplikací používajících kernelové moduly (což je bohužel každá blbost na vypalování CD a každý nástroj pro sledování HW) lze provozovat prakticky cokoliv. Na Windows Vista s velmi dobře běží aplikace pro Windows 3.x. Pokud aplikace neběží, je to typicky proto, že jí autor napsal špatně (například vykrádání zdrojů ze systémových knihoven). MS ovšem zpětné kompatibilitě věnuje veliké úsilí, a některé chyby aplikací ošetřuje. Na Linuxu je všechno součástí distra, a pokud ne, hrozí problém. Rozchodit aplikaci na jiné verzi kernelu není úplně vyloučeno, ale šance na úspěch není velká.

    Mezi službami samozřejmě jsou závislosti. Pokud vám nad DB běží nějaký aplikační server, je tam závislost. Pokud zastavíte Kerberos, zřejmě odpadne funkce řady aplikací, včetně například DB serveru, web serveru, sdílení apod.

    Service Manager určitě nebude nic zabíjet po 2 minutách. Jako minimum bych viděl 10 minut. V takovém případě je samozřejmě lepší službu odstřelit. Ovšem stejná situace může nastat (a nastává) i na unixech. Více služeb v jednom executable je celkem výjimečná věc, která se používá primárně u systémových služeb.

    Počítače jsou až nechutně složité. Mě takový způsob uvažování přijde intuitivní, ale jsem jedním z mála (podle všeho i v IT oboru). Pro řadu lidí je obtížné pochopit stromovou strukturu souborů, a uvědomit si, že "dopis.doc" ve dvou různých adresářích není ten samý soubor. Účelem snažení vývojářů je, aby počítač mohl intiutivně používat každý, kdo pochopí právě stromovou strukturu a double click. Všechno je vidět na obrazovce a vy si z toho vybíráte, máte nápovědu. Samozřejmě praxe je o něco drsnější, ale ideál je nastavený takhle. Windows se ideálu blíží jen velmi přibližně :). Unixy bohužel o řád hůře. V případě původních unixů proto, že uživatel nebyl důležitý (okolo serveru chodilo těch 5 adminů v bílých pláštích a galoších, a každý z nich strávil 10 let studiem informatiky). V případě Linuxu jednak kvůli unixovému dědictví, a potom kvůli nedostatku designu a podinvestovanosti. Pár miliard USD investovaných do vývoje platformy a zlepšování interface by vedlo k velkému pokroku. Jenže invesice předpokládá návratnost, a když výsledek díky GPL může mít kdokoliv zdarma, investic moc nebude.

    Nemyslím, že by UNIX byl typický pro lidi, kteří mají hluboko do kapsy. Bude to spíše typické pro Linux. Uživatelé Linuxu buď nemají peníze (například studenti), jsou členy fanatické sekty (určitě jste takové lidi viděl), chtějí šetřit, potřebují nezbytně unix, nebo jsou jim principy unixů velmi blízké (za to asi může výuka unixů na VŠ). Faktem je, že aplikace pro Linux jsou ve většině oborů prakticky neprodejné. Konkurence různých "polotovarů zdarma" je velká, rozšířenost Linuxu malá, a aspekt "Linux mají ti, kdo nemají peníze" sice není absolutně platný, ale určitě také hraje roli.
  • 21. 1. 2008 21:06

    anonymní
    S tím právě nesouhlasím - je rychlejší v případě velkého konfiguráku pro jeden program ( => velké množství dat), jinak ne.

    Ne, není problém rozběhat něco z kernelu 2.6.20 a 2.6.23. "Majoritní" vydání (2.x) není vydáváno každý týden... Problém nehrozí díky balíčkovacím systémům - příklad: chci balík X. zadám tedy "emerge X". Balíčkovací systém Portage se "podívá" na závislosti a zjistí - balík X potřebuje balík Y a Z. Zkontroluje tedy závislostí u Y a Z, a zařadí je před balík X, takže instalace proběhne v pořadí Y, Z, X. Není tedy žádný problém.

    Záleží na provázanosti, a to jakožto systémový správce _musím_ vědět, zda jsem u WWW serveru použil autentifikace pomocí Kerberosu nebo ne. Pokud jako správce toto nevím, je to na zvážení okamžité výpovědi :-)

    Nedělá mi problém pochopit adresářovou strukturu. I mě se způsob "uvažování" UNIXu zdá intuitivní. Nejde o přizpůsobení - to o čem mluvím je to, že uživatel se značkou "BFU jak vyšitý" se prostě _odmítá_ vzdát svého Administrátorského účtu, a je těžké mu to rozmluvit. V tom je ta chyba. Pozor, abychom zde nemlžili - na Linuxu je možné používat licencovaný SW (dobrý příklad CEDEGA, RealPlayer), takže je možné investovat.

    Já doma používám Linux právě z důvodu jeho koncepce. Bohužel, trollové, kteří se vyznačují výkřiky do tmy typu "Linux ruleeezzz" nebo "M$ suxxx" jsou pořád mezi námi. A ani to nemusí být Linuxoví trollové. Tito lidé jsou opravdu pod průměrem (a to obvykle jak inteligenčním, tak i znalostním). Určitě toto roli hraje, ale neřekl bych, že moc velkou. Já mám GENTOO proto, že mě _baví_ se kopat v systému a koukat, co vlastně skrývá. Takových "úchylů" je jistě víc ( :-D ). A jak jsem řekl už v minulém příspěvku - věci, které mě zajímají si kupuji
  • 4. 1. 2008 22:17

    Mates (neregistrovaný)
    Omlouvam se za OT, ale kdyz uz jste nakousl ten Remote Desktop, tak bych mel dotaz. Lze to nejak pouzivat i pro 3D grafiku? Zkousel jsem nekolik aplikaci (Ansys, ProE, MSC Mentat, neco z toho jsem zkousel i bez OGL (ze na klientskem pc muzu na akceleraci zapomenout chapu)) a na gigabitove siti a velmi slusnych pocitacich si pres tuhle vychytavku nezatocim plynule ani s kostickou. Na obou pocitacich jsou winxp(sp2). Kdyz si exportuju Xka (pouzivam Xming-mesa), tak to bezi temer jak na lokale. V nastaveni ms terminal klienta jsem toho moc nenasel, lze to nejak ovlivnit?
    A nedelam si legraci, opravdu by me pripadne reseni zajimalo.

    Jinak mam moc rad MS wheel mouse optical (O hromadnem prodeji ale neuvazuji). Pro cloveka, kt. hodne macka prostredni tlacitko (kolecko) je k nezaplaceni.
  • 5. 1. 2008 12:09

    LO (neregistrovaný)
    3D grafiku přes RDP jde provozovat blbě. RDP pracuje na úrovni GDI/driver, a poskytuje tedy primárně funkce, které driver nabízí GDI. Zkuste Citrix Metaframe, nebo RDP ve Vistě. Ve Vistě lze provozovat Aero přes RDP, tedy počítám, že umí 3D primitiva.

    Mám několik MS myší. Jedna bezdrátová má bohužel kolečko, které se musí stisknout silou úderu kladiva. Vyjma toho jsem s MS mouse* celkem šťastný. Jiné myši mohou fungovat stejně dobře, ale často tomu tak není. Vybrat z ceníku MS myš je v podstatě sázka na jistotu.
  • 4. 1. 2008 13:51

    Peto_MiG (neregistrovaný)
    LO, táraš. Editácie registrov je bežná a často JEDINÁ cesta, ako môžeš ovplyvniť niektoré správanie Windows, na ktoré nestačí priblblý wizard.

    Otvor si ľubovoľný magazín a počítačoch, rubriku "tipy a triky pre windows/office" a prvá veta, ktorú nájdeš, je "otvoríme regedit"...

    A škoda hovoriť o tom, že ani správne nastavenie nie je vo Windows zárukou funkčnosti. Napríklad nastavenie siete.. nejde a nejde, ale keď spustíš wizarda a zadáš TIE ISTÉ hodnoty, tak zrazu to zázračne ide. Wizard čosi kdesi do registrov zapísal, čo sa v ostatných GUI nástrojoch zapísať pozabudlo. Chcelo by sa mi povedať niečo o "desivých GUI utilitách Windows".

    V Linuxe aspoň viem, že keď chcem niečo zmeniť, tak to urobím v konfiguráku, kde sú všetky možnosti dobre opísané vrátane príkladov. Ešte si pozriem man stránku, a mám plnú kontrolu nad všetkým čo program dokáže.
  • 10. 1. 2008 22:50

    bez přezdívky
    Cože dělám? No to je jedno, pojďme k věci. Ještě musím připomenout, že si netykáme.

    V magazínech je opravdu většinou rubrika "1000+1 editace Registry". Typicky se tam popisují nastavení, která jsou buď zcela nezajímavé, například jak umístit wallpaper na danou pozici na desktopu (ne na strěd, ne roztahnout na desktop, ale umístit ho na pozici řekněme 300,200 od levého horního rohu). Řadu nastavení navíc lze provést z GUI, jenom to autoři těchto veleužitečných nesmyslů neuvádějí. Typickým příkladem jsou věci, které se běžně mění přes Policy Editor (hlášky při přihlášení, zákaz spuštění některých aplikací apod).

    Ve Windows se nedějí zázraky. Protože počítač je deterministický stroj (byť o tom člověk někdy může pochybovat), zázraky nejsou.

    V Linuxu měníte nastavení v komentovaném konfiguráku? A jak je komentovaný konfigurák OpenOffice, KMailu, xmms a dalších aplikací? A upravujete ho fakt ručně? Nebo se v případě ruční editace konfiguráku jedná jen o aplikace, které nemají dostatečně kvalitní konfigurační interface, protože jsou vývojově či koncepčně zastaralé?
  • 5. 1. 2008 0:11

    333 (neregistrovaný)
    Jako obvykle s Vami musim nesouhlasit. V YaSTu na SUSE Linuxu lze udelat vicemene vse, co bezny uzivatel potrebuje, a vubec se nejedna o desivou GUI utilitu. Uvedte, co Vam tam schazi, at vime, co pridat.
  • 5. 1. 2008 12:16

    LO (neregistrovaný)
    Bohužel YaST je věcí pár dister. Já se typicky trápil s tím, že je GUI utilit více, a každá nabízí jiné možnosti (například každá nabízí jiné nejvyšší rozlišení displaye a refresh rate). Občas se bijí nastavení provedené v utilitách distra (YaST) s nastavením z utilit prostředí (KConfig). A v YaSTu si například zkuste založit 16 partitions na RAID řadiči. Budete překvapen, jaké skvělé hlášky vyhodí (rozhodně neřekne "na RAIDu je možné mít max 15 partitions).
  • 5. 1. 2008 13:53

    333 (neregistrovaný)
    YaST je sice zalezitosti par dister (openSUSE, SLES, SLED), ale SUSE melo v roce 2007 zastoupeni na desktopech kolem 21% (http://www.desktoplinux.com/news/NS8454912761.html). Neni to ponekud hodne na to, abyste prohlasil, ze (cituji:) "komentované konfiguráky jsou na Linuxu prakticky jedinou cestou, jak dělat změny v konfiguraci"? Ja myslim, ze ano. Nic se nema prehanet a pro to Vase "generalizovani" to plati dvojnasob.

    Co se YaSTu a 16 partitions na RAID radici tyce: to jsem nezkousel. Nicmene nedomnivam se, ze by to obycejne uzivatele trapilo.
  • 5. 1. 2008 15:40

    LO (neregistrovaný)
    Jak jsem psal, YaST je jen jedním z mnoha nekvalitních GUI.

    16 partitions na RAIDu vás trápit nemusí, ale bugem to zůstává. Bug není v tom, že na RAIDu lze mít jen 15 partitions (byť je to způsobené tím zaostalým systémem major/minor number, který Linux převzal odkudsi z pravěku), ale to, že nástroje v takovém případě neumí nic rozumného zahlásit.
  • 5. 1. 2008 17:19

    333 (neregistrovaný)
    Neztotoznuji se s nazorem, ze YaST je nekvalitni GUI. Pouzivam ho mnoho let, a tak muj nazor neni nazorem cloveka, ktery ho videl z rychliku.

    Nicmene souhlasim s Vami, ze YaST by mohl uzivatele vice vest (treba tim, ze lepe zahlasi chybnou konfiguraci). Nedavno probehla v ramci openSUSE komunity anketa ohledne nametu na zlepseni YaSTu (http://news.opensuse.org/2007/10/01/yast-survey-started/, vysledky, IMHO, nejsou verejne pristupne) a tato byla jedna z navrhovanych veci.