Základní problém je, že kdejaký domácí uživatel je zároveň admin. Toto je fatální nedorozumění. Kdekdo si myslí, že si dokáže systém nainstalovat a nastavit. To není pravda. Jelikož si BFU s admin právy ve Win může cokoli stáhnout a spustit, neznamená to, že je skutečný admin. Viděl jsem spoustu zmršených Win instalací, protože BFU něco instalovali a nastavovali. Nechápali, že to má dělat někdo, kdo tomu rozumí.
U Linuxu všichni tihle rádoby admini narazí. Proto nadávají na Linux. Prostě něco neumí a od uživatelů se ani neočekává, že by to měli umět. To je starost admina. Měli by dostat do rukou nainstalovaný, plně funkční počítač, na kterém by jen pracovali. Jenže to jim zadarmo nikdo dělat nebude. A běžný domácí uživatel nebude nikdy platit za instalaci a za nastavení.
Běžný domácí uživatel dostane buď počítač nainstalovaný (pokud koupil značkový stroj), nebo vloží instalační média, a nějak se s tím popere (sám nebo se známým). Kupodivu to funguje. Faktem je, že si lidé občas způsobí dost problémů, ale funguje to. Instalaci Windows, Office a WinRARu zvládne asi opravdu každý. Naštěstí je ke všemu nápověda, vše je lokalizované atd.
Souhlasím, že tohle u Linuxu jde špatně. Rozchodit WiFi je mnohdy problém na pár hodin i pro zkušeného admina, instalace driveru grafické karty se lehko může stát noční můrou uživatele, a instalace čehokoliv, co není v repository daného distra, je pro uživatele vždy veliký problém. Linux od uživatelů-rádoby-adminů vyžaduje daleko více znalostí.
Nevim, jestli stav, kdy se s tim uzivatel popere, prohraje, privola znameho, poperou se s tim oba, nejak to ubastli, petkrat za rok to preinstaluji a berou to jako normu da nazyvat fungovanim.
Me tedy system funguje na ponekud jine urovni.
...rozchodit wifi je mnohdy problém na pár hodin i pro zkušeného admina...
Zrovna nedávno se brácha potýkal s instalací karty pro bezdrát... na Windows XP (úpravy v registrech apod). V Arch Linuxu nainstaloval podle návodu opensource ovladače a ... jely.
Tolik ke kompatibilitě hardware na linuxu.
...a instalace čehokoliv, co není v repository daného distra, je pro uživatele vždy veliký problém...
Ehmm... dost lidí na PCLinuxOS používá RPM z Mandrivy či Fedory. Stačí se kouknout na fóra.
Jeden člověk se u recenze PCLinuxOS zmínil, že potřeboval jistý program do PCLinuxOS (konkrétně Ekigu) (i zdůraznil, že se jedná o balík, který by potřebovali i ostatní) a do týdne ho tam měl.
On existuje nějaký HW, který by byl kompatibilní s Linuxem? A jaký *konkrétně* to je? Některá distra mají sice nějaký hardware compatibility list, ale typicky tragicky krátký. A různé neofociální databáze na netu obsahují řadu neověřených informací typu "zkoušel jsem, funguje mi to". V praxi ono "funguje mi to" může znamenat, že WiFi karta bude potřebovat stáhnout MadWiFi v develop verzi, zkompilovat ho, zeditovat řadu konfiguráků, a stejně například nepůjde AdHoc mode, start systému se vždy zaklesne než karta naběhne atd.
Například v případě scannerů existuje SANE. V compatibility listu najdete hromadu scannerů. Když váš scanner bude v principu fungovat, stejně bude mít pravděpodobně řadu problémů typu pomalého skenování v některých rozlišeních, nesmírně zubatých výstupů v jiných rozlišeních, příšerných barev apod. Takhle si podporu HW nepředstavuje snad nikdo.
Například v případě scannerů existuje SANE. V compatibility listu najdete hromadu scannerů. Když váš scanner bude v principu fungovat, stejně bude mít pravděpodobně řadu problémů typu pomalého skenování v některých rozlišeních, nesmírně zubatých výstupů v jiných rozlišeních, příšerných barev apod. Takhle si podporu HW nepředstavuje snad nikdo.
Když se na seznam SANE ovladačů pro skenery podíváte pořádně, najdete nemalý počet modelů s podporou "Complete", tedy že ovladač umí vše, co umí samotné zařízení, a spoustu s podporou "Good", tedy že zařízení až na pár exotických funkcí funguje jak má. Například můj skener je v seznamu označený jako "Good", ale v SANE funguje výrazně lépe než s TWAIN ovladačem. A to teď nepočítám možnosti, které jsou v TWAIN prakticky nemožné. On je ten seznam totiž už trochu zastaralý. Podle stránky projektu ovladače mého skeneru totiž zbývá jediný nevyřešení problém, který se týká jiného modelu (1 z 5 podporovaných).
> On existuje nějaký HW, který by byl kompatibilní s Linuxem? A jaký *konkrétně* to je?
Typicky hardware podporovany originalnim (nepatchovanym) Linux kernelem. Nevim, zda je ten seznam nekde vystaven, ale neni problem ho vygenerovat. Mnohem vetsi problem je vytahnout z prodejce, jaky hardware vlastne prodava - treba PCI ID. Protoze v bordelu obchodnich nazvu vyrobku (ktere se casto bezduvodne meni a nebo naopak nemeni, i kdyz se zmenil vyrobek) se dost spatne orientuje.
Kdo má Windows, musí mít HW pro Windows, aby mu měly ty Windows na čem běžet. Na čem mu poběží, však zjistí teprve z té stránky. Proč mi to jen připomíná Hlavu XXII?? Domyšlené to teda panáčkové rozhodně nemají.
Protože MSIE má k dispozici 99+ lidí ze 100, není to až takový problém. Přístup k HCL potřebujete, když kupujete HW ke svému počítači. Koupě počítače se typicky obejde bez HCL (velcí výrobci mají certifikované všechno). Takže nám zbývá případ, kdy si nějaký uživatel Linuxu, OS/2 nebo BSD, který nemá přístup k MSIE, chce postavit počítač. Fakt je to problém? ;)
Naštěstí je ke všemu nápověda, vše je lokalizované atd.
Ještě je třeba říct pár slov ke kvalitě té lokalizace. Někdy před 3 lety jsem něco nastavoval ve Windows XP. Jak to nastavit jsem našel v nápovědě. Jenže ta lokalizovaná nápověda se jaksi se skutečným obsahem ovládacích panelů velmi brzy rozešla. Nakonec mi trvalo déle uhodnout, jak se těch pár konfiguračních položek jmenuje ve skutečnosti, než to celé nastavit. S anglickou verzí nápovědy bych nejspíš hádat nemusel, i kdyby zbytek systému byl česky.
Naprosto souhlasím. Že běžný uživatel jakž-takž nainstaluje holé Windows Home ještě neznamená, že by nainstaloval i Windows Server. Jenže v běžné distribuci Linuxu má spoustu věcí, které prostě pro běžného uživatele nejsou a to ho značně irituje. Pak se v diskuzních fórech objevují dotazy typu "jak spustit MySQL, jak přeložit program" a podobné, ze kterých plyne, že autor by rád něco, co už není pro BFU, ale nehodlá číst ani read.me, natož investovat do nějaké knihy. Klikací GUI naučilo uživatele pracovat stylem "pokus-omyl" a "co to udělá,když...". Linuxové servery tímto stylem administrovat nelze. Těžko se pak takovým lidem vysvětluje, že buď se musí chovat jako běžní uživatelé a o více se nesnažit, nebo se to prostě musí naučit.
Ve Windows je také jasný předěl mezi systémem a ostatními programy. V Linuxu si někdo stáhne alfa verzi čehosi a když má potíže, nadává na Linux.
Obzvláště pozoruhodný byl pak diskuzní příspěvek jednoho uživatele, který nadával, proč jsou v Linuxu takové pitomosti, jako kompilátory.
Není pravdou, že Linux není vhodný pro domácí uživatele. Pravdou je, že Linux není zdaleka určen pouze jim. Ale pokud si vyberou vhodnou část, mohou být spokojeni,
> Měli by dostat do rukou nainstalovaný, plně funkční počítač, na kterém by jen pracovali. Jenže to jim zadarmo nikdo dělat nebude.
Proč by to nemohl dělat dodavatel SW? On na tom vydělá (dostane zaplaceno), uživatel na tom vydělá (zaplatí míň než za Windows), prodělá jen Microsoft. Jediný problém s Linuxem je obrovská neinformovanost: kolikrát jste v médiích (kromě Asusu Eee a OLPC XO-1, ani jeden se u nás neprodává) slyšeli něco o desktopovém Linuxu (třeba vydání nového Ubuntu nebo Compizu)? A kolikrát jste slyšeli o Windows (Vista)? Uživatelé zkrátka neví, co od něj mají čekat, a tak si radši koupí to, o čem čtou a co vidí v televizi.
Jestli čtete root.cz, tak se o Vistě dočtete nejvýše že je špatná, neprodává se, a jak z ní migrovat na Linux ;). Mainstreamová média jsou Linuxu téměř plná. Resp. nepochybně se tam Linuxu dostává disproporčně více místa, než kolik lidí Linux používá v poměru třeba k Windows.
Pochopte, že problém není v nedostatku informací o Linuxu. Problém je v kvalitě Linuxu, v jeho celkovém konceptu, v dostupnosti aplikací, lokalizaci, absenci nápovědy, dostupnosti a přehlednosti dokumentace pro vývojáře, dostupnosti a kvalitě vývojových nástrojů apod.
> Jestli čtete root.cz, tak se o Vistě dočtete nejvýše že je špatná, neprodává se, a jak z ní migrovat na Linux ;).
Ano, ale já zaprvé nečtu jen root.cz a zadruhé Windows znám. V tom je zásadní rozdíl.
> Mainstreamová média jsou Linuxu téměř plná. Resp. nepochybně se tam Linuxu dostává disproporčně více místa, než kolik lidí Linux používá v poměru třeba k Windows.
Opravdu jediné, co jsem se o Linuxu v mainstreamových médiích v poslední době dozvěděl, je, že je na Asus Eee (informace byla o superlevném PC, ne o Linuxu) a OLPC XO-1 (ve zmínce, že tam budou i Windows). Naopak o Windows se každou chvíli něco dozvídám, (naposledy že brzo vyjde Service Pack, který konečně vyřeší všechny problémy, a jak je Aero úžasné a inovativní). Ani jedna zpráva nebyla o Linuxu.
> Pochopte, že problém není v nedostatku informací o Linuxu. Problém je v kvalitě Linuxu, v jeho celkovém konceptu, v dostupnosti aplikací, lokalizaci, absenci nápovědy, dostupnosti a přehlednosti dokumentace pro vývojáře, dostupnosti a kvalitě vývojových nástrojů apod.
Kvalitě Linuxu? Kromě špičkových grafických studií (které stejně vezmou MacOS X místo Windows) jsem nenašel nikoho, kdo by měl nějaké problémy s kvalitou (tedy podporou aplikací, resp. balíčkovacím systémem a stabilitou - nebo hodnotíte kvalitu ještě jinak?).
Celkový koncept je daleko lepší než koncept vycházející z jednouživatelského, k síti nepřipojeného systému, jako je Windows. Tohle se ve Windows Vista hodně zlepšilo, ale ještě stále je pozadu (jediné, co mají Windows lepší, je koncept sdílení sítí CIFS, který ale Linux přijal a umí).
Dostupnost aplikací je naopak špičková - spousty prověřených aplikací, snadno dostupné i se závislostmi, minimální nebezpečí trojských koní nebo virů. Podle mě je systém, kde jsou aplikace dodávány z centrálního repozitáře (i ty komerční, viz Ubuntu) daleko lepší, než když si je můžete stáhnout z Internetu (i zde se Microsoft zlepšuje, např. digitální podpisy ovladačů a aplikací na PDA). Problémem je snad jen to, že spousta softwarových firem Linux ignoruje, takže zrovna ta jejich není dostupná. To je problém her a CADu, ale ničeho jiného.
Lokalizace? Co byste ještě víc chtěl? Aby Linux přeložil i BIOS a všechny hry? S lokalizací je problém na obou platformách, základ je přeložen, mnoho dalších aplikací ne (btw. hry pro Linux jsou často přeloženy daleko lépe než hry pro Windows).
Absence nápovědy? No, tady máte pravdu. Ale to bych jako klíčové nebral, nápověda Windows není moc obsáhlá a často uživatele spíše zmate. Pokud máte na mysli tištěnou nápovědu, tak tady jsou opět oba systémy vyrovnané.
Dostupnost a přehlednost dokumentace? Pro nejnižší systémové programování máme manuálové stránky (lze je prohlížet i v nich snadno vyhledávat). Jsou přehledné a snadno dostupné. Různá rozšíření mají vlastní obsáhlé dokumentace (SDL, KDE, ...). Tady jsou si oba systémy rovnocenné.
Dostupnost a kvalita vývojových nástrojů? Co třeba Eclipse nebo KDevelop? Nestačí? Ani tady nemá ani jeden systém navrch.
Zkuste se podívat na ihned.cz, zpravy.idnes.cz apod., a fulltextem vyhledat Linux. Možná budete překvapen.
Celkový koncept Linuxu je unixový. Tedy tty, command line, vi, hromada utilit, GUI jako nadstavba která může a nemusí být. GUI je mizerné, pro administraci je v Linuxu opravdu lepší command line. Ve Windows je lepší používat GUI, i když lze totéž dělat i z command line. Více jsem k tomu napsal třeba zde: http://www.root.cz/zpravicky/microsoft-zrusil-v-office-podporu-formatu/178336/
Dostupnost aplikací je v Linuxu velmi špatná, viz opět příspěvek linkovaný výše. Centrální repozitář není realistický. Pro Windows je tolik aplikací, že by repository muselo mít velkou spoustu TB. V případě Linuxu je hřebíčkem do rakve fakt, že každou aplikaci je nutné připravit pro každé distro a každou jeho verzi (Mandriva x, Mandriva x+1, OpenSuSE x, OpenSuse x+1, Ubuntu x, Ubuntu x1). Balíčkování, závislosti a snadná instalace končí, jakmile balíček není dostupný. V praxi navíc distra mají řadu balíčků bez popisu (nebo je popisem jen název balíčku), a po instalaci se balíček nijak neprojeví v GUI (pro uživatele instalace nemá žádný výsledek, protože nezná příkaz, kterým by balíček použil). A samozřejmě dostupnost produktivních aplikací typu účetnictví apod je tragická (viz ten link).
Lokalizace Linuxu je hrozivá. Desítky procent textu jsou nelokalizované. Co lokalizované je, má ve spoustě případů úděsnou kvalitu. Na překladech je vidět, že je dělali amatéři, a navíc bez metodologie (ten samý originál se překládá různě). Nápověda často úplně chybí, nebo je bez lokalizace. Navíc nápověda ve Windows dovede odpovědět na otázky typu "change screen resolution", "add user", "change permission on file", "change swap size" apod. V Linuxu se typicky buď dozvíte něco typu "file blablalba.htm is missing", nebo nic nenajdete. Zkuste si vybrat běžné administrativní úkony, vyhledat si nápovědu v nějakém distru Linuxu, a ve Windows. Pěkně od nabídky Start, jak největší lama. A pak se svěřte s výsledkem.
Když jsme u dokumentace, máte nějakou představu, jak (nejlépe POSIX portabilně) získám z kódu seznam běžících procesů? Jak přidám z kódu lokálního uživatele, nebo uživatele do LDAP/Kerberos (ve Windows do Active Directory)? Jak z kódu získám seznam daemonů, jejich stav (běží/startuje/zastavuje se/stojí), a jak je mohu ovládat? Jak přehraji multimédia ve vlastní aplikaci? Na tyto a další otázky odpovídá MSDN, na jednom místě. Kvalita dokumentace je proti Linuxu nesrovnatelně vyšší. Nehledě na šíři a kvalitu celé vývojové platformy.
K vývoji: zkuste si spustit Visual Studio, a napsat si aplikaci, která provádí OCR nad soubory, které přibývají v nějakém adresáři, a výsledek posílá nějakém web servisu. Ve Windows vezmete kreditku, koupíte nějakou OCR komponentu, a máte OCR (stejně tak report generator, komponenty pro l=kařský imaging, nebo cokoliv jiného). Zbytek napíšete za chvilku. V .NETu, tedy s daleko méně chybami, než v C/C++. A když už nějakou chybu uděláte, skončí to zpravidla na kompilaci nebo výjimkou, a ne tím, že se aplikace bude chovat "tak nějak divně". A až budete hotový, pár kliky si vyrobte instalátor. KDevelop opravdu nestačí.
2002 - .Net zmeni programatorsky svet, giganticky skok vpred v oblasti informacnich technologii, programator potrebuje pouze instalovat visual studio ...
Rad bych se jeste zeptal, kolik vam za to plati hrubeho mesicne. Ja umim take obacs napsat provokativni kecy, mozna bych si mohl privydelat.
Za diskuze na roou mi templáři dávají veškerý MS SW zdarma, mozkové implantáty s Windows Mobile, anděly světla kteří mě hlídají před nebezpečím a svody, a ještě mi posílají peníze. Aštar to celé schvaluje, Ještírkům je třeba vyhlásit boj. Chcete také? ;)
A když už nějakou chybu uděláte, skončí to zpravidla na kompilaci nebo výjimkou, a ne tím, že se aplikace bude chovat "tak nějak divně".
Vy si to programování představujete jako Hurvínek válku. Já už za svou programátorskou praxi opravil pěknou řádku chyb a ani jednu z kategorie "chová se divně" by .NET ani jiný úžasný systém detekovat vůbec nedokázal. Dokud programy nebude psát neomylná umělá inteligence, která čte myšlenky programátora, bude tu kategorie chyb "chová se divně" pořád. .NET může zabránit jen části chyb z kategorie "padá". Chyby z kategorie "chová se divně" jsou totiž často způsobeny tím, že programátor myslí A, píše B a správně je C.
V C/C++ může vést (a vede) i překlep k memory corruption. Vůbec celý koncept práce s paměti v C/C++ je důvodem velké většiny problémů dnešního IT. Argumentovat, že chyby byly, jsou a budou, a tedy nemá smysl přijímat opatření ke snížení jejich počtu, je nesmyslné. Je to jako tvrdit, že airbagy nemají smysl, protože jsem viděl řadu nehod, kde stejně nepomohly, a žádné airbagy za řidiče stejně přemýšlet nemohou.
Zkušenější programátoři takové chyby ve střízlivém stavu dělají opravdu velmi výjimečně. Memory corruption typicky odhalíte velmi snadno, pokud víte, co máte hledat. Většinou je jedním z projevů padání, pak je to hledání o to snazší díky nástrojům jako Valgrind. Věřte mi, že za podivným chováním mnohem častěji stojí logické chyby a ne paměťové.
Vy si to programování představujete jako Hurvínek válku. Já už za svou programátorskou praxi opravil pěknou řádku chyb a ani jednu z kategorie "chová se divně" by .NET ani jiný úžasný systém detekovat vůbec nedokázal.
Tim "divnym chovanim" myslel kolega urcite chyby typu preteceni zasobniku. To se Vam v Jave a NETu opravdu stat nemuze.
> Tim "divnym chovanim" myslel kolega urcite chyby typu preteceni zasobniku. To se Vam v Jave a NETu opravdu stat nemuze.
Přetečení zásobníku? To jsem viděl naposledy v Céčku. V C++ se mi to tedy nikdy nestalo. Ale možná Microsoft ukládá data ve std::string na zásobník místo na haldu.
> Kvalita dokumentace je proti Linuxu nesrovnatelně vyšší
Mozna tak programatorske dokumentace. Ale kvalita uzivatelske dokumentace je ve Windows (alespon podle mych starych zkusenosti) dost tragicka. Ta je zaplavena banalitama, ktere mi prijdou jasne, a dulezite veci tam bud nejsou, nebo je tam pres same banality clovek nenajde. Klice v registrech pak vetsinou nejsou dokumentovane vubec.
V Linuxu je situace velmi ruzna, ale zakladni nastroje z GNU jsou dokumentovany vyborne a z bohate nabidky software je vetsinou mozne vybrat takovy, ktery ma spickovou dokumentaci (coz je duvod, proc preferuji exim pred postfixem).
Budu se opakovat, ale přesto: vyberte si pár běžných úkonů typu "change swap size", "add user", "change screen resolution", a zkuste si vyhledat nápovědu v nějakém distru Linuxu (nejlépe z GUI, od nabídky Start). Pravděpodobně nenajdete vůbec nic. Ve Windows najdete, co hledáte (a s každou verzí je to lepší). Klíče v Registry se nastavují pomocí GUI. Kde máte do Registry zasahovat ručně, máte i popis daných hodnot.
Základní nástroje GNU jsou dost o ničem. Zkuste ve Windows napsat "if /?", nebo "for /?". Dostanete nápovědu. Jenže ta je v GUI celkem k ničemu. A tím se dostáváme zpět k prvnímu odstavci.
> Budu se opakovat, ale přesto: vyberte si pár běžných úkonů typu "change swap size", "add user", "change screen resolution",
Napoveda je v Linuxu proste jinak organizovana. Takovehle 'ukolove' napovedy jsou sepsane v podobe HOWTO dokumentu. Staci si vybrat vhodny HOWTO dokument a precist si ho.
Ve Windows se clovek musi prokousat radama typu 'Zkontrolujte, zda je tiskarna zapojena do elektriny' ci 'Zkontrolujte, zda je zapojen ethernetovy kabel do pocitace', ktere v dokumentaci k operacnimu systemu nemaji co delat.
> Klíče v Registry se nastavují pomocí GUI.
A kdyz napisi argumenty, proc je lepsi pouzivat textove konfiguraky nez GUI, tak odpoved je, ze stejnych vyhod je mozne docilit primou editaci registru, kdyz pak chci primo editovat klice v registru, tak dokumentace je jen k volbam v GUI. To v Linuxu mam oboji zaroven - vyhody editace konfguraku, ktery byva dobre dokumentovan.
> Zkuste ve Windows napsat "if /?", nebo "for /?". Dostanete nápovědu.
Obvykle velmi povrchni a prehledovou (zhruba jako v Unixu 'prikaz --help'). Je ve Windows podrobna napoveda k prikazum na urovni manu?
Nápověda je v Linuxu organizovaná tak, že špatně. V nápovědě KDE se dočtu o tom, jak změnit tažením myší velikost okna, ale o běžných úkolech se nedočtu nic. HOWTO nenajdu, protože honápověda neobsahuje.
Ve Windows máte mimo jiné postupy pro troubleshooting. A zkontrolovat, jestli je tiskárna v zásuvce, je celkem podstatné. Lidé z helpdesku by vám o tom mohli vyprávět. Byl jsem svědkem toho, jak uživatel měl stažený jas na monitoru na nulu, a volal helpdesk, že počítač nejde (a co je na monitoru? nic? ani po resetu?) :)
Nejsou žádné relevantní důvody, proč by textové konfiguráky měly být lepší, než GUI. Nebo jsem takové nikdy neslyšel.
> Nápověda je v Linuxu organizovaná tak, že špatně. V nápovědě KDE se dočtu o tom, jak změnit tažením myší velikost okna, ale o běžných úkolech se nedočtu nic. HOWTO nenajdu, protože honápověda neobsahuje.
Nápověda je v Linuxu organizovaná velmi přehledně, přičemž (např. v KDE) není problém v jedné aplikaci najít dokumentaci k jiné (nebo v K Menu zvolit Nápověda a vybírat). Běžné úkoly jako je změna velikosti swapu jsou i v nápovědě KDE (mezi manuálovými stránkami).
> Ve Windows máte mimo jiné postupy pro troubleshooting. A zkontrolovat, jestli je tiskárna v zásuvce, je celkem podstatné. Lidé z helpdesku by vám o tom mohli vyprávět. Byl jsem svědkem toho, jak uživatel měl stažený jas na monitoru na nulu, a volal helpdesk, že počítač nejde (a co je na monitoru? nic? ani po resetu?) :)
Nápověda ve Windows mi přišla jako vhodná pouze pro troubleshooting. Ale v tom je o dost lepší než ta v Linuxu.
> Nejsou žádné relevantní důvody, proč by textové konfiguráky měly být lepší, než GUI. Nebo jsem takové nikdy neslyšel.
Dá se u registrů nějak nastavovat fine-granted permissions? Třeba aby některý uživatel měl právo měnit registry v některé části (např. podklíč HKLM\Software\Microsoft\Windows\CurrentVersion\Run)? Dá se část registrů (podklíč) nastavit read-only? U textových konfiguráků to lze poměrně snadno.
> Nejsou žádné relevantní důvody, proč by textové konfiguráky měly být lepší, než GUI.
- konfiguraky mohu snadno zalohovat ci prenaset z jednoho pocitace na jiny.
- konfiguraky mohu sdilet s ostatnimi uzivateli (emailem, vystavenim na webu).
- upravu konfiguraku mohu nekomu nadiktovat do telefonu a on ji bude schopen provest, aniz by znal cokoliv o danem programu (staci aby ovladal textovy editor). Oproti tomu postup v GUI nejsem schopen po pameti presne popsat, i kdyz jsem ho mnohokrat delal.
- pokud me neco zajima o nejake volbe v konfiguraku, tak jeji jmeno mohu snadno vyhledat v dokumentaci nebo vygooglit. Pokud me neco zajima o nejake volbe v GUI, tak se to googli o dost hure.
- pri konfiguraci mohu vyuzivat moznosti editoru (vyhledavani, nahrazovani), v GUI abych hledal danou polozku rucne.
- u komplikovanych konfiguraku je moznost jejich generovani skriptem z jednodussich konfiguraku navrzenych pro specifickou situaci.
- je explicitne oddelene pouzivani programu od jeho nastavovani - tim se software chova deterministicteji a tedy predvidatelneji. U GUI casto neni jasne, jestli dana volba je aktualni volba, nebo ma vliv na persistentni konfiguraci. U konfiguraku diky jejich explicitnosti ma uzivatel konfiguraci vic pod kontrolou.
- Kupodivu i Registry můžete zálohovat či přenášet z jednoho počítače na druhý. V celku (celý hive), nebo po kouskách (soubory .reg).
- Obdobně i Registry lze posílat emailemm, celý hive (byť bych to vzhledem k objemu nedoporučoval), nebo vybraný kousek.
- Úpravy nastavní v GUI lze distovat po telefonu celkem dobře. Hlavně je ale pravděpodobné, že to nebude třeba, prtože druhá strana najde co potřebuje v GUI.
- V GUI máte typicky help, takže nic googlit nemusít. Když už googlit chcete, máte v GUI popisky. Pokud umíte v Google používat uvozovky, nemáte problém.
- Vyhledávat a nhrazovat v konfiguraci je velmi neobvyklý úkol (kdy jste naposledny prováděl search/replace k konfiguráku KMailu nebo OpenOffice?). Ale máte možnost to udělat přímo v Registry.
- Obsah Registry můžete též generovat skriptem. Buď primitivně tak, že vygenerujete soubor .reg, který poté naimportujete, nebo lépe tak, že vytvoříte konfiguraci rovnou v Registry.
- GUI musí být kvalitně napsané, abyste věděl, co vlastně nastavujete.
Zeptal bych se: kdy jste naposledy ručně zakládal nebo editoval konfigurák KMailu, OpenOffice, FireFoxu, xmms nebo mplayeru? A kdy jste je nechal založit aplikaci, nebo dělal změny v konfiguraci přes GUI? Zamyslete se nad tím.
"kdyz napisi argumenty, proc je lepsi pouzivat textove konfiguraky nez GUI, tak odpoved je, ze stejnych vyhod je mozne docilit primou editaci registru, kdyz pak chci primo editovat klice v registru, tak dokumentace je jen k volbam v GUI. To v Linuxu mam oboji zaroven - vyhody editace konfguraku, ktery byva dobre dokumentovan."
K ostatnim bodum jen:
> Hlavně je ale pravděpodobné, že to nebude třeba, protože druhá strana najde co potřebuje v GUI
Co znam nektere laiky, tak ty nejsou schopni si ve Windows ani nastavit IP adresu, pokud jim presne nerikas, co maji delat.
> Vyhledávat a nhrazovat v konfiguraci je velmi neobvyklý úkol
Nahrazovat mozna ano, ale vyhledavat je docela obvykle. Napriklad nedavno jsem si chtel nastavit v prohlizeci proxy a trvalo mi docela dloouho, nez jsem prislusnou volbu v tech zalozkach a podmenu nasel. Kdyby to bylo v konfiguraku, tak proste dam vyhledat "proxy" (bud v konfiguraku nebo v napovede) a mam to.
> Zeptal bych se: kdy jste naposledy ručně zakládal nebo editoval konfigurák KMailu, OpenOffice, FireFoxu, xmms nebo mplayeru?
Z vyse zminenych programu pouzivam akorat mplayer, ktery jsem konfiguroval tim, ze jsem si napsal shellovy alias (nebo mozna funkci, ted nevim) spoustici mplayer s pozadovanou mnozinou parametru.
Tipuji, ze vetsina desktopovych programu, ktere pouzivam, konfiguruji editaci textovych konfiguraku (napr. mutt, rxvt, sawfish, bash).
"Co znam nektere laiky, tak ty nejsou schopni si ve Windows ani nastavit IP adresu, pokud jim presne nerikas, co maji delat."
Co znam nketere laiky, tak ty nejsou schopni si v Linuxu ani nastavit IP adresu, pokud jim presne nerikas, co maji delat. A problem je, pokud maji jine distro nez ty. Pak jim muzes rikat co maji delat a jim je to stejne prd platne.
Pro export a import částí Registry nepotřebujete popis k hodnotám. Zbytek můžete udělat z GUI.
Také znám různé lidi. A když jsme u IP adresy, by default Windows použijí DHCP. Pokud DHCP server není, použije se Automatic Private IP Addressing, takže se spolu bez nastavování domluví i počítače propojené twisted pair kabelem.
V důsledku uživatel IP adresu nastavuje jen výjimečně. V GUI jí změní triviálně ve vlastnostech spojení (to si většina lidí zapamatuje lépe, než příkaz a jeho syntaxi, navíc se to dá najít v GUI nebo v nápovědě), na command line existuje příkaz netsh.
Většina uživatelů Linuxu konfiguruje své desktopové aplikace z GUI, a konfiguráků se ani nedotkne. Samozřejmě pokud bash a mutt považujete za desktopové aplikace, je vaše deformace již příliš těžká ;)
V čisté instalaci Firefoxu jako první věc otevřu adresu about:config a nastavím většinu voleb podobně, jako bych editoval přímo konfigurační soubor.
U MPlayeru jsem si psal vlastní filtr obrazu (deinterlacing a podobné vychytávky).
U GVIMu jsem si upravoval detekci typu souborů přímo v konfiguračních souborech.
U her založených na Quake enginech spustím hru, po najetí menu jí vypnu, otevřu vygenerovaný konfigurační soubor, vložím svá oblíbená nastavení, a pak teprve jdu hrát.
> Zkuste se podívat na ihned.cz, zpravy.idnes.cz apod., a fulltextem vyhledat Linux. Možná budete překvapen.
Naprostá většina se Linuxu netýká, pouze se v nich nachází (jako je ten Asus Eee).
> Celkový koncept Linuxu je unixový. Tedy tty, command line, vi, hromada utilit, GUI jako nadstavba která může a nemusí být. GUI je mizerné, pro administraci je v Linuxu opravdu lepší command line. Ve Windows je lepší používat GUI, i když lze totéž dělat i z command line.
No, nejsem úplně seznámený s PowerShellem, takže v tom posledním nevím. GUI v Linuxu už dávno není mizerné, spousta věcí se dá nastavovat i přes webový server (dokonce tak lze instalovat nebo aktualizovat balíčky), jediná věc, co zatím chybí, je X server s možnostmi měnit parametry za běhu. Alfa verze ale již existuje.
> Dostupnost aplikací je v Linuxu velmi špatná, viz opět příspěvek linkovaný výše. Centrální repozitář není realistický. Pro Windows je tolik aplikací, že by repository muselo mít velkou spoustu TB. V případě Linuxu je hřebíčkem do rakve fakt, že každou aplikaci je nutné připravit pro každé distro a každou jeho verzi (Mandriva x, Mandriva x+1, OpenSuSE x, OpenSuse x+1, Ubuntu x, Ubuntu x1). Balíčkování, závislosti a snadná instalace končí, jakmile balíček není dostupný. V praxi navíc distra mají řadu balíčků bez popisu (nebo je popisem jen název balíčku), a po instalaci se balíček nijak neprojeví v GUI (pro uživatele instalace nemá žádný výsledek, protože nezná příkaz, kterým by balíček použil). A samozřejmě dostupnost produktivních aplikací typu účetnictví apod je tragická (viz ten link).
Máte pravdu, v Linuxu není sto různých správců souborů, jen asi deset (a tak je to se všemi ostatními aplikacemi). Dependency hell je poměrně nešťastný, ale úplně stejné to je ve Windows, i tam se střídaly různé verze různých knihoven (a zase to není tak hrozné, balíček pro Mandrivu x v Mandrivě x+1 i v SUSE y ze stejné doby s největší pravděpodobností fungovat bude). Pokud potřebuji nějaké to účetnictví, tak sáhnu po Wine. Jediné, co v Linuxu opravdu chybí, je, jak jsem již psal, CAD.
> Lokalizace Linuxu je hrozivá. Desítky procent textu jsou nelokalizované. Co lokalizované je, má ve spoustě případů úděsnou kvalitu. Na překladech je vidět, že je dělali amatéři, a navíc bez metodologie (ten samý originál se překládá různě). Nápověda často úplně chybí, nebo je bez lokalizace. Navíc nápověda ve Windows dovede odpovědět na otázky typu "change screen resolution", "add user", "change permission on file", "change swap size" apod. V Linuxu se typicky buď dozvíte něco typu "file blablalba.htm is missing", nebo nic nenajdete. Zkuste si vybrat běžné administrativní úkony, vyhledat si nápovědu v nějakém distru Linuxu, a ve Windows. Pěkně od nabídky Start, jak největší lama. A pak se svěřte s výsledkem.
Které desítky procent? Pokud vím, tak jediné, co opravdu není lokalizované, je nápověda. Problém s různými překlady je tak možná v konzoli, např. v KDE se překlady dělají metodologicky a ještě se pro jistotu ověřují.
Překlad ve Windows je opravdu profesionální, stačí se podívat, co se zobrazí ve výpisu oddílů na disku (místo oddíl je tam hlasitost). A rozhodně to není jediná chyba v překladu.
Jen tak pro zajímavost, před chvílí jsem nainstalovat microsoftí myš ve Windows XP a zjistil, že ty ovladače (i nápověda) nejsou lokalizované (a hned se mi podařilo zapnout lupu; samozřejmě v dokumentaci nic o tom, jak se vypíná, nebylo). V Linuxu ji stačilo zapojit, hned bez problému fungovala všechna tlačítka a nastavení, co ty tlačítka navíc mají dělat, jsem prováděl v přeložené aplikaci.
Ano, nápovědu má Windows nesrovnatelně lepší, i když dostat z ní kloudnou informaci stojí velké úsilí. Naproti tomu Linux má daleko použitelnější dokumentaci, bohužel nepřeloženou a s občas chybějícími stránkami.
Btw. proč v lokalizované nápovědě hledáte anglicky?
> Když jsme u dokumentace, máte nějakou představu, jak (nejlépe POSIX portabilně) získám z kódu seznam běžících procesů? Jak přidám z kódu lokálního uživatele, nebo uživatele do LDAP/Kerberos (ve Windows do Active Directory)? Jak z kódu získám seznam daemonů, jejich stav (běží/startuje/zastavuje se/stojí), a jak je mohu ovládat? Jak přehraji multimédia ve vlastní aplikaci? Na tyto a další otázky odpovídá MSDN, na jednom místě. Kvalita dokumentace je proti Linuxu nesrovnatelně vyšší. Nehledě na šíři a kvalitu celé vývojové platformy.
popen("ps -A", "r")
popen("useradd uživatel", "r") + popen("passwd uživatel", "w")
LDAP ani Kerberos nejsou POSIX
Démon je obyčejná aplikace (POSIX démony a ostatní procesy nerozlišuje); POSIX proces má jen tři základní stavy: běží / pauza (SIGSTOP) / stojí; ovládá se jako každý proces signály (HUP, TERM, KILL, ...)
Multimédia nejsou součástí POSIX, ale např. dokumentace ke xine je poměrně obsáhlá
> K vývoji: zkuste si spustit Visual Studio, a napsat si aplikaci, která provádí OCR nad soubory, které přibývají v nějakém adresáři, a výsledek posílá nějakém web servisu. Ve Windows vezmete kreditku, koupíte nějakou OCR komponentu, a máte OCR (stejně tak report generator, komponenty pro l=kařský imaging, nebo cokoliv jiného). Zbytek napíšete za chvilku. V .NETu, tedy s daleko méně chybami, než v C/C++. A když už nějakou chybu uděláte, skončí to zpravidla na kompilaci nebo výjimkou, a ne tím, že se aplikace bude chovat "tak nějak divně". A až budete hotový, pár kliky si vyrobte instalátor. KDevelop opravdu nestačí.
Ve Windows vezmete kreditku a vydáte pár desítek tisíc za jednu komponentu. V Linuxu nechám kreditku v peněžence, ale vezmu ocrad, pověsím se na FAM nebo dnotify a upload udělám přes FUSE (ftp, scp, ..., záleží na aplikaci). Za chvilku v shellu, nepotřebuji žádně obří GUI ani nic kompilovat. Anebo to udělám v .NET, Javě, Qt, C++, C, Pythonu, PHP nebo třeba ještě něčem jiném. A když nějakou chybu udělám, tak to nanejvýš skončí v debuggeru (pokud udělám chybu, že se to bude chovat divně, tak mi .NET nepomůže). No a potom si jedním příkazem (nebo v KDevelop kliknutím) vyrobím balíček. Takže stačí.
GUI v Linuxu je pořád mizerné. Totéž můžete nastavit v nástroji distra (KDE Control Center) i prostředí (YaST), ale trochu odlišně (například jedno prostředí nabídne jiné maximání rozlišení monitoru, než druhé). Nastavení provedené jedním nástrojem se přepíše spuštěním druhého nástroje, apod. Kvalitna vlastního GUI je mizerné, help není nebo je nekvalitní, a typicky není lokalizovaný (a když, tak úděsně). Změnu rozlišení za běhu měly tuším Windows 95 OSR2, X11 server je možná po 10+ letech dohoní.
Pokud potřebujete produktivní aplikaci (a to není jen účto - jsou to všechny ty aplikace, kvůli kterým uživatelé používají počítače; přehrávání mp3 abrouzdání webu to fakt není), budet se patlat s wine, což je pro uživatele nepřekonatelný problém. Mnohdy neuspějete ani vy, a i když uspějete, aplikace bude mít nejspíš řadu problémů (rychlost, chybějící funkce, pády). Otázka je, proč běžet aplikace, kvůli kterým lidé počítač používají, v emulaci. Není lepší použít původní systém?
Lokalizace chybí u nápovědy, a hromady balíčků, které jsou součástí každého distra. Lokalizace jsou často nekonzistentní, občas jsou texty ořezané apod. Chyby překladu jsou v každém produktu, ovšem distra Linuxu jsou mimořádně příšerná. K MS Mouse: utilita není k používání myši třeba; je lokalizovaná do 11 jazyků (čeština mezi nimi není).
Shell out není API, na tom se snad shodneme. POSIX ani Linux nemá API, které by vrátilo seznam procesů. Windows ano. POSIX ani Linux nemá API pro přidání uživatele (lokálního ani LDAP, ve Windows ActiveDirectory). Windows ano. POSIX ani Linux nemá API pro zjištění seznamu deamonů, zjištění jejich stavu a jejich ovládání. Windows ano. POSIX ani Linux nemá multimediální API, existují nejvýše jednotlivé utility. Windows má. Tolik k šíři platformy, a zároveň dokumentaci. Mimochodem paradoxem je, že Windows se Services for Unix jsou POSIX compliant, kdežto Linux není.
Komponenty jsou zásadní výhoda. Nevím, jak pomocí shellu a orcadu dostanete do aplikace OCR, nebo medicínský imaging, nebo pouhý report writter. V unixech jste odkázaný na úzkou platformu, pro kterou neseženete v podstatě vůbec nic. Ale ta myšlenka se shell skripty mě pobavila.
Měnit rozlišení za běhu u mě na Linuxu umí i Windows aplikace běžící pod WINE (samozřejmě pokud to rozlišení podporuje grafická karta a monitor a není zakázané v konfiguraci). Pouze mají zakázané měnit barevnou hloubku (zakázal jsem já sám). X.org má nástroj xorgcfg (nebo xorgconfig, jeden je textový, druhý grafický), který umožňuje celý konfigurační soubor naklikat včetně modeline.
Pod Linuxem mi na rok a půl starém notebooku ve WINE plynule funguje i demo Command & Conquer: Tiberium Wars. Problémy s rychlostí u kancelářské aplikace budou opravdu zanedbatelné. Na chybějící funkce jsem narazil jen jednou, a to se týkalo protipirátské ochrany jedné hry. WINE není emulátor, je to jen port Win32API knihoven a zavaděč PE souborů.
Neví, jak aplikace ve Wine, ale můj xserver v cca rok a půl starém Ubuntu měnit rozlišení za chodu neumí. Natož abych mohl za chodu připojit druhý monitor (s jiným rozlišením), prohlásit ho za primární, a odpojit ten první. Ve Windows je to věc pár kliknutí.
Jistě, když umíte opravit driver v C, asi rozchodíte i některé aplikace pod Wine. Bohužel to nevypovídá o tom, co je dobré pro zbytek lidstva. Wine není emulátor, ale compatibility layer. Jeho kompatibilita je pochopitelně omezená.
Možná to bude problém distribuce, ne X serveru. Měnit rozlišení jde například z terminálu příkazem xrandr (měl by být dostupný přes stejnojmenný balíček), v KDE to jde přes pravý klik na plochu, Nastavení pracovní plochy -> Obrazovka, kde je seznam možných rozlišení, u mě jdou nastavit okamžitě.
Zatím se veškeré problémy s rozcházením programů ve WINE daly řešit stažením správné DLL knihovny. Podotýkám, že šlo vždy o hry, s žádnou kancelářskou aplikací jsem zatím problém neměl.
>Celkový koncept je daleko lepší než koncept vycházející z jednouživatelského, k síti nepřipojeného systému, jako je Windows.
Ano, prihlaseni jako bezny uzivatel a instalace programu nebo reseni systmovych veci pres gksu je super vec. Nicmene jestli celkovy koncept je lepsi nebo horsi bych si netroufl tvrdit. Napr. jsem jeste neslysel, ze by si na Windows musel uzivatel po instalaci update nebo SP instalovat (nebo dokonce kompilovat) znova vsechny drivery. Zatimco na linuxu musim pri kazdym updatu kernelu znova kompilovat vsechny moduly.
>Dostupnost a přehlednost dokumentace? Pro nejnižší systémové programování máme manuálové stránky (lze je prohlížet i v nich snadno vyhledávat). Jsou přehledné a snadno dostupné. Různá rozšíření mají vlastní obsáhlé dokumentace (SDL, KDE, ...). Tady jsou si oba systémy rovnocenné.
Myslim si, pane kolego, ze jste MSDN jeste nevidel. To je opravdu vyborna dokumentace. Nevyrovna se ji ani jinak dobra Sun Developer Network.
> Ano, prihlaseni jako bezny uzivatel a instalace programu nebo reseni systmovych veci pres gksu je super vec. Nicmene jestli celkovy koncept je lepsi nebo horsi bych si netroufl tvrdit. Napr. jsem jeste neslysel, ze by si na Windows musel uzivatel po instalaci update nebo SP instalovat (nebo dokonce kompilovat) znova vsechny drivery. Zatimco na linuxu musim pri kazdym updatu kernelu znova kompilovat vsechny moduly.
Pokud máte povolený module versioning (ve většině distribučních jader je), tak je potřebujete překompilovat jen, pokud se změní ABI. A to se zase tak často nemění. Takže jediné, co je potřeba, je přesunout moduly do nového umístění a depmod (ano, dalo by se ošetřit, aby se to dělalo samo, těžko říct, proč to v distribucích zatím není). Na druhou stranu, v Linuxu je potřeba doinstalovat jen minimum ovladačů (a ty, u kterých je to nutné - např. nVidia -, lze často vyklikat).
> Myslim si, pane kolego, ze jste MSDN jeste nevidel. To je opravdu vyborna dokumentace. Nevyrovna se ji ani jinak dobra Sun Developer Network.
MSDN jsem viděl ve Visual Sudiu a on-line a nepřišlo mi nějak o mnoho lepší, než je dokumentace v KDevelopu.
Já si jádro kompiluji sám, mám na to skript, kde jen odklepu nové konfigurační volby. Až doběhne, jádro je připravené k použití včetně všech ovladačů a stačí jen restartovat.
MSDN je použitelné jen v kombinaci s Googlem. V tom vyhledávači přímo na MSDN čekám na výsledek půl minuty a to, co hledám, typicky najdu až někde na 4. stránce výsledků. Pak mě čeká nemilé překvapení v podobě několika nicneříkajících vět. Manuálové stránky jsou daleko přehlednější.
Mě tu někdo přesvědčoval, že ovladače mohou být zaváděný jako moduly, a není kvůli nim nutné kompilovat jádro. Já mu oponoval, že řada modulů nejde zavádět (nebo naopak nejde přikompilovat do jádra), a mnohdy se o tom člověk dozví jen tak, že to prostě nefunguje :), na což dotyčný nereagoval. Jak to tedy je?
Zlaté pravidlo pro práci s fulltexty: musíte vědět, jak se zeptat. V tom je každý systém trochu jiný. Knowledge base produktu, Wikipedia, Google, MSDN - pokaždé formulujete dotaz trochu jinak. A zatímco na Wiki řekněme link "hlava" v článku o praseti povede na článek o hlavě (část těla), v případě MSDN by vedl na článek o prasečí hlavě, což je celkem rozdíl.
MSDN je primárně desktopový produkt. Existuje i online verze, ale pro vážné použití je lepší lokální instalace (mimochodem se typicky instaluje s Visual Studiem). Stránky manu jsou proti MSDN velmi chudé (a hlavně je chudá platforma, kterou popisují).
Já kompiluji celé jádro když vyjde jeho nová verze, ne když potřebuji přidat jeden ovladač.
Pokud něco nejde přikompilovat do jádra nebo naopak nejde zkompilovat jako modul, dozví se to člověk už při konfiguraci jádra, kdy konfigurátor příslušné nastavení nedovolí. U součástí jádra je první možnost velmi výjimečná a druhá se týká jen hrstky základních věcí, které nemají nic společného s konkrétním hardwarem (podpora modulů by jako modul asi nebyla příliš užitečná).
Když jsem asi před rokem hledal popis několika knihovních funkcí z Windows XP, vysypalo na mě MSDN hromadu odkazů týkajících se Windows CE a hromadu článků z Knowledge Base. Co jsem hledal jsem našel až o několik stránek výsledků dál.
Ano, například stránka opendir(3) je proti MSDN článku o FindFirstFileEx opravdu velmi chudá. Možná to bude tím, že opendir neumí vedle své hlavní činnosti ještě vařit kávu, mýt nádobí a ani se nechystá vytírání podlahy. Přesto ale stručně říká naprosto vše, co při programování o opendir potřebuji vědět.
Ještě jendou k MSDN: nainstalujte si lokální verzi. Hledejte ve správné knihovně, nastavte si filtry.
Ano, dokumentace FindFirstFileEx je delší, než opendir. On FindFirstFileEx totiž hledá soubor, což umožňuje využít index adresáře. Opendir jen vrátí directory stream (který si potom projdete kompletně). Navíc vidíte, že FindFirstFileEx je dokumentovaný daleko podrobněji. Je snad lepší API a lepší dokumentace nevýhodou? ;)