Изпечатай

[leta4]

Radislav_Debian, как го постигаш това  Mem<=60% ? И аз съм с 256 SD, Дебиан.Доскоро бях с XFCE, но реших да потърся нещо по леко та се спрях на WindowMaker. Определено му олекна на компа, но памета си е натоварена и  е повече от 60%.  Гледам да използвам повече конзола, но пак си се мъчи.Не съм много  запознат затова ще съм ти благодарен ако споделиш това-онова.

[Radislav_Debian]

Не съм направил нищо особенно.
Незнам какво имаш предвид.
Компиливал съм си ядро без инитрамдиск (initrd), вътре ((не като модул, иначе: "kernel panic ...") съм компилирал IDE драйвъра, и root файловата сисъема - ext2 (на лаптопа не ми трябва журнална), във подменю - процесор (menuconfig ползвам) съм задал междинни варианти (компромис м/у сеървър и десктоп), като малко падна  response-a (с десктоп опцията и за най-малкото нещо скача на 100% CPU-то).
Плейърите също съм си компилирал за да не ми засичат динамично мултимедийните разширения на процесора. А audacious защото в бинарен вид идва без потдръжка на encodings (cp1251 в слуячая ми трябва).

Имам пуснат pure-ftpd  (компилиеран без излишните глезотии)- за да ми уплоадват и теглят някакви неща (понеже доста мой приятели са зад рутери и директ кънекшъна е еднопосочен).

Спрял всякакви излишни daemons: ssh, exim, portmap, openbsd-inetd, inetd, който не ползвам а и нямам намерение.
Ползвам BlackBox. xterm е локализиран на cp1251 (този Unicode не го обичам - цели два байта на знак Базикам се, но предпочитам cp1251).

И това е, напълно нормално дебиан десктопче.

Screenshot

П.С. скрииншота е правен със scrot, а за графиките използвам conky.
  Надявам се, че бях достатъчно изчерпателен, и успех.

[leta4]

Компилиране на ядро ми звучи малко страшно ама и на него ще му дойде ред, само да имам повече време.  Вместо да давам 50 лева за 256 SD RAM  предпочитам да понауча това онова пък парите ще ги пазя за нов компютър '>. Благодаря

[ilian_BIOS]

Да наистина GUI-to на Windows XP върви бая по бързо от колкото GNOME-то на дебиана ми, ма усещащо се по бързо, kakто и самия windows като че ли, и като по време на зареждане на системата pff (мисля си че всичко идва от с извинение лайняния X сървър, но какво да го правим...), както и самото зареждане на програмите, пък говорим за 1 ГБ рам '>, не да каже 256 да има за какво да се хванеш, ами 1гб., не знам ако искайте ме ругайте и тем подобни, но който иска да се отбие до нас и да направи сравнение , защото не ми вярват...

[gat3way]

Цитат

GUI на Уиндос е вградено в ядрото, докато при Линукс Х е сървър, т.е отделно приложение.

Нито едното твърдение е 100% вярно, нито другото. При уиндоус, една немалка част си е userspace-ска. При линукс на практика, графичният драйвер си е kernelspace, като при това се offload-ват немалко неща върху хардуера.

Цитат

Имах предвид, че има прекално много "високи" библиотеки във Linux, като водещи са GTK и Qt. Хипотетично нека имам две приложения, като всяко едно ползва едната от гореспоменатите и се оказва, че имам библитеки в паметта които правят едно и също. Да не говорим, че повечето линукс приложения ползват и куп други странични библиотеки. Нямам нищо против динамичния подход, но товари. Докато виндовс има едни kernel32.dll и user32.dll (за това обичах да пиша на асемблер за виндовс навремето '>)

Идеята на .so-тата е същата като на .dll-тата, това са shared библиотеки. Надали има дистрибуция със статично "билд-нат" X server и wm. Просто би било нещо заемащо ненужно много дисково пространство (и РАМ). Естествено, тази идея не е перфектна и много често един и същ код стои на няколко места в паметта, но това се случва и при двете операционни системи. Проблемът е по-скоро архитектурен и следва от това, че един процес без специално да се погрижиш за това, не може да адресира паметта на друг такъв. Вероятно може някоя голяма глава да пач-не ядрото така, че shared libs да се зареждат в регион от паметта, достъпен за всички процеси. Това обаче ще доведе до доста по-бавен context switching и не мисля, че е много добра идея (особено например за един натоварен уеб сървър, който форк-ва доста процеси/нишки).

Мисля, че нещата са далеч по-сложни от недоглеждане в софтуерния дизайн '>

[tarator]

> Просто би било нещо заемащо ненужно много дисково пространство
> (и РАМ).

За диска е вярно, за паметта не.

> Това обаче ще доведе до доста по-бавен context switching и не
> мисля, че е много добра идея

Не виждам как това ще направи context-switching-а по-бавен.

[gat3way]

За паметта - също.

Цитат

router:/proc# cat 15573/maps |grep crypt-2 a7ef4000-a7ef9000 r-xp 00000000 fe:01 296968     /lib/tls/libcrypt-2.3.6.so router:/proc# cat 15864/maps |grep crypt-2 a7d33000-a7d38000 r-xp 00000000 fe:01 296968     /lib/tls/libcrypt-2.3.6.so

Цитат

Не виждам как това ще направи context-switching-а по-бавен.

Ще го направи - нямаше да го направи, ако нямаше paging, но при това положение ще имаш още няколко операции при context switch-a, за да знае откъде да го вземе, дали не се е swapin/swapout-вало по време на изпълнение на другия процес например. Вероятно това може да се реши по някакъв начин, но ако става въпрос за два отделни процеса, не мисля че има начин да се спестят проблемите с paging-a '>

[tarator]

Това, че виртуалните адреси в двата процеса са различни не означава, че има две реални копия на библиотеката в паметта.

> Ще го направи - нямаше да го направи, ако нямаше paging

Paging-а не променя нищо.

[gat3way]

Цитат

Това, че виртуалните адреси в двата процеса са различни не означава, че има две реални копия на библиотеката в паметта.

Мисля, че малко надценяваш възможностите на ELF loader-a. Когато се наложи да се ползва функция от някоя динамична библиотека, то кода й се копира във "виртуалната" памет на процеса. Така че реално погледнато е съвсем нормално един и същ код да присъства в паметта. Обратното би било малко странно. От гледна точка на процеса, всичко е виртуална памет, не можеш да правиш CALL @blabla и функцията blabla да не ти е мап-ната във виртуалната памет.

Цитат

Paging-а не променя нищо.

Защо мислиш така?

[tarator]

> Мисля, че малко надценяваш възможностите на ELF loader-a. Когато
> се наложи да се ползва функция от някоя динамична библиотека, то
> кода й се копира във "виртуалната" памет на процеса.

Погледни кода на ld.so. Динамичните библиотеки се "зареждат в паметта" с mmap(..., MAP_SHARED, ...), което казва на ядрото да използва едни и същи страници, евентуално map-нати на различни адреси в различните приложения. Библиотеките се компилират с -fPIC, което прави кода им да работи независимо къде са map-нати.

> Защо мислиш така?

Ами защото няма код, който специално да проверява, дали някоя страница е във физическата памет или не. Ако не е в паметта, приложението получава page fault, който се обработва от ядрото, зареждайки съответната страница от backing store-а.

[gat3way]

Цитат

Погледни кода на ld.so. Динамичните библиотеки се "зареждат в паметта" с mmap(..., MAP_SHARED, ...), което казва на ядрото да използва едни и същи страници, евентуално map-нати на различни адреси в различните приложения. Библиотеките се компилират с -fPIC, което прави кода им да работи независимо къде са map-нати.

Нема нужда, има по-лесен начин:

gat3way:~# ldd /bin/date
        linux-gate.so.1 =>  (0xffffe000)
        librt.so.1 => /lib/tls/librt.so.1 (0xb7f57000)
        libc.so.6 => /lib/tls/libc.so.6 (0xb7e1f000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb7e0c000)
        /lib/ld-linux.so.2 (0xb7f7a000)
gat3way:~# strace /bin/date
execve("/bin/date", ["/bin/date"], [/* 35 vars */]) = 0
...
open("/lib/tls/libc.so.6", O_RDONLY)    = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260O\1"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1270928, ...}) = 0
mmap2(NULL, 1276892, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7e49000
...
open("/lib/tls/libpthread.so.0", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340G\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=85770, ...}) = 0
mmap2(NULL, 70104, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7e36000
...
open("/lib/tls/librt.so.1", O_RDONLY)   = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\35\0\000"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=30612, ...}) = 0
mmap2(NULL, 29264, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7f81000


PRIVATE е при мене, всъщност не знам..

Иначе библиотеките се компилират с -fPIC главно заради големите удобства, които се предоставят по този начин. Примерно, реферирането на някаква променлива, глобална за функцията от библиотеката би било забавна играчка. Съществуването на 2 функции с едно и също име в рамките на библиотеката и на програмата, линк-ната с нея също би довело до доста ядове (примерно).

И накрая, ld.so се грижи за a.out, не за ELF бинарни файлове (които се използват в 99.99% от случаите днес). За второто - ld-linux.so '>

[luda_glawa]

Само да спомена една среда - FVWM-Crystal. От всички които съм използвал досега, най-много ми харесва.

http://www.linux-bg.org/cgi-bin....1676630

[tarator]

gateway,

Интересно, ще погледна пак кода като отида на работа. А за ld.so и) ld-linux.so -- двете са абсолютно едно и също нещо, погледни пак :

[tarator]

Блах, кода е доста сложен, няма да имам време да го разучавам този месец. Другия месец, като минат Usenix и Ottawa Linux Symposium може да имам повече време да го разгледам.

BTW, ако някой ще ходи на Usenix или OLS, да свирка, може да се видим там...

[Radislav_Debian]

С прости думи: повтарящият се код намалява времето за изпелнение, и заема повече памет, а неповтавящият се пести памет и е по-бавен.
Тука кривоглед станах ... с вашия спор, a предполагам е същото и при другите наблюдатели (читатели).
Общото адресно пространство за shared libs е интересна идея идея (за някоя RISC архитектура), но такова в Protected mode на i386 съм виждал само при  win 3.11, впрочем то там вскичко е общо - 16MB ram. (real mode не коментирам - тогава живота е бил лесен '>).

Айде млъквам, че при толкова *nix гурута, ставам смешен, с мойте изветрели виндовс/дос спомени. '>

ilian_BIOS@ каза: "... , но който иска да се отбие до нас и да направи сравнение ..."
Tова си е 100% покана. '>
У вас бира има ли? Ще идваме целия форум!
Ще пием и ще играм netris в мрежа. '>  хаха.
moonbuggy и netris ... прости и гениални!