Fórum Root.cz
Hlavní témata => Distribuce => Téma založeno: Miki 02. 04. 2013, 18:26:05
-
Zdravím,
rád bych vyřešil pár věcí, které mi vadí v souvislosti s Linuxem (Ubuntu). Nedávno jsem ho začal používat jako jediný systém na notebooku (do té doby jsem ho měl jen ve virtuálu, i když pravidelně využívaný).
1. Notebook má 20GB SSD disk (+ normální plotnový) a já si nainstaloval systém právě na SSD a "/home" napojil na ten plotnový. Vzhledem k tomu, že 20GB není moc, rád bych některé programy instaloval jinam než do složek v kořenovém adresáři. Jde to nějak? Zároveň bych rád zachoval automatické aktualizace těch programů i jejich viditelnost v aptitude.
2. To trochu souvisí s první otázkou. Pokud mám nějaký program, který si chci nainstalovat (je v repozitáři), ale nechci s tím zadělávat celý systém (chtěl bych si ho nainstalovat někam do home a později ho smazat). Je nějaká taková možnost? Kompilaci neuvažuju, protože to typicky znamená zároveň instalovat tuny dev balíčků a to už pak celá ta procedura trochu ztrácí smysl. Něco podobného Windowsímu Sandboxie ( http://www.sandboxie.com/ ).
3. Jde nějak zjistit, které konfiguráky v home patří k jakému programu? jsou tam pravděpodobně složky, které už dávno nejsou používané a pravděpodobně už ani nikdy nebudou (programy, které jsem si nainstaloval na zkoušku a pak smazal). Začíná jich být celkem hodně.
Díky za případné odpovědi.
-
1. V podstatě ne. Teoreticky, pokud se s tím chceš hodně s*, tak klidně můžeš místo /usr/share/program mít symlink někam na ten plotnový disk nebo mountovat přes fstab.
2. To je stejná otázka. Přečti si něco o struktuře FS.
3. Jde to zjisti podle jmen těch kofiguráků. Jsou to obyčejné soubory, takže to nemá smysl řešit (koukni na velikost, vyjma cache browseru to bude pár KB).
...chápu jak jsi na ten dotaz přišel, ale prakticky řešíš blbosti.
-
/home na pomalym plotnovym disku => prakticky nepoznas, ze tam ssd mas (krome startu, ale ten delam max 1x denne).
-
Na ostatní otázky už tu odpověď byla, odpovím jen na třetí: Ke zjištění jména balíčku slouží
$ dpkg -S název_souboru
-
Díky za odpovědi. I když jsem tak trochu doufal v něco jiného :).
1. V podstatě ne. Teoreticky, pokud se s tím chceš hodně s*, tak klidně můžeš místo /usr/share/program mít symlink někam na ten plotnový disk nebo mountovat přes fstab.
2. To je stejná otázka. Přečti si něco o struktuře FS.
3. Jde to zjisti podle jmen těch kofiguráků. Jsou to obyčejné soubory, takže to nemá smysl řešit (koukni na velikost, vyjma cache browseru to bude pár KB).
...chápu jak jsi na ten dotaz přišel, ale prakticky řešíš blbosti.
1. hmm, to je pech... proč nemá Linux něco jak Windowsy "C:/Program Files", "D:/Program Files"... (spíš řečnická otázka, tohle by asi stejně vedlo na nějaký flame :-D)
2. Tady upřímě řečeno moc nechápu tu souvislost s FS... Měl jsem na mysli, jesti prostě neexistuje nějaká možnost sandboxu pro aplikaci, abych jí odstínil od zbytku systému. Podle mě fakt perfetkní příklad tohohle je odkazovaný Sandboxie. Ten umožní programu číst z disku, ale zápisy odchytí a poznamená si je do nějaké vlastní vrstvy, takže při příštím čtení se pro ten sandboxovaný program tváří, jako kdyby byla data zapsaná normálně na disku. Něco takového by na Linuxu snad mohlo být, ne? Já to právě na Windowsech používám pro čisté zkoušení programů. Instalačku pustím v sandboxu, ona si rozkopíruje soubory a zapíše do registrů kam je libo, program vyzkouším a když už ho nepotřebuju, tak sandbox smažu a jako kdyby tam nikdy nebyl. Zároveň díky tomu, že to není žádná virtualizace, tak tam není téměř žádné zpomalení.
3. Jo... uznávám, že tohle je asi tak trochu moje úchylka, ale mám prostě rád na disku uklizeno a vadí mi, že když dám `LL`, tak se ukáže seznam složek na dvě stránky s tím, že vlastně polovina tam už nejspíš být vůbec nemusí...
/home na pomalym plotnovym disku => prakticky nepoznas, ze tam ssd mas (krome startu, ale ten delam max 1x denne).
Jak to? Já bral SSD především jako urychlení načítání kernelu a často používaných programů. K čemu by mi bylo SSD pro filmy/hudbu/cokoli-co-mám-v-home? Tam ta rychlost čtení moc podstatná není, ne?
-
Este tu chyba odpoved na
2. mám nějaký program, [...] chci nainstalovat [...] nechci s tím zadělávat celý systém
Na to tu mame chroot - nainstalujes si to v nom. Ked nechces ani vacsie prava, tak by mozno stacil fakechroot + fakeroot (za toto druhe uz nerucim).
Celkovo ale rucne spravovany "zakladny" Linuxovsky chroot casto znamena zlozitejsie aktualizacie a nasledne kopec moznych bezpecnostnych problemov. Na to je ale uz kopec nastrojov, ktore si lahko najdes (pripadne pomozu vlastne skripty alebo sa vzdas Linuxu a skusis Solaris alebo FreeBSD).
-
Díky za odpovědi. I když jsem tak trochu doufal v něco jiného :).
Doufal jsi právem, ony ty odpovědi jsou minimálně trochu diskutabilní :)
1. V podstatě ne. Teoreticky, pokud se s tím chceš hodně s*, tak klidně můžeš místo /usr/share/program mít symlink někam na ten plotnový disk nebo mountovat přes fstab.
To přeci není žádné sraní. Pokud mám distribuci, která mi např. celé Gnome instaluje do /opt/gnome, tak to je jeden symlink, který nemá na updaty prakticky žádný vliv (protože ten kořenový /opt/gnome pravděpodobně nikdo nikdy mazat nebude).
...čímž se mimochodem dostáváme k tomu, že [rýpací mód on]kdyby lidi kolem linuxu nebyli takoví frikulíni, tak by normálně fungovalo mountování /usr až po startu, že... No ale bylo mi zeširoka vysvětleno, že to prý v dnešní moderní době není potřeba. No tak není no ;) [rýpací mód off]
2. To trochu souvisí s první otázkou. Pokud mám nějaký program, který si chci nainstalovat (je v repozitáři), ale nechci s tím zadělávat celý systém (chtěl bych si ho nainstalovat někam do home a později ho smazat). Je nějaká taková možnost? Kompilaci neuvažuju, protože to typicky znamená zároveň instalovat tuny dev balíčků a to už pak celá ta procedura trochu ztrácí smysl.
Zkus nám to vysvětlit jako tříletému dítěti. Ptáš se na tohle? "Chci aby software fungoval jinak, než jak ho zkompiloval autor, ale zároveň program nechci kompilovat"? Na první pohled stupidní otázka :)
...ale ne zas tak moc. Samozřejmě to jde. Na unixech jde všechno ;) Ale pokud nevíš, jak na to, tak to nedělej, stoprocentně si přiděláš víc problémů než kolik ti to přinese užitku.
Něco podobného Windowsímu Sandboxie ( http://www.sandboxie.com/ ). [...] Měl jsem na mysli, jesti prostě neexistuje nějaká možnost sandboxu pro aplikaci, abych jí odstínil od zbytku systému.
Definuj "něco podobného". Samozřejmě existují různé způsoby, jak udělat sandbox. Je jich asi tak tisíc. Např. můžeš mít layered fs. Nebo chroot. Nebo jail. Nebo paravirtualizaci. Nebo hodinky s vodotryskem :)
Tady ale platí to samý - pokud to neumíš udělat ručně (a někdo ti neporadí totálně BFU nástroj), tak to nedělej. Až se naučíš unixoidní OS používat tak, jak ho radí používat manuál, pak teprve se pouštěj do toho, že ho budeš nějak fantasmagoricky ohýbat.
A hlavní rada: běžné použití Linuxu nevyžaduje sandbox. "Něco jako Sandboxie" na unixovém systému prostě při jeho obvyklém použití není potřeba. Na unixových systémech není zvykem, že by programy mírnyxtýrnyx kdesi v jakýchsi neviditelných registrech trousily jakýsi odpad. Pokud programy korektně instaluješ a korektně odistaluješ, nemáš co řešit. Maximálně můžeš udělat to, že program spustíš pod jiným uživatelem, než je tvůj běžný účet pro práci. V unixoidních systémech prostě problém "zapíše do registrů kam je libo" de facto neexistuje, proto taky nejsou potřeba frikulínské nástroje pro jeho řešení.
3. Jde nějak zjistit, které konfiguráky v home patří k jakému programu? jsou tam pravděpodobně složky, které už dávno nejsou používané a pravděpodobně už ani nikdy nebudou (programy, které jsem si nainstaloval na zkoušku a pak smazal). Začíná jich být celkem hodně.
Co o tomto problému říká manuál OS, který používáš? Jak je tam popsaná práce balíčkovacího systému s konfiguračními soubory? Čekáš, že hnedka, jak uvidíme "Miki", budeme vědět, že se ptáš na to, jak konfiguráky řeší Centos 6? :)
1. hmm, to je pech... proč nemá Linux něco jak Windowsy "C:/Program Files", "D:/Program Files"... (spíš řečnická otázka, tohle by asi stejně vedlo na nějaký flame :-D)
No asi tak ze stejného důvodu jako proč Windowsy nemají /dev/bpf :) Ano, máš pravdu, je to hloupá otázka. Pokud ti vyhovuje způsob, jakým mají FS rozvržený Windows (například tisíce souborů bez ladu a skladu totálně neprůhledně naházené do kontinuálně bobtnajícího C:\Windows), tak prostě používej Windows! Přesně tak snadné to je :)
3. Jo... uznávám, že tohle je asi tak trochu moje úchylka, ale mám prostě rád na disku uklizeno a vadí mi, že když dám `LL`, tak se ukáže seznam složek na dvě stránky s tím, že vlastně polovina tam už nejspíš být vůbec nemusí...
Zkusím to ještě polopatičtěji: program, který není spuštěný pod rootem, může zapisovat jenom na přesně definovaná místa. Obvykle jenom do ~user (domovská složka uživatele, který program spustil), /tmp a /var/tmp. Nikde jinde prostě nic program trousit nemůže.
Oba dva tmp se obvykle pravidelně mažou, čili na ty zapomeň. A zbyde ti jenom ~user. Čili si vytvoř uživatele "tester", vyzkoušej si pod ním program, a potom jeho home smaž. Voilá! Máme "něco jako Sandboxie" ;)
Jediný problém je s pouštěním programů, které vyžadují rootovská oprávnění. Ty si musíš zkoušet ve fikanějším sandboxu. Ideální je na to virtální mašinam, to je taky "něco jako Sandboxie" ;)
Jak to? Já bral SSD především jako urychlení načítání kernelu a často používaných programů. K čemu by mi bylo SSD pro filmy/hudbu/cokoli-co-mám-v-home? Tam ta rychlost čtení moc podstatná není, ne?
Pokud máš dostatek paměti, tak ty často používané programy máš stejně v cache. A s kernelem si nemusíš dělat starost, ten se stejně z disku načítá jednou pro vždy při startu :)
-
Omlouvám se za ten Centos, teprve teď koukám, že jsem přehlédl, že Ubuntu zaznělo.
Takže: co říká o práci s konfiguráky manuál Ubuntu? ;)
-
Tady ale platí to samý - pokud to neumíš udělat ručně (a někdo ti neporadí totálně BFU nástroj), tak to nedělej. Až se naučíš unixoidní OS používat tak, jak ho radí používat manuál, pak teprve se pouštěj do toho, že ho budeš nějak fantasmagoricky ohýbat.
S tymto az tak nesuhlasim (ak sa teda bavime naozaj len o OS "na hranie"). Jasne, manual je treba, ale je nudny, pomerne silno vynucuje nejaky postup a uzivatel mu zo zaciatku az tak dobre nerozumie. Preto odporucam, aby sa s tym pohral na testovacom stroji a az si skusi, ako to vlastne funguje (s vedomim rizik kompromitacie takehoto systemu), potom si moze citat manual a pripadne to nasadzovat niekam do produkcie.
V unixoidních systémech prostě problém "zapíše do registrů kam je libo" de facto neexistuje, proto taky nejsou potřeba frikulínské nástroje pro jeho řešení.
Na urovni "kam je libo" to AFAIK nie je ani vo Windows; zalozenie ineho uzivatela pomoze prakticky tak isto. Problem je len "zostavajuci bordel" a pustanie programov s plnymi pravami - to je ale vlastne mozne aj na Unixoidnych systemoch. Bordel u mna na Linuxe zostal napriklad v ~/liferea_1.6 a ~/liferea_1.7; program s plnymi pravami ma rovnaku sancu hadzat vsetko vsade...
Obvykle jenom do ~user (domovská složka uživatele, který program spustil), /tmp a /var/tmp. Nikde jinde prostě nic program trousit nemůže.
Pre uplnost, na Linuxe aspon 2.6 je takto este bezne /dev/shm (z principu sa maze pri reboote); na Ubuntu 13.04 je naviac world-writable aj /run/user/$USER a /run/lock.
Oba dva tmp se obvykle pravidelně mažou, čili na ty zapomeň.
Taky /var/tmp by mal prezit aj reboot - tam sa neda spolahnut na mazanie, ak si to uzivatel nezariadi sam (ja tam mam napriklad zabudnuty subor este z roku 2009, takze to bezne prezije aj upgrade).
-
S tymto az tak nesuhlasim (ak sa teda bavime naozaj len o OS "na hranie"). Jasne, manual je treba, ale je nudny, pomerne silno vynucuje nejaky postup a uzivatel mu zo zaciatku az tak dobre nerozumie. Preto odporucam, aby sa s tym pohral na testovacom stroji a az si skusi, ako to vlastne funguje (s vedomim rizik kompromitacie takehoto systemu), potom si moze citat manual a pripadne to nasadzovat niekam do produkcie.
Jo, to je pravda. Jestli si chce hrát, může zkoušet cokoli. Třeba dd if=/dev/zero of=/dev/sda. Ovšem pokud mu tak moc záleží na nezasírání systému (proto chce sandbox), nejsem si jistý, jak by mu vyhovovalo takovéhle úplné vyčištění systému :)
Ale především, než vůbec s tímhle vším začne, měl by se naučit dokazovat věty o Turingově stroji, na tom je to totiž všechno založeno a bez toho vůbec nemá smysl si s nějakým počítačem hrát, že jo.
Na urovni "kam je libo" to AFAIK nie je ani vo Windows; zalozenie ineho uzivatela pomoze prakticky tak isto. Problem je len "zostavajuci bordel" a pustanie programov s plnymi pravami - to je ale vlastne mozne aj na Unixoidnych systemoch. Bordel u mna na Linuxe zostal napriklad v ~/liferea_1.6 a ~/liferea_1.7; program s plnymi pravami ma rovnaku sancu hadzat vsetko vsade...
Ano, teoreticky to je stejné, v praxi je to úplně jiné. Např. proto, že v unix-světě se obvykle dodržují jakási základní pravidla. Nebo proto, že unixové systémy obvykle mají jakýsi repozitář, kam se dostanou jenom programy splňující jakási kritéria.
Pokud sw na unixovém systému po odinstalaci zanechá jakýsi bordel kdesi, je to jasný bug, o kterém se nediskutuje. Na Win je to spíš standard.
Pre uplnost, na Linuxe aspon 2.6 je takto este bezne /dev/shm (z principu sa maze pri reboote); na Ubuntu 13.04 je naviac world-writable aj /run/user/$USER a /run/lock.
Díky za doplnění.
Taky /var/tmp by mal prezit aj reboot - tam sa neda spolahnut na mazanie, ak si to uzivatel nezariadi sam (ja tam mam napriklad zabudnuty subor este z roku 2009, takze to bezne prezije aj upgrade).
Může být. Ale taky nemusí. Proto je potřeba číst ty nudné manuály :) Každopádně soubory v tempech si hlavu lámat nemusí, o to jde.
-
nějaké tipy jsou tady, http://serverfault.com/questions/23734/is-there-any-way-to-get-apt-to-install-packages-to-my-home-directory , další potom na googlu (https://www.google.cz/search?q=dpkg+install+other+directory).
podle manuálu by to měl umět i dpkg :-)
man dpkg
--root=dir
Changing root changes instdir to dir and admindir to dir/var/lib/dpkg.jen pak teda bude problém se spouštěním programů, nemusí najít všechny knihovny... obvykle to potřebuje na původní místa v /usr/lib/, /usr/bin apod. přidat symlinky. hodí se to hlavně u embedded zařízení, které mají malou flash a externí usb (routery...) :-)
-
podle manuálu by to měl umět i dpkg :-)
man dpkg
--root=dir
Changing root changes instdir to dir and admindir to dir/var/lib/dpkg.
To není určeno k jenom tak mírnyx týrnyx přesunutí čehokoli kamkoli, ale pro instalaci balíčku v chrootu apod. Má to stejný efekt, jako kdybych ty soubory přesunul pomocí normálního mv. Čili většina programů po přesunutí nebude fungovat.
-
Jo, to je pravda. Jestli si chce hrát, může zkoušet cokoli. Třeba dd if=/dev/zero of=/dev/sda. Ovšem pokud mu tak moc záleží na nezasírání systému (proto chce sandbox), nejsem si jistý, jak by mu vyhovovalo takovéhle úplné vyčištění systému :)
Prave preto je tu chroot, ktory izoluje pomerne dobre aspon na opatchovanych jadrach... Nastavit si popisovanu paravirtualizaciu sa mi zda o rad zlozitejsie; o moznosti layered fs per-program ani neviem (co nevylucuje existenciu takeho niecoho). Islo by preloadnut vlastne kniznice cez LD_PRELOAD, ale to podla mna nie je dost bezpecne.
Ale především, než vůbec s tímhle vším začne, měl by se naučit dokazovat věty o Turingově stroji, na tom je to totiž všechno založeno a bez toho vůbec nemá smysl si s nějakým počítačem hrát, že jo.
Tak to by sa mal najskor naucit citat - to bude potrebovat ako u prispevkov na fore, aby netvrdil co ini nehovoria, tak sa mu to oplati vediet aj v lubovolnych inych systemoch a programoch.
Bohuzial dnes castejsie vidim, ze ludia citaju, co si myslia, ze je napisane ako co je napisane.
Ano, teoreticky to je stejné, v praxi je to úplně jiné. Např. proto, že v unix-světě se obvykle dodržují jakási základní pravidla.
To by mali aj na Windowse...
Nebo proto, že unixové systémy obvykle mají jakýsi repozitář, kam se dostanou jenom programy splňující jakási kritéria.
Myslis napriklad spominany program Liferea?
Pokud sw na unixovém systému po odinstalaci zanechá jakýsi bordel kdesi, je to jasný bug, o kterém se nediskutuje. Na Win je to spíš standard.
Na obidvoch platformach sa ten bordel zanechava len za tym ucelom, aby sa zachovali uzivatelske nastavenia. Preto casto zostava bordel v ~/.program (nie vyhradne tam) a preto zostava aj v registroch na Windowse.
Může být. Ale taky nemusí. Proto je potřeba číst ty nudné manuály :) Každopádně soubory v tempech si hlavu lámat nemusí, o to jde.
Ciastocne suhlasim - ale na druhu stranu to moze niekomu vadit rovnako ako registry Windows.
-
K vyřčenému bych možná ještě doplnil, že cesty, kde program hledá své další části, jsou obvykle compile-time proměnné, které se nastavují jako parametry skriptu configure.sh před kompilací. A když jsou compile-time, tak to taky znamená, že jediná čistá cesta, jak je změnit, je rekompilace. Takže pokud si chci nainstalovat vlastní program na server, kde nemám root práva, můžu ho zkompilovat například takto:
$ mkdir /home/user/local
$ ./configure --prefix=/home/user/local
$ make -j
$ make install
Jinak pokud bys chtěl distribuci, která používá spíše windowsovské uspořádání souborů, kdy se k sobě dávají všechny soubory stejné aplikace, namísto unixovského třídění souborů podle typu, tak i takové distribuce existují/existovaly, vím například o Gobo linuxu (http://www.root.cz/clanky/ubuntu-redhat-fedora-mandrake/) a Sinuxu (http://old.avc-cvut.cz/avc.php?id=2842).
-
Na obidvoch platformach sa ten bordel zanechava len za tym ucelom, aby sa zachovali uzivatelske nastavenia.
Nejen. Taky napriklad proto, ze (afaik) na Windows nejde smazat otevreny soubor. Cili program nemuze odinstalovat sam sebe, takze smazani posledni casti se necha na nekdy jindy (napr. pri dalsim restartu). Snadny zdroj chyby.
Taky je velky rozdil v tom, ze unixove systemy maji jednoho spravce balicku, zatimco na Windows ma obvykle kazdy program svuj instalator, nekdy pochybne kvality (malo kdo instaluje vsechno pres msi a ani to neni samospasitelne).
A dalsi rozdil je v tom, ze pro rozumny unixovy OS se balicky do repozitaru vytvari v nejakem sandboxu a kontroluje se, jestli se korektne nainstaluji a odinstaluji. Takze pravdepodobnost, ze nekde zustane nejaky bordel je zase o neco mensi.
Proste kdyz budu unixovy system pouzivat tak, jak rika navod, a budu instalovat jenom balicky z rozumnych repozitaru, sance, ze budu mit problem s nejakym bordelem nekde, je celkem zanedbatelna.
A když jsou compile-time, tak to taky znamená, že jediná čistá cesta, jak je změnit, je rekompilace.
...kterouzto ale OP odmita :)
-
Nejen. Taky napriklad proto, ze (afaik) na Windows nejde smazat otevreny soubor.
Cili program nemuze odinstalovat sam sebe, takze smazani posledni casti se necha na nekdy jindy (napr. pri dalsim restartu).
To (s nejakym obmedzenim) ide. Mozes zmazat otvoreny subor, ale treba to urcit uz pri otvarani. Takze typicka uloha, aby sa binarka sama zmazala takto nejde vyriesit bez externej pomoci a na to je tebou opisany delete on reboot.
Taky je velky rozdil v tom, ze unixove systemy maji jednoho spravce balicku,
Ten ti je na 2 veci, ked niekto aj tak pouziva vlastny instalator (IBM JRE), niekedy aj s grafickym rozhranim, aby to uzivatel bez X nemal take lahke (Oracle RDBMS).
zatimco na Windows ma obvykle kazdy program svuj instalator, nekdy pochybne kvality (malo kdo instaluje vsechno pres msi a ani to neni samospasitelne).
Rovnako ako cast proprietarnych programov na Linuxe. Podla mna ma drviva vacsina firemnych PC instalovane takmer* vsetko cez MSI. Ja ani neviem, ako by som cez GPO (na AD) instaloval exe...
*mozno az na drivery nutne na rozchodenie PC
A dalsi rozdil je v tom, ze pro rozumny unixovy OS se balicky do repozitaru vytvari v nejakem sandboxu a kontroluje se, jestli se korektne nainstaluji a odinstaluji. Takze pravdepodobnost, ze nekde zustane nejaky bordel je zase o neco mensi.
Sandbox instalacie az tak velmi nepomoze (netvrdim, ze nie vobec). Totiz aspon u mna bordelu urcena na zachovanie nastaveni vznika az po spusteni programu.
Proste kdyz budu unixovy system pouzivat tak, jak rika navod, a budu instalovat jenom balicky z rozumnych repozitaru, sance, ze budu mit problem s nejakym bordelem nekde, je celkem zanedbatelna.
Ono, docela otazne je, ci sa to s instalaciou da dodrzat (ci nepotrebujeme napr. Oracle), co je vlastne bordel a ci bude vacsi problem u Windowsu alebo u Linuxu. Neverim, ze nech aj 20 klucov v databaze dokaze nieco citelne spomalit, nech sa to prida aj 100x. Podobne neverim, ze sa niekomu spomali PC, ak bude mat o 20 suborov viac v ~/.program pre 100 roznych programov.
Podla toho, co som videl, tak spomalenie u Windowsu vznika hlavne tak, ze uzivatel chce vyzerat ako profik, tak si stiahne najnovsi Photoshop a nainstaluje si ho. Potom si chce stiahnut crack z pochybnych stranok, chce to od neho nejaky plugin do browseru na smajlikov - on to stiahne, nebude predsa ako zaciatocnik bez nich. Potom mu velkym vyskoci, ze je jeho PC nakazeny, tak si stiahne aj takto ponukany antivirus. Nakoniec stiahne crack, ten chce administratorske prava - on mu ho da, on predsa *potrebuje* otacat fotky.
Este lepsie to je, ked ma uzivatel stiahnuty komplet upraveny Windows (ine GUI) z pochybnych zdrojov, cracknute tak, ze crack sa zavadza este pred Windowsom. Na tom kopec dalsich cracknutych programov doplnenych cracknutym antivirom - ved len s tym je v bezpeci. Ale antiviru sa zasadne neveri, ved autor cracku napisal, ze ide len o falosny poplach a treba pridat vynimku...
-
Díky za odpovědi. I když jsem tak trochu doufal v něco jiného :).
Doufal jsi právem, ony ty odpovědi jsou minimálně trochu diskutabilní :)
Diskusi jsi předvedl pěknou :-)
1. V podstatě ne. Teoreticky, pokud se s tím chceš hodně s*, tak klidně můžeš místo /usr/share/program mít symlink někam na ten plotnový disk nebo mountovat přes fstab.
To přeci není žádné sraní. Pokud mám distribuci, která mi např. celé Gnome instaluje do /opt/gnome, tak to je jeden symlink, který nemá na updaty prakticky žádný vliv (protože ten kořenový /opt/gnome pravděpodobně nikdo nikdy mazat nebude).
To je značně subjektivní, zvlášť když to budeš dělat pro X méně důležitých a používaných programů. Zrovna pro /opt/gnome (to je navíc není standardní umístění) to je dost kravina v daném kontextu.
-
Já to celé nečetl tak jen k bodu číslo 1 - hledáš příkaz ln, konkrétně jak udělat symlink
Trochu konkrétnějc to popíšu:
1. na /home disku si uděláš adresář (např. programy, bude k němu tedy cesta /home/programy)
2. do něj zkopíruješ (!!! bacha na vlastnictví a oprávnění !!!) obsah adresáře, kam se instalujou programy (to si najdi, Ubuntu nepoužívám a není to vždy jednotné)
3. přejmenuješ původní místo, kam se instalujou programy (např. mv /usr/programy /usr/programy.stare)
4. uděláš symlink, symbolický odkaz ze starého místa na /home/programy (vždy, když dělám symlink, znovu objevuju, jak se dělá = z hlavy sem příklad nenapíšu)
Co je symlink - je to ukazatel/odkaz. Vytvoříš tím přesměrování odněkud někam. Například tady přesuneš adresář pryč z /usr a na jeho původním místě uděláš právě tenhle odkaz, který říká, kde vlastně ty soubory nově jsou. Systém to pak chápe tak, že jsou stále v /usr, zatímco jsou v /home/programy. Tímhle způsobem přesuneš všechny programy, ne vybrané.
V porovnání s Windows a dvěma disky - Neoddělíš tímhle způsobem programy do dvou skupin. Ale Windows tohle neumí (přesunout celý adresář včetně všeho v něm a nechat po něm pouze odkaz na jeho nové umístění).
Symlinky se nauč chápat, často se můžou hodit. Pokud je chceš po vytvoření ověřit, tak na něj udělej ls -la, on Ti řekne kam míří a jestli funguje (pokud nebliká červeně jak o život, tak funguje :-) ).
Schválně zkus ls -la ~ a koukni se, jestli nemáš symlink i ve svym domovskym adresáři. Možná že i jo :-)
K otázce odebrání bordelu po starých programech - v domovskym adresáři jsou adresáře a soubory začínající . (tečkou). Jsou to v Linuxu skrytý soubory. Dle jejich jména lze odhadhnout, k jakýmu programu patří. Stačí je vymazat. Otázka je, proč to ale dělat. Většinou zabírají málo místa a nezabordelují se jimi žádné registry (tohle jsou "registry", obyčejné soubory).
-
Díky všem za reakce. Žádné řešení není dokonalé, ale objevil jsem tu několik pro mě nových věcí, které si vyzkouším na virtuálu :).
Zároveň jsem se o tom bavil se známým a ten mi tvrdil, že se do budoucích verzí FSH uvažuje o překopání standardní souborové hierarchie. Pochopil jsem, že by to mohlo být zhruba něco ve stylu http://objectroot.org/ , nevíte o tom někdo něco?
-
[...] (IBM JRE) [...] (Oracle RDBMS) [...] proprietarnych programov [...] drviva vacsina firemnych PC [...] GPO (na AD)
Jezkovanoho, to je o voze a o koze. OP se pta, jak si na domacim PC muze sandboxovat, ja mu tvrdim, ze pokud bude OS pouzivat beznym zpusobem, tak to nepotrebuje, a ty tady zacnes vykladat o Oracle a AD... Ja to vzdavam.
Pochopil jsem, že by to mohlo být zhruba něco ve stylu http://objectroot.org/ , nevíte o tom někdo něco?
No potes koste, zas nejaci frikulini, co nemaji do ceho pichnout a tak vymysleli, jak zachranit svet... Jako prochazel jsem to jenom velmi zbezne, ale jestli nekoho napadne jenom tak z hecu prejmenovat /home na /users, tak to je chory mozek. Tak samozrejme jako prvni to bude mit Arch, protoze to je desne cool ficura, kterou musime hnedka nasadit, protoze uz nam system nejakou dobu jede celkem stabilne, tak bysme meli neco zmenit, at maji spravci radost :(
-
Jezkovanoho, to je o voze a o koze. OP se pta, jak si na domacim PC muze sandboxovat, ja mu tvrdim, ze pokud bude OS pouzivat beznym zpusobem, tak to nepotrebuje, a ty tady zacnes vykladat o Oracle a AD... Ja to vzdavam.
Aha, tak to som sa nechal uniest samotnym prispevkom a reakciou nan (aj ked IBM JRE snad nie je az tak mimo).
Ale prave pred par minutami sa mi prejavil tiez problem so zasvinovanim, ked sa mi vycerpala kvota v skole. A za tu mohol zabudnuty stary adresar ~/.cache/netbeans/6.8 o velkosti cca 600MB - Netbeans 6.8 som mal naposledy pusteny velmi davno a akurat som tam mal aj vacsie projekty.
Jasne, aj .cache sa da pravidelne mazat - ale chcem poukazat na to, ze zasvinovanie nie je problem len u Windowsu.
-
No potes koste, zas nejaci frikulini, co nemaji do ceho pichnout a tak vymysleli, jak zachranit svet... Jako prochazel jsem to jenom velmi zbezne, ale jestli nekoho napadne jenom tak z hecu prejmenovat /home na /users, tak to je chory mozek. Tak samozrejme jako prvni to bude mit Arch, protoze to je desne cool ficura, kterou musime hnedka nasadit, protoze uz nam system nejakou dobu jede celkem stabilne, tak bysme meli neco zmenit, at maji spravci radost :(
Ta otázka nebyla mířena konkrétně na objectroot. Ale spíš jestli někdo neví, že by se uvažovalo o novém uspořádání složek v linuxu... objectroot byl jen jako ukázka jak zhruba jsem pochopil, že by to mohlo vypadat. O jména složek mi fakt nešlo :).
-
Ale spíš jestli někdo neví, že by se uvažovalo o novém uspořádání složek v linuxu...
No dostal's dva příklady distribucí, které nad tím nejenom uvažují, ale naimplementovali to. Ani jedna z nich se nijak zvlášť nerozšířila, takže asi tak.
Jinak částečně touhle cestou jde MacOS, vlivem dědictví NeXTSTEPu. Klasické unixové věci ale nechává na svých místech.
-
Ale spíš jestli někdo neví, že by se uvažovalo o novém uspořádání složek v linuxu...
No dostal's dva příklady distribucí, které nad tím nejenom uvažují, ale naimplementovali to. Ani jedna z nich se nijak zvlášť nerozšířila, takže asi tak.
Jinak částečně touhle cestou jde MacOS, vlivem dědictví NeXTSTEPu. Klasické unixové věci ale nechává na svých místech.
IMHO, je to celé hovadina, každý si sytém po instalaci stejně přizpůsobuje obrazu svému. Já říkám, že neznám špatný linux, ale jen špatné uživatele. Ano, nastavováním strávíš dost času od dvou dnů do týdne, záleží na tom, s čím vším si hraješ! A co se týče "zasviňování" což je hodně špatný výraz, tak linux je na tom podstatně lépe. To, že v home zůstávají po odinstalaci programu jeho nastavení je zcela v pořádku. Někde se pracuje na dvě až tři směny adminů ... jeden něco odebere, a zapomene se o tom poradit s kolegy ... no program po jeho šichtu nefunguje, lidé začnou však řvát na jeho kolegu, donainstaluje program a víc nemusí řešit! No a co se týče různých cache, tak pomocí symlinků je můžeš nasměrovat všechny na jedno místo, které se pomocí cronu v určitém časovém rozmezí smaže. Takže nastavit to lze, ale chtít to po systému v základu je dost naivní představa, a já bych to ani nechtěl. Tak jak to je dnes je to plně vyhovující. Je to mnohem jednodušší, než kontrolovat, kam který symlink směřuje, nedej bože, když bude směrovat zase jen na symlinky!