Šoupni to s tečkou do houmu (diskuse)

[StefanV]

Zdravím... Úplně s vámi souhlasím. Dokud jsem nezačal zálohovat i svůj desktop, tak jsem tomu nevěnoval moc pozornosti.

[pasmen]

[pasmen@nyx ~]$ du -sh .evolution/
1.2G    .evolution/

Mne se zase vcelku libi, ze to mam v home, o kterem jsem na 100% presvedcen, ze ho muzu kdykoliv jakkoliv promazat. Radeji budu mit zapraskany home, nez rozhazene _moje_ soubory po celem disku nekde ve /var.

[Tom.š Ze.le.in]

Tak to bude asi rozdíl přesvědčení. Já jsem si vcelku jist, že mohu plošně smazat vše (příp. na co mám právo) ve /var/cache, ale v home bych to radši dělal jen opatrně.

[Lu-Tze]

S tím /var/cache jsi vedle, ale jinak s tebou souhlasím, taky mi to vadí. Nicméně těch adresářů není tolik, abys nemohl ručně sestavit jejich krátký seznam a nasymlinkovat si to, kam se ti to hodí víc, a při zálohování je vynechat. Kandidáti na tyhle adresáře by šli hledat např. podle toho, že obsahují soubory s netextovými daty.

[Tom.š Ze.le.in]

Proč jsem vedle s /var/cache? V čem to např. u thumbnailů neodpovídá FHS?

/var/cache : Application cache data

Purpose /var/cache is intended for cached data from applications. Such data is locally generated as a result of time-consuming I/O or calculation. The application must be able to regenerate or restore the data. Unlike /var/spool, the cached files can be deleted without data loss. The data must remain valid between invocations of the application and rebooting the system.

Files located under /var/cache may be expired in an application specific manner, by the system administrator, or both. The application must always be able to recover from manual deletion of these files (generally because of a disk space shortage). No other requirements are made on the data format of the cache directories.

Rationale The existence of a separate directory for cached data allows system administrators to set different disk and backup policies from other directories in /var.

Jinak kandidáty pro mne hledá du - pragmaticky mne malé věci tolik nezajímají.

[Ondrej 'SanTiago' Zajicek]

> Proč jsem vedle s /var/cache?

Protoze FHS je kodifikace zabehlych postupu a jeste jsem nevidel program, ktery cached data pri praci s uzivatelskymi daty ukladal do /var/cache .

[kavol]

Protoze FHS je kodifikace zabehlych postupu ...

MUHEHEHE ... to jsme viděli například při zavedení /media, když to až do té doby všichni prali do /mnt/něco

[Leoš Literák]

Ja ted na pracovnim notebooku uklizel windows. Furt se mi nedostavalo mista. Pak jsem zjistil, ze kazda instalace update (at uz systemu nebo aplikace) si ulozi stazeny soubor do adresare Application Data a nesmaze to po sobe. Takze se data hromadi a hromadi .. Nektere destiky megabajtu velke updaty jsem nasel v systemu vicekrat. Proste sileny zmatek.

[Luk]

Ve skutečnosti je to ještě horší. Něco je v Application Data, něco v Data aplikací, potom v Local Settings/Data aplikací, potom třeba v UserData, případně ještě v jiných adresářích.

[petr3]

to jste se asi jeste nedivali do Windows/Installer/ nebo Windows/Downloaded Installations nebo Windows/SoftwareDistribution (i kdyz tady si nejsem jisty) :)

[Murry]

a to jste asi neinstalovali nikdy SP2 (:-!) ktery se rozbali do root/i386_A_NEJAKY_CISLA_PISMENA a lide se to boji smazat, pac to vypada Dulezite
Po rozbaleni to ma vcelku dost....

[Aleš Kapica]

Celý problém je v tom, že bud autoři těch aplikací, nebo instalačních balíčků neakceptují FSB pravidla, jaké má např. Debian.. Pro neznalé FSB - File System Base je základní koncept toho co kam patří, viz Adresářová struktura na Wikibooks.

[Aleš Kapica]

Omlouvám se, správně má být FSH - File System Hierarchy

[Tom.š Ze.le.in]

A co to nazvat Filesystem Hierarchy Standard a psát FHS? :)

(dám si sem link, když už jsem na to dvakrát odkázal...)

[Aleš Kapica]

A nebo táák.. 8-) Z toho horka jsem vážně v útlumu. Nicméně zkratka sem, zkratka tam, podstatné je že umístování souborů by mělo mít svůj řád..

[Robo]

Problem je v tom, ze kazdy user navstevuje ine stranky a ma svoj vlastny cash vo svojom vlastnom home/usename adresari, na ktory ma potom prislusne prava len on. Asi nechcu, aby to jednotlivy useri zdielali spolocne. Mozu tam byt kompromitujuce videa napr. :)

[finn]

A o přístupových právech už jsi slyšel?

[Robo]

Lenze je tam konflikt ci maju mat useri svoje data v home adresari alebo niekde inde. O tom, ci to je cash nejakej aplikacie je v podstate jedno.

[Tom.š Ze.le.in]

V cache souborech žádná data v pravém slova smyslu nejsou. Respektive jsou asi jako třeba ve swapu a v RAMce. A jedno to není třeba kvůli zálohování (čím větší prostor pro cache, tím lépe - dokud je místo, ale se zálohováním to moc nejde dohromady)

[thingie]

No, jenže to je právě trochu problém, protože většina toho kešovaného v home je něco mezi daty a keší, ale striktně vzato by to často nebylo ani jedno z toho. Na druhou stranu je určitě pravda, že ukládat soubory které si program dokáže kdykoliv dopočítat a proto o ně může bez ztráty kytičky přijít na nějaké určené místo, kde to půjde snadno promazat a nezálohovat, to asi něco do sebe má.

[freshmouse]

Asi máš pravdu, ale takhle to je zase hezky pohromadě v ~. Mám tam poštu atd. Když už zálohuju, tak cache předtím promažu (to se týká hl. WWW prohlížečů a .thumbnails) a je to.

[Tom.š Ze.le.in]

S poštou nemám problém - to jsou zřetelně (doufejme) užitečná uživatelská data - i když jsem radši, když je pošta ve viditelném souboru, ne někde pod tečkama. Výrazem cache jsem myslel (viz i FHS citát výše) to, co mohu kdykoliv smazat aniž bych se trápil, a co bude stát jen "trochu" CPU/IO.

A, principiálně, proč si zbytečně promazávat (doufejme užitečnou) cache když chci zálohovat?

[kavol]

reportuj to a postni čísla bugů, pokud se dá někde hlasovat, jistě se tu najde pár lidí, co to podpoří (třeba já )

[sk7]

"Pokud někdo nechápe, co se mi na tom nelíbí: standard má na cache dobře definované místo, /var/cache, o kterém vím, že ho nemusím zálohovat a můžu kdykoliv promazat. O případné potřebě mirrorovat ani nemluvě."

Ked to chces tie adresare (.thumbnails .opera atd) cachovat vo /var/cache tak si ich tam vytvor a urob na nich symbolicky odkaz.Potom ti to bude cachovat vo /var/cache ako si chcel.

[David Jaša]

Už nějakou dobu existuje standard XDG, který se snaží tenhle bordel trochu uspořádat, ale moc projektů to zatím nezaregistrovalo. Pokud to zaregistrují, tak jenom vynecháš ze zálohy/mirroru adresář .cache.

[Tom.š Ze.le.in]

Díky za odkaz, tohle neznám (což taky o něčem svědčí). Tahle varianta by mi ke štěstí úplně stačila (a na druhou stranu asi uskokojila i ty co zde v diskusi toužili mít vše v ~/).

[Ondrej 'SanTiago' Zajicek]

Co by ale melo byt spravne reseni? Napada me jich nekolik:

1) ~/.cache/${NAME}

Presunuti cache do jednoho adresare v home

2) /var/cache/${NAME}

Oddeleni dat jednotlivych uzivatelu pomoci pristupovych prav, podobne jako v /tmp .

3) /var/cache/${NAME}/${USER}

Oddeleni dat jednotlivych uzivatelu podadresari, nevyhoda je v nutnosti vyresit zakladani podadresaru.

4) /var/cache/user/${USER}/${NAME}

Podobne jako 3), ale opacne cleneni. Je mene v souladu s aktualni strukturou /var/cache, ale asi snazsi na administraci.

[Tom.š Ze.le.in]

Dobrá otázka :)

Cokoliv z toho lepší než teď, moje osobní preference by byly nejradši 2/3 (podle toho zda více souborů nebo jeden), ale v zásadě to je skoro jedno.

[kavol]

podle mě záleží na účelu; například nevidím důvod, proč by browsery nemohly například sdílet tutéž cache (a to nejen v rámci jednoho browseru mezi uživateli, ale i různé browsery mezi sebou)

tedy "nevidím důvod" - důvodem je samozřejmě nedostatek vůle a potřeba dělat si věci po svém (jo, někdy se nějaká vychytávka, která je specifická jen pro určitý program, může hodit, ale pří rozumně navržených standardech není problém v extensibilitě, ostatní prostě budou ignorovat to, čemu nerozumí)

[Aleš Kapica]

Tak já vidím důvod celkem jasný - aby se nemlátily ty soubory mezi sebou a třídit pak takový bordel, to by byla pak práce pro frajera.. Ostatně.. např. Opera si udržuje svou cache ve svém chlívku (jako každý slušný program) a dočasné soubory co stahuje frká do tmp.

Naopak za zvířecí považuji způsob jak to dělá KDE, které zahrabává tyhle adresáře extra pro každou aplikaci hluboko do adresáře ~/.kde

[kavol]

Tak já vidím důvod celkem jasný - aby se nemlátily ty soubory mezi sebou a třídit pak takový bordel, to by byla pak práce pro frajera..

proč by se měly mlátit mezi sebou a proč by to měl být bordel, který je potřeba třídit, pokud by byl nadefinován společný způsob?

Ostatně.. např. Opera si udržuje svou cache ve svém chlívku (jako každý slušný program) a dočasné soubory co stahuje frká do tmp.

Naopak za zvířecí považuji způsob jak to dělá KDE, které zahrabává tyhle adresáře extra pro každou aplikaci hluboko do adresáře ~/.kde

nerozumím, co tím chtěl básník říci? jaký je rozdíl mezi tím, jestli Opera ukládá do .opera a KDE do .kde?

[Josef Kufner]

K tomuhle se používají kešující proxy. Máš pak zajištěno, že to je bezpečné, nejsou tam uložena citlivá data a programy se o to nepřetahují.

[Lu-Tze]

Nemohly. Důvod je zřejmý - pokud za uložení do cache zodpovídá uživatelský proces, může si tam kdokoli uložit cokoli. Takže by šlo cizím lidem podstrkávat změněné stránky, co by to znamenalo si už každý domyslí.

[kavol]

každý problém má řešení ...

[kavol]

(než budu nařčen z plácání do větru ... o hlouposti set[gu]id už mluvil MJ, nic lepšího než to mě momentálně nenapadá, tak jsem to ani nechtěl zmiňovat, ale radši to nakonec píšu, ať si Ignor nestěžuje, že nemám žádný argument )

[Lu-Tze]

Jde o to, že je úplně jedno, jak to zařídíš, jestli nad tím bude pracovat nějaký specielné program třeba. Pokud ty data půjdou od nedůvěryhodného zdroje - čímž uživatelský program je, tak se prostě ta data sdílet nedají.

[kavol]

když vymyslíš, jak (bez rootovských práv) zařídit, aby se nějaký "nedůvěryhodný zdroj - uživatelský program" tvářil třeba jako /usr/bin/konqueror, měl stejné checksumy jako při instalaci z balíčku atd., máš u mě pivo

[Lu-Tze]

Takže přístup do keše dovolíš jenom předem vybraným programům nebo rovnou zakážeš uživatelům pouštět programy (skripty!), které nebyly nainstalovány přes balíčkovací systém? Pak budeš taky muset brát do úvahy to, že uživatel si může nastavit a vyrobit proxy, která bude ty změněné stránky posílat, takže při kešování musíš vzít do úvahy to, přes co byla ta stránka stažena (nejspíš asi stránky stažené přes proxy nekešovat vůbec). A pak je tu ještě LD_PRELOAD, ten musíš taky pořešit, jinak si útočník přeplácne třeba fce typu gethostbyname a přesměruje se na změněnou stránku, která se pak nakešuje. To se možná řeší už v rámci těch dvou možností, ale to nevím.

Ale máš pravdu, asi by to realizovat šlo. SELinuxoviny atd. jsem neuvažoval. Tak sorry, no

[kavol]

uživatelům nic nezakážu pouštět, jenom prostě "nedůvěryhodný" program nebude smět zapsat do cache

jinak lepší řešení by bylo asi něco jako Squid, akorát aby to neběželo pořád, ale "ondemand", a fungovalo transparentně bez nutnosti explicitně zadávat proxy ... to potom odstíní i možnost použití vlastní podvodné proxy, protože se hnedle pozná, odkud odpověď přišla, a zbývá už jen man-in-the-middle útok, který je možný i když si každý uživatel syslí svou cache jen a jen pro sebe

no vidíš, tož jsme si lehce zabrainstormovali a hnedle máme dva možné směry, kterými se při vymýšlení, jak udělat společnou cache, dá ubírat, a pak že je to nemožné

[thingie]

Není důvod, proč by to nemohlo běžet pořád. Když to nebude mít co dělat, tak se to blokne a bude čekat. A při požadavku nebude nutné čekat až se to pustí.

[Lu-Tze]

Takže možnost "Takže přístup do keše dovolíš jenom předem vybraným programům" - nevím jak bys chtěl "důvěryhodnost" určovat nějak automaticky.

[kavol]

např. instalovaný z balíčku = důvěryhodný?

[Hynek (Pichi) Vychodil]

uživatelům nic nezakážu pouštět, jenom prostě "nedůvěryhodný" program nebude smět zapsat do cache ...

A to prosím zajistíme jak?

[kavol]

žeby pomocí práv?

[Hynek (Pichi) Vychodil]

Důvěryhodný a nedůvěryhodný program běžící pod stejným uid se rozpozná jak?

[happy barney]

podpísaný administrátorom ?

lepšie by i tak snáď bolo open (filename, flags | O_CACHE) (a to je asi tak všetko, čo si k danej téme momentálne viem predstaviť)

[Hynek (Pichi) Vychodil]

A jak fs pozná, že proces provádějící write je podpísaný administrátorom?

(a to je asi tak všetko, čo si k danej téme momentálne viem predstaviť)

Jinými slovy víš o tom kulové a jen tak plácáš. Děkujeme mnohokrát, že nám tu zaplácáváte diskusi planými žvásty.

[Lu-Tze]

Ne, nemá. Tohle není technický ale logický problém.

[Tom.š Ze.le.in]

Zrovna u těch browserů by to tříštění mělo jít zmírnit tím, že se rozumně lokálně nakonfiguruje a používá proxy (třeba squid), a souborová cache se zruší - nebo ne? Tím by všichni a všechny (míněno uživatelé a browsery) užívaly stejnou cache.

[kavol]

jasně, jeden squid na internetové gatewayi a druhý u každého na lokále ... jenže ono to taky žere nějaké systémové prostředky (ne na každém počítači se 100% času browsí, ne každý má 2 a více GB RAM ...)

"souborová cache se zruší" - to by ovšem musel každý uživatel nastavit sám (ok, nějaké mechanismy nastavení globální konfigurace asi většina browserů má, ale kdo to má uhlídat ...)

[thingie]

No je to zdaleka nejlepší řešení. Takový nepříliš používaný squid si vezme jenom maloučko a tyto prostředky by se patrně získaly ušetřením té keše u každého prohlížeče zvlášť. A může to klidně fungovat system-wide, pro všechny uživatele, bezpečně a jen s minimem změn v současných aplikacích.

Sdílená keš stránek pro celý systém mimo, to není nic moc. Jeden ztřeštěný program v tom udělá okamžitě paseku.

[Ondrej 'SanTiago' Zajicek]

> Zrovna u těch browserů by to tříštění mělo jít zmírnit tím, že se rozumně lokálně nakonfiguruje a používá proxy (třeba squid), a souborová cache se zruší - nebo ne?

Prohlizece muzou v cache udrzovat stranky i v jine podobe, nez v jake je dostanou od serveru - pro ucely zrychleni renderingu mohou mit v cache predpocitane ruzne udaje.

[Aleš Kapica]

Záleží.

Já osobně bych volil řešení..

/tmp/${USER}/${NAME}

a s příslušně nastavenými právy. Eventuálně, pokud bych trval na tom, aby měl každý svůj bordel ve svém chlívku..

~/tmp/${NAME}

[Tom.š Ze.le.in]

Ze zvědavosti jsem se zeptal (viz update blogu).

[MJ]

(2) má značné potíže s právy -- kdo může do takového adresáře zapisovat? Bylo by dost hloupé muset kvůli cacheování pořizovat nějaké programy se set[ug]id. Také není jasné, jak to udělat, když si uživatel chce nainstalovat nějaký program do svého home.

U (3) i (4) je dost těžké vyřešit zakládání adresářů, aby uživatelé nemohli navzájem škodit.

Co třeba:

(5) ~/.cache/{$NAME}, přičemž ~/.cache je link do adresáře /var/cache/ s náhodně vytvořeným jménem.

?

[Michal Kubeček]

U (4) by se to dalo vyřešit tak, že /var/cache/users/$USER by se vytvořil s právy 700 hned při založení uživatele. Co si tam pak udělá (resp. jeho aplikace) pod ním, to už je jeho problém. Z navrhovaných variant mi to připadá nejschůdnější řešení, jen donutit aplikace, aby to používaly - u open source to nebude problém, s closed source by to asi bylo horší.

[miso]

u open source to nebude problém, s closed source by to asi bylo horší

IMHO ujednotit a pretlacit do LSB (pripadne spravit na to nejake kniznice) a pojde to

[MJ]

Pokud jsou uživatelské účty sdílené v celé síti, je poměrně praštěné při zakládání uživatele procházet všechny počítače a zakládat mu tam adresář s cache

Můj návrh se symlinkem toto elegantně řeší a hlavně funguje i na strojích, které /var/cache nemají, tam se může použít třeba /tmp nebo adresář v home.

[Josef Kufner]

To není problém. Uděláš /var/cache/users s právy 770 + sticky bit, vlastník root:users a ať si tam každý uživatel vyrobí ten svůj adresář sám. Pro pořádek by to jednoduchý script spuštěný z cronu čas od času zkontrolovat, že tam nikdo nemá nějaký svinčík.

[Lu-Tze]

Akorát jméno toho adresáře, pak musí být nejspíš generované náhodně (nemůže to být třeba uživatelské jméno).

[Josef Kufner]

Ba naopak. Musí to být uživatelské jméno, aby byla zaručena unikátnost, bylo jasné komu to patří (a dalo se to lehce ověřit) a každý program to byl schopný najít.

[Lu-Tze]

Nic z toho není pravda Deterministicky generované to být nemůže, nic nezabrání uživateli vytvořit adresář jiného uživatele.

[Josef Kufner]

Ale může, jen stačí, aby si uživatel při přihlášení ověřil, že ten adresář existuje a je jeho.

[Lu-Tze]

A když není jeho? Tak do něj psát nemůže, což mi teda přijde jako vada, která vůbec nemusí nastat:

by to mohlo fungovat tak, jak píšeš +

* uživatel najde svůj adresář (projde všechny, najde nejmladší, který mu patří)

* pokud nenajde nic, vytvoří nový - název vygeneruje náhodný, zatím nepoužitý

- není vyloučeno, že se vytvoří dvě keše pro jednoho uživatele - přidáme do toho tvého cronového skriptíku mazání nadbytečných keší (zachová se jen nejnovější) - kěš uživatele se ale nebude mazat, pokud je přihlášen

[Josef Kufner]

Pokud není jeho, dočasně nebude kešovat (nebo použije /tmp), napíše mail adminovi a ten dá majiteli do nosu. Výhodou je, že se na škodiče rychle přijde a hledání kešovacího adresáře je výrazně rychlejší. A jako bonus tam bude pořádek.

[Lu-Tze]

Kdo chce kam... Když si vzpomenu, co jsem prováděl na základce... Kdyby víc věcí mělo fungovat tímhle stylem, pak by snad ani žádné sítě nebyly, nebylo by lidí, kteří by je dokázali spravovat.

BTW Nevím, co je nepřehledného na tom tak strašně nepřehledného, prostě místo na názvy koukám na vlastníky adresářů. Pročišťovat se to musí tak jako tak, neboť účty se taky ruší, takže v podstatě nic moc navíc by se implemetovat nemuselo. Název adresáře s keší by se mohl někam uložit, pak by se v ideálním případě nemusel zjišťovat tím procházením nikdy.

[Josef Kufner]

To jsem se jen inspiroval uživatelskýma crontabama

Stejně to nikoho nenapadne implementovat, tak co...

[Robo]

Ja by som radsej preferoval mu davat prava iba na adresar Home, nikam inam by explicitne prava mat nemal - ostatne riesi prislusnost do skupiny. Ten Home adresar je spravidla na inej particii nez system, aby s nim nekolidoval ked cash narastie aj na niekolko desiatok MB.

[Michal Kubeček]

Ja by som radsej preferoval mu davat prava iba na adresar Home, nikam inam by explicitne prava mat nemal - ostatne riesi prislusnost do skupiny.

Co třeba mailbox?

[thingie]

Nevim jak u vás, ale já poštu beru rovnou k sobě do ~/Mail

[Michal Kubeček]

To je sice možné, ale defaultní ani většinové to určitě není…

[Ondrej 'SanTiago' Zajicek]

> (2) má značné potíže s právy

Co treba 1777 ? A vytvorene soubory s nahodnymi jmeny a pravy 0600?

I kdyz je pravda, ze tenhle model ma cetne nedostatky (podobne jako /tmp). Osobne si myslim, ze i u /tmp by bylo dobre mit samostatny adresar pro kazdeho uzivatele.

Pokud uzivatel instaluje programy do sveho home, tak stejne bud pouzije jiny prefix nebo localstatedir (parametry configure).

(3) a (4) by slo resit sgid programem s vyhrazenou skupinou pro zakladani techto adresaru. Ale je to prilis obskurni.

(5) onen symlink a adresar by vytvarel administrator, nebo kazdy program sam? V prvnim pripade to ma podobny problem jako (3)/(4), v druhem pripade jako (2)

[Vinicius]

Me by se hlavne libilo, kdyby vsechny teckove soubory nebyly primo v $HOME, ale v $HOME/.config, aby se to trochu oddelilo od uzivatelskych dat (zatim se to resi tak, ze spravcum souboru se naridi nezobrazovat je).
Ja myslim, ze data tam programy ukladaji kvuli jistote - $HOME existuje skoro vzdycky. /var/cache nemusi existovat, ja jsem se takhle spalil i s promennou TMPDIR.
$HOME je ale podle mne spravne misto na ukladani pozic ve hrach - je to hracuv nedocasny vytvor.

[frdrx]

Možná raději $HOME/.etc/?

[David Jaša]

Hoši, už tady padl odkaz na standard, který to řeší.

[Tom.š Ze.le.in]

No, on ten standard ani tak neřeší kde to má být, ale jak si to aplikace má zjistit :) Být to může zdá se kdekoliv, když se nastaví proměnná.

BTW, ty odkazy na předchozí posty vypadají v mailu divně a při odpovídání je ani nechci zkoušet (vedou na nějaký edit). Já vím, mám si udělat účet v bugzille.

[frdrx]

"...a default equal to $HOME/.config should be used," což může být třeba to co jsem napsal. Ten standard definuje jenom ty proměnný.

[Ondrej 'SanTiago' Zajicek]

Ktery je dost overengineered, takze je otazka, kolik programu ho bude podporovat.

[frdrx]

Hlasoval jsem "nic nechápeš", což znamenalo "nic nechápu".

[Zaphod]

Zabúdaš že Linux je serverový systém.
Pre desktop by sa o tom ešte dalo uvažovať. Ale koľko užívateľov by kričalo "Ubúda mi miesto na disku. Prečo keď v home adresári nič nemám?" Užívateľské dáta majú byť na jednom mieste. Inak by si neprišiel na to že treba prečistiť cache adresáre.
Pri použití Linuxu ako servera je to veľmi zlý nápad. Ak nechceš byť na preklínaný administrátormi na celom svete (aj keď to je určitá forma slávy) zabudni na iné adresáre ako /home/user
Pri použtí servera sa delia / /var /home a /tmp na rôzne partície. Ak pustíš užívateľa mimo /home stabilita systému bude na úrovni Windows 3.1. Bol by si prekvapený ako rýchlo by prišli na to kde uložiť svoje veľké súbory, zaplniť disk a tým odstaviť systém.
Užívateľské data (jedno či .avi .mp3 cache alebo config súbory) patria skrátka do /home a nie upratať bordel o ktorý sa nechcem starať niekde do systému.
Opera a Firefox vedia limitovať a zmazať svoje cache. Treba sa sťažovať u vývojárov ostatných programov nech to dorobia do svojich programov - to je podľa mňa systémové riešenie.

[Tom.š Ze.le.in]

Nezapomínám. Ale mám za to, že /var/cache je také na samostatné partition (zvlášť když máme LVM). Pokud tam uživatelé dávají velké soubory, tak musí počítat s tím že tyto samy můžou zmizet. A na vážně braných serverech se snad procento zaplnění disků kontroluje. Zrovna tak mohou uživatelé svůj nepořádek dávat do /tmp - to je také často zapisovatelné.

[Zaphod]

Systém sa dá nastaviť aby mazal /tmp pri každom štarte. Alebo príkazom v crone keď beží stále. Tým odpadá pokušenie. To delenie adresárov na partície netreba preháňať - systém je potom málo flexibilný, nie všade treba LVM.
Dlho robím s Unix a Linuxom a vo /var som ručne mazal len datový súbor samby - chybne vytvárala zoznam tlačiarní. Inak vždy cez program ktorý data vytváral. Cache a temporary súbory majú odlišné určenie. Nesmie sa s nimi zaobchádzať rovnako.
S cache súbormi užívateľa sa musí niečo robiť nech už sú umiestnené hocikde. A má to ošetriť ten program ktorý ich vytvoril. Nie rm.
Tvoj návrh znižuje základ bezpečnosti - oddelenie systémových a užívateľských dát. Z toho vznikajú problémy. Niektoré sú už naznačené v príspevkoch. Samozrejme sa dá všetko ošetriť, naprogramovať. Základná otázka či sa oplatí na túto zmenu vynaložiť toľko práce a prijať bezpečnostné riziká. Mne sa zdá že nie.

[Tom.š Ze.le.in]

Chápu možný problém. Nicméně minimalistická v diskusi navržená verze - všechny uživatelské cache soubory v ~/.cache - vyhoví oběma: podle mne nemá problémy, které zmiňujete, a na druhé straně umožní tam, kde to administrátor považuje za vhodné, jednoduše omezit zálohování a zjednodušit promazávání, případně jedním symlinkem ve skriptu pro tvorbu uživatele přesměrovat jinam.

Jinak čistě intuitivně dle mého má smysl (podobně jako to dělá jádro s pamětí) všechno v dané chvíli nepoužívané místo na disku (s určitou rezervou kvůli efektivitě filesystémů a podobně) použít pro cache - a nechargovat ji proti uživatelským kvótám. Ale to je můj osobní názor, se kterým nikoho nenutím souhlasit.

[happy barney]

štve ťa to? napíš libku, ktorá umožní ľubovoľnú kombináciu, vydaj pod milión licenciami a začni písať patche.

dobre navrhnutá (a nakódená) libka je hodná tisícov slov

[happy barney]

čo treba brať do úvahy: quota, user-defined cache size (hmm, kombinácia týchto dvoch výrazov imho postačuje na hlasovanie "nic nechápeš" ...)

[Hynek (Pichi) Vychodil]

Ad anketa poslední možnost: Je příznačné, že tam není Mozilla, to by mělo stejný efekt jako to poslat rovnou do /dev/null