Új hozzászólás Aktív témák

• #68 mezis félisten dabadab #63

  Új Válasz 2009-10-09 14:04:26 #68

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  mezis

  félisten

  válasz dabadab #63 üzenetére

  
  szinte semmi ellenorzes nem volt a hatarokra, a pointerek, a tombok meg a bufferek oda masztak el, ahova akartak.
  Csak oda másztak, ahová a programíró engedte. De ez ma is így van.
  Az Algol68-ban volt indexhatár ellenőrzés. A Fortran IV-ben nem. Tudomásul vettük és a programban irtuk meg az indexhatár ellenőrzéseket. Ott, ahol szükség volt rá. Legalábbis igyekeztünk.

  És ha napjainkban van ellenőrzés a szoftverfejlesztő, futtató eszközökben a határokra, akkor azok a pufferek mitől tudnak túlcsordulni ? Szabotázs ?

• #66 Hiftu senior tag dabadab #63

  Új Válasz 2009-10-09 13:59:28 #66

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Hiftu

  senior tag

  válasz dabadab #63 üzenetére

  A telekomm eszközöket ki is veheted a jól tesztelt dolgok listájáról...

• #61 mezis félisten dabadab #59

  Új Válasz 2009-10-09 11:16:38 #61

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  mezis

  félisten

  válasz dabadab #59 üzenetére

  Ma már nyugdíjas vagyok.
  Az előző bő harminc évben alap és felhasználói szoftverfejlesztéssel foglalkoztam. (Odra 1013/Most1, Odra-1204/Algol 68,CDC-6500/FortranIV, PDP-8,11/assamler,Focal,Fortran,Midibol, Commodore-64/Basic, IBM PC(klón)/Fortran,Foxbase,Clipper)
  A szofvereim (szoftvereink) természetesen nem voltak tökéletesek, lehetett volna még tovább fejleszteni, bizonyára maradtak ki jogos felhasználói igények, de akkor adtuk át a felhasználónak, amikor biztosak voltunk abban, hogy nem fog "fejreállni" a felhasználó által kitalált bármilyen adatoktól. Legfeljebb félbeszakítja a futást, a lehető legpontosabb hibaüzenettel (hol, milyen adat, számított érték miatt nem szabad folytatni a program futását.)

• #56 Rive veterán dabadab #43

  Új Válasz 2009-10-09 10:17:33 #56

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Rive

  veterán

  válasz dabadab #43 üzenetére

  Au contraire! Minden modern virusirtoban van heurisztika, ami a program kodjat elemzi (tulkeppen egy virtualis gepben futtatja a programot egy kicsit, hogy megnezze, mit csinal). Ezt plusz egy mag erdemben nem befolyasolja, az viszont sokkal inkabb, ha egy teljesen uj utasitaskeszletu vegrehajtoegyseg kerul a kepbe.
  Nem gondolom, hogy ez igazi gond. Az OS, ami a CPU-n fut vagy tud jó homokozót csinálni, vagy nem tud. Ha tud, akkor a legnagyobb gond ami a GPGPU környékén előfordulhat, hogy a kártékony kód nagyobb számitási kapacitást tud bevonni. Ha nincs homokozó, akkor lásd fenn: székház leromol, helye sóval behint.

  Pillanatnyilag az egész koncepció arról szól, hogy egyes komplex, erőforrásigényes feladatokat exportálni a GPU-ba. Nem arról, hogy a GPU majd bármiféle tevékeny részt vállal mondjuk az OS futtatásában, vagy akár csak potenciálisan is teljes hozzáférést kap az erőforrásokhoz.

• #46 sghc_toma senior tag dabadab #44

  Új Válasz 2009-10-09 00:25:48 #46

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  sghc_toma

  senior tag

  válasz dabadab #44 üzenetére

  jepp, de talan kevesbe, mint egy virus/fereg..
  btw, csupan azert probalkozom ezzel a GPU alapu masolasvedelem dologgal, mert kihivas.. meg ha kesz lesz, egy ezzel levedett exe megy a crackmes.de-re, kivancsi vagyok, mennyi ideig marad toretlen, es hogy hogyan torik meg..

Új hozzászólás Aktív témák