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

Nič v zlom, Linux mám rád, ale zrovna toto sú fakt "problémy" ktoré treba akútne riešiť...

Pokud máte pocit, že je třeba řešit jiné problémy, nikdo Vám nebrání se jakkoli angažovat.

Verte mi, že keby som dokázal veci pomôcť, rád to urobím. Nie každý je dostatočne zdatný, aby mohol linuxu pomôcť technicky ako programátor. Ja sa skôr snažím presadzovať ho medzi užívateľmi vo svojom okolí.

Nemajte mi to za zlé, (zrejme málo vidím do problematiky) ale myšlienka "dohodneme sa na zmene" vo mne vyvoláva obavy, že žiadne pozitíva nebudú ale že to zasa bude o tom, že niekto to implementuje a niekto nie.

To je zahada. Ako moze byt disk rychlejsi ako pamat? Aj na starom stroji. Mozete to vysvetlit?

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.

Jo, zvlada. Ze cenu zpomaleni a za cenu toho, ze rada veci nejde, protoze neni misto v tmp. A dost me desi, ze i Debian to natvrdo a bez ptani zmenil.

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.

1. Nekdo testoval, u kolika % uzivatelu to je lepsi? Testoval to nekdo na slabsich strojich nebo jenom novych? A kolik % budeme pozavazovat za dostatecne na to, abychom to natvrdo, bez ptani prestelovali? Jestlize to zpusobi potize pouze 1/4 uzivatelu, je to porad moc. Krome toho, instalator by mohl alespon zjistit velikost pameti, protoze ne kazdy ma 16 GB a na strojich s mene pameti mit default na disku. Aby se nestavalo, ze se neda vypalit CD nebo treba vygenerovat initrd. Treba netbooky maji typicky 1 GB pameti a nebeha jich po svete malo. Notebooky mivaji vic, ale casto to ma k 16 GB daleko.

Trvalo mi chvili, nez jsem vygoogloval, o co go. Zretelne jsem s tim problemem nebyl jediny, ale vsichni si akorat stezovali, tech, co nabizeli reseni, bylo pomalu. Predstavte si BFU s Linuxem, jak se mu tohle stane a reseni je utajeno nekde hluboko v databazi Google. Tak takto Linux mezi BFU moc nedostaneme.

2. Kdyz jsem mel /tmp na disku a nekdo se rozhodl, ze je lepsi v pameti, povazoval bych za inteligentnejsi, aby mi to instalator oznamil, ze mi hodla zmenit zavazne nastaveni a eventuelne mi dal na vybranou a rekl, kde dane nastaveni najdu. Nekdy se instalatory ptaji na veci, ktere me vubec nezajimaji, ale na toto se vykasle.

3. Jestlize to zpusobuje pokles vykonu (nebo minimalne zhorsuje odezvu GUI) na mych dvou slabsich strojich, existuje slusna sance, ze to zpusobuje stejny problem na silnych strojich take nebo alespon na jejich nezanedbatelne podmnozine, akorat si toho uzivatele nevsimnou, protoze jejich stroj je rychly. To je nesmyslne plytvani vykonem ve stylu MS.

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.

> 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.

To asi tezko. Hned po nabehnuti stroj s 2 GB nevycerpa dostupnou pamet, ani kdyby na nem jelo KDE, tim mene moje LXDE. Pameti je volne dost, nicmene stroj, hlavne GUI je pomalejsi. Jiste tam nekde je zakopany pes, ale bude nekde jinde.

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?

> a ste si isty, ze problem mate v pamati?

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

> Skusili ste uz diagnostiku, ze ci vam nieco nevyziera CPU resource alebo priliz casto nekomunikuje z HDD

Podle grafu v systrayi CPU nic moc nedela a disk jen obcas blikne. BTW, kdyby problemem bylo pretizeni disku, tak presunem tmp na disk by se rychlost spis zhorsila, nez zlepsila.

> 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.

Celkem neverim, ze by se na dvou strojich z ruzne doby a s odlisnymi specifikacemi vyskytl stejny HW problem nebo stejny SW zpusobujici zpomaleni. Jedno je stara instalace Debian testing s LXDE, druhe je na Debianu testing a Mepisu zalozeny Antix s IceWM ocesany na minimum.

Je stejne celkem jedno, cim to zpomaleni je zpusobene. I kdyby se problem podarilo nakrasne vyresit, tak pokud mi budou padat aplikace na nedostatek mista v tmp, tak skutecnost, ze budou padat rychleji, mi nepomuze. Davat tmp na tmpfs na stroji s 2 GB pameti (v druhem pripade dokonce jen 196 MB) je nehorazny nesmysl. Tohle mel nejaky konfigurator otestovat, dat mi na vybranou a upozornit me, ze pameti neni zrovna moc. Anebo se do toho nemel nikdo stourat a poslat rootovi mail se sdelenim, ze se tmp nyni muze dat na tmpfs a jak se to udela.

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.

Jiste, pokud to treba delate vy a ne nekdo za vasimi zady, kdo vam prestavuje veci v systemu a ani vas neupozorni, ze se neco muze podelat, protoze bydete mit malo mista v tmp.

Ja mam jeste vetsiho starescka s 196 MB SDRAM a toho to totalne zabilo. Pozoruhodne je, ze na desktopu s DDR pozoruji zpomaleni take.

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?

Je to notebook, tam toho moc nevymenim, vic pameti neumi. A notebooky na srotaku jsou vetsinou uplne pro kocku, jeste horsi nez ten muj nebo naprosto zdevastovane, eventuelne oboji. V podstate se da pouzit akorat jako terminal k necemu - ma docela dobry display. Ale jinak na prd. Rychlost celkem ujde, ale staci spustit browser a za chvili se ucpe pamet. Linux jsem tam strcil jen tak ze zvedavosti. Ale pri laborovani s timhle kramem jsem zjistil problem s tmp na tmpfs. A pak jsem zjistil, ze prehozeni tmp na disk prinasi zrychleni i na mem o dost modernejsim desktopu. K cemuz ale doslo az tehdy, kdyz jsem nedokazal vypalit CD, protoze nebylo misto v tmp a zjistoval jsem, jak je to mozne.

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í.

„Jiste, pokud to treba delate vy a ne nekdo za vasimi zady, kdo vam prestavuje veci v systemu a ani vas neupozorni, ze se neco muze podelat, protoze bydete mit malo mista v tmp.“

Pokud se jednalo o nějakou testing distribuci, jsi si jistý, že to neproběhlo mailing listem a případně dalšími informačními kanály?

Pokud se jednalo o stable distribuci, pak ano. V takovém případě by to bylo špatně.

Jisty si nejsem, ale myslim si, ze na takovou vec by mel clovek byt nejak upozornen, treba z dpkg pri instalaci. Kdyz se to pta na jine veci, muze i na toto. Zejmena, kdyz hrozi, ze se najednou clovek ocitne s nedostatecne velkym tmp a neco prestane chodit.

Tak v praxi by se vývojáři aplikací a tvůrci distribučních balíků měli v první řadě snažit, aby nebyl /tmp zneužíván (ano, tu změnu provází určitá pravidla)
pro velké soubory, které mají být na disku.

Aha. A kam treba maji dat soubory pri tvorbe CD nebo DVD? Ty typicky mohou byt akorat velke.

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.

Presne. Ale utesuji se tim, ze je to Linux a tedy si to mohu presunout tam, kam chci. Kdyby s touhle debilitou prisel Microsoft, urcite jedinym resenim by bylo pridani par desitek gigabyte pameti. :-)

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.

Neverim. Ten stroj je sice stary vrak, ale po nabehnuti IceWM mu porad zbyvat tak tretina pameti volna, jestli se dobre pamatuji. Mozna i vic. A pak staci pustit xterm, v nem mc a je to tak pomale, ze nez se presune kurzor, clovek by vyletl z kuze. Po prestehovani tmp na disk se sice kurzor nepohybuje rychlosti svetla, nicmene se s tim da normalne delat. Zrychleni je nejmene nekolikanasobne.

To je potom naozaj dosť divné.

To nevim, zejmena, kdyz na te stare plecce jede disk na PIO 4.

Ale na novejsim stroji s P 4 a 2 GB pameti jsem pozoroval zrychleni po presunu tmp zpet na disk take. Tedy krome toho, ze jsem najednou zase mohl vypalit CD.

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.

1) tmpfs pouzivam uz tak dlouho, ze ani nevim jak. A zacal jsem s tim uz v dobe, kdy Debian (unstable) o necem takovem neuvazoval
2) kazdy stroj s 2 a vic GB RAM, zadne zpomaleni jsem nezaznamenal.
3) na mem aktualnim debianu unstable na notebooku jsem zjistil, ze tmpfs neni zapnute... Nijak jsem to po instalaci neovlivnoval. Prvni co mne napadlo, bylo podivat se do /etc/default/ . A hle, zde je soubor tmpfs, sem vkladam relevantni cast:


...

# mount /tmp as a tmpfs. Defaults to no; set to yes to enable (/tmp
# will be part of the root filesystem if disabled). /tmp may also be
# configured to be a separate mount in /etc/fstab.
#RAMTMP=no

# Size limits. Please see tmpfs(5) for details on how to configure
# tmpfs size limits.
#TMPFS_SIZE=20%VM
#RUN_SIZE=10%
#LOCK_SIZE=5242880 # 5MiB
#SHM_SIZE=
#TMP_SIZE=

# Mount tmpfs on /tmp if there is less than the limit size (in kiB) on
# the root filesystem (overriding RAMTMP).
#TMP_OVERFLOW_LI­MIT=1024

...

Takze z meho pohledu nevidim zadny podraz na uzivatele v podobe zakerneho meneni za uzivatelovymi zady.

4) pokud mam problem, tak vypis prikazu df a letmy pohled napovi. Potom snad neni problem vytvorit iso jinde.

Divne. U me to nastaveni je tusim v /etc/default/rcS a Debian je to take.

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í".

Mozno to bol zavaznejsi problem nez vieme.

v linuxe sa problemy neriesia, v linuxe iba denne vznikaju nove a nove zbytocne forky ;)

Není tam překlep? Lepší by bylo /vař/rum a rum?

/destiluj/spiritus
/destiluj/slivka
/destiluj/cokoliv
/koštuj
/slopej
/dev/zvracej
/dev/fuck/you/bill

mapujte dle libosti. Unix to zkousne !!!