Linuxové distribuce zavádějí nový adresář /run

Nemôže to byť uvoľnenou pamäťou RAM? Keď ti tam nestrašia zbytočnosti z /tmp, môže slúžiť na spustené programy. Obzvlášť v starých systémoch s nedostatkom RAM.

A to nikoho nenapadne ze si musi system pre taky stroj nastavit? Ako napriklad pre SSD disk si clovek tiez musi nieco v systeme upravit. Tipujem ze nieco podobne existuje aj pre stare systemy.

Ak mate viac ako 2GB RAM je to divne. Malo by to zvladat bez problemov tmpfs v /tmp.

Ale problem je s 'vacsinou'. Ak viac ako 50% ludom bude lepsie ked /tmp bude v pamati tak je lepsie to urobit ako default. Myslim ze takych ako ty je mensina takze si default musis prestavit.

Plně sdílím vaše rozhořčení.
Podle mě - když na podobné problémy půjdu od lesa - jde o generační záležitost. Distribuce v posledních pár letech začali ovlivňovat hošíci, vychovaní Microsoftem, kteří už moc nevědí, co to je Unix. A tak vedle drobných "vylepšení" třeba kolem adresářů čím dál víc člověka otravují nejrůznější nepřehledné slepence, "pokrokově" řešící problémy, které často vůbec neexistovaly, ale vytvářející množství zcela nových a otravných chyb.
Člověk by se někdy nad tím zblil jako Alík.

Zaplaťbůh za to, že je to pořád otevřené a můžete si to přizpůsobit. Jen te ztracený čas vás občas na.ere....

"Distribuce v posledních pár letech začali ovlivňovat hošíci, vychovaní Microsoftem, kteří už moc nevědí, co to je Unix." skuste toto napisat Linusovi ;)

Inak hosi nechapem co tu riesite. Ked tmp adresar premapujete na pevny disk, tak dost pochybujem, ze vam pojde prostredie rychlejsie. Okrem toho, ze si skor odrovnate HDD, ktory bude musiet robit castejsie R/W operacie, vam to pojde o dost pomalsie, kedze HDD operacie su podstatne pomalsie nez operacie s RAM pamatou. Inak viete preco vam to ide pomaly, ked vam dojde miesto v tmp? Je to preto, ze sa dalsie udaje zacnu ukladat do swapu, ktory je prave na HDD a preto vam to vsetko zacne sekat, takze premapovanie by bolo kontraproduktivne. Ja skor pouzivam vypinanie swapu prikazom swapoff -a. Vtedy mam istotu, ze vzdy sa pouzije iba RAM pamat. Ma to vsak nevyhodu v tom, ze vam mozu programy bud padat alebo vyhlasia, ze je malo miesta na ulozisku.

a ste si isty, ze problem mate v pamati? Totiz ja pouzivam KDE prostredie na pc ktore ma 1GB RAMky a CPU ma 9 rokov stare a ani ked som ho kupoval to nebola zrovna spicka. System, mi na nom bezi celkom svizne, pokial sa krotim v pocte spustenych aplikacii. Skusili ste uz diagnostiku, ze ci vam nieco nevyziera CPU resource alebo priliz casto nekomunikuje z HDD, lebo co sa tyka rychlosti RAMky, tak tam by problem byt nemal podla mna?

> Zadny problem v pameti nemam. Mam 2 GB a staci mi to.

Asi som to potom pochopil zle, lebo ste pisal, ze vas problem je v tom ze tmp adresar je namapovany na RAMku ale pokial ho premapujete na HDD tak to ide dobre. Ak mate pocas prace na pc RAMky dostatok, CPU neslape na plno a HDD je v poriadku, tak by som to videl na problem s HW. Skusil by som este pouzit nejake live CD distro (bez primountovania HDD), ci to aj na nom pojde vsetko pomaly. Tym aspon overite, ci to nema na svedomi nejaky SW na vasej aktualnej instalacii. Ak to pojde pomaly aj na tom live CD, tak podla mna je problem v HW.

Nesmysl to není pokud víte co děláte. Co a jak tam poběží. Mám to takhle na jednom stařečkovi a vlivo mu to krev do žil. Přece jen 1.5Gb DDR je rychlejší ako HDD.

To ano. Tu vyvztávají jiné otázky. Proč nejít na nejbližší šroťák a nevyhrabat výkonější PC či co to je za destičku? Čím je tak unikátní?
Proč se to muselo updatovat do tohoto stavu?

Hm to mě mrzí, že to nechodí jak má. Nedávno jsme kupovali Lenovo Thinkpad ze "šroťáku" s 1.5GB RAM s 1core CPU 1.6GHz a jede dobře. Až jsem se divil. napohled líp jak Athlon XP 1.6GHz. Asi lepší optimaliazce pro Intel. Nebo čip sada. Kdo ví.

To je zase celé padlé na hlavu. Aplikace chce dočasně odložit soubor na disk, nejspíš protože se jí data nevejdou do paměti. Takže vytvoříme ramdisk, aplikace tam bude odkládat dočasné soubory, a my se budeme hrozně divit, že se to - světe div se - nevejde do paměti(!). Takže nejspíš zítra vytvoříme "opravdový" temp directory na disku, naučíme všechny aplikace rozdělovat dočasné soubory na ty v temp dir a ty "opravdovém" diskovém temp dir... a budeme čekat, než nějaký inteligent ten nový FS také iniciativně narve do RAM. Pak se může celé kolečko opakovat.

Společný jmenovatel problému je Debian testing.

no neviem, to by uz chcelo pozriet sa na ten stroj osobne ale ako som uz pisal na mojom stroji s 1GB RAM to vsetko fici ako ma a tmp adresar mam namountovany na tmpfs, takze neviem v com bude u vas problem.

na 100% souhlasim, dokud byla cilem Linuxu implementace Unixu, tak to bylo jednoduche. Vsichni meli podobne zazemi, podobny rozhled a zadani bylo taky jasne. Proste vzali to nejlepsi s ostatnich Unixu trochu to poladili a implementovali.

Ted ale nestava obdobi hledani novych cest a opousteni tech slepych. Prijde mi, ze nove vizionare vubec nezajimaji stavajici reseni, oni si jdou svoji cestou, a kdyz to nevyjde tak to klidne cely prekopaji a zacnou od zacatku.
Kdyz odhlednu od tech desktopovych veci, tak me namatkou napadne detekce HW a postup bootovani, LVM(LVM1, EVMS, LVM2, MD, ...).

Zrovna vcera, jsem omylem zahnal pocitac do swapu (spustil jsem "make -j" - bez cisla). Pocitac byl uplne mrtvej, nedalo se to zabit z terminalu a nedalo se prihlasit na konzoli. S hruzou jsem zjistil, ze poradne nefunguje ani prepinani konzoli Alt+Fn. Ten novej init se necha klidne odswapovat - WTF?

Jojo, taky jsem si vsiml ze swap system v posledni dobe spolehlive zlikviduje, a celkem me to irituje.

Napriklad Mysql Workbench na mem Ubuntu ma tu vlastnost, ze pri spusteni SQL dotazu je tak 20% procentni sance ze zacne zrat pamet jak divy. UZ jsem si zvykl, ze vetsina veci spojenych s Mysql je naprd. Co me ale dostalo je, ze pokud nezareaguju dostatecne rychle - tak do peti sekund - a system zacne swapovat, prepnuti do konzole trva klidne 10 minut. Pokud to necham swapovat jeste o chvilku dyl (dalsich 5 sekund), odezva na CTRL+ALT+F? se nedostavi ani za hodinu ... dyl jsem cekat nevydrzel. Totez se mi podarilo i s javou ...

Linux pouzivam dlouha leta, a jsme presvedcen, ze pamet jsem dokazal spolehlive ucpat mnohokrat, vzdy jsem ale byl schopen pres konzoli problem vyresit. Proc to ted nejde?

Také mne zaujalo, že když darktable spolykal veškerou RAM v důsledku přehnané paralelizace z mé strany (8 GB, nemám swap) a Xka zatuhla, tak mezi konsolemi jsem se stále mohl přepínat. Jenže to bylo k ničemu, protože jsem se už nepřihlásil ani jako root.

Po půl hodině čekání jsem to vzdal...

v pripade debianu si to nenastavis, protoze to je hardcodnuty ve skriptu.

To je potom naozaj dosť divné.

Zde to jede dobře.

total used free shared buffers cached
Mem: 1507 1355 151 0 54 829
-/+ buffers/cache: 471 1036
Swap: 1699 0 1699
tmpfs /tmp tmpfs defaults,nosuid 0 0
Athlon XP 1.6GHz

Tiez som narazil na podobny (mozno aj rovnaky) problem s pomalostou GUI na starsich strojoch od 3GHz Northwood/1GB RAM az po 800MHz IP III/1GB RAM, distro Fedora od 14 vyssie, Gnome.
Mne sa zda, ze by to mohlo byt spojene s X-kom. Uz samotne vykreslovania grafickych primitiv ako ciarym kruznice, obdlzniky, vyplnove vzory su pomalsie zhruba 10 nasobne oproti distram pred Fedora 14.
Je mozne, ze je tam sucastne viac problemov, pretoze je vidiet ako sa okna prekresluju a to iba vtedy ak nastane nejaka zmena v pohybe s GUI prvkom. Zda sa mi ako keby zaciatok procesu na nieco par desiatok milisekund cakal a potom bezal takmer normalne.
Pritom vykon procesora je v norme. Ak sa spusti vypocet trebars Pi, tak to bezi normalne, len odozva GUI je nejaka divna.
Bohuzial tomu nepomoze ani ina grafika (vyskusal som 4 rozne), ani ine ovladace a dokonca ani zmena na LXDE ak sa doinstaluje a zmeni po instalacii Gnome.
Ak sa LXDE zvoli pri instalacii bez Gnome, tak to bezi vcelku rozumne. Nemozem, ale potvrdit ci to bezi lepsie na stasich strojoch ako 3GHz Northwood. Este som sa nedostal k tomu aby som to vyskusal.

Fall back?
Nesouvisí to s kontrolou změn vykreslení? Dřív bylo často defaultně nastaveno bez kontroly.

Zřejmě tohle je příčina, proč na Debianu 6 nejede video v plném rozlišení (respektive jede s cca 1/3 rychlostí oproti zvuku), zatímco na pětce na stejném železe jede zcela bezproblémově. Faktem je, že když už nějaký b*l*b udělá takovouto změnu, tak by měla být rozumně dostupná informace, jak to změnit zpět a obnovit funkčnost systému. Já to řešil downgradem zpět na verzi 5, protože počítač mám na to, aby fungoval, ne na to, aby byl "aktuální".