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

• #190 sh4d0w félisten bambano #189

  Új Válasz 2009-08-26 22:03:14 #190

  Ú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

  

  sh4d0w

  félisten

  LOGOUT blog

  válasz bambano #189 üzenetére

  "...A linuxban már elég régen O(1) ütemező van, sikerült már ilyet rakni a w7-be? Pedig nem lenne nagy kunszt, csak el kell lopni a linuxos ütemezőt, úgyse jönne rá senki a zárt kód miatt..." - ne adj ötleteket, láttunk már karón varjút.

  https://www.coreinfinity.tech

• #196 Gregorius őstag bambano #189

  Új Válasz 2009-08-26 23:58:16 #196

  Ú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

  

  Gregorius

  őstag

  válasz bambano #189 üzenetére

  egyrészt nem ártana valami bizonyíték erre nézve, másrészt én hozzátenném, hogy jórészt ok nélkül. Úgy értem: ok nélkül tartják biztonságosabbnak a bsd-ket, mint a linuxot
  Ez egy vélemény. Az OpenBSD fejlesztői deklaráltan azt a célt tűzték ki maguk elé, hogy egy jól megtervezett, megbízható, biztonságos rendszert építsenek. Hogy ebből mennyi valósult meg, arról én nem tudok nyilatkozni, mint ahogy azzal sem áltatom magam, hogy a biztonságosság mérhető egy összehasonlító mértékkel, ami alapján a rendszereket sorba lehetne állítani. Az is tény továbbá, hogy az OpenBSD-t rengeteg biztonságkritikus beágyazott hálózati eszközben használják, legyen az egy VPN gateway vagy egy hardveres tűzfal.

  Ja, és egy halom outlookon meg egyében támadó vírushoz sem kellett user engedély, elég volt, ha megjelent a levelezőben.
  Most komolyan fel fogjuk sorolni az összes biztonsági problémákkal küzdő szoftvert? Az OpenBSD-t arra hoztam fel, hogy felhasználói interakció nélkül kihasználható sebezhetőségek még a legjobb körökben is előfordulnak. A hülyeség és a hanyagság platformfüggetlen.

  A finoman hangolható lomokról meg annyit, hogyha szétpakoltad volna több diszkre, kötetre, akkor nem lenne szükség a finomhangolásos dolgokra.
  Azt hiszem félreértésben vagy. Úgy pakolom szét több diszkre, ahogy nekem tetszik és ezen felül még be is állíthatom, hogy az adott diszken az adott fájlnak mit szabad csinálnia és mit nem. Legyen alatta akármilyen hardveres megoldás. Hozzá tudom igazítani az architektúrámhoz.

  Linuxra is van millió meg egy szines-szagos reportoló, akár tivoliról beszélünk, akár egyéb lomokról. Én meg nem tudom elképzelni, hogy egy lassú internet kapcsolaton bejelentkezzek egy grafikus lomba azért
  5h4rK nem, én igen, te nem. Ez van. Ha nagyon akarom, Windowst is tudok távolról csak konzolból bütykölni felhasználói felület nélkül. De a két kattintás általában gyorsabban meghozza az eredményt, még akkor is, ha lassú a netkapcsolat. Amúgy a távasztal újabb verzióinak barátságosan kicsi a sávszéligénye (persze ha az ember nem full HD videót néz a szerveren).

  Ha a konkurens hozzáférést szolgáltatás ütemezi, akkor az lassabb, mint a rendes multithreaded fájlrendszer. Minek oda ipc?
  A tisztánlátás kedvéért. Szerinted itt mi IPC-zik mivel, ami eredetileg nem IPC-zne? Egy darab szolgáltatásunk van, ami ahelyett, hogy delegálná a hozzáférés szabályozást az OS vonatkozó részeinek saját processzen belül intézi el az egyes objektumokhoz hozzáférés zárolását. Ha meg elosztott fájlrendszerben van az adat, akkor ugyanúgy vagy a szolgáltatásunk vagy a Workstation service intézi a szinkronizálást. Előbbi saját protokollon utóbbi RPC-n. A kliens felé pedig ugyanaz az interfész látszik, ami egyébként is.

  Az, hogy az sql team schedulert ír, szerintem más probléma ahhoz képest, hogy a konténerfájlokban újraimplementálták a fájlrendszer karbantartó cuccokat.
  A konténerfájlokban viszont nem feltétlenül csak fájlok vannak. Például kontaktinformációkat, indexeket, stb sokkal inkább el tudok képzelni relációs-jellegű tárolóban, annak meg nem sok köze van a hierarchikus fájlrendszerekhez, és habár rengeteg hasonló algoritmust (pl. B+ tree) implementálnak a fájlrendszerekhez képest (elvégre a fájlrendszer is egyfajta specializált adatbázis), rengeteg másik algoritmusban alapvetően eltér a két architektúra.
  Persze ettől még lehet azt is csinálni, hogy külön van egy összefogó fájlunk a nem fájl-jellegű adatok tárolására magukat a leveleket is külön-külön fájlokban tároluk (mint ahogy az újabb Live Mail csinálja): ekkor persze ha abból indulunk ki, hogy az átlag júzer ritkán törli a leveleit a kiszolgálóról és tízezer levél figyel a tárolómappájában, és van még jópár notórius júzerünk, akkor marha jól teleszemeteljük a lemezt fájlokkal szép kis $MFT overheadet generálva, ami ráadásul a szolgáltatás szempontjából teljesen fölösleges metaadatokkal is szennyezi a system cache-t, a rendszer (kernel-területen) karbantart nekünk millió handle-t a fájlok kezeléséhez, teljesen fölöslegesen lógnak attribútumok, ACL-ek, stb a fájljainkon. Nem biztos, hogy ez a kíméletesebb megoldás a rendszererőforrások tekintetében, összehasonlítva mondjuk egy bazinagy memory mapped file-lal. Persze tagadhatatlanul könnyebb migrálni egyik rendszerből a másikba egy nagy köteg eml fájlt mint egy egyedi konténert (még akkor is, ha egyébként specifikált a formátum).

• #212 anulu félisten bambano #189

  Új Válasz 2009-08-27 14:09:29 #212

  Ú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

  

  anulu

  félisten

  válasz bambano #189 üzenetére

  tivolit a jelenlétemben pls ne emlegessük, mert rémálmaim lesznek, és újra kell tanulnom beszélni meg járni, olyan sokkhatás ér. köszi

  "Jelenleg a cloud nem más mint a sales által elhazudott és eladott utópia, egy ígéret, csalánba csomagolt mézesmadzag, amit az üzemeltetés f@$zával vernek" | Feel the power! Intel Core i7 | iPhone 14Pro 256GB | iPad Pro 2017 64GB

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