Vlákno názorů k článku Dvě dekády s Linuxem od Hovádko - Je dojemný, jak se tady v diskusi kmeti...

Zrovna ty konfiguráky jsou lahůdka. Vyskytují se v nevím kolika formátech, přečtení jedné hodnoty znamená přečtení celého souboru, a přepsání jedné hodnoty znamená přepsat celý soubor (a spoléhat že z něj po tu dobu nikdo nebude zkoušet číst). Asi proto mají na AIXu Object Data Manager, rpm používá rpmdb, a Gnome má dconf.

Jj loliku, neni ned rozesrany registry, to se clovek ani nemusi snazit nic opravovat, ale rovnou muze zacit s celodenim reinstalem.

Jeronýmku, registry mají na rozdíl od konfiguráků last known good configuration, a Windows mají automatickou opravu startovacího prostředí.

Jiste loliku ... a ted mi ukaz aspon jednoho jedinyho cloveka, kterymu to nekdy nastartovalo ... widle maji tak dokonalej system, ze si schovavaj kazdou verzi kazdy kktiny, ma to desitky GB na disku, ale stejne nedokazkou tak trivialni vec, jako nastartovat ve stavu, v jakym byly po instalaci.

Ale je ti víš na co, když během příštích 20 hodin nainstaluje 350 akualizací, ze kterých 50 je nekompatibilních s výchozím nastavením a stovka z nich zakazuje to, co mělo být původně zakázáno by default už při release první verze (např. porty ve firewalu atd.). Takže jako by nebylo.

Jenze dalsi 150 to bude instalovat pred SP (protoze to samo neumi zjistit, ze existuje SP) a dalsich 200, az na to nainstalujes opice. A k tomu pricti jeste vsechny ostatni aplikace, ktery chces pouzivat, a je treba je patchnou taky.

Kdyz nainstalujes tuxe, tak se ti nainstali rovnou v aktualni verzi, rychlost instalace je omezena maximalne rychlosti tvy linky do netu a po startu, budes mit jak aktualni system, tak aplikace. Kdezto ty widle ti minimalne po dobu desitek hodin pobezej deravy.

Já doufám, že na Linuxu nebudu muset nikdy procházet nějaký registr a hledat, kam se do p*** zase něco zapsalo, abych to smazal, jako jsem to dělal ve Windows. Když mám dneska pochyby, zda něco není nastavené špatně (třeba po upgradeu) a nechce se mi hledat, tak smáznu celý adresář .něco a je to, program si vytvoří nový. Dokáže to i malé dítě, a nové nastavení programu je také většinou snadné. Nevím, jak to řeší uživatel Windows dnes, třeba na 8.1 ?

To bys chtel vid ... jednoduse zjistit co se zmenilo ... obycejne skopirovat par souboru a mit stroj naconfenej ... ve widlich se to dela jinak hosanku, vedecky ....

Tam si pro konfiguraci (trebas) utlouka musis nahrat nalezitou porci sablon (pro kazdou verzi zvlast) a pro kazdou verzi zvlast musis naklipat prislusny zaskrtitka, umisteny projistotu jinde v jinym poradi a neco uplne jinyho delajici.

A kdybys nahodou mel pocit, ze to je prece jasny, tak ti pak pro zjednoduseni daj sablonu spolecnou pro vic verzi (widli), kde ovsem zaskrnuti krizku znamena v jedny vezi, ze se ma vypnout a v jiny, ze se v zadnym pripade vypinat nema.

Moc fajn, hlavne kdyz tech stroju mas par stovek.

Ve Windows můžete provést export větve Registry HKCU\Software\vý­robce\aplikace a pak ji z Registry smazat. Má to úplně stejný efekt. Samozřejmě se do toho exportovaného souboru můžete dívat, a naimportovat ho zpátky u sebe nebo u někoho jiného.

Vyjma toho ale máte k dispozici Windows Easy Tranfer wizard. Na starém PC si vyberete co se má přenést, uložíte to na externí disk, a pak prostě provedete import na novém počítači. Přenesete tak účty, emaily, dokumenty, obrázky, hudbu i videa, a zvládne to i laik. A pokud to chcete naskriptovat, můžete použít User State Migration Tool.
http://technet.microsoft.com/en-us/library/hh824873.aspx

Samozřejmě aplikace na Linuxu také zapisují konfiguraci i do /etc, a některé ještě jinam (v extrému třeba do aplikačního adresáře). Práva admina aplikace vyžadují zcela výjimečně. Příkladem může být geniální Total Commander, který dlouhá léta ukládal nastavení do Program Files :)

Ad do nového počítače starý disk - to samozřejmě můžete udělat i ve Windows. Chce to mít stejný druh power managementu (APM/ACPI, už léta je všude ACPI), a nainstalovaný driver pro cílový druh řadiče. Když driver řadiče nemáte, stačí dát z instalačního média repair startovacího prostředí. Měnil jsem HW se zachováním (případně klonováním) disku vícekrát, takže vím že to funguje.

Nicméně řeč byla o přenosu dat mezi počítači, ne o přesunu disku do nového počítače. A tam existují možnosti, které jsem popsal. Jak to děláte na Linuxu? Kopírujete data ručně na command line?

Do /etc aplikace samozřejmě nic nezapisují, protože za to nemají práva. Velmi jednoduché paradigma, kdy je globální neměnná konfigurace v /etc a uživatelská v ~/.config či ~/.<app_name> je dodržováno velkou většinou aplikací. Některé starší programy ještě používají ~/.<app_name>rc. Každopádně je vždy jasně dokumentováno, kam se konfigurace ukládá a není potřeba ručně prohledávat registr a něco z něj exportovat. Dá se vůbec na Win zapsat do HKCU bez práv administrátora?

Na přenos a synchronizaci dat mezi počítači existuje armáda speciálních nástrojů, spousta z nich multiplatformních­...

Aplikace má často per-machine konfiguraci a per-user konfiguraci. Tu per-machine část ve /etc samozřejmě uživatel běžně nezapisuje, ale přesto ji můžete potřebovat občas změnit. Nakonec kdyby konfiguraci nebylo potřeba nijak měnit, asi by byla zbytečná :)

Nevím proč byste měl ručně prohledávat Registry.

Ad dá se vůbec na Win zapsat do HKCU bez práv administrátora - do HKCU\Software se zapisuje per-user konfigurace aplikací. Například naposledy použité soubory, konfigurace toolbarů, nastavení defaultního fontu atd. Co myslíte, dá se tam zapsat bez admina? :)

Ad na přenos a synchronizaci dat mezi počítači existuje armáda speciálních nástrojů - to jistě existuje. Spousta z nich nejspíš neumí přenést uživatelský účet a nastavení.

BTW o jedné věci se v diskusi o přenášení nastavení nějak nemluvilo. Pokud přenesete uživatelské nastavení na jiný stroj, a použité aplikace tam mají jinou verzi, konfigurace nemusí zafungovat.
Podobně nemusí fungovat pokud v ní máte například neplatné cesty, odkazy na chybějící fonty nebo tiskárny apod. S tím by si aplikace měla poradit, ale záleží na autorovi.
Věci holt nejsou tak jednoduché, jak se občas na první pohled zdají.

He loliku, to mi rekni, jak nainstaluju na widle drivery, kdyz mi prave chcipla deska a potrebuju ji vymenit? Jo, ja vim, z diskety ...

Spustit na widle repair je pak idealni cesta jak je dostat ze stavu "mozna nekdy nabehnou" do stavu "uz nikdy nenabehnou".

Mimochodem, loliku

mount -o bind / /cosi
rsync -a /cosi /kamsi

To je zalohovac co? To vis, ve widlich na to potrebuju uber nastroje, protoze polovinu souboru na bezicich ani neprectu ...

Jeronýmku, drivery se dají doinstalovat pomocí Repair Startup Environment, případně z command line.

Ad ve widlich na to potrebuju uber nastroje, protoze polovinu souboru na bezicich ani nepřečtu - to je ale je super nápad: zálohovat otevřené soubory v nekonzistentním stavu :). FYI praktická absence zamykání souborů je na Unixech celkem problém. BTW permissions při zálohování řešíte jak? Root má "elegantně" přístup ke všemu?

FYI ve Windows máme API pro zálohování, které umí mimo jiné nastavenému uživateli dát přístup ke všem souborům (včetně těch zamknutých) bez ohledu na permissions, a umí zálohovat i soubory transparentně šifrované na úrovni FS (samozřejmě v zašifrovaném stavu).

No, mě nedávno docela příjemně překvapilo, že když jsem vzal disk z tři roky starého EliteBooku a strčil ho do nového ZBooku, tak Wokna normálně najely. Asi jsou HP ovladače dostatečně univerzální a HW se moc nemění :)

Stejnej chipset. To (obcas) rozdejchaly uz win 9x. Tuxovi je ale uplne jedno, ze ho proste capnes a preneses na uplne jinej HW.

Ještě za časů NT4 nebyl problém je přesunout ze 486 na PII a ani necekly. Jediné, co muselo sedět, byl řadič disků - univerzální IDE nebo na driveru závislé SCSI. Pak ovšem přišlo plug&pray a bylo hotovo :-)

Ve Windows můžete prostě smazat větev registry HKCU\Software\vý­robce\aplikace. Je to totéž, jako když na Linuxu smáznete adresář .něco.

Ad místa kde je konfigurace - C:\Windows\apli­kacia.ini se používala naposledy ve Windows 3.x :), ProgramData per machine a nikoliv per user (stejně jako /etc), a HKLM\Software\vy­robca\aplikacia je opět par machine (stejně jako /etc). AppData máte v seznamu pěkně asi desetkrát :), a v AppData\Roamin­g\výrobce\apli­kace byste opravdu mohl najít konfiguráky - kdyby ten adresář fakt někdo fakhle používal :)

Pak píšete o CSIDL_MYDOCUMEN­TS\Vyrobca\Apli­kacia, Documents\Saved­Games\Hra, %HOMEPATH%\Vy­robca\Aplikacia apod. Tam nastavení aplikace nemá co dělat. Ovšem třeba Metro: Last Light na Linuxu také ukládá save games do ~/Steam/SteamAp­ps/common/Metro Last Light/<userid>, s tím těžko něco uděláte.

Zápis do Program Files byl pro restricted usera možný naposledy tuším ve Windows ME :). Adminovi to prošlo ještě ve WinXP, dál už ne.

Chování je dané celkem přesně: pokud se o zápis do Program Files pokusí aplikace kompilovaná před vydáním Visty (je tam tuším závislost na manifestu nebo verzi kompilátoru), přesměruje se zápis to VirtualStore. To proto aby lidé jako drahé kolega "j" nenadávali, že jsou ty nové Windows hnus, protože jim tam nefunguje aplikace kterou napsalo prase. Novější aplikace dostanou ERROR_ACCESS_DE­NIED.

Ad Cistit nieco take musi byt cisty luxus - co byste na tom chtěl čistit?

Ad C:\Windows\apli­kacia.ini sa veselo pouziva dodnes, Total Commander je len najznamensi priklad - to asi ne. I autor Total Commanderu (velmi schopný hoch :D) někdy cca v době uvedení Visty zjistil, že do adresáře Windows nemůže zapisovat ani admin, takže používá AppData. Některé exoty bohužel k lepšímu chování přinutíte jen silou.

Na Windows XP prý Total Commander dál píše do C:\Windows\win­cmd.ini, od Visty dál do ProgramData. To že aplikace hledá ini file v adresáři Windows neznamená že ho tam zakládá, navíc to může souviset s Wine.

TC nepoužívám, takže nevím, jak ho autor prasí (podle starších verzí je to neuvěřitelný bastl). Proto ani nevím jestli konfigrurák v adresáři Windows zakládá podle verze OS, nebo se ptá (jak tu někdo píše), jestli ho tam na Vistě a pozdějších Windows hledá při každém spuštění, a co s ním dělá když ho najde (možná ho chce jen migrovat do ProgramData).

Pokud si s tím chcete hrát, spusťte si Sysinternals Process Monitor na monitorování přístupů k FS, a pak TC. Ale závěrem může být jen to že autor TC je prase, což už stejně všichni víme :)

Loliku, tys ty widle vzivote nevide ze? Do program files si zapisuje tak 50% appek (a je to jeste porad lepsi nez registry) a presne tech 50% bez pristupu tam proste nefunguje. Proto ma drtiva vetsina lidi admina, protoze bez toho se porad neda delat.

Mimochodem loliku, sem zvedav, jak budes pod userem aktualizovat aplikaci bez toho, aby mel admina.

Jeronýmku, do Program Files zapisují konfiguraci jen prasata. A ani u aplikací psaných prasaty to samozřejmě není to není důvod dávat uživateli admina. Schopný administrátor totiž umí triviálně nastavit permissions na dané soubory či adresáře.

Ad od userem aktualizovat aplikaci bez... admina - zřejmě aktualizace nepoběží pod restricted userem. Založit scheduled task běžící pod adminem snad umíte i vy.

"Některé exoty bohužel k lepšímu chování přinutíte jen silou."

Inu, jak si M$ programátory aplikací vychoval, takové je má :-D

Njn, jsou to holt widle.

Když jsme programovli na škole, byl požadavek konfigurace v jednom adresáři s exáčem. Aby pak nemuseli v učebně čistit systém. Aplikačka mohla kamkoliv a dala se spustit odkudkoliv. V programu to vypadalo takhle nějak:
char* configFilePath = ChangeFileExt(ap­plication->ExePath, ".ini");
Jednoduchý a efektivní.

V produkčním prostředí, když to chtěl člověk rozdělit, tak mám pocit, že to bylo na alokování struktury, vyplnění tak pěti parametrama, předání pointru na strukturu jakési funkce, zkontrolování návratové hodnoty, vykopírování cesty, přidání jména souboru a uvolnění paměti + ošetření chyb, dohromady cca 40 řádků kódu a přečtení 50 stránek dokumentace. A při tom napsání
char* configFilePath = "C:\aplikace\con­fig.ini";
je tak lákavý, když šéf a termín tlačí...;)

Když je WinAPI složitý jak parní mlátička a zabezpečení systému to dovolí, tak není boha, který by znemožnil a potrestal občůrávání správnýho, ale překomplikovanýho postupu...

Na prvním místě máte nastavení zapisovat do Registry. Na druhém místě se vám o správu nastavení stará Framework, například .NET. A na třetím místě získat cestu na ProgramData je v C# pár znaků:
Environment.Get­FolderPath(En­vironment.Spe­cialFolder.Com­monApplication­Data)

Pokud chcete psát v C/Win32, musíte se holt smířit s tím, že je to víc práce.

Hromadu aplikaci nespustis, pokud nemaji do program files RW. Dalsi hromada apek ma svoje aktualizacni algoritmy, protoze widle nejsou schopny pouzivat repozitare, takze jim ty prava stejne dat musis, a nakonec skoncis u toho, ze nez vyrabet tisice pravidel je jednodussi dat userovi admina.

BTW: TC ti da pri instalaci uz hezkych par patku vybrat, kam to ini zapise.

Me obecne sere trebas to, ze nainstaluju gamesu (samo ne do programfiles, ale do k tomu vyhrazenymu adresare). Delam to tak z vice duvodu, ale jednim je, ze kdyz ten adresar s hrou smaznu, byl bych rad, aby bylo v trapu vse.

Jenze ... kazda jedna si dava svoje save nekam jinam. Takze pak cas od casu prolejzam ten mrdnik co je v profilu a zkoumam, proc to ma 50GB. Pochopitelne, jen promile games ma tu slusnost, ze se aspon zepta, 50% si nainstaluje sracky po celym systemu, bez ohledu na to, kam ji clovek nasmeruje.

A ze za to muze tvurce hry? Ale kdeze ... v tuxovi se mi kazda jedna zobrazi pekne ve hrach (v menu) a kazda jedna po sobe umi uklidit, a pokud ma nejaky save, tak ho najdu v ~/.hra.

Samo, bonusem sou stovky, nekdy tisice zaznamu v registrech, ktery tam zustanu uz navzdy (tedy do pristiho nabozenskeho obradu zvaneho reinstalace).

Bodel v /home me nijak neirituje, jednou za cas si vemu ~/data odsypu pryc, a zbytek smaznu ;D. Kazdopadne to nemusim hledat po celym disku vsude mozne a desit se, ze smaznu neco cim rozmrdam celej system.

Samo sem pro, vyvojarum lamat pravidelne ruce, vplejtat je do kola a podobny kratochvile.

A ta smazaná větev pak "zregeneruje", stejně jako ten .něco adresář? Navíc - já už ty Windowsy neviděl opravdu dlouho, ale pokud si vzpomínám, tak někdy byly kousky konfigurace rozeseté všude možně, to opravdu teď stačí smazat jen jednu větev? Ale stejně: otevřít editor registru a smazat větev "djfire\retio­eirto\retwert\wer­te" oproti prostému smazání adresáře? :-/

Navíc na regedit (pokud vím) je potřeba admin práva, takže i pokud už je aplikace tak sofistikovaná že ukládá nastavení v HKLM/CurrentUser (a takových je jako šafránu), tak si ji uživatel stejně nesmaže :-) Jj, není nad registry, to je pošušňáníčko něco zálohovat.

Ano, na regedit jsou potřeba práva admina. Můžete mu vnutit běh bez admina (dodáním externího manifestu s odlišným requestedExecu­tionLevel), případně můžete použít command line utilitu reg.exe.

Pokud jde o zálohování, tak to ve Windows zpravidla řešíme trochu jinak :)

Tohle je hezká stránka Windows - při tom všem snažení o co nejjednodušší ovládání aby byl člověk inženýr, když si chce smazat konfiguraci programu, který sám nakonfiguroval :-))

Zálohování konfigurace vytvořené uživatelem spolu s daty vytvořenými uživatelem mi přijde snazší, nicméně takový export a import konfigurace z/do registru a další popsané operace zase přinesou víc pracovních míst, takže nevím, co je lepší... :-)

Uživatel by neměl hrabat do konfiguráků ani do Registry. Na práci i nastavování má GUI.

Ad zálohování konfigurace vytvořené uživatelem spolu s daty vytvořenými uživatelem - jak jsem psal, zálohování stroje se řeší trochu jinak :)

"Uživatel by neměl hrabat do konfiguráků, na nastavování má GUI" - to si nemyslím. Uživatel by neměl být schopen dělat změny v systému, ale pokud si sám vytvoří konfiguraci programu, měl by mít možnost si ji i sám jednoduše (!) přenést nebo zazálohovat. Windows místo toho sledují stejný trend jako automobilový průmysl. Před 20 lety si šikovný člověk mohl opravit celé auto sám. Dneska může být šikovný jak chce, ale nevymění ani žárovku v předním světle, protože mu k reflektoru nějaký "konstruktér" umístil akumulátor, a když ho odpojí, tak může rovnou volat odtah. Jak jsem napsal, určitě to výrazně zvyšuje zaměstnanost, ale doufám, že do Linuxu takové trendy nedorazí.

Ale loliku ... a to je zajimavy, ze 80% konfiguracnich voleb nejde nastavit jinde nez v registrach, protoze na to zadny GUI zaskrtavatko neexistuje.

Obávám se, že grafické udělátko buď obslouží jen omezené množství funkcí a možností jejich nastavení, nebo je tak složité, že je odkomentování a naopak zakomentování potřebných řádků v konfiguračním souboru daleko jednodušší (pochopitelně, pokud je to editovatelný konfigurační soubor a ne binární shit a'la Microsoft).
Druhá věc je, že Windows mají tendenci nastavené úpravy měnit při restartu programu nebo systému, takže se programy musejí konfigurovat znovu a znovu (dělají to i některé verze officí). Což je, pochopitelně, velice otravné. V Linuxu se to jednak neděje a jednak by se to dalo vyřešit zákazem přepsání konfiguračního souboru.

K tomu zálohování: IMHO docela důležitou možností je, že mohu překopírovat staré konfigurační soubory do nově instalovaného systému a v 99% se nic neděje a jede to tak, jak to jelo ve starém počítači. Málokdy dojde k tak drastické změně verze programu, že konfigurace takto přenosná není. Pamatuji v podstatě akorát změnu stylu konfigurace Midnight Commanderu před několika lety.

Podobně jako konfigurace jsou v Linuxu geniálně vyřešeny kodeky - nic se neinstaluje (s rizikem totální likvidace systému, jako u windows, což se mi stalo a později od IT pracovníků komentováno jako "běžná věc"), ale jen se rozbalí a nakopírují do příslušného adresáře.

Ad grafické udělátko buď obslouží jen omezené množství funkcí a možností jejich nastavení, nebo je tak složité, že je odkomentování a naopak zakomentování potřebných řádků v konfiguračním souboru daleko jednodušší - kdy jste si naposledy upravovat konfiguraci KMailu nebo OpenOffice editací konfiguráku? Zvlášť u toho OpenOffice musí být radost se hrabat v těch cca 1.5MB XML souborů :D

Ad Windows mají tendenci nastavené úpravy měnit při restartu programu - nemají. Už několikrát jsem vám psal, že váš problém je nejspíš způsobený přepisováním konfigurace například z roaming profile apod. Ad by se to dalo vyřešit zákazem přepsání konfiguračního souboru - samozřejmě přepis konfigurace můžete zakázat i v Registry, od toho mají ACL.

Ad mohu překopírovat staré konfigurační soubory do nově instalovaného systému a v 99% se nic neděje - úplně stejně můžete překopírovat Registry nebo celý profil ve Windows. A úplně stejně to může a nemusí fungovat.

1. Od toho jsou funkce typu "najdi"
2. Je mi naprosto jedno, jakým mechanismem se to děje, pro mě jako uživatele je důležité, že se restartem obnoví původní nastavení a zmizí to, které jsem tam horko-těžko vyrobil. A že před započetím jakékoli práce s MSO nebo podobnou obludou se musím idiotsky hrabat v uživatelsky velmi nepřívětivých nástrojích na konfiguraci.
"Zákaz přepisu" vzhledem k tomu, že se na windows nedá nadefinovat "nepřepsatelnost" souboru, je to prostě nesmysl.
3. Se situací, kdy windows po jakémkoli zásahu do registrů nešly nastartovat, nebo jen do nouzového režimu, jsem se setkal opakovaně. Ani použití regeditu nedává záruku, že se editované registry nestanou překážkou v nastartování systému.
Pokud na linuxu přepíšu blbě konfigurační soubor nějakého programu, tak bez problému jede samotný systém, a tudíž to mohu nějak vyřešit. Při zachování určité minimální míry štábní kultury (= ty původní konfiguráky si v systému zazálohuji) jsem schopen obnovit stav před zásahem.

Vidím, že v podstatě "normální" vytuhnutí windows po instalaci kodeků raději ani neřešíte.

Ad 1 - takže kdy jste si naposledy upravovat konfiguraci KMailu nebo OpenOffice editací konfiguráku? :)

Ad 2 - jak jsem psal, problém není v Registry ani v produktu, ale nejspíš někde jinde v konfiguraci. Předpokládám že pokud vám někdo třeba nastaví přepisování konfigurace ze sítě na Linuxu, tak nebudete tvrdit, že je to problém způsobený použitím konfiguráků nebo použitého SW :)
Ad na windows nedá nadefinovat "nepřepsatelnost" souboru - ehm... znáte zkratku ACL?

Ad 3 - asi ne po jakémkoliv zásahu do Registry. BTW ani použití vi nedává záruku, že nezmršíte konfigurák na Linuxu. BTW2 ve Windows můžete provést Repair Startup Environment z instalačního média, případně zabootovat na command line.
Ad na linuxu přepíšu blbě konfigurační soubor nějakého programu - pokud tím programem bude systemd, tak mám dost pochybností, jestli vám pojede systém jako před tím.

Ad vytuhnutí windows po instalaci kodeků - to se mi ještě nikdy nestalo, a to Windows používám už nějaký pátek.

1. Kupodivu jsem to nepotřeboval.
2. Na Linuxu se takové prasečiny vesměs nedělají a není pro ně ani důvod.
Na Windows byl hlavní problém ten, že se muselo pracovat jako superuživatel, protože jinak spousta aplikací pod userem nejela (potřebovala zapisovat do registrů). Tím pádem veškerá bezpečnost systému v háji.
Na Linuxu pracuji jako root párkrát za měsíc, a to si hlídám, co dělám. A vím o tom, že mohu něco zmrvit.
3. Linux pochopitelně mohu opravit z cd, dvd, flešky (dříve i diskety). A je s tím podstatně méně problémů než s windowsy, kde se v některých případech pohybuji prakticky na hraně legality. Jinak z éry, kdy jsem dělal na windows nepamatuji úspěšnou obnovu systému, který šel do háje. Vždy to skončilo reinstalací.
Do konfigurace systémových souborů nemá uživatel Linuxu důvod zasahovat, protože ty zajišťují chod systému, a ne třeba barvu ikonek na ploše. Tyhle funkce jsou prostě u Linuxu dobře odděleny a ne promíchány jak Vlašský salát, jak je tomu u windows.
Že instalace kodeků je na windows velmi riskantní zásah, který může vést ke zhroucení systému, mi ex post prozradili počítačáři v práci. Totéž platilo svého času (současný stav neznám) i pro instalaci vypalovacího softu (poslední win 95, co jsem měl, šly nereparabilně do kopru po instalaci ovladačů vypalovačky).
V Linuxu jsem měl bradu až u kolen, když jsem stáhl kodeky, rozbalil, podle návodu překopíroval pod rootem do příslušných adresářů a ono všechno okamžitě jelo, jak mělo jet.

Ad 1 - přitom jste ještě před pár příspěvky psal, že klikátka jsou omezená, a editace konfiguráku je jednodušší. Zjevně to není tak úplně pravda.

Ad 2 - ano, na Linuxu nemáte roaming profiles, takže když se přihlásíte ve firmě v jinému počítači, nezkopíruje se vám profil ze sítě. Ad Windows... se muselo pracovat jako superuživatel - to máte jistě na mysli Windows 9x :)

Ad na windows nepamatuji úspěšnou obnovu systému - to ovšem nebude problém Windows.

Ad konfigurace systémových souborů nemá uživatel Linuxu důvod zasahovat - přesně jako na Windows. Jenže pokud uživatel provádí i správu stroje, což je doma dost obvyklé, tak pochopitelně mění i per-machine konfiguraci (na Linuxu obsah /etc).

Ad instalace kodeků je na windows velmi riskantní zásah - opakuji že jsem ještě neviděl takový problém. Samozřejmě jde ale o setup package třetí strany, který v principu musí mít právo měnit per-machine konfiguraci, a ten setup může napsat jakýkoliv matlák v garáži. To je pak ovšem chyba autora daného SW, nikoliv OS.

Ad instalace vypalovacího SW - pokud je vaše zkušenost z Win9x, tak se o ní nemá smysl bavit.

Ad údajná neopravitelnost - jinými slovy vy jste to neuměl opravit. Ve skutečnosti se dá opravit skoro všechno. Jsou případy kdy se to časově nevyplatí, ale ani jeden z těchto případů tak nepůsobí.

1. Konfigurovával jsem MSO a Klasik, OOo a LO jsem zatím nějak překonfigurovávat nepotřeboval, dtto kmail, tkže jsem tyhle věci neřešil. Zato jsem zasahoval do konfiguráků MC, mplayeru nebo vim.
2. Nechápu smysl roaming profiles. Pokud dělám vzdáleně na jiném počítači, tak na něm asi nedělám stejné věci, jako na tom, co mám na stole. Pokud by se mi tam nějak automaticky vnutila konfigurace z počítače, určeného na jiný typ práce, tak by mi to spíš vadilo.

Úspěšná oprava windows - pokud vím tak i naprostá většina IT profesionálů buď backupuje ze zálohy předchozího stavu, nebo instaluje de novo.

Do konfigurace systému opravdu user na Linuxu nemusí zasahovat, zato má k dispozici u většiny programů řadu možností jejich individualizace dle svých potřeb, něco takového na windows není.

Kodeky - nevím, ale když se mi to stalo, tak IT odborníci (na windows) tvrdili, že to riskantní zásah je a navíc jsou příslušné package blbě dokumentované.

Vypalování - faktem je, že instalace ovladačů vypalovačky mi shodila systém akorát na win, nikoli na Linuxu.

Neuměl jsem to opravit a v helpu, stejně při pádu systému nedostupném, jsem ani na jiném počítači relevantní informace nenašel. Ono v helpu Windows se stejně nikdy nic nedá najít. A kupovat si po 1000 - 1400 Kč knihy, které obsahují to, co by mělo být v helpu a další integrované dokumentaci, na to se tedy mohu ... (vyexkrementovat). Jejich nákupem by se ty windows prodražily možná až na dvojnásobek.
Mimochodem, na Linuxu je k dispozici i vypalování z konsoly pro případ nenastartování grafického prostředí. V době před fleškami a USB disky to byla jedna z mála možností záchrany dat z počítače. Na windows nic takového není.

Ad 1 - konfigurace větších aplikací je tak velká, že je konfigurák jako interface naprosto nevhodný. Proto na Linuxu provádíte konfiguraci z GUI, stejně jako na Windows. Výjimkou je pár "tradičních" konfiguráků, pro které jejich autoři před dekádami nenapsali žádné konfigurační GUI.

Ad roaming profiles - přihlásíte se ve firmě na jakýkoliv počítač, a všude máte svůj profil.

Ad oprava windows - pokud máte připravenou instalaci tak že trvá 30 minut, může to být rychlejší než hledat problém. To ovšem nevypovídá nic o nutnosti té reinstalace.

Ad do konfigurace systému opravdu user na Linuxu nemusí zasahovat - pokud nepotřebuje třeba změnit IP adresu :). Možnosti individualizace programů máte samozřejmě i ve Windows, a to často daleko širší než na Linuxu. Zkuste se podívat třeba na add-ins pro MS Office.

Ad kodeky - jak jsem psal, hlavní riziko vyplývá z instalace balíčku neznámého původu, který mohl napsat jakýkoliv blb nebo zlovolník, a který může udělat se systémem cokoliv. Systém kodeků je samozřejmě dokumentovaný na MSDN a v SDK.

Ad instalace ovladačů vypalovačky mi shodila systém akorát na win - některým zase instalace Linuxu bricknula mechaniku :)

Ad Neuměl jsem to opravit - to jsem předpokládal. Ad v helpu Windows se stejně nikdy nic nedá najít - ve srovnání s helpem na Linuxu je výrazně lepší. Nejen že se v něm nedozvíte jak odstranit špatný ovladač. Většinou nenajdete ani to co by tam být mělo: jak změnit rozlišení obrazovky, přepnout layout klávesnice, přidat uživatele, naformátovat disk atd.

Ad pro případ nenastartování grafického prostředí - chápu že na Linuxu je GUI nadstavbou která může a nemusí fungovat. Ve Windows to naštěstí není problém.

Díval jsem se na uživatelské konfiguráky LibreOffice, je to několik souborů, tak na dvě obrazovky. Neměl jsem potřebu do toho lézt, ale v případě potřeby bych to asi zvládl.
roaming profiles - naštěstí nepotřebuji. Navíc, pokud přecházím z počítače na počítač, tak na každém dělám úplně jinou práci a potřebuji ho mít nakonfigurovaný jinak.
IP adresa - existuje na to sice grafické udělátko, ale dá se to velice dobře udělat i editací konfiguráku. Navíc mohou starou IP adresu zakomentovat a když se na ni vrátím zpět, tak jen přehodit znak # z jednoho řádku na druhý.
Kodeky - šlo o oficiálně distribuovaný balík kodeků, doporučovaný MS
Bricklo to mechaniku, protože firmware nerespektoval normy.
V Linuxu mám spíš potíž s tím, že informace je příliš rozsáhlá a podrobná, než že by nebyla žádná (tu a tam najde člověk odkaz na web s manuálem). Prostě man (jméno programu) pomůže prakticky vždy. Na windows jsem se setkal taky s kvalitně dokumentovanými programy, ale ty nebyly od MS.
Rozlišení obrazovky, layout klávesnice atd. to jsou všechno věci, které jsem už v konfiguračních souborech upravoval.
"apropos new user" mi vyhodilo spoustu odkazů, včetně odkazu na adduser a deluser (programy pro vytvoření nového uživatele nebo skupiny a pro výmaz stávajícího uživatele nebo skupiny)
"apropos formating disk" mi podobně vyhodilo odkazy na programy manipulující s disky a oddíly, "apropos file system" mi vyhodilo odkazů ještě víc, vč odkazu na program mke2fs, který používám na formátování externích disků a flešek (pokud na nich potřebuji ext 3 file system)
Na windows sice mám jakousi volbu "formátovat", ale nemám absolutně žádnou kontrolu nad tím, co to vlastně bude dělat.

Ad konfiguráky LibreOffice, je to několik souborů, tak na dvě obrazovky - můj LibreOffice má konfiguraci v 59 souborech, velikost 1.5MB. To byste určitě dal,
GUI je pro sraby ;)

Ad oficiálně distribuovaný balík kodeků, doporučovaný MS, bricknul to mechaniku - bricknuté mechaniky jsem zatím viděl jen na Linuxu. Máte víc detailů?

Ad "apropos new user" - zapomeňte na command line a znalost příkazu. Použijte GUI, jako to dělá uživatel.
Ad na windows sice mám jakousi volbu "formátovat", ale nemám absolutně žádnou kontrolu nad tím, co to vlastně bude dělat - ehm... Zadáváte u toho FS, velikost bloku, volume label, a můžete si vybrat jestli quick format nebo full format.

Ty dílčí soubory se nějak jmenují a ty názvy jsou +- kompatibilní s tím, co se v nich dá najít. Já vím, pro windowsáka těžký nezvyk a stres.

Oficiálně distribuovaný balík kodeků mi shodil windowsy do BSOD, takže R.I.P. a nová instalace.
O bricknutí mechaniky jste se zmínil vy, šlo o mechaniky zprasené výrobcem, který nedodržoval standardy.

Proč bych používal GUI, když je command line pružnější, kvalitnější a rychlejší. Včetně toho, že příkazy mohu automaticky generovat shellem nebo třeba Perlem. Ovšem, je mi jasné, tohle na windows není, a tak jejich user musí na každou blbost shánět grafické udělátko. A když ho nemá, je v ...
A, mimochodem, kolik filesystémů můžete na windows přes vaše grafická udělátka vytvořit na médiu?

Takže z jedné dvou stránek máme najednou 1.5MB :). Ale to je v poho, protože se v tom dá v pohodě navigovat. Naštěstí je to "human readable" XML. Taková konfigurace je sice v praxi člověkem nečitelná, a znamená pomalé čtení konfigurace a ještě pomalejší zápis, ale jinak phoda jazz :)

Ad oficiálně distribuovaný balík kodeků mi shodil windowsy do BSOD - který konkrétní balík kodeků?
Ad bricknutí mechaniky - standard nedodržoval autor driveru pro Linux (a zřejmě ani autor firmwaru mechaniky), navíc šlo o od který se nikdy neměl dostat do produkce.

Ad proč bych používal GUI - protože uživatelé používají GUI.

Ad na windows není... user musí na každou blbost shánět grafické udělátko - budete se divit, ale ve Windows máme command line. Posledních pár let objektový PowerShell, který na rozdíl od unixových shellů nespoléhá na "spusť utilitu, naparsuj výstup, spusť jinou utilitu". Unixové shelly se hodí leda k práci na command line.
Abyste měl představu: ve Windows můžu pomocí PowerShellu vybrat objekty servisů (deamonů), vyfiltrovat ty které neběží, automaticky se spouští po startu a začínají na "N", a nastartovat je. Nebo vybrat okna s popisem začínajícím na "W" a minimalizovat je. Na Linuxu sci-fi.

Ad kolik filesystémů můžete na windows přes vaše grafická udělátka vytvořit na médiu - na USB klíčenkách jen jednu partition. A to záměrně, protože USB klíčenka je pro uživatele něco jako disketa. Na disku můžete mít samozřejmě partitions nepočítaně. Ne jako na RAIDu na Linuxu, kde můžete mít "velmi prakticky" jen 15 partitions, utility hází jen nesmyslné chybové hlášky, a podstatu problému se člověk dozví po pár hodinách hledání někde v dokumentaci kernelu :/

1. Jistěže klasický textový konfigurák je lepší než nějaké xml, ale chápu, že dnes programují lemry zkažené windowsy, které kvalitně něco podobného udělat prostě nedovedou (zvlášť když ten konfigurák je podkladem pro práci nějakého GUI, které neuměli naprogramovat a jen ho vložili do svého programu). Nicméně pořád je to lepší než nějaké obskurní binární soubory ve windows, do kterých se uživatel bez extra placených utilit nedostane.

2. Jméno toho balíku kodeků z druhé poloviny 90 let si, pochopitelně, nepamatuji.

Jinak u těch mechanik skutečně šlo o to, že firmware chápal běžné ovládací příkazy jako pokyn k přepsání dodaným souborem. Přičemž se jednalo o příkazy běžně OS mechanice dávané, na podobné věci jsou extra kombinace jedniček a nulk, které OS "zná" a nepoužívá je. Jednoznačně debilita výrobce.

3. (užívání GUI) Exkrement je nejlepší jídlo. Miliony much to tvrdí (a s nadšením žerou).

4. Rozhodně jsem se nesetkal s tím, že by se unixové shelly daly ovládat pouze z command line. Naprostá většina z nich umí pracovat dávkově. Vaše příklady rozhodně nezahrnují nějakou smysluplnou činnost na počítači, alespoň pro běžného uživatele.

5. Ptal jsem se nikoli na to, kolik diskových oddílů umíte na windows vytvořit, ale kolik různých filesystémů jste schopen krom obligátního NTFS a FAT na vyndows udělat a obsluhovat.
Jinak 15 partitions považuji i na TB disku za zbytečně vysoký počet. Naopak, pokud mám na USB klíčence přenosný operační systém typu Knoppixu, tak zase oddělení systému, utilit a prostoru pro data uvítám velice, případně i extra partition VFAT pro komunikaci s windowsy. Zejména, pokud se to má chovat jako plnohodnotný OS.

Ad 1 - XML umožňuje hierarchickou strukturu, dá se snadno validovat proti schématu, a snadno se do něj serializují objekty. Kdybyste programoval, velmi byste to ocenil. Ad lepší než nějaké obskurní binární soubory ve windows, do kterých se uživatel bez extra placených utilit nedostane - když máte Windows, máte i regedit.

Ad 2 - firmware těch CD-ROM mechanik byl zjevně psaný pro starší verzi ATAPI bez podpory zápisu. Driver těm mechanikám vůbec neměl posílat příkaz FLUSH CACHE, protože ho nepodporovaly. To že mechaniky měly upgrade firmware pověšený na kód, který byl v pozdějších verzích specifikace ATAPI přidělen pro příkaz FLUSH CACHE, nijak neopravňuje posílání nesprávného příkazu na zařízení. Jestli tohle nevidíte jako chybu driveru (který byl mimochodem unstable a přesto se dostal do "ostrého" distra), tak je problém na vaší straně.

Ad 3 - exkrement je možná nejlepší jídlo, pro mouchy. GUI je určitě lepší interface než command line, pro uživatele.

Ad 4 - dívka je sada příkazů, tak jak jsou psané na command line. Ad příklady rozhodně nezahrnují nějakou smysluplnou činnost na počítači, alespoň pro běžného uživatele - command line je pro admina. Zjistit stav daemonu je na Unixech prakticky nemožné. A z command line pracujete pouze z command line. Zkuste si z bashe spustit LibreOffice Calc, nechat ho vytvořit dokument podle šablony, nasázet do něj hodnoty a vyexportovat ho do PDF. Samozřejmě to nejde. Jste omezený na spuštění utility a přesměrování výstupu.

Ad 5 - ve Windows umíme FAT, FAT32, exFAT, NTFS, ReFS, ISO 9660 a UDF (plus cokoliv si nainstalujete dodatečně, včetně ext2-4, HFS+ a dalších). V počtu FS na Linuxu nějak nevidím výhodu. Proč mít jeden FS který má žurnál, další který umí NFS, další co umí kvóty, další co umí kompresi atd.? Není lepší napsat jeden FS pořádně?
Ad 15 partitions považuji i na TB disku za zbytečně vysoký počet - na Unixech je takovým pěkným zvykem rozsekat disk na spoustu partitions. Když serveru provozujete pár aplikací, na těch 15 se dostanete celkem snadno. Jedním z důvodů je fragmentace, protože většina unixových FS dodnes neumí online defragmentaci.
Ad na USB klíčence... zase oddělení systému, utilit a prostoru pro data uvítám velice - jak jsem psal, USB klíčenky jsou pro uživatele jako disketa, tedy s jednou partition. Mělo by jich snad jít přimountovat i víc přes Disk Management applet, ale nezkoušel jsem to. Nějak jsem k tomu nikdy neměl důvod.

ad 1 Pamatuji doby, kdy se regedit dokupoval (nebo pirátil) a stejně nebyla žádná záruka, že se po jeho použití Windows ještě rozjedou, spíš to byla konečná.
ad 2 Vypalovačka, která má firmware jen jako čtečka, je prostě zmetek.
ad 3 :-)
Nicméně jsem toho názoru, že opouštění command line je spíš dáno nižší kvalitou uživatelů.
ad 4: (zkuste si spustit z Command Line Libre Office Calc ...) Tyhle věci dělám v (La)TeXu, a tam to, pochopitelně, jde.
ad 5: Proč víc oddílů? Minimálně proto, že když se podělá jeden, tak data z těch dalších půjdou zachránit. A spíš se podělá systémový oddíl než datový. Oddělení uživatele (home) od systému zase vede k tomu, že se do toho systémového oddílu nezapisuje tak často.
Pokud je mi známo, tak Linux automaticky defragmentuje oddíly Ext n (a možná i některé další. Ne FAT a odvozeniny a ne obskurní bastly typu NTFS, k nimž neexistuje rozumně dostupný popis. Potřebuje pouze 15 procent a něco volného místa, proto je dobré držet disky pod zaplněností na 85 %.
Pokud máte na klíčence OS a máte nastaveno bootování z USB, tak se vám pochopitelně namountuje sama při tom bootování Linuxu.

"Ve Windows můžete provést export větve Registry HKCU\Software\vý­robce\aplikace a pak ji z Registry smazat. Má to úplně stejný efekt."

vs.

"Uživatel by neměl hrabat do konfiguráků ani do Registry. Na práci i nastavování má GUI."

Aneb bez admina ani ránu. LOL :-D

"Ano, na regedit jsou potřeba práva admina. Můžete mu vnutit běh bez admina (dodáním externího manifestu s odlišným requestedExecu­tionLevel), případně můžete použít command line utilitu reg.exe."

Takže jinými slovy jako uživatel si svou konfiguraci nesmažu ani nezazálohuju, případně zešedivím, až budu prohledávat registry pomocí command line utility reg.exe a hledat, kde že ta konfigurace je :-D

"Pokud jde o zálohování, tak to ve Windows zpravidla řešíme trochu jinak :)"

Nějakými mega super extra cool udělátky, protože jednoduchá cesta neexistuje. Už jsem to tady popisoval, že reinstalace serveru s debianem (čistý upgrade) mi trvala necelé 2 hodiny včetně obnovy konfigurace a uživatelských dat. A to vše dálkově, protože mi nepřišlo nutné kvůli tomu jezdit 200 km.

Ad jako uživatel si svou konfiguraci nesmažu ani nezazálohuju - proč ne? Utility i API máte k dispozici. O zálohy celého stroje by se navíc měl starat admin.

Ad zálohování - na prvním místě restore není reinstalace, z restore setu obnovíte celý systém. Na druhém místě pokud chcete provést reinstalaci a obnovení profilu, nic vám nebrání si profil založit na nové instalaci a přepsat ho profilem ze staré instalace.

Ad místa kde je konfigurace - C:\Windows\apli­kacia.ini se používala naposledy ve Windows 3.x :), ProgramData per machine a nikoliv per user (stejně jako /etc), a HKLM\Software\vy­robca\aplikacia je opět par machine (stejně jako /etc). AppData máte v seznamu pěkně asi desetkrát :), a v AppData\Roamin­g\výrobce\apli­kace byste opravdu mohl najít konfiguráky - kdyby ten adresář fakt někdo fakhle používal :)

Pak píšete o CSIDL_MYDOCUMEN­TS\Vyrobca\Apli­kacia, Documents\Saved­Games\Hra, %HOMEPATH%\Vy­robca\Aplikacia apod. Tam nastavení aplikace nemá co dělat. Ovšem třeba Metro: Last Light na Linuxu také ukládá save games do ~/Steam/SteamAp­ps/common/Metro Last Light/<userid>, s tím těžko něco uděláte.

Na Windows mažete z HKCU\Software\vý­robce\aplikace. Na Unixech z těchto míst:
/var/users/user­name/.config/vý­robce/aplikace
/var/users/user­name/.výrobce/a­plikace
/usr/username/­.config/výrob­ce/aplikace
/usr/username/­.výrobce/apli­kace
/Users/userna­me/.config/vý­robce/aplikace
/Users/userna­me/výrobce/apli­kace
/home/username/­.config/výrob­ce/aplikace
/home/username/­.výrobce/apli­kace

A to nehovořím o ~/Steam/SteamAp­ps/common/apli­kace/uživatel a dalších specialitách.

To vizejo loliku .... uz vidim jak user hleda ..\20B91A1DE7­1869244AB57058F37DD475 a zkouma, jestli je to to, co potrebuje smazat.

Předpokládám že env variable %APPDATA% znáte :)

Jak jsme rozebírali dříve, aplikace na Linuxu mohou mít nastavení ve /etc, ~/.config, ~/.aplikace, a na spoustě dalších míst (včetně adresářů Steamu, nebo té příšerné struktury adresářů co píše Oracle). Podobně na Windows existují místa kam se má psát konfigurace, a existují i místa kam ji píšou prasata. Například Firefox svého času vtipně psal cache do roaming profile, takže když jste se ve firmě přihlásil na jiný počítač, dotahovala se vám do profilu i cache Firefoxu. Naštěstí někdo v Mozille po pár letech použil mozek, a tu cache přesunul kde má být.

Ad rozdiel medzi zadavanim retazca %USERPROFILE% a ~ - v kódu aplikace stejně použijete API, ve skriptu asi %USERPROFILE% (a ruka vám z toho neupadne). V GUI to vůbec není problém, protože se uživatel do konfigurace ručně nehrabe, a na Documents, Pictures atd. má shortcuty v Exploreru i file dialogu.

Ad MS vtipne umiestnil %USERPROFILE% prave do AppData/Roaming - ehm? %USERPROFILE% mám na C:\Users\userid, %APPDATA% na C:\Users\userid\Ap­pData\Roaming. Cache browseru patří do LocalApplicati­onData, tj. C:\Users\userid\Ap­pData\local. Konkrétní umístění adresářů jsou v předchozích verzích Windows jiná, ale to nehraje roli.

Ad ako by ste donutili uzivatelsku aplikaciu zapisovat do /etc - neříkám že bych k tomu nutil aplikaci běžící pod restricted userem. Ale předpokládám že když zakládáte nového uživatele nebo měníte konfiguraci sítě, máte konfiguraci umístěnou pod /etc. Jinými slovy aplikace mají konfiguraci ve /etc.

BTW ve Windows také restricted user nezapíše do Program Files, adresáře Windows apod. V NT4 a možná Win2K to ještě ve výchozím stavu šlo, protože byl by default aplikovaný profil s volnějšími permissions kvůli kompatibilitě s programy psaným Win9x. Ty tam sice také neměly zapisovat, ale protože neměly permissions, autoři SW to hromadně ignorovali.

Kudy podle vás vede to rozdělení mezi "systém" a "uživatelské aplikace"? Když změníte konfiguraci síťové karty z GUI, jde "systém", ale měníte ji pomocí GUI utility, která je "uživatelská", a například nastavení té utility jsou (nebo mohou být) "uživatelské"; příkladem může být seznam posledních otevřených souborů, stav okna (restored/maxi­malized) ve kterém aplikace startuje apod. Podobně Oracle RDBMS je jistě aplikace a nikoliv systém, a přitom je nastavení "systémové". A koukněte se i na RPM databázi, která je sice "systémová", ale nenajdete ji ve /etc. Některé položky ve Start Menu nebo ikony na desktopu také mohou být sdílené všemi uživateli, tedy "systémové", a jiné "uživatelské".

Ve skutečnosti totiž jde o konfiguraci per-machine a per-user.

Ve Windows je per-machine a per-user konfigurace oddělená od první verze Windows NT. Win3.x neměly oddělené uživatele, a Win9x je sice oddělovaly, ale neměly možnost o vynutit, takže to řada autorů aplikací ignorovala.
Slušně vychované aplikace do Program Files nezapisují. FYI zápisy do Program Files a HKLM se přesměrovávají na VirtualStore jen pokud aplikace píše kam nemá, a netýká se 64-bitových procesů ani aplikací obsahujících manifest (tj. cokoliv přeložené v posledních cca 10 letech). Jde o dočasné řešení zajišťující zpětnou kompatibilitu.

Pokud jde o to že je to bordel, tak samozřejmě souhlas. Ovšem koukněte se na Linux: Oracle má konfiguraci v kdo ví kolika adresářích, Lotus Domino má konfigurák v adresáři kde je executable, Steam zapisuje konfiguraci do podadresáře svého executable atd. Jistě by v případě Windows i Linuxu šlo odříznout aplikace, které se chovají nesprávně. Jenže uživatelé by pak házeli kamenem na autory OS, a nikoliv na autory aplikací.

Ad RPM DB není konfigurace - ta DB se mění jen na základě akce admina, úplně stejně jako třeba nastavení síťovky. A je společná pro všechny uživatele, takže jde jasně o per-machine konfiguraci.

Ad kde v /etc by som mal hladat zrovna Start menu - předpokládám že když nainstalujete program, objeví se ve Start Menu všech uživatelů. Minimálně ve Windows máme část Start Menu společnou pro všechny uživatele (per-machine), a k tomu může mít uživatel svoje (per-user) položky. Samozřejmě když chcete změnit ty per-machine části, potřebujete k tomu oprávnění admina. Jak to máte na Linuxu?

Ad špatné umístění konfigurace jako dosledok spatnej portacie z Windows - to se mýlíte. Například Oracle byl napsaný pro VAX/VMS, poté portovaný na Unixy, a poté až na Windows. Na Unixech odjakživa ukládá konfiguraci i logy všude možně, jen ne tam co má. Podobně nevychovaně se chová prakticky všechen komerčního SW pro Unixy. Poděkovat za to můžete autorům SW, stejně jako my jim "děkujeme" za příšernosti které dělají ve Windows.
Steam na Windows ukládá konfiguraci špatně, a podobně špatně ji ukládá i na Linuxu. Opět za tím nejsou Windows, ale autoři SW.

Na prvním místě bych chtěl vyjasnit terminologii. Per-user konfigurace se týká daného uživatele a nikoho jiného. Per-machine konfigurace je společná pro všechny uživatele na daném stroji.

Ad nastavenia RPM mozu byt spolocne kludne i pre desiatky strojov v sprave jedneho člověka - co máte namysli tím společným nastavením? To že RPM na více strojích opravdu čte (a ukládá) konfiguraci do jedné lokace? Jak na to?

Ad Unix deli konfiguraciu a aplikacne subory na tie, ktore sa za normalnych okolnosti nemenia - to máte na mysli třeba IP adresu? :)
BTW jaké máte permissions na /usr/share/X11/xor­g.conf.d, resp. /usr/lib/X11/xor­g.conf.d? Je to samozřejmě per-machine konfigurace, tedy společná pro všechny uživatele. Vašimi slovy jde o systémovou konfiguraci.

Ad aplikacne menu per-machine... XDG desktop subory sa instaluju do /usr/share/ap­plications - a co to tedy je, když ne per-machine konfigurace? Když je něco společné pro všechny uživatele na daném stroji, je to konfigurace daného stroje a nikoliv konkrétního uživatele.
Ad uzivatel ich moze overridnut - to ve Windows samozřejmě také, akorát pokd vím nemůže nic odebrat. BTW ten popis merge na freedesktop.org je ukázkou mizerně napsané dokumentace.

Ad nabootuje sa zo siete... - to je špatný začátek. Od zavádění systému ze sítě jsme ve Windows upustili. Doma to jaksi nemá smysl, a ve firmě ráno krásně (a zcela zbytečně) zahltíte síť. Navíc to vytváří zbytečnou závislost na síti, což je třeba u notebooku na nic. Daleko praktičtější je to co děláme ve Windows už skoro dvacet let: stanice je součástí AD domény, a nastavení si sama stáhne, když má k dispozici připojení k domain controlleru.

Ad xorg.conf.d - v xorg.conf je mimo jiné konfigurace monitoru a myši, která asi nebude stejná pro všechna distra. BTW xorg.conf se hledá na 12 různých místech; konfigurák Total Commanderu v adresáři Windows (který tam stejně dávno není) je proti tomu celkem nuda :)

Ad uživatel ve Start Menu nemůže ani premenovat, ani presunut, ani zmazat - jde o položky určené pro všechny uživatele, takže nemůže.

Ad XDG menu som... docela uspesne pochopil - pochopit se dá i mizerná dokumentace.

Ad /etc a spol moze byt read-only a system ma v takej situacii ma nabootovat a fungovat - pokud ho dotahujete ze sítě, tak to jednak nemá smysl, a pak jste závislý na té síti. Samozřejmě read-only konfiguraci můžete použít i ve Windows, jsou tak řešené například internetové kavárny.

Ad xorg sa medzitym naucil celkom slusnej autodetekcii - sláva. Kde se tedy dneska uchovává například nastavení rozlišení monitoru, rozmístění více monitorů apod.? Je to samozřejmě per-machine, protože to ovlivňuje všechny uživatele.

Ad snad Windows do verzie 15 zvladne okopirovat aspon zaklady XDG menu - doufám že ne :). Ve Windows je shell poněkud bohatší. Umí například folders (Fonts, Control Panels), používání COM objektů v kontextových menu, property kartách objektů atd.

Ad sa pouzije overlay cez ramdisk a /etc sa don (uz po nabootovani) stiahne - z toho asi běžící deamoni nebudou mít radost.

Read-only konfigurace se dá řešit přes ACL. Pokud nechcete modifikovat nic, dá se použít File-Based Write Filter. Ten veškeré zápisy do souborů přesměrovává na RAM disk, případně je umí selektivně pustit na disk. V praxi mi ale dost uniká, proč by desktop nebo server měl mít read-only konfiguraci. Má to smysl u internetové kavárny, možná u jukeboxu.

Ad to zvlada kazdy druhy filemanager - pokud se něco nezměnilo, tak na Linuxu máte file managery (i ostatní aplikace) z funkčního hlediska statické. Umí co umí, a žádné rozšiřování kódem třetích stran se nekoná. Pokud existují pluginy, tak specifické pro daný SW.

Ohledně fontů: uživatel je může vytvořit ze souboru, ale nemůže je instalovat pro všechny uživatele.

Ad mate pocit, ze Vam ta orezana funkcionalita prinasa v suvislosti s ponukou start daku vyhodu - koncept je jasný: co je ve Start Menu pro všechny uživatele, to všichni uživatelé vidí.

Ad FBWF - určitě je ve Windows Embedded. Na běžných Widows jsem ho neviděl. Ad taka kombinacia dost rychlo zakapala na OOM - záleží na které soubory ji použijete. Windows toho samy o sobě na disk píší poměrně málo.

Ad este aj mc ma podporu rozireni - ano, ale pokud si vzpomínám, jsou to DLL a nikoliv komponenty. Dost by mě překvapilo, kdyby cokoliv na Linuxu mělo takovou rozšiřitelnost jako Windows Explorer: custom context menu, custom folders, custom file properties, custom property card handlers, custom toolbars... Navíc to není implementované deklarativně, ale kódem.

Ad [fonty] nemoze... instalovat ani pre seba - samozřejmě může, je to jedno volání API. Fonty jsou pak použité pouze v aktuální session. Ve Windows na to nejspíš není GUI, ale je to pár řádků skriptu, z čehož by uživatelé Linuxu měli mít radost :)
http://msdn.microsoft.com/en-us/library/dd183327(v=vs.85).aspx

Ad Start Menu, inak blby jak tago - otázka je čeho chcete docílit. Ve Windows potřebujeme, aby všichni uživatelé na stroji měli nějaké položky ve Start Menu nebo na desktopu. Naopak je nežádoucí, aby si je jakkoliv měnili nebo odstraňovali; jednak to ve firmě prostě nechcete, a pak to nemá moc praktický smysl. BTW jak na Linuxu uživatelům zabráníte, aby per-machine položky menu ve své session přejmenovali nebo odstranili?

Ad som si na 90% isty, ze FBWF desktopove resp. pro edicie Windows nepodporuju - je to pravděpodobné.

Ad k elegancii "/etc ... ro" vo fstab sa to nikdy nepriblizi - ovšem protože ve /etc máte i IP adresu a hostname stroje, asi se vám špatně bude konfigurace sdílet mezi více stroji. Navíc může nějaká aplikace zkusit do /etc zapsat (třeba GUI používané pro změnu IP adresy), a můž to dopadnout špatně. To asi budou důvody, proč MS používá FBWF.

Ad mc a dll - moje chyba, měl jsem na mysli TC.
Ad custom toolbar - Windows jsou v podstatě skládačka z COM komponent, takže to není problém. COM komponenta se registruje na nějaké akce (třeba TasksItemsSelected) pro foldery daného typu, a v kódu přidá do GUI co potřebuje. Ohledně skriptů v Nautilu a dalších: minimálně Nautilus používá shell scripty, což je příšernost. Nabízí to jen omezené možnosti customizace, a je to příšerně pomalé. Ono spustit bash (nedej bože pomocí fork/exec), nakrmit ho environment variables, provést skript a naparsovat výsledek musí být nutně řádově pomalejší, než zavolat COM komponentu, která je v paměti po celou dobu, a přidá do view aplikace to co je potřeba.
http://www.nirsoft.net/utils/customexplorertoolbarsamplesmall.png

Ad per-user fonty - ve Windows jsou prostě fonty per-machine, a upřímně jsem ještě nikdy nepotřeboval je instalovat per-user. Samozřejmě si můžete triviálně napsat skript, který vám per-user fonty natáhne při přihlášení. Ad sialeny hack - volání dokumentovaného API snad není sialeny hack :)

Ad nejakeho konkretneho dovodu je nežádoucí, aby si je [uživatelé] jakkoliv měnili nebo odstraňovali [položky Start Menu] - protože si odstraní ikonu firemního informačního systému, Wordu a Excelu, a pak jim to někdo musí opravit.

Ad odoberem im prava na ~/.local/appli­cations - to si pak ale ani nepřidají vlastní položky.

Ad v kombinacii s podivne fungujucim vyhladavanim - na prvním místě se zobrazuje to, co používáte nejčastěji. Pokud párkrát spustíte Geany, bude na prvním místě. Přijde mi to celkem logické, protože po nějaké době hledání vyhodí na prvním místě to co chci nejspíš spustit. Nové programy se tuším nějakou dobu zobrazují prioritně.

Ad ako by ste pod Windowsom dosiahol rovnaky system - zkusil bych třeba shortcut zkopírovat do Start Menu uživatele, a sebrat mu permissions Read&Execute. Případně vytvořit shortcut o nulové velikosti. Případně bych hledal nějak callback na Start Menu. Ale upřímně jsem to nikdy nepotřeboval, takže jsem to nezkoušel.

Ad Nautilus podporuje minimalne shellscripty, python a .so pluginy - shellscripty jsou nutně pomalé jako slimák. Python bude možná o něco lepší, i když je pořád interpretovaný. Knihovny jsou samozřejmě správná cesta, ovšem zřejmě budou Nautilus-specific, a totéž pro ostatní shelly.

Ad aplikacia zreportuje access denied, presne, ako sa ocakava - v ideálním světě jistě ano. V praxi jistě najdete spoustu aplikací, které nepočítají s tím, že akce může selhat.

Ad ste nikdy nepracoval s grafickym programom v prostredi restricted usera - prostě při instalaci zadám heslo admina. Pokud ho nemám, musím admina poptat, aby mi fonty nainstaloval. Ale pokud jsem si všiml, někteří grafici používají font managery, které dělají přesně to API, které jsem minule linkoval.

Ad Geany pouzivam denne, zatial co na to "Get Help" som nikdy neklikol ani omylom, napriek tomu stale dostava prednost - tenhle problém jsem ještě neviděl. Zkusil bych nejprve obě položky ze Start Menu odstranit a zase je přidat (tím se reindexují). Pokud to nepomůže, dá se ještě provést rebuild indexu. Ovšem to vám reindexuje všechno, včetně dokumentů.
Samozřejmě můžete zkusit hledat, kde se drží frekvence používání položek ve Start Menu. Tohle ale záměrně nemá veřejný interface (nejspíš to bude ve Windows Search). Autoři aplikací by si totiž svoje kousky dávali vždy na první místo.

zalezi na hw, na uzivateli...

me osobne se pri upgrade ubuntu 12.10 pres 13.10 na 14.04 nerozbilo nic
na 4kusech hw... desktop/server/me­dia Atom+ION2 a 3xNB (PM1.5+Radeon, CD2+FireGL, i5+Intel) eth,wifi,bt,zvuk,v­ideo vse chodilo/chodi out-of-box ;)

takze doporucuju negeneralizovat, proste jste mel smulu a rozdhodl se jak jste chtel :)

btrw: nekomu muze vadit napsat dmesg&lsusb, nekomu zas muze vadit hledat inf&dll&sys&... k spatnemu drv ve win aby ho odstranil, zobrazovat skryte zarizeni v devicemanageru, prolejzat registry s 20znak generovanejma stringama :)

no je fakt, že něco se občas rozsype. Já jsem zatím měl štěstí, že to nebylo tak kritický, že by stroj byl nepoužitelný a vždycky to během dvou - tří týdnů někdo opravil, takže no stress.

Co se týkalo starosti o systém, tak během roku cca 50x sudo yum -y update (řekněme minuta) s prací na pozadí + po půl hodině restart, pokud se změní jádro. 1x update, ten byl asi na 2h. Restart je záležitost tří minut.
50x1+10x3+120=200 minut za rok, aktuální jsou aplikace i systém.

Za rok na widlích? 50x update systému s resetem, instalace patchů probíhá během restartu (půl hodiny je stroj mimo provoz). Cca 10x si o restart řekne antivir (tam je to tak desetiminutový výpadek). 1x za měsíc kontrola aktuálnosti SW, ruční stažení a instalace. Řekněme, že se každý měsíc aktualizuje 10 aplikací, každá tak 5 minut hledání, minuta čekání, než se widle zeptají na potvrzení, že chci instalovat, 10-15 minut chroupání disku. Ve výsledku 50*30+10*10+1­2*10*(5+1+10) = 3520 minut = 58 hodin.

I kdyby se 2x ročně něco pos... (jako že jsem tu kliku ještě neměl) a sežralo to pokaždý 10 hodin googlení, furt je tam dalších 25 hodin klidu proti widlím. Akorát je to nárazovka a není to rozprostřeno do celýho roku.

Víc strojů s Linuxem: jenom zadám příkaz, občas rychlý restart, občas rozkopírování jednoho fajlu s nastavením, který si doaldím na prvním stroji.
Víc strojů s widlema: individuální péče pro každý

Zálohy do toho nepočítám, ty bych dělal bez ohledu na systém +/- stejnou rychlostí (prostupnost sítě, rychlost disků,...).

Já jsem na to šel jinak. Vybral jsem si, co mě nejlíp sedne a přizpůsobil tomu zbytek. Holt některý věci nejsou, některý jsou lepší.

Oceňuju hlavně spouštění aplikací bez proklikávání nějakýho hloupýho start menu nebo patlání prstem po okachličkované zdi, update všeho zvolenýho jedním přílkazem, možnost restartovat jenom změněnou část, víc ploch, ale třeba i filesystém. Ono připojení hubu, kde je USB HDD a flash disk je ve widlích problém, člověk pak neví, jestli je ten HDD připojený jako G: nebo H: A stabilní rozhraní, command line stejný víc než 50 let.