Hol van a memóriám?

 ( zolpet | 2011. március 29., kedd - 7:53 )

Bekapcsoltam ma reggel a gépet, megnyíltak a tegnapi dolgaim, 2 böngészőablak összesen 7 tabbal, 1 msn, 1 skype, 1 pdf olvasó, 2 file kezelő és 1 terminal.
Memóriahasználat 1 gb felett.

Nézegettem a processzeket, valóban elég sok memóriát használnak, de hiába adom össze, ennyi azért nem jön ki.

És ami viccnek is rossz:

python /usr/bin/printer-applet -> 34 Mb

WTF? Elképesztő.
Ennek a dupláján elvileg elfutott az első XP. 98 alatt elég komoly játékokkal játszottunk ennyi rammal szerelt gépen. Most meg belefér egy ratyi nyomtatásvezérlő applet.

Chromium 1 db HUP tabbal -> 200Mb.

Érdekes.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

"Ennek a dupláján elvileg elfutott az első XP. 98 alatt elég komoly játékokkal játszottunk ennyi rammal szerelt gépen. Most meg belefér egy ratyi nyomtatásvezérlő applet."

Hanyag programozás...

mar megint hulyeseget szoltal :)
nem 'hanyag programozas', egyszeruen valtoznak az idok, modszerek
libeket egymasra epitve fejlesztenek, modulokbol vannak osszerakva, fontosabb hogy rovid ido alatt jol hasznalhato, atlathato kod keszuljon, konnyen megertheto legyen, az nem kritikus szempont hogy 50 helyett csak 30 MB RAMot hasznaljon egy alkalmazas
plusz pl egy bongeszo eseteben siman hasznalhat sajat pici adatbazist, memoriaba cache-el, stb, stb...
-
Slackware current / OSX Snow Leopard

Az odáig rendben van, hogy a böngészők mindig is sokat zabáltak. A modularitás is ok.

De egy mai átlagos pc 1-2 giga ramjának ne foglalja már el 1,5-3%-át egy nyomtató tálca alkalmazás, mikor nyomtató sincs a géphez csatlakoztatva. Ebből kiindulva ugyanez a cucc 1 giga ramot fog foglalni 15 év múlva?

Ha nincs nyomtató, kapcsold ki az appletet. ;) Testreszabás, ugyebár.
--
Coding for fun. ;)

^- the cancer that is killing IT

Ma reggel megvolt. 2 napja van fent a KDE, de még nem vettem észre, hogy ott van, mert összezsugorította az értesítési területet, és így nem látszott.

ha van 1 tera ram a gépben, akkor nyugodtan. De ha ennyire zavar, rakj fel egy 6.22 -es dos-t, ott nem lesznek memória gondok

mellékhatásként több és jobb játék is rendelkezésre áll majd a tuxracer helyett

:)

Tudsz ajánlani hozzá drivereket, egy biztonságos böngészőt, egy irodai csomagot, csevegőklienseket, meg ami még kell a napi használathoz?

pci-ne2k
arachne
word.exe
valamelyik irc kliens
desqview
mpxplay.exe
vc.com (ennek nincs unixos alternatívája se:)

Ez már döfi! Hanyas Word-re gondoltál?

word 5.5 for dos-t eléggé kedveltem

Annyi vele a baj, hogy haver szerint rosszul nyitja meg a PPT-ket. :(

and nothing of value was lost.

Vannak hasznos PPT-k is, csak nem körlevélben jönnek.

és a kiterjesztésük .keynote

vc.com -mal vitatkoznék, legyen akkor már necromancer's dos navigator. :)
mai napig nem készült olyan jó filemanager. :)

dn bloat

én imádtam, tudott mindent. :) (mondjuk annyiban igazad van, hogy rengeteg fass'ágot nem használtam belőle, kezdve a cd playerrel, a naptárig, tetrisig bezárólag...)

teljesen mindegy, mert dn-t megközelítő util _sincs_ unixra

pedig mar sok eve openszosz
nyugodtan nekiallhatsz egy fasza valtozat portolasanak ;)
-
Slackware current / OSX Snow Leopard

én nem vagyok kóder, csak gondoltam az around-the-world-many-eyeballs kft.-ből lehetne legalább 1 darab, aki egy 64kb-os COM állomány funkcionalitását meg tudja valósítani

az altalad emlitett 64kb-os com allomany (nyilvan a Volkovrol beszelsz) funkcionalitasabol mit nem tud mondjuk a midnight commander?

MOD: ja rajottem, nem tud MEGHAJTOT valtani :D
-
Slackware current / OSX Snow Leopard

amugy en akkor sz*pnam le magam, ha egy total commander szeruseg lenne unixra.
ami "klonok" vannak, azok egy viccek.
(a javas megoldasok kulon rohogogorcsot szoktak kivaltani belolem.)

izles dolga, most eppen windowson kell dolgoznom, kerdezte a ceg hogy kell-e TC licence, de nem kellett, en a FAR-t szoktam/szerettem meg
Linuxon meg az mc-t, szoval nekem nem hianyzik grafikus commander :)
bar teny, hogy mikor utoljara neztem oket (4-5 evvel ezelott) akkor nem volt igazan fullos
-
Slackware current / OSX Snow Leopard

vagy legalabb egy FAR manager is jol jonne...

1. sebesség
2. méret
3. look
4. alt gombbal kapcsolatos bármilyen funkcionalitás
5. panel on/off
6. ctrl \
7. külön sort menü--
8. pulldown menü shadow
9. értelmes használata az ansi grafikának
10. glib--
11. sigbus--
12. shift+f4

1) van, soha nem ereztem meg lassunak az mc-t hasznalat kozben
2) fogalmam sincs hogy mekkora a merete, de oszinten, ki nem szarja le hogy 100KB vagy 1MB, egy sokszaz gigas vinyon?
3) ugye ez most vicc? egyebkent ha nem tetszik a kinezet, csinalsz sajat stilust, ennyi. raadasul ez nem 'feature'
4) ezt kifejtened? nagyon bullshit-szagu ez a pont
5) ha valoban nincs az mc-ben, akkor ez jogos igeny, tessek feature requestet irni (nekem meg sosem hianyzott)
6) a FEATURE-t tessek leirni, ne a hozza tartozo hotkeyt, ezzel nem tudok mit kezdeni...
7) he? mi a baj azzal hogy van egy sort menupont?
8) te most komolyan szorakozol...
9) ld. 8
10) mert??? amugy ez nem 'feature'
11) ld. 10
12) ld. 6

amugy ahogy elnezem, csak trollkodsz, mivel nem erdemi kifogasaid vannak, hanem hogy 'azert szar, mert nem vc'

-
Slackware current / OSX Snow Leopard

ahogy elnézem csak trollkodsz, mivel saját bevallásod szerint sincs fogalmad hogyan működik a wc^H^Hvc

mutasd meg legyszives, hogy hol fikaztam a vc mukodeset, illetve a postom melyik resze volt szerinted trollkodas

ja es mutasd meg, hol irtam hogy FOGALMAM SINCS a vc mukodeserol
hasznaltam kb. 15 evvel ezelott sokat, minden floppymon rajta volt, de teny hogy az otthoni gepen Dosnavoztam, mivel a vc-bol rengeteg funkcio hianyzott amit a DN tudott

de ha szerinted a 'Shift+F4' egy FEATURE, akkor csak gratulalni tudok ;)

-
Slackware current / OSX Snow Leopard

nem kell felháborodni, kérésedre leírtam mi nincs az mc-ben. ez(ek). de úgy tűnik felére nem emlékszel, másik fele meg mesterségesen generált igény©, vicc©, vagy gratuláció©

nem felhaborodtam, csak siman nagykepu trollkodasnak erzem, hogy miutan kertem, hogy sorold fel az altalad az mc-bol hianyolt, de a vc-ben meglevo feature-oket, irtal pl. hotkeyeket, majd miutan nem vagtam fejbol 15 ev utan hogy mit is csinalt az anno, kozolted hogy 'fogalmam sincs a mukodeserol'

amugy az egyetlen FEATURE felsorolasodbol a panel on/off, amivel kapcsolatban igazat is adtam neked...
-
Slackware current / OSX Snow Leopard

Nekem (igaz a norton-féléből), de hiányzik még az, hogy mintha a menürendszert az ALT-gombbal érhettük volna el. Még rááll a kezem, azt hiszem, emiatt, és nem más programok miatt. Valamint a sebesség: ha lusta dög vagy parancssorosan kitömöríteni pl. egy zip-et, vagy valamit, az rettentő lassan működik. Törlés sem sokkal jobb...
Szóval használható, de a feeling mégsem ugyanaz.
Lehet, hogy megragadtam (sőt biztos) a DOS622-WIN31 korszakban, de az azóta kijött rendszerekkel nem érzem olyan jól magam.

arra gondolsz, hogy siman az ALT megnyomasa aktivizalta a menut, mint windowseknal?
ez egyebkent nem hulyeseg (en nem szerettem, de attol meg ertelmes gondolat)
megerne egy feature requestet :)

a kitomorites sebessege nem az mc-tol, hanem az altala hasznalt kicsomagolotol (unzip, unrar, egyebek) fugg, ha jol emlekszem, zip-nel csinalta azt, hogy ha csak egy file kell belole, akkor is az egeszet szetszedi, nem tudom ez meg mindig igy van-e
a torles meg a filerendszerbol adodoan is eleg lassu lehet esetenkent (bar az, hogy elotte vegigrohangal az egesz torlendo konyvtarstrukturan, tenyleg eleg idoigenyes rendesen elburjanzott konyvtarszerkezetnel, de pl. windows alatt a FAR is csinalja meg SHIFT+DEL eseten is)
-
Slackware current / OSX Snow Leopard

hát az alt+gomb directory/file traversal, és a ctrl+\ elég alap feature-k imho

akkor leirom meg egyszer, lassan:

h o t k e y ! = f e a t u r e

tehat a 'CTRL+\' meg mindig NEM FEATURE
de tudod mit, legyen neked igazad. igen, a CTRL+\ egy feature. es bizony benne van a mc-ban is, ha megnyomom, feldobja a hozza tartozo dialogusablakot :P

a 'directory/file traversal' az mar tenyleg feature :)
ez mit is jelent pontosan a vc eseteben? ha ezt leirod (es NEM azt hogy 'azt hogy alt+gomb') akkor mar tudunk vegre beszelni egy konkret, altalad hianyolt feature-rol :)

-
Slackware current / OSX Snow Leopard

funkcionalitásról volt szó, nem feature-ről (ezt a fogalmat neked sikerült közben belekavarnod), úgyhogy érdekes látvány ahogy magadnak magyarázol "meg egyszer, lassan"

ctrl+\: change to root dir
alt+key mc-ben ctrl+s-key, remélem nem kell külön elmagyaráznom miért szar

es az emlitett kontextusban a funkcionalitas miben kulonbozik szamottevoen a feature-tol?
foleg hogy szerinted FUNKCIONALITAS a meret, menuarnyek, illetve bizonyos system libek hasznalata

root dir: tekintve hogy a vc olyan rendszerre keszult, ami tobb meghajtot, ebbol adodoan tobb root dirt hasznal, eleg jogos es gyakran hasznalt muvelet a 'fokonyvtarba lepes', ahogy akkoriban hivtuk. mashol, ahol csak egy 'nagy szent root' van, szerintem (az en esetemben legalabbis) ez nagysagrendekkel ritkabban hasznalatos, sokkal nagyobb szukseg van bizonyos konyvtarakba (pl /mnt, /home, /usr, stb) torteno lepesre. es (figyelem, meglepetes kovetkezik!)a CTRL+\ hotkeyre elougro dialogus pontosan az erre a celra szolgalo 'Directory hotlist', amire legfelulre nyugodtan berakhatod a rootot. igaz, igy egy ENTERrel tobbet kell megnyomni, cserebe kapsz egy, a rendszerhez sokkal jobban illo, es sokkal sokretubb, rugalmasabb funkciot

alt+key vs alt+s+key (bizony, ALT+s-sel is mukodik): ugyanaz mint fent, eggyel tobb billentyulenyomas. igen, kenyelmesebb lenne eggyel kevesebb keypress, de szerintem nem a filenevkereses miatt fogsz inhuvelygyulladast kapni ;)
egyebkent mivel az ALT+betukre bizonyos funkciok vannak rakva, ezert nyilvan nem mukodik a vc viselkedese. megint csak ugyanaz mint fent: cserebe az eggyel tobb billentyulenyomasert rengeteg mas funkciot elerhetsz gyorsabban
-
Slackware current / OSX Snow Leopard

Igen egyetértünk, az mc-s alternatívák kényelmetlenebbek.

A "rendszerhez sokkal jobban illő", "sokkal sokrétűbb", "rugalmasabb" buzzwordok nem kellenek, valóság: kényelmetlen, használhatatlan.

Belépés /bin-be, vc:
ctrl+\, alt+b, enter

Belépés /bin-be, mc:
fn+shift+fel, enter, fn+shift+fel, enter, fn+shift+fel, enter (eddig tartott a ctrl+\ "rugalmasabb, sokrétűbb" verziója), ctrl+s, b, enter

A ctrl+\-re történő ablak feldobás és definiálgatás csak egy ugly workaround a fenti két hiányzó funkcióra.

"A "rendszerhez sokkal jobban illő", "sokkal sokrétűbb", "rugalmasabb" buzzwordok nem kellenek, valóság: kényelmetlen, használhatatlan"
jo, legyen. a CTRL+\, ENTER valoban hasznalhatatlan :D
ALT+s+betuk, valoban hasznalhatatlan :D

"A ctrl+\-re történő ablak feldobás és definiálgatás csak egy ugly workaround a fenti két hiányzó funkcióra."
ilyen erovel a vc-s CTRL+\ egy ugly workaround a hianyzo directory hotlistre
amugy belepes a /bin-be, mc: CTRL+\, lefelenyil, ENTER (ehhez nyilvan be kell rakni a hotlistbe, ami erre valo...)

ugy tunik, tenyleg igazam lett, neked egesz egyszeruen azert szar az mc, mert nem a legutolso bitig pontosan ugyanaz mint a vc...
minden amit egy gombnyomassal tobbel lehet elerni mint vc-ben, megbocsathatatlan, halalos bun, szar az egesz, hasznalhatatlan
minden, amivel tobbet tud a vc-nel, felesleges, bullshit, workaround :)

-
Slackware current / OSX Snow Leopard

"egesz egyszeruen azert szar az mc ... minden amit egy gombnyomassal tobbel lehet elerni mint vc-ben"

Pontosan. Egy 2 billentyűs funkció 3 billentyűsre módosítása pontosan minimum 33%-kal kevésbé hatékony, mint az eredeti (nem véletlen úgy készült az el), és mivel ehhez az ezalatt eltelt plusz idő is hozzájön, már -50%-nál tart a hatékonysági mutató.

És ezután ezt a szarul megtervezett rendszert a hupperek -ffast-math fordítják, mert úgy hátha 1%-kkal gyorsabb.

Fundamental flaws, anyone?

rotfl
tehat az, hogy ALT+a helyett ALT+s, a-val tudok az 'a' betuvel kezdodo file-okra ugrani, felere csokkenti a filekezelesi hatekonysagot :D :D

ezek utan, merthogy latom jo vagy matekbol, szamold ki legyszives hogy hany szazalekkal NOVELI a hatekonysagot, hogy bizonyos alapveto funkciok benne vannak az mc-ben, mint pl. 'Shell link' vagyis sshfs, ugyanez persze FTP-vel is, vagy hogy csak a mar emlitetteknel maradjunk, az hogy a directory hostlist listaba berakom a /usr/share/doc konyvtarat, es ket vagy harom billentyuleutessel elerem, vagy mondjuk hogy ismeri a kijelolt/panelon levo file-ok/konyvtarak makrozasat (szamomra nelkulozhetetlen funkcio, mindennap tobbszor hasznalom (a %t %T %d %D makrokra gondolok))
vagy pl. sylink letrehozasa/modositasa, stb

bar vegul is igazad van, ezeket dobjuk ki a francba, ha cserebe nem 3 hanem 2 billentyu kell a rootba lepeshez :D
-
Slackware current / OSX Snow Leopard

tolhatnád jobban is a trollingot, mert a "linux azért jobb mint a windows, mert igaz hogy nincs rá assassin's creed 2, de van textmode konzol" kaliberű "összehasonlítás"... hát hogyismondjam, rém gagyi :-)

he? o.O
-
Slackware current / OSX Snow Leopard

valaki dobjon már neki egy autós hasonlatot

segitek: A auto teljesen hasznalhatatlan, mert B-vel szemben 4 helyett 6 masodpercig kell nyomvatartani az ablakemelot a teljes le- ill. felhuzashoz ;)
-
Slackware current / OSX Snow Leopard

most jönne az a rész amikor ujjaid szorgos pötyögése folyamán napvilágra kerül a komment ahol az mc teljes használhatatlansága volt kijelentve (részemről)

sajnos ezt most kínos csönd váltja fel

parancsolj: http://hup.hu/node/101158#comment-1253012
-
Slackware current / OSX Snow Leopard

vajh' kell rámutatnom az "mc teljes használhatatlansága" és az "egyik funkció használhatatlansága" közötti nüansznyi különbségekre?

Biztos, hogy urai vagytok a helyzetnek? :)

Szerencsétlen valahogy kitalálta hogy az mc teljesen szar, és azt hiszi én is így gondolom :o

akkor most jon az, hogy te is belinkeled a postot ahol ezt allitottam, ugye? :)
(azt mar elo sem merem hozni, hogy az altalam beirt postokbol kikovetkeztetheto velemenyem mennyire passzol az altalad most leirthoz)
-
Slackware current / OSX Snow Leopard

/o\ pihenned kéne

eppen azt teszem. van aki allatkertbe jar zsirafot etetni, en allatkert nelkul trollt etetek ;)
-
Slackware current / OSX Snow Leopard

uh
további segítséget a sword mastertől kaphatsz, mêlée island™

eloszor a Sam & Max-et kene megint vegigjatszani, a melee island majd csak utana :)
-
Slackware current / OSX Snow Leopard

ugyan nem tortent explicit hozzakapcsolas sem a 'teljes mc' sem az 'mc bizonyos funkcioja' kifejezeshez, a megelozo postokat figyelembe veve rahuzhato egy implicit kapcsolodas a 'CTRL+\ funkcionalitashoz', szoval ezt kihuzhatjuk

ebben az esetben nem a teljes auto, csak az ablakemelo valik hasznalhatatlanna a 4 helyett 6 masodperces ablakfelhuzasi idotol :)
-
Slackware current / OSX Snow Leopard

azt hogy te mire mit húzol, az továbbra is a magánügyed, és itt viszonylag kevés érdeklődés mutatkozik iránta

1. attól még lassú.
2. vc előnye, hogy pici, kompakt volt. Nah, ez az, ami nagyon hiányzik az mc-ből. Egyébként tényleg csak egy nagyságrendet tévedtél, mert olyan 10-15 mega körül van az egész hányadék.
10-11, hja, valóban nem feature, hogy egy bloatware fos az egész.
+1. Hexa exditor.

----------------
Lvl86 Troll

tisztaban vagyok vele... :(

Norton Commander? (10 éve használtam Dos-t, Win 3.11-el és dos alatt ez volt a legjobb, Win alatt meg a "Filekezelő".)

áhhhh...

(amúgy hol voltál te 10 évvel ezelőtt?!)

Norton Commander..... Léccineeeeeee...........

----------------
Lvl86 Troll

De, kritikus szempont.
Egy alkalmazás ne használjon 30MB-os adatbázis motort pár tucat sor kezelésére, ne használjon több megányi helyet foglaló XML parsert párszor 10 sornyi konfig filehoz. Egy 3 gombot és egy ikont mutató alkalmazás ne cachelje be a teljes GUI ikonkészletét és lehet a végtelenségig sorolni.
Igen igazad van, változnak a módszerek, egyre több lusta programozó van, aki a gyors alkalmazás reszelés érdekében, hígfost állít elő. Lehet takaródzgatni azzal, hogy "de ma már minden gépben van 1Gb" memória, de leszarom. Érdekes módon ugyanezen funkcionalitásokat képesek voltak 15-20 évvel ezelőtt 1-2MB-ban implementálni, működőképesen.
Az egyik legdurvább példa az agyon ajnározott tüzesróka. Egy 2GHz-es gépen, egy youtube videó 500 MB-ot és 80%-os processzorterhelést visz el a 10-es flash pluginnal. Felteszem a kérdést, hogy mire? Elárulom, azért mert a köztes réteg, köztes rétegének, a köztes rétegén keresztül kerül a monitoromra egy pixel. Az erőforrások legjelentősebb hányada teljesen feleslegesen megy el.
Vagy beszéljünk a tervezés és józan ész nélkül fejlesztett alkalmazásokról? Például a state of the art almástermékről a CUPS-ról. A spoolerben van egy feladat, viszont a hozzá tartozó nyomtató nincs csatlakoztatva. Mi a megoldás? Elkezdjük, postscriptel konvertálni a MEMÓRIÁBA. Kéne másra is a procsesszor? Kit érdekel! Kéne másra is a memória? Kit érdekel! Miért kell kompletten legenerálni a postscriptet egy darabos nyomtatásnál? És egyáltalán, miért kell mindenáron postscriptbe konvertálni? Vagy megérdezhetném, hogy miért kell várni 20-25 másodpercet, hogy nyomtatásnál lekérdezze a nyomtatók állapotát?

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Ez a postscriptes dolog engem is nagyon idegesit, nyomtatot dugtam a sheevaplugomra, h majd helyi halon tudjam hasznalni, jol is csinalta, de nehany doksinal nem tortent semmi, ssh-n belepve meg porog a proci 100%-on es 20MB-os pdf alapjan megeszi a maradek 300MB-ot a memoriaban (temp fs)...

@Hiena: te vagod a hardveres reszt, van usb-s konnyen programozhato lcd/egyeb kijelzo olcson (a sheevahoz kellene)?

---
return NEVER;

Ubuntu 8.10
HP nx6110
http://java.tszebeni.hu
http://s2.sfgame.hu/index.php?rec=148223

Ha gyorsan kell, akkor léteznek USBs videokártyák, amik X alól támogatottak. http://www.nslu2-linux.org/wiki/HowTo/AddVGAAdapter
Ha olcsó kell és szeretsz reszelni, akkor épp mostanában kezdtem csinálni egy 128x128-as szines USB->LCD hacket. Teljes költsége olyan 4000 HUF körül lesz.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

ez utobbi nekem sokkal szimpibb, egy szepen elkeszitett multiplatform uzembiztos cuccert 4e hufnal tobbet is fizetnek.

---
return NEVER;

Ubuntu 8.10
HP nx6110
http://java.tszebeni.hu
http://s2.sfgame.hu/index.php?rec=148223

"a köztes réteg, köztes rétegének, a köztes rétegén keresztül kerül a monitoromra egy pixel"

pont ezt mondtam en is :)

"Egy alkalmazás ne használjon 30MB-os adatbázis motort pár tucat sor kezelésére, ne használjon több megányi helyet foglaló XML parsert párszor 10 sornyi konfig filehoz"

nyilvan megoldhato mashogy is. te fizetned a fejleszto sokkal tobb ideig tarto munkajat azert, mert az altala mar ismert es bevalt, 5 perc alatt integralhato megoldas helyett sajat parsert ir, vagy nekiall olyan utan keresgelni, ami a leheto legkevesebb eroforrast foglalja?
es ha mar sporolunk a memorian, miert ne irnank meg mindent a leheto legalacsonyabb szinten?
az emlitett nyomtatos appletet meg lehetne csinalni ASM-ben is, egybol nem zabalna 30MB-t. de ki fog elcseszni tizenotszor annyi munkaidot csak azert, hogy a usernek 30MB-tal tobb RAMja maradjon??
en ha valamilyen GUIs, ablakozos programot irok, Qt-t hasznalok. a kesz program tobb RAMot hasznal mintha C++/Qt helyett ASM / Xlib+MFC+ezercsilliomasapi, vagy akar csak SDL hasznalataval irnam meg. de soha nem fogom, mert a fejlesztesi ido brutalisan soksoksokszorosara ugrana. es a munkahelyem sem fizetne ezert, mivel a megrendelo sem fog harmincszoros osszeget fizetni a kesz szoftverert, csak mert nem kell az azt futtato gepbe 1GB ram legalabb, hanem elfut 256MB-val is...

-
Slackware current / OSX Snow Leopard

nem kellene sokat tenni, csak lazy inited kodot kellene irni. - az viszont tele van plusz checkekkel, ami a proci idot rontja... - mindig az kell ami nincs.
Engem nem zavar, ha a szabad memoriam elmegy file cachebe, de az mar zavar, h a pagefileom 5,5GB mert egy eclipse tomcat megesz 2GB-t, PS kb 3-4GB-t, bongeszok darabja 500MB-ot, ez van.

---
return NEVER;

Ubuntu 8.10
HP nx6110
http://java.tszebeni.hu
http://s2.sfgame.hu/index.php?rec=148223

Lazy initet sem erdemes tulzasba vinni, mert a vege az, hogy katt a java app menujere, app fagyas, fel perc utan megjelenik a preferences ablak. Nem nyero.

A masik az eggyel fentebbi hozaszolasban volt, de akkor mar ideirom: erdemes-e 15x annyi idot fektetni abba hogy kevesbe legyen eroforraszabalo. Namost, ez mokas kontrasztot ad a gentoos sracok alairasaival...

". de ki fog elcseszni tizenotszor annyi munkaidot csak azert, hogy a usernek 30MB-tal tobb RAMja maradjon??"

Az ordasnagy probléma az, hogy nem 1x30 mega ramról van szó. Hanem 10..30x20 megákról. Az nagyon nem ugyanaz.

Egyébként a mindenféle köztesrétegről annyit, hogy azt is lehet értelmesen és ész nélkül csinálni. Igen, kell EGY absztrakciós réteg. De jelenleg az absztrakciós réteg fölé még 5-6-7-t húzunk. Nah, itt van elbaszva az egész.

----------------
Lvl86 Troll

+1 Különösen az a fájó, hogy mivel a már meglévő működését (X) nem képesek megérteni és nem is akarják megérteni, ehelyett csinálnak mindenféle más szemetett.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

nyilvan nem a konkret szam a kerdes

adott egy feladat: pl. fejlessz egy GUIs alkalmazast, ami egyszerre tobb szoveges 'ojjektum' szerkeszteset teszi lehetove (mondjuk egy tabos feluleten), amik kozott bizonyos kapcsolatok vannak (egymasra hivatkozasok, stb) , a jobb oldalan az ezekbol keszult graf realtime-ban modosul mozgathato, zoomolhato, rakattintva valamelyik node-ra a hozza tartozo ojjektum jelenik meg baloldalt

vazoljunk fel ket megoldast:

1) megirod a programot pl. Qt hasznalataval 1 nap alatt. meg fog enni mondjuk (hasamra utok) 50 MB memoriat amig fut (de legyen 100...). ez hasznalja ugye a Qt-t, az az X-et, az meg az alatta levo drivereket, stb. kell mondjuk egy legalabb 1GHz CPU a folyamatos zoomhoz 200 node eseten

2) megirod a programot siman az Xlibet hasznalva, ezzel 1, azaz egy absztrakcios szintet kidobva. az egesz program hasznal mondjuk 5 MB memoriat, koszonhetoen annak hogy nem kell a Qt, es akar egy 500MHz-es Celeronon is szepen fut a 200 node-dal. mennyi ido alatt tudod ez leimplementalni csak az Xlibet hasznalva? legyen mondjuk 15 nap (ami ismerve az Xlib csodait, talan meg mindig boven keves)

most vegyuk hozza, hogy az egesz egy megrendelonek keszul, aki fizet erte. szerinted melyiket fogja megvenni, azt, amelyik:
- 1 napi munkadijba kerul
- ott van mogotte a Qt, amihez az esetleges bugfixeket, egyeb update-eket megkapja ingyen, ha akarja a programot hasznalhatja nem csak Linuxon hanem akar Windowson vagy OSX-en is, de akar mas, Qt altal tamogatott platformon, mondjuk egy ARM procis, X nelkuli configon
- a kinezete (gombok kinezete es sorrendje, menuk, stb) es hasznalata az eppen hasznalt rendszernek megfelelo

vagy azt amelyik:
- 15 napi munkadijba kerul
- a fent felsorolt elonyok nem igazak ra
- cserebe elfutna azon a gepen is (ha meg meglenne), amelyiket 5 eve selejteztek le

tegyuk fel, hogy egyszerre 50 ilyen modon elkeszitett programot kell futtatni egy gepen, akkor a felhasznalt memoria kulonbsege vagy 2GB (de legyen mondjuk 4, csak hogy nagyvonaluak legyunk). szerinted a ceg kifizet 700 napi (5600 munkaora!!) munkaidot pluszban, vagy vesz 4GB gyors ramot mondjuk 30.000 forintert?

nyilvan a 'balfaszul megirt kod' egy masik eset, fent mondjuk ugyanannak a fejlesztonek a ket kulonbozo modszererol van szo
-
Slackware current / OSX Snow Leopard

általában az szokott lenni a dogma, hogy a nyíltforrásfejlesztő hobbiból dolgozik, úgyhogy adódik az "és akkor miért mégis szarul" kérdés

jo lenne ha vegre egyszer valoban valaszolnal az abban a postban felvetett gondolatra, amire a 'valasz'-t nyomod, vagy legalabb kapcsolodna hozza a fikahalom amit alahanysz
ket kerdes:

1) a fenti esetben megrendelokent melyik verziot venned meg
2) a fenti esetben fejlesztokent melyik megoldast valasztanad

bonusz kerdes: a sajat fejlesztesu szoftvereid keszitesekor mennyi idot toltesz a feltetlenul szukseges minimumnal nagyobb eroforrasigeny eltuntetesevel?
-
Slackware current / OSX Snow Leopard

szelíd probálkozás volt csupán az offtopic elkerülésére, tekintsd kérlek tárgytalannak és nyugodtan vezesd tovább a szálat mindenféle absztrakt "megrendelőkkel"

tehat a feltunoen nagy memoriazabalassal foglalkozo topicban az nagy memoriahasznalattal jaro szoftver fejlesztesi okai OFFok, de annak az elozmeny nelkuli behozasa, hogy az opensource fejleszto marpedig hobbibol csinalja, ugyebar ontopic
grat, nem csalodtam benned :)
-
Slackware current / OSX Snow Leopard

Nagyon szűklátókörűen nézed a témát.
Vegyünk egy egyszerű példát:
Van egy konvertáló programom, ami képes nekem A típusú filmből B típusúba konvertálni. A konvertálásnak minimális a memóriaigénye és a gépigénye, viszont a forrás nehezen és lassan hozzáférhető (pl. stream). Ezen alkalmazás legyen egy népszerű GUI környezetben megírva ami indulásnál a két textbox és a 5 gomb kedvéért beránt 36 MB-ot és és megeszik 18% procit.
Mivel szeretnéd a gépidőt hasznosan kitölteni, ezért több példányban fogod futtatni a programot.
Namost, szerinted mi a helyes eljárás, ha van 50 munkaállomásod, munkaállomásonként kb. 300 filmed amit ezen eszközzel kell konvertálnod?
Dedikálsz gépet és embert aki malmozik 4-5 megnyitott alkalmazás mellett, vagy költesz egy irreális összeget gépbővítésre, vagy megkérsz valakit, aki kidobja a használhatatlan GUI-t és csinál egy kicsi és gyors alkalmazást?
A példa életből vett, mai napi csókoltatom az eredeti alkalmazás íróját.

Egy desktop környezet is hasonló. Egy komolyabb munka esetén 7-8 alkalmazás is meg van nyitva az ember előtt. Ha ész nélkül vannak megírva pillanatok alatt kifogy az erőforrás az ember alól. Ez esetben, legyen akármennyire is open-source, ha nekem kell infrastruktúrát bővítenem egy filekezelő miatt, akkor a jó édes anyukáját annak aki megírta...
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

"ket kerdes:

1) a fenti esetben megrendelokent melyik verziot venned meg
2) a fenti esetben fejlesztokent melyik megoldast valasztanad

bonusz kerdes: a sajat fejlesztesu szoftvereid keszitesekor mennyi idot toltesz a feltetlenul szukseges minimumnal nagyobb eroforrasigeny eltuntetesevel?"

Megrendelőként, mindkettőt, mert nem látja előre, hogy az ótvar GUI miatt nem tud majd hatékony munkát végezni, és utána mégegyszer fizetnie kell a jó kódért.
Fejlesztőként amelyik a legkisebb erőforrás igényt jelenti.
Bónusz válasz: Elég sokat különben nem férek bele a mikrokontroller memóriájába vagy az időzítésbe. Elég nagy szívás, mondjuk amikor egy soft UART-nál nem fér bele a stop bit idejébe a hasznos kód...
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

win

nagyon rossz valasz
ha a fejleszto olyasmit fejleszt, amiben 'otvar a GUI', akkor ez a fejleszto az elterjedt toolkit (a peldaban Qt) helyett Xlibet hasznalva szerinted mennyivel fog jobbat alkotni?
raadasul ha egy szamara hasznalhatatlan termeket kap es vesz meg a megrendelo, akkor ott o is boven hulye. munkat akkor veszunk at es fizetunk ki, ha a megrendeleskor tamasztott elvarasoknak es felteteleknek eleget tesz.

"Fejlesztőként amelyik a legkisebb erőforrás igényt jelenti."
human vagy szamitogepes eroforrasra gondolsz?
elobbi esetben szinte tokeletesen egyetertunk, a masodikban szinte egyaltalan nem
ami szemely szerint engem illet, en probalok egy realis egyensulyt tartani a befektetett munka es az elerheto eredmeny kozott. ha 1 ora munkaval felere tudom csokkenteni a gepigenyt, plane ha olyan szofvterrol van szo ahol ez fontos (mondjuk jatek), akkor nem kerdes. ha napokig kell azon hackelnem, hogy 100 helyett 90 MB memoriat egyen, vagy 40 helyett 42 FPS-t produkaljon, akkor nem fogok szenvedni vele

a mikrokontroller nagyon specialis terulet, igy nyilvan teljesen mas szabalyok vonatkoznak ra, mint a desktopra, eleve ertelmezhetetlen ra pl. az emlitett Qt-s pelda, vagy akar az indulo postban felvetett python
-
Slackware current / OSX Snow Leopard

Az egeszben az a szep, hogy szerinted letezik a Qt es az Xlib. Ezzel annyi a problema, hogy ehhez meg hozza jon a python, a QtPy, - es akkor csapjunk a lecsoba - a composit rendering, az X-org halozattranszparenciaja es meg ki tudja hany ezer baromsag, ami mind-mind hozza a maga plusz reteget.

Ahelyett, hogy lenne *egy*, normalisan elkeszitett reteg, ami pont arra szolgalna, hogy egy lepesbol megoldja, ami kellene. De sebaj, nyilvan nem az egyes koztesretegek hivogatasa teszi ki az ido 80%-t, mert nyilvan lehetetlen az egesz rakast felszamolni, mint ahogy mas platformokon sem lattunk peldat meg erre...

----------------
Lvl86 Troll

Oh csak minden reteg hozza magaval a manapsag trendi OO-t, objektumwrappert hanyva minden szinten, mig eljutsz oda hogy egy szinbeallitashoz lesz 80 malloc ;)

"szerinted letezik a Qt es az Xlib."
nyilvan nem mondtam hogy csak ez a ket lehetoseg van, csak pelda volt arra, hogy nem feltetlenul a leheto legkevesebb reteg hasznalata a legjobb megoldas

-
Slackware current / OSX Snow Leopard

Szerintem meg ertekeljuk at az egesz implementacio letjogosultsagat ennek tukreben: http://hup.hu/node/101236

Mert valakinek a millio +1 wrappert is ossze kell reszelni egy egessze.

----------------
Lvl86 Troll

ha az elso program 18% procit megeszik, a masik altalad emlitett, 'kicsi es gyors' pedig nem, akkor ez a mar emlitett 'balfasz kod' esete, hiszen ugyanazt csinalja mindketto (es nyilvan nem az 5 gomb es a ket textbox megjelenitese fog 18%-ot enni, mint ahogy ugyanazt a toolkitet/libraryt sem kell 50-szer betolteni ha 50 peldanyban futtatod az azt hasznalo programot). magyarul a program belsejeben levo algoritmus van szarul megirva. ha ugyanaz a programozo mondjuk parancssoros verzioban irja meg ugyanazt a programot (vagyis GUI helyett CLI interface-t rak a szar motor ele) akkor ugyanugy meg fogja enni a 18%-ot, bar nyilvan a RAM kevesebb lesz. ekkor viszont egyszeruen annyi a kerdes, hogy mik az igenyek? ha a usernek nem kell a GUI, hanem eleg, sot elonyosebb a CLI, akkor nyilvan azt kell valasztani, es itt pontosan ez a helyzet.

amugy ha a feladatot jol ertem, akkor nem kell uj alkalmazast irni, hiszen mar letezik, raadasul ingyenesen hozzaferheto, tehat nyilvanvaloan a csere a legjobb megoldas mert nincs koltsege

-
Slackware current / OSX Snow Leopard

A 18% jelen esetben a GUI csatolt részei miatt folyik el. Hiába nincs kommunikációja a szoftvernek, ha egyszer a GUI elemek létrehozásakor elindul az IPC kezelésért felelős összes fittyfene és ezek aztán folyamatosan chatelnek. Ugyanígy nem sokat tehetsz, ha mondjuk a file selector a gyors előnézeti kép generálás és a filenevek tallózása miatt adatbáziskezelőt indít. Ez utóbbi, minden egyes alkalmazás indításnál új processzt indít. Maga a belső feldolgozást végző motorral nem volt gond, mert a "start" megnyomása épp nagyjából annyival növelte a terhelést, mint amennyivel az én kódom.

A user igénye az, hogy a kód menjen, és ha a gép elé ültet egy aranyhalat, akkor az is kezelni tudja. XXI. században már elvárható, hogy egy célszoftver rendelkezzen megfelelő GUI-val. Nem?

Az alkalmazás zárt szoftver volt, forráskód nélkül. De ez lényegtelen.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

az altalad leirtak alapjan tenyleg irtozatos el lett cseszve az egesz es nem is az implementalasnal, hanem mar a tervezesnel...
es meg mindig tartom, hogy ha egy GUI onmagaban 18%-ot eszik, akkor ott az ugynevezett 'fejleszto' baromira nem tudja mit csinal

es jelen esetben kb. ugyanannyi munkaval, mint amennyibol ez a cucc keszult, meg lehetett volna csinalni normalisan, vagyis nem arrol van szo, hogy sokkal tobb munkat igenyelt volna a kisebb eroforrasigenyu szoftver elkeszitese (mint amirol en beszeltem), hanem egesz egyszeruen 'el lett b@szva'...

-
Slackware current / OSX Snow Leopard

> nem arrol van szo ... amirol en beszeltem

van egy ilyen vonatkozása valóban

"mint ahogy ugyanazt a toolkitet/libraryt sem kell 50-szer betolteni ha 50 peldanyban futtatod az azt hasznalo programot"

Ez igy mar megint santit. Ha ugyanazt a toolkitet betoltod, annak kodja nem fog 50 peldanyban memoriat foglalni. Na de mi van a toolkit futasakor hasznalt adatokkal?

----------------
Lvl86 Troll

a sw gáz, a hw meg az edény.. kisiskolás anyag ;)

Mivel nézted a memóriafogyasztást? Biztos hogy az egyszer memóriában lévő shared libeket csak egyszer számolta és nem adta hozzá minden processzhez, ami használja őket?

--
Ahol a telefontöltőd, ott az otthonod.

ps -e -orss=,args= | sort -b -k1,1n | pr -TW$COLUMNS

Én nagyon kiváncsi lennék mi van a nyomtatásvezérlő applet által lefoglalt 34 Mb-ban, az nem kevés adatmennyiség.

MOD: Ez tényleg csak ennyit csinál? http://utils.kde.org/projects/printer-applet/

Python futtatókörnyezet. Szerintem az tud enni.

Értem.

Kíváncsiságból belenéztem a forrásába, max. 3000 sor lehet, nem tudom egyátalán minek ehhez python, egyátalán minek bármihez is, c-ben se bonyolultabb megírni.

lol

---
return NEVER;

Ubuntu 8.10
HP nx6110
http://java.tszebeni.hu
http://s2.sfgame.hu/index.php?rec=148223

Valami effélét akartam írni, hogy "mert ez python". Az aztán tud zabálni. Szerintem nem kéne desktopon erőltetni ezt a nyelvet, csúnya memóriazabálásokat tud csinálni.

Off: szerintem pythont sehova nem kellene erőltetni, de erről a python fanoknak megint teljesen más lesz a véleménye, így igazából hagyom a témát. :)

----------------
Lvl86 Troll

Nem az a lenyeg hogy kics, gyors es jo legyen, hanem hogy jo legyen az indentalas. :)

meg a gpl compliance \o/