Hol van a memóriám?

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.

( Zoltan1992 | 2011. 03. 29., k – 08:55 )

"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?

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

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

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

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

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

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

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

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

"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

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

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

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

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

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

"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

( tomaza | 2011. 03. 29., k – 09:41 )

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

( simca | 2011. 03. 29., k – 12:15 )

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.