Vlákno názorů k článku Ubuntu * RedHat / (Fedora - Mandrake) = DTDTDTDTDTDTDTDTDTDT od P. Cernoch - Koukam ze se tady rozproudila docela vasniva debata,...

Koukam ze se tady rozproudila docela vasniva debata, tak pridam nekolik vlastnich nazoru.

Nejsem si jisty, jestli lidi prirovnavajici popsanou hierarchii k te ve windows vedi o cem mluvi.

V tomto systemu existuje jiste usporadani pouze v zakladnim systemovem adresari a to maximalne po ciste instalaci. Jinak prakticky vsechny instalatory uzivatelskych programu hazeji vsechno do "Program Files", obcas neco do systemovych adresaru,... spolu se spoustou zbytecnych podadresaru atd. a vysledkem je podobny bordel jako v linuxu.
Jestli se tedy chci v systemu vyznat, vytvarim si vlastni zakladni pseudohierarchii, napr. adresar "Grafika" do ktere instaluji Gimp, XnView,... , adresar "Utility" pro pomocne nastroje, "Office" pro MSOffice a OOo atd.

Podobny pristup uplatnuji i v linuxu kde je mym "vernym pritelem" adresar /opt s vyse nastinenou strukturou.

Co se tyce linuxu, pouzivam jej uz par let jako svuj domaci desktop. Pouzival jsem nejaky cas v RedHat a momentalne necely rok v Suse.
Muj osobni vysledny dojem je absolutni nekonzistence v pouzivani nejakych "pravidel" a to i pri pouziti balickovaciho systemu.
Kdyz nekdy potrebuji konfigurovat program/cist dokumentaci/upravit skript/...(doplnte si co chcete) mojim typickym ukolem je:
* patrat po plne ceste k programu
* zjistit ke kteremu baliku patri
(spousta utilit je soucasti vetsi skupiny)
* vylistovani souboru obsazenych v baliku
* nalezeni toho praveho v linuxove hierarchii
* uprava toho co potebuji

Problemem je ze obcas se programy instaluji do /usr, obcas do /usr/local , obcas do /usr/share, obcas do usr/share/local, obcas do /opt a buhvi kde jeste.
Najit dokumentaci (man a info nam nejak postupem casu umira) je rovnez porod. Krome jejiho umisteni v adresari aplikace se muze navic nachazet napr. v
/usr/local/doc
/usr/share/doc
/usr/share/applications
...



Co se tyce konfiguraci:
/etc
/usr/share/etc
/usr/local/etc
adresar aplikace
...

V tomto gulasi mi pouziti (a dodrzovani) nejake logictejsi hierarchie pripada jako spasa.
Adresare jako /sbin /etc a /tmp bych zachoval - maji sva specifika a adrear na pomocne soubory je nezbytnost.
Konfiguracni soubory je mozne (pro vetsi prehled) do /etc linkovat, /etc/init/d atd. by mohlo rovnez zustat zachovano.
Adresare /System s prislusnymi podadresari a nejake rozumne cleneni adresare /Programs jsou vyborny napad.
Rovnez tak nezavisle pouziti vice verzi knihoven - na linux.cz se casto (ted napr. pro jdk 1.5) resi jak pouzit stary/novy program na nove/stare distribuci.
Pri instalaci do samostatnych adresaru pojmenovanych podle verze si soubory se stejnym nazvem nebudou prekazet a volbu pouzitych knihoven specifikujeme treba ve spoustecim skriptu pomoci promennych prostredi.
Vyhneme se tak aspon problemum kdy pri up/down(grade) za mesic zjistime ze aplikace kterou momentalne nutne potrebujeme nepracuje, protoze...

Rovnez dokumentaci a globalni konfiguracne by nebyla zbytecne roztristena. Manualove a info stranky lze linkovat do nejakeho pomocneho adresare, co treba /System/man ?

Takze se, damy a panove, nejdriv zamyslete nad tim, jak vlastne svuj linux pouzivate, co na nem delate a jak jej spravujete a jak pritom nadavate.

A az potom si muzete dovolit kritizovat pokus o (podle meho nazoru docela slusnou) napravu, protoze pocitacovy system neni jen nainstalovana databaze, PHP a apache a pripadne par skriptovacich ci jinych jazyku. Ono se to obcas pouziva i k jine praci nebo zabave!

Pouziti velkych pismen v nazvech - to si nekdo dela srandu??? Aspon bude nutne pri psani trochu premyslet :o)

Rekl bych ze Linux takto NEPRESTANE byt linuxem, jen bude pro nekoho (taky spravce) citelnejsi.

Co se tyce moznych problemu ostatnich programu, zapomeli jste snad ze skoro vsechno se konfiguruje pri ./configure a make ????!!!!
A zase dale modifikuje promennyma prostredi, v nejhorsim pripade linkama?

Tuto "spinavou" praci krome programatoru obstaravaji i tvurci distribuce, takze zachovat jednotnost neni az tak neresitelny problem.

No a jestli se aplikace nedokaze srovnat s jinym nez standardnim umistenim, tak to proste neni dobre a flexibilne napsane - o tom se, myslim, neda diskutovat - a je potreba to zmenit. (Ja tak aspon svoje programy pisi, minimalne v posledni dobe. Asi mam schopnost predvidat zmeny :-) )
Jak totiz nekdo vyse trefne poznamenal, ne vsichni maji presne tu vasi konfiguraci.

Par slov na zaver (konecne):
* nedelejte si iluze, ve windows je podobny bordel jako momentalne v linuxu
* myslim, ze uceni novych veci se spis boji ti kteri broji proti novemu napadu...
* linux po zmene hierarchie zustane linuxem, jen mozna trochu prehlednejsim!!!
* spousteni aplikaci s jinym nastavenim je (vetsinou) mozne
* jestli tak tomu neni, je asi nekde neco spatne a hodilo by se apelovat o napravu

Co jsem jeste zapomel?

> Jestli se tedy chci v systemu vyznat, vytvarim si
> vlastni zakladni pseudohierarchii, napr. adresar
> "Grafika" do ktere instaluji Gimp, XnView,... ,
> adresar "Utility" pro pomocne nastroje, "Office"
> pro MSOffice a OOo atd.

rpm (dpkg AFAIK taky) ma skupiny balicku (rpm -qg), objevujete kolo.

K tomu bordelu ve fs: neni to nahodou uzivatelem (GIGO -- garbage in, garbage out :-))?

Ano, rpm ma skupiny, ale zkousel jste se na ne poradne podivat? Kdyz pominu obcasne znasobeni skupin podle pouziteho jazyka (Grafika, Graphics - neberte mne za slovo, nepamatuji si to ted z hlavy) po instalaci novych nebo nelokalizovanych baliku, tak mi je to na dve veci.

A to z toho duvodu, ze skupina jenom popisuje dany balik, ale ne vysledne umisteni v systemu souboru.
Takze kdyz chcete zpravovat/editovat konf./cist dok. zustane vam zase jen mnou naznaceny postup.

Bordel v systemu muze byt samozrejme zpusoben uzivatelem, ale je zajimave ze situace mnou popsana je vysledkem instalace standardnich balicku distribuce. Mam osobne odskouseno RedHat a Suse takze si myslim ze aspon trochu vim o cem mluvim.
Organizaci - podle mych kriterii - mam prakticky jen v adresari /opt kde mam strukturu jaka mi vyhovuje.

Jestli vy v takove situaci nejste, tak:
* pouzivate lepsi distribuci a uprimne vam proto gratuluji a preji at vam to vydrzi
* nemate poneti o tom co je to zpravovat linuxovy desktop a pracovat v nem
* upravujete si instalaci balickovacim systemem podle sveho a tim vlastne pouzivate neco podobneho jako v clanku, tedy "nestandartni reseni" se vsemi vyhodami a problemy

:-)

Hehe, mam Slacka a co neni ze systemu mam v oddilu /data. Celkem bez problemu. A kdyz jsem zkousel rozbehnout RHIDE, mel jsem tam nekolik verzi TV, seteditu a gdb vedle sebe a ruzne jsem to kombinoval, abych toho musel co nejmin opravovat v RHIDich zdrojich (chudak se tvari nejak mrtve, ale ja se bez nej nejak neobejdu:-)

Zkuste motor a na rhide (a problemy s nim spojene) razem zapomenete - www.konst.org.ua/motor.

Tak nevím, možná jsem nenáročný uživatel, ale s rozvržením fs fakt problém nemám... třeba dělám něco špatně :-)

Mám na (svých) desktopech jak rpm a yum, tak deb a apt a většina programů co potřebuju je v balíčcích, takže instalaci nijak zvlášť neprožívám (ale jsem si celkem jistý, že do /usr/local se nic neinstaluje). Samozřejmě pár programů buď v balíčku není a nechce se mi ho vytvářet, nebo balíček sice existuje, ale potřebuju tu nejnovější verzi apod., potom mám takový program buď v /usr/local, nebo v ~/bin (tam jsou většinou jen nějaké skriptíky / malé prográmky co se mi nechtělo instalovat). V /opt nic nemám.

Když potřebuju změnit konfiguraci nějakého programu, tak mi přijde jako větší problém zjistit, co které položka v konfiguraci dělá, než kde se nachází konfigurák.

>Problemem je ze obcas se programy instaluji do /usr, obcas do /usr/local , obcas do /usr/share, obcas do usr/share/local, obcas do /opt a buhvi kde jeste.

Mám Debian a vím docela dobře, kde co je.
- v /usr/local jsou veci, které se neinstalovali z Debianích balíčků
- /usr/share - jsou sdílená data nezávislá na platformě - ikony, dokumentace apod.
- /usr/share/doc/balicek - najdu vždy nějakou dokumentaci k danému balíčku
- do /opt se neinstaluje nic

Jinými slovy se starám jen o to, co je v /usr/local o zbytek se postará systém sám. Pokud potřebuji něco v novější verzi, nainstaluju to do ze zdrojáků do /usr/local, takže není problém mít spoustu věcí ve dvou verzích, z čehož dělal autor hrozný problém.

Prave som sa chystal napisat svoj nazor. Ked som po refreshi objavil tvoj. Nemam co dodat. Uplne suhlasim. Este by som dodal - OS nie je FS. FS a hierarchicka struktura vznikla kvoli tomu aby bol poriadok v datach. To co je momentalne v OS (win aj linux) je bordel a vobec sa nedivim, ze niekto chce v tom urobit poriadok.
Vecsina koderov mi urcite da za pravdu, ze ked 20x pridavaju nieake ficurky do programu (modulu), pride cas ho cely zmazat a napisat ho od znova (alebo aspon spravit v nom reviziu) aby bol v tom poriadok. Som rad ze aspon ludkovia z gobo sa toho ujali.
Inak ak nieco funguje od 60 rokov este neznamena, ze nie je dovod to zmenit. To by sme stale mohil pouzivat parne lokomotivy, ved naco zmena ked to funguje.

co mas proti parnym lokomotivam? v indii funguju
;)

K tomu lze dodat jen ze pro pripad valecneho konfliktu jsou zakonzervovane i ty nase.

Neni to stastne zvoleny priklad :-)

proboha kde ?? :-)

>Inak ak nieco funguje od 60 rokov este neznamena, ze nie je dovod to zmenit.

Ale když už to měním, tak by to mělo mít nějaký přínos a ne to měnit jen proto, aby byla změna. Vůbec nechápu, jaká je tak velká výhoda té nové struktury.
Je to jen komsetická úprava, že místo /usr si mám pamatovat /Programs. V současném systému nevidím žádný problém, až na to, že ho člověk musí nejprve pochopit. To by ale pro admina neměl být problém a běžný uživatel by se tím neměl zabývat. Radší bych své síly upínal na menší specializované distribuce, které budou dobře chodit, než znovu vymýšlet kolo.

>> Ale když už to měním, tak by to mělo mít nějaký přínos a ne to měnit jen proto, aby byla změna.
Suhlasim.

>> Vůbec nechápu, jaká je tak velká výhoda té nové struktury.
Poriadok ??
Problem tej momentalnj je v tom, ze veci rovnakeho vyznamu casto najdete na roznych miestach.

Mam rad ked mam na disku poriadok a bol by som rad keby som nemusel kvoli zmene jedneho riadku precitat stohy dokumentov (teraz prehanam ja viem :-)))

Poradek je prave v tom jak to je!
bin je pro bezne binarky pro kazdeho uzivatele, sbin pro administratora
/ je pro vlastni system, ty nedulezitejsi veci aby to nabehlo.
/usr je pro binarky, ktere se sytemem primo souvisi, nebo jsou spravovavy balickovacim systemem
/usr/local je pro veci ktery si clovek kompili sam, nesouvisi tedy se systemem a prostym prenesenim /usr/local si premigruju vsechny tyto programy na novy system
/opt je pro instalovane prograny, tedy neco co rozbalim z archivu a placnu tam. linky odsud, pokud je potrebuju by mely vest do /usr/local
Poradek v tom je, kdo ho nevidi, at si prostuduje FHS a chvili ten system pouziva, pak ho pozna.
Jina varianta usporadani implikuje predevsim ztratu jedne z vyhod toho systemu, tedy snadnou uspravovatelnost na zaklade znalosti principu, ktere nejsou zas tak mimo misu, aby se nedaly pouzivat...

No, preco teda stale pouzivat ten sprosty TCP/IP protokol, ze :)
A naco nam je vlastne koncepcia PC/AT ? Ved je to stare uz asi 25-30 rokov.
A naco stale pisat main() {}. Ved je to stare 40 rokov.
Hmm, a preco vlastne pouzivame dvojkovu sustavu. Je to stare este viac.
A ked sa nad tym tak zamyslam, preco vlastne stale pocitame v 10kovej sustave ? To je stare cez 2000 rokov, ze :)

Takze to su asi take argumenty ... veci sa nemaju menit preto,ze sa vymysleli pred 100 rokmi, ale z inych dovodov. Ale ... miliony ludi, meniacich si mobilne telefony castejsie ako ponozky si to nemyslia. Co uz. Je to sice ich problem, odseriem si to ale ja.

Asi ste ma zle pochopili. Ja nie som za zmenu len z toho dovodu ze je tu nieco dlho. Ale kvoli tomu ze tym neustalim nabalovanim v tom vznikol bordel. A myslim, ze linux by uz v tomto fakt potreboval reviziu.

Inak 2 a 10 sustava su tu stale len preto, ze su jednoduche a nemenne. Ak by vam stale niekto menil vyznam cislic, ich podobu, alebo vztahy, tiez by ste z toho mali gulas. (Som rad ze sa o to nikto nepokusa - aspon neviem otom :-)) )

>Asi ste ma zle pochopili. Ja nie som za zmenu len z toho dovodu ze je tu nieco dlho. Ale kvoli tomu ze tym neustalim nabalovanim v tom vznikol bordel. A myslim, ze linux by uz v tomto fakt potreboval reviziu.

Ale to je asi jen proto, že ne všechny distribuce dodržují standard adresářové struktury. Takže změna těch pravidel asi nikam nepovede.

Jestli se nemylim, tak prave TCP je jen "zaklad" pro vyssi protokoly, ktere maji vlastni a asi vhodnejsi strukturu a usporadani.

TCP je v tomto pripade spis neco jako nosic, tedy jistym zpusobem zelezo na kterem bezi novejsi a modernejsi system, ktery se rovnez stale vyvyji :-))

Jestli se nemylim, tak prave distribuce je jen "zaklad" pro vyssi aplikace, ktere maji vlastni a asi vhodnejsi strukturu a usporadani.

TCP je protokol nad IP vrstvou. IPv4 nestaci potrebam sveta (predevsim proto, ze ze zacatku se adresama plejtvalo, takze Cina ma min IP adres naz alabamska universita) a IPv6 ma nezapamatovatelny adresy, takze bude mnohem hur uspravovatelny. Nicmene se zda, ze masivni podpora IPv6 nas stav zakukli a TCP, UDP, ICMP a podobnych se jentak nezbavime. Mozna by stalo za uvahu 9P/IP, jenze jeho implementace v linuxu je pomala a ve widlich nebude snad nikdy, takze jeho universalita bude asi vzdycka mala.
Nevim co si predstavujete pod pojmem vyssi protokol. Treba http je v podstate totez jako telnet, tedy jen proud znaku v TCP, ktere se stara o vsechno ostatni. Takze vyssi z hlediska, ze vyuzivaji sluzeb TCP snad...

Zrovna TCP/IP by mi pripadalo jako dobry kandidat na odchod do technologickeho duchodu. Zkuste si nekdy prostudovat napriklad Decnet.
Je smutnou pravdou, ze technologicka vyspelost neni zarukou obchodniho uspechu a byva obcas jednoduse prevalcovana rozsirenejsi technologii treba i nizsi urovne. Takovych pripadu zname bezpocet. Nicmene to rozhodne neni duvod k tomu, aby se o podobne veci lide nepokouseli, ne? Zakladem pokroku je nespokojenost a lenost.

No jo, tam je to dulezite slovicko "obchodniho".

Dyt ono FHS se taky vyvyji.Stare unixy z let 70 a 80 mely trochu jine usporadani, ale i tak se v nich da najit co clovek potrebuje.

s naprostou vetsinou pripominek souhlasim, dobre napsano

používáte standardní linuxové utility, typu:
1. which <program>
2. balíčky (apt, rpm, atd.)
3. něco jako Yast, anaconda?
??

Pak problémy mít nebudete.

Adresářová hierarchie a její relativní stálost je VÝHODOU Linuxu.

Myslim, ze stale plati co jsem psal.

which: jestli mate aktualni databazi (nebo spravnou PATH??? - asi si to pletu s locate) najdete cestu k programu.

Ale stejne musite zjistit ke kteremu baliku patri protoze treba kvuli zminene dokumentaci nebo konfiguraci potrebujete hledat soubory prislusejici k tomuto (nalezenemu) programu.

Treba prave pomoci RPM ktery umozni vyhledat
balik vlastnici danou binarku. A tento balik si pak pomoci RPM muzete "vypsat" a az v tomto vypisu hledat co potrebujete.

Nezapomente totiz ze vy casto dopredu neznate presna klicova slova resp. jmeno adresare s konfiguraci/dokumentaci a jen jednoduche which nestaci.

Prave balickovaci system (v mem pripade rpm) mi umoznuje nakonec v te "ruznorodosti" nebo "bordelu" nalezt co potrebuji a jsem za nej vdecny.

Nic to ale nemeni na tom ze v instalovani baliku je, slusne receno, silna nekonzistence a zmatek.


yast atd. - moc zatim nevim co s tim, ale co kdyz nepotrebujete jen konfigurovat spousteni systemu, pridavat a nastavovat hardware, ale jak stale opakuji, treba cist dokumentaci nebo upravovat konfiguraky k programum ktere do yast-u zahrnute nejsou?

yast vam ale mozna (myslim) muze ulehcit prave ono meneni "promennych" pro system pri pouziti nestandartnich cest a konfiguraci.

Stejne ale casto budete nucen prolezt konfiguracni soubory osobne a doladit je rucne. To je, jestli se nemylim, jeden z velmi castych argumentu prave pro linux.

Adresarova hierarchie atd. je uzasna vec, ale ne jeji soucasna podoba a nestandardnost se kterou se pouziva.

Ta nestandardnost, IMHO, je pomerne velka prave u tzv. komercnich distribuci. Kazdy si to dela po svem, kazdy trochu jinak... Ale Suse jsem nikdy nepouzival v praxi, to jsem zavrhnul po nekolika dnech, a u RedHatu jsem skoncil u 7.3 (i kdyz v RH me tak moc nepripadalo, ze by to byl nejak moc velky bordel /vyjma Xu, ale to je samostatna kapitola/), takze treba je to jinak...

nespajal by som "rpm" a "problemy mit nebudete". nie je to zdrave ;) este si asi nezazil "dependency hell" co v rpm distribuciach, v mojom pripade mandrake 10.0, nie je problem... cirkularne zavislosti su fak fasa (potrebujem baliky A, B a C. A je zavisle od C, B je zavisle od A a C je zavisle od B.... dalej nebudem popisovat). odvtedy sa rpm vyhybam...

inak struktura FS je to posledne co by nas malo trapit... uplne bude stacit, ak v adresari kazdeho usera bude defaultne adresar ".readme_now" a v nom popis struktury filesystemu a pod. ak sa nejaky user dostane tak daleko, ze toto objavi, tak to bude znamenat, ze je pripraveny, aby poznal "pravdu". :D

Clovece, nauc se, ze kdyz mas takovouhle cirkularni zavislost, tak muzes nainstalovat ABC dohromady. Navic - kdyz vis, co delas, tak muzes udelat i '--nodeps'. A kdyz nevis, tak pouzivej up2date/yum/... a nestourej se v tom, cemu nerozumis...

> potrebujem baliky A, B a C

rpm -U A B C

v čem je problém?

případně pokud jde o Mandrake: urpmi --auto A
(nainstaluje A, protože ho požadujete, C, protože na něm závisí A, a B, protože na něm závisí C)

popravdě, já bych spíš měl problém se do problému se závislostmi dostat :-)

Presne tak. Vim (alespon zhruba), jak se jmenuje balicek, ktery chci nainstalovat: urpmi jmeno a je to. Nevim, kam patri dany soubor: rpm -qf a je to. Nevim, kde je umisten soubor: rpm -ql | less a je to. Nevim, ve kterem baliku je nejaka binarka: rpm -qf `which binarka` a je to. Nastavim si cesty k main, contrib a plf a urpmi mi nainstaluje vsechno, co jako uzivatel desktopu potrebuju. Pokud ciste nahodou balicek neexistuje, "svata trojice" mi program narve do /usr/local. Kde jsou jake problemy se zavislostmi, kde je jake tezke hledani, kde je jaka nesystematicnost a v cem je vlastne problem?

Kazda alespon trosku rozumne napsana distribuce, at uz rpm-based nebo Debian, Gentoo apod. problemy za uzivatele spis resi. Gobo Linux resi akorat pseudoproblemy a zbytecne dal tristi platformu.

Moje rec. Ve Windows je taky totalni bordel v adresarich. Navic prvni, kdo porusuje veskerou logiku, je sam Microsoft, od ktereho by to naivni clovek necekal. Jenom namatkou, po instalaci SMS (System Management Server) se to vsechno nahraje do %SystemRoot%\MS\SMS, zatimco podle logiky by clovek ocekaval, ze to bud skonci nekde v %SystemDrive%\Program Files nebo v System32. %SystemRoot%\Profiles a %SystemDrive%\Documents and Settings - to je taky bomba. Ted jsem upgradoval WinNT server na Win2k a ejhle, zadne Documents and Settings - profily zustaly tam, kde byly.

Jenze Linux obecne je to same v blede modrem. Pokud nekdo obhajuje adresarovou strukturu poukazem na jeji 30tiletou historii, tak bohuzel, byla to historie plna prehmatu. Zase jenom priklad, prechazel jsem z uw-imapd na Courier imapd. K tomu se doinstalovava jeste knihovna (tusim) authlib. Oboji to skoncilo v tak obskurnich mistech...

Hodne lidi zapomina, ze BFU (taky tu zkratku nemam rad, ale tady se mi hodi) bud rozhodi jakykoli system, nebo naopak je jim jedno, kde co lezi, protoze si hraji jenom na vlastnim pisecku. Pak ale jeste existuji cosi jako BFAdministratori. Spousta firem nema mnohohlave IT oddeleni, kde je bezpecnostni manazer, postmistr, administratori toho nebo onoho programu, helpdesk, databazisti, programatori etc. etc., ale vsecno to musi obslouzit 1 clovek, v lepsim 2-3, kteri se ovsem museji umet vzajemne zastupovat :-(

Tohle ovsem Windows neresi, protoze uz jsou s Active Directory myslenkami nekde uplne jinde. BFA potrebuje maximalne jednoduchy system na servery, ktery se da nainstalovat v podstate prekopirovanim a INTUITIVNIM nastavenim zakladnich parametru. Dobre okomentovany konfiguracni soubor je lepsi, nez klikaci rozhrani, ale bohuzel, pokud je umisteny v nejakem miste, ktere si autor programu zjevne vymyslel, pak pak to celou vyhodu eliminuje.

Ale to k..a přece není problém *nixové hierarchie, ale problém toho programu a té konkrétní knihovny. Jestli to strkala kam nemá tak jste:
a) měl se na ni vybodnou a nepoužívat tu bugovou app,
b) reportovat chybu autorovi,
c) opravit chybu.
Cokoliv jiného je vaše vlastní blbost! Geniální *nixové hierarchie fs s tím chudina nemá nic co do činění. Jen tak mimochodem, jak jinak by jste chtěl třeba svazek /usr hodit ro, nebo nasadílet po síti, /etc po zkonfigurování hodit ro, /var hodit na nějakej rychlej HW a /tmp šoupnout do ramky a zálohovat jen /home. Že je to na nějakém umrněném desktopu k ničemu je zabedněnost pohledu optikou desktopu.

Hmm, Courier imapd = bugova aplikace. No vidite, a me normalne funguje :-)

To, že aplikace funguje, neznamená, že není bugová. Wokna jsou toho zářným příkladem. Když se aplikace neumí správně nainstalovat tak bugová je i kdyby fungovala přímo zázračně.

Nedelam si iluze, ze ve windows je podobny bordel, jako v linuxu. Je tam totiz daleko vetsi. Mam to stesti/smulu spravovat, nebo byt pritomen sprave povicero linuxovych i windowsovych desktopu a serveru. Je to naprosto o necem jinem. Pokud mate problemy s umistenim souboru a hledanim konfiguraku, zrejme neumite vyuzivat moznosti balickovaciho systemu. to je vse. A zkuste si mimo jine uvedeomit, ze nejsou jen uzivatelske stanice pro jednoho cloveka, ale ze jsou i terminalove stanice a dalsi reseni, ktera uspesne funguji a pracuji prava nad existujici hierarchii souboru. Pokud se vam dany system nelibi, udelejte lepsi. ale lepsi znamena mit pro to podlozene argumenty a ne jen tvrdit, ze v systemu je bordel protoze balickovaci system. a vubec pomalu mne prestava bavit ztracet cas s lidmi, kteri se domnivaji ze sezrali vsechnu moudrost. Podejte smysluplne argumenty a muzeme se bavit. driv ne.

Prave ze ten balickovaci system mi umoznuje najit co potrebuji, protoze muzu dohledat prislusne soubory. Jestli to vyznelo jinak, je to nedorozumeni protoze je to neco co skutecne v nynejsi situaci velmi ocenuji.

Zminene stezovani patri k obcas skutecne neskutecnemu (jak hezke slovne spojeni) roztristeni souboru aplikaci do ruznych mist. Proste je to ve snaze zachovat nejake zvyklosti z minulosti prilis prehnane.

Co se te vyzkousene a overene minulosti tyce - kdyby se o ni nepochybovalo a nesnazila se zmenit, tak jsme stale na stromech. Prave tyto pochyby a protesty (krome lenosti, samozrejme) jsou hnaci silou pokroku, podle mne ve vsech oblastech.

A co platilo pred 60 lety nemusi byt automaticky to nejlepsi pro dnesek, i OS a prislusny software se vyvyji. Nezapominejte navic, ze v zacatcich UNIXu byla kvuli terminum spousta veci sita horkou jehlou a zustala tak kvuli zvyklostem/obavam/nechuti menit zabehane veci.

Mimochodem, jestli nejaka terminalova stanice zavisi na pevne hierarchii systemu, tak "potes panbu". Ta by prece mela pracovat podle toho co ji naridi jeji konfigurace a server. Oboji je mozne zmenit tak aby odpovidalo aktualnimu stavu.

Pokus o nejake usporadani je mozne obcas i pozorovat:
Napriklad sdilene knihovny - nevim jak u vas, ale vsimnul jsem si ze i v /lib (nebo v /usr/lib - uz si to nepamatuji a nejsem u sveho stroje) jsou knihovny cleneny do adresaru podle typu. Proc by byl problem tam umistit vsechny prislusne soucasti vcetne dokumentace? Zmenilo by se neco?

Jen poznamka:
Vyse bylo argumentovano -ro mountovani /usr .
Zmenilo by se neco pri -ro mountovani /System ?
Stale jsou tam systemove veci, vcetne treba binarek ktere jsou jinak umisteny v /bin , /sbin nebo /usr/bin, jen je to pekne pohromade.
Myslim ze tady bylo trochu spleteno rozdeleni disku a hierarchie adresaru.


Na vasi poznamku "Pokud se vam dany system nelibi, udelejte lepsi" muzu rict jenom to ze se ji v zivote ridim. Obcas napisu nejaky software (s podle mne logictejsi hierarchii), nebo neco opravim pripadne nekomu s necim pomuzu. Muzete to rict o sobe?

A co povazujete za podlozene argumenty?
Patri mezi ne taky vlastni zkusenosti ziskane pri praci se systemem a premysleni o nem?

Vzdycky je co zmenit a vylepsit a nemusi to automaticky byt cesta do pekel. Rovnez tak pochybovani a ne jen slepe nasledovani se obcas vyplati.

Asi je to ale mysleni dane charakterem vedecke prace :-)

Když nevíte proč, tak to prostě nevíte. Nevědomostí se nechlubte, je to něco za co by jste se měl stydět a ne se tím tady ohánět. S tím vaším /System jděte k sobě na svůj umrněný desktop, ale prosím vás snažně, necpěte ho do mojí sítě, na mé terminálové servery a na moje terminály. To jako v /System budu mít lokálně jako /bin a /sbin, /Programs budu mít ro nfs sdílené a v /Programs/Local budu mít zase lokálně svoje specilitky. To je výhra jak prase proti /etc /bin /sbin tam kde vy máte /System a /usr tam kde vy máte /Programs a /usr/local tam kde by jste měl /Programs/Local. Co jste tím vlastně vyřešil? Já vám to řeknu. Začíná to na h, končí na o a má to pět písmen.

Nevim jak vy, ale kdyz neco mi neni jasne tak si o tom neco prectu (neodkazujte mne na dokumentaci, udelal jsem to) a kdyz si i potom myslim ze neco neni jasne nebo muze byt vsechno trochu jinak, tak se ptam a konzultuji to. Minimalne kvuli tomu ze lidi maji ruzne nazory a zkusenosti a ani muj napad nemusi byt idealni.

Vy to delate jinak - nekde se neco doslechnete a je to automaticky svate a nikdo nesmi pochybovat a pidit se po detailech?

Nove usporadani vam nikdo nevnucuje, pouzivejte si co vam - v pripade ze to spravujete - vyhovuje.

Nemate ale pravo povazovat to za to nejlepsi reseni pro vsechny pripady.

Jestli si vzpomenete, puvodni debata byla o aplikaci prilisne (ne)organizovanost na soub. system.
Nad hierarchii zakladniho systemu by bylo ptreba vic premyslet. Ale nevim proc u aplikaci je nutne hazet jejich ruzne casti na ruzna mista a to obcas velmi zvlastnym zpusobem.
I v pripade aktualni struktury fs plati ze kazdy program muze klidne mit vlastni adresar, treba s linkovanim binarky nekde do /usr/bin at to moc lidi nedrazdi (usetri se tak delka PATH).

Jestli chcete neco mountovat ro, stejne to (mylim se?) musi byt na jinem oddilu a je to tedy otazka spravneho nastaveni jeho velikosti. Tady jde jen o to ze veci prislusejici k dane aplikaci by byli u sebe. Je neco hrozneho na tom ze soucasne bude ro i dokumentace a konfigurace? Co tam ma kdo sahat krome spravce?
Jedinym prikazen/zmenou konf. pak zpristupnite dane aplikace se vsim co tam patri uzivateli. Treba na terminalu. Ostatni je zalezitost vhodnych prav.


PS:
Rekl bych ze tech umrnenych desktopu bude vic a vic, takze se mate na co tesit...

;-))

A vite co je nejzajimavejsi, ze vetsinu tech unixovych nesmyslu (ostatne v motivaci plan9 jsou pekne definovane) v nejake, mnohdy velmi pomrsene verzi portuje M$ do widli? Ze by se M$ rozhodl pomstit svym zakaznikum za to, ze nekdy pouzivali unix? Ze by je chtel protahnout tim neprehlednym unixovym peklem, bay teprve poznali jak byly ty 95 dokonale uzasne a genialni? Myslim ze ne, myslim, ze ac je unix opravdu zastaraly a pulka jeho konceptu je papirove mrtva, porad je to nejlepsi pouzivana koncepce a ty lepsi (jako plan9) se proste neuchytily.
Vemte Plan9 a udelejte revoluci, nad linuxem to nema smysl.

Jestli tvoje distribuce má konfiguráky jinde než v /etc tak ji nepoužívej! To není distribuce, ale paskvil. Z toho je na první pohled vidět, že je ta distribuce šita horkou jehlou a její maintaneři na tebe jako na uživatele zvysoka se..ou. Občas se kouknu v práci na stroje kolegů, kteří používaj tyhle rychlokvašky (FC, MDK, SUSE a podobnej sjrajt) a nestíhám zírat, kde všude se taky dá umístit konfigurák. Když se mě ptaj kde se co konfiguruje, tak jim vždycky odpovídám: Já to mám v /etc, ale kde to máte vy, to netuším. Debian vám nevoní, tak si to užijte!

Mam mdk 10 a konfiguraky mam v /etc. Nevzpominam si, ze bych konfigurak od nejakyho programu v /etc nenasel. V pohode je to i s Debianem (jasna vec), vzpominam si kdysi na RH, ten mam pocit byl taky /etc-ovej...
Zato ve slacku jsem se docela ztracel :)

No tak to jsi toho potřeboval konfigurovat dost málo. MDK 10 je z nich snad nejhorší. V Debianu jde všechny balíčky z oficiálních zdrojů konfigurovat v /etc a tím myslím skutečně všechny! Jo to je to deblianí Debian policy.

> No tak to jsi toho potřeboval konfigurovat dost
> málo. MDK 10 je z nich snad nejhorší.

prosil bych argumenty a ne plácání ...
co konkrétně se v Mandrake konfiguruje mimo /etc ?