LTS

Szerintem nem az jut eszébe az embernek az LTS-ről, hogy egy évig szarnak magasról egy high priós bugra. Na mindegy.

"My gnome-shell is using 20.8GiB right now on my Ubuntu 16.04.2 Gnome. Still slowly increasing! Any fix?"

https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1572801

( szegecs | 2017. 04. 20., cs – 08:54 )

>Na mindegy.

"Majd hazamennek." (c) national saviour, 2006

( _ventura_ v | 2017. 04. 20., cs – 12:08 )

Ugyan már, gondolom a következő releasben majd javítják :D

Fedora 25, Thinkpad x220

( locsemege v | 2017. 04. 20., cs – 12:43 )

Ügyes. Mindeközben Fedorán Xfce és Compiz megy, fut a böngésző, levelező, meg egy rakás aprójószág:

              total        used        free      shared  buff/cache   available
Mem:           7.8G        1.1G        5.0G        168M        1.8G        6.2G
Swap:          8.1G          0B        8.1G

A Firefox-ot nem számítva a Xorg eszi a legtöbb memóriát a maga 1.3 %-ával. A claws-mail kliens is megeszik 1 %-ot a 8 GB-ból. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Gondolom, ez abból jöhetett ki, hogy nem azonos feltételekkel néztem. Fogalmam sincs, hogy a Gnome shell mit alakít Fedorán, lehet, hogy ugyanúgy vacak. Nem az volt a mondanivalóm, hogy az Ubuntu sz.r, bezzeg a Fedora jó, hanem inkább az, hogy mi a fenének használ valaki bugos software komponenst, amikor van egy rakás alternatíva. Például másik desktop környezet. Szerintem Ubuntun is jól működne az Xfce, Compiz, Emerald összeállítás.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Be kellett volna zárnom a Firefoxot, mivel az falta fel a RAM nagy részét. Ezen felül jellemzően ez nem hízik, nem látok komolyabb memory leak-re utaló jelet.

Amúgy jelez a troll detektorom, tudniillik ez ebben az esetben nem bug, legfeljebb neked nem tetszik. ;)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nemreg irtal egy programrol, amiben 20 eve!!! nem voltak kepesek kijavitani egy egyszeru jpeg importot, meg hogy mukodjon egy 16 eves OS-en. Es meg a juzer a hulye, mert nem olvasta el a leirasat, hogy az a funkcio bugos.

Egyebkent demoscene-ben mennyire hasznalnak IFS-t? Mert ott jol ki lehetne hasznalni a kibontas gyorsasagat, kelloen lecsokkentheto a merete, a tomorites meg nem szamit. Meg lehet benne jovo.

--
A strange game. The only winning move is not to play. How about a nice game of chess? - Wargames

>nem voltak kepesek kijavitani egy egyszeru jpeg importot

ez melyik program ez

>mukodjon egy 16 eves OS-en

dehát működik

>Es meg a juzer a hulye

dehát a júzer a hülye, lásd a readme kapcsán olvasottakból összehallucinált hagymázas tévelygéseit, valamint

>mert nem olvasta el a leirasat

hogy milyen OS-en kell operálni

Természetesen nem, de ha valamit hosszú időn át nem orvosolnak, s az zavaró, akkor van workaround. Most dicsekedjek el azzal, hogy - vélhetően - az emerald egy bugja miatt nagyon ritkán elhasal a dekorátor, kompozitor kombó? Írtam rá egy daemont, amelyik ezt kiszúrja, majd néhány másodperc elteltével újraindítja a compizt, emeraldot. Havonta egyszer talán.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Jogos. Különben azért, mert ez a bug ritkán jön elő, nem zavar, így meg pláne nem, hogy egy deamon újraindítja, ha elhasal. Meg azért, mert megszoktam, olyan szolgáltatásokat nyújt, amelyeket más környezetben hiányolnék, beköltöztem, ismerem, a nyavajáival meg együtt tudok élni. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Azt mondtam csak, hogy van erre lehetőség. Ha nagyon zavaró buggal találkozom, magam is eldöntöm, hogy jelzem a hibát a fejlesztőknek - elsősorban ezt szoktam tenni -, elviselem a hibát, valamilyen workarond-dal megkerülöm azt, vagy másik, hasonló funkcionalitású eszközt választok.

Épp jött Fedorához új nouveau driver a Xorg-ba, amelytől elhasalt az X, ha elindult a Compiz. Jeleztem a hibát, már van új build, ez már működik jól.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Kekeckedésnek érzem, amit teszel. Felőlem használjon bugosat is, csak azt, s ha jön javítás, fel se tegye a gépére. Mondtam fentebb, értem az érvelésed, mert lehet érzelmi oka is a ragaszkodásnak, vagy olcsóbb a buggal együttélni, mint új alrendszerre migrálni. Az volt a mondanivalóm lényege, hogy mindenképp van megoldás, legfeljebb mérlegelendő, melyik jár kisebb fájdalommal.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( zaphodb v | 2017. 04. 21., p – 07:52 )

szüzmária, akár 1GB-ot is fogyaszt egy desktop os (minden sallangjával), most mi lesz?

nekem meg az a bajom, hogy van 9GB swap, de amikor 2GB-ot swapol, akkor az oom-killer kinyír valamit. pedig idő van, ráérnék kivárni.

tudtam, hogy tetszeni fog :)
akinek meg fáj az ubuntu memóriahasználata, annak nem kötelező azt használni, lehet 200MB-al szaladgáló OSX-et is. 


$ top -bn1 -o RES | head -n 20
top - 14:33:15 up 6 min,  2 users,  load average: 0,03, 0,25, 0,16
Tasks: 195 total,   1 running, 194 sleeping,   0 stopped,   0 zombie
%Cpu(s):  6,1 us,  2,9 sy,  0,0 ni, 88,2 id,  2,8 wa,  0,0 hi,  0,0 si,  0,0 st
MiB Mem : 12045,94+total, 10666,73+free,  410,227 used,  968,977 buff/cache
MiB Swap: 9319,992 total, 9319,992 free,    0,000 used. 11311,80+avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 2954 user      20   0 1738,5m 169,0m  78,1m S   6,2  1,4   0:12.54 cinnamon
 2362 root      20   0  409,6m 119,5m  53,9m S   0,0  1,0   0:35.29 Xorg
 2831 user      20   0 1205,9m  50,2m  42,7m S   0,0  0,4   0:00.84 cinnamon-settin
 3119 user      20   0  635,3m  43,7m  27,9m S   0,0  0,4   0:00.48 cinnamon-screen
 1290 root      20   0  800,9m  33,4m  25,3m S   0,0  0,3   0:00.43 libvirtd
 2970 user      20   0  508,5m  30,7m  25,7m S   0,0  0,3   0:00.18 nm-applet
 2936 user      20   0  184,2m  30,3m  20,6m S   0,0  0,3   0:00.15 cinnamon-launch
 2969 user      20   0  404,2m  30,1m  20,7m S   0,0  0,3   0:00.13 cinnamon-killer
 2718 user      20   0  420,1m  23,4m  17,6m S   0,0  0,2   0:00.23 cinnamon-sessio
 2965 user      20   0  318,2m  19,3m  16,1m S   0,0  0,2   0:00.05 polkit-gnome-au
 1089 root      20   0  439,6m  16,1m  13,1m S   0,0  0,1   0:00.52 NetworkManager
 3480 user      20   0   82,4m  14,5m   5,5m S   0,0  0,1   0:00.22 xterm
 2942 user      20   0  490,3m  13,3m  11,6m S   0,0  0,1   0:00.02 csd-printer

( NevemTeve | 2017. 04. 21., p – 09:18 )

Ha ez nem Pöttering érdeme, akkor nem tudom kié. Valószínűleg a /usr/systemd/memleakd csinálja, és nem bug, hanem feature.

( Huncraft v | 2017. 04. 21., p – 11:55 )

Most komolyan átnéztem a bugreportot, de hú se sok használható adatot nem találtam arról, hogy pontosan ki és hogy is csinálta a méréseit (avagy honnan jönnek a számok). A legtöbben inkább csak picsognak. Így nem csoda, hogy nem nagyon tudnak haladni a fejlesztők szerintem
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Sajnos itt tartunk: a Linux már nem Unix, hanem egy gyengébb de ingyenes Windows; a felhasználók sem programozók/mérnökök/tudósok, akik esetleg képesek egy-egy hibát önállóan bemérni és használható bugreportot írni, hanem egységsugarú Fecók és Jucusok. Így romlanak el a tranzisztoros rádiók a világban.

Az egy dolog, de a fejlesztők közül se sok volt aki kapkodta volna magát, hogy ha valaki ilyet tapasztal, akkor legyen már szives ezt meg ezt megfuttatni és beküldeni, és nem csak beírni egy random adatot amiről azt se lehet tudni, hogy honnan jött.
Mondjuk azért tényleg lehet érdemes lenne elgondolkodni valami memory profilozó utility-ről (svmon?) ami szépen megmondaná, hogy 1-1 processnek pontosan mekkora a fizikai/virtual/paged memória használata, illetve esetleg átnézné, hogy a memória foglalás pontosan hogy is oszlik el (hány page-nyi application stack, esetleges kernel segment, plusz private memory). Az már csak hab lenne a tortán, ha az egyes alkalmazások írnának is valami olyan API (vagy szerű) call-t amin keresztül a private memória is profilozható lenne. Ez meg esetleg a proc stack már elvileg bőven elég kéne legyen, hogy legalább elkezdhessenek 1-1 nyomozást a fejlesztők és nem kéne minden progiban külön-külön implementálni ezt 60 féle módon
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

És tényleg! /proc/${PID}/smaps.. De akkor meg pláne nem értem, hogy miért nem fordítanak a fejlesztők időt legalább ennek az adatnak a bekérésére (összedobni erre egy scriptet innen már ujjgyakorlat)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

$ uname -a
Linux zolti-desktop 4.4.0-72-generic #93-Ubuntu SMP Fri Mar 31 14:07:41 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

$ top -bn1 -o RES | head -n 40
top - 19:47:07 up 10 days, 32 min, 1 user, load average: 0,13, 0,25, 0,36
Tasks: 238 total, 1 running, 237 sleeping, 0 stopped, 0 zombie
%Cpu(s): 30,4 us, 5,8 sy, 0,1 ni, 63,0 id, 0,3 wa, 0,0 hi, 0,3 si, 0,0 st
KiB Mem : 16125680 total, 3768176 free, 6782296 used, 5575208 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 7190880 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
14141 zolti 20 0 2894420 971752 185372 S 0,0 6,0 83:55.45 chromium-browse
17005 zolti 20 0 2065516 781084 128652 S 0,0 4,8 33:28.45 qtcreator
14565 zolti 20 0 2059036 660864 117976 S 0,0 4,1 14:54.48 qtcreator
31071 zolti 20 0 2061676 621872 121148 S 0,0 3,9 9:56.03 qtcreator
1049 zolti 20 0 736028 396372 276712 S 6,2 2,5 116:48.61 Xorg
28948 zolti 20 0 1916852 389052 119672 S 0,0 2,4 0:19.47 qtcreator
1336 zolti 20 0 2010420 362392 68456 S 0,0 2,2 72:59.39 gnome-shell
9063 zolti 20 0 2189164 311660 107632 S 0,0 1,9 5:45.93 firefox
14222 zolti 20 0 1248624 294144 171404 S 0,0 1,8 30:14.77 chromium-browse
20164 zolti 20 0 2035040 254524 46960 S 0,0 1,6 0:48.08 dropbox
29427 zolti 20 0 1856316 230900 85560 S 0,0 1,4 18:53.73 chromium-browse
27637 zolti 20 0 1825292 230108 83884 S 0,0 1,4 0:37.68 chromium-browse
9543 zolti 20 0 1844328 229204 81352 S 0,0 1,4 0:40.22 chromium-browse
1542 zolti 20 0 1313288 224688 30824 S 0,0 1,4 0:16.80 gnome-software
19431 zolti 20 0 1891936 222260 95472 S 0,0 1,4 0:35.98 chromium-browse
28313 zolti 20 0 1800520 216076 79964 S 0,0 1,3 7:23.98 chromium-browse
6591 zolti 20 0 1814316 209888 68252 S 0,0 1,3 0:36.26 chromium-browse
17474 zolti 20 0 1828916 207300 87824 S 0,0 1,3 0:29.71 chromium-browse
17451 zolti 20 0 1827008 200668 97640 S 0,0 1,2 0:47.67 chromium-browse
14820 zolti 20 0 1795060 190004 76904 S 0,0 1,2 0:06.06 chromium-browse
3915 zolti 20 0 1779056 187284 78864 S 0,0 1,2 11:39.82 chromium-browse
1534 zolti 20 0 1693056 179324 60564 S 0,0 1,1 4:14.00 nautilus
22128 zolti 20 0 1784824 173740 67264 S 0,0 1,1 0:13.78 chromium-browse
11894 zolti 20 0 1776860 172764 77644 S 0,0 1,1 0:17.37 chromium-browse
32684 zolti 20 0 1749632 161268 65780 S 0,0 1,0 0:28.87 chromium-browse
1457 zolti 20 0 1053192 133944 29260 S 0,0 0,8 0:15.28 goa-daemon
14253 zolti 20 0 1685440 117772 59440 S 0,0 0,7 0:17.81 chromium-browse
18156 zolti 20 0 1663416 104008 66220 S 0,0 0,6 0:01.62 chromium-browse
14274 zolti 20 0 1669780 103984 59952 S 0,0 0,6 0:19.55 chromium-browse
14287 zolti 20 0 1669752 100740 60840 S 0,0 0,6 0:10.57 chromium-browse
30485 zolti 20 0 1073420 94160 51864 S 0,0 0,6 0:29.12 server
29152 zolti 20 0 1660036 90444 62740 S 0,0 0,6 0:02.24 chromium-browse
14297 zolti 20 0 1663084 88884 59576 S 0,0 0,6 0:03.73 chromium-browse