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

• #181 Gregorius őstag sh4d0w #24

  Új Válasz 2009-08-26 20:16:28 #181

  Ú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 sh4d0w #24 üzenetére

  Saját gép csökkenő ellenőrzése: Win7 100 megás különálló, rejtett partíció...
  Azon a kérdéses partíción a Win7 boot managere van és már a Vista is ilyet csinált, ha új lemezre telepítetted és nem előre particionáltra. A disk managerben nem rejtett, adhatsz neki betűjelet vagy mountolhatod, a lemez-utility-k többsége kérdés nélkül használatba veszi.

  Mégpedig azért, mert az szerinted negatív, ha pénzéhes kis cég mondja meg, mit használj, de az szerinted nem negatív, ha pénzéhes nagy cég mondja meg. Mindkét cég pénzéhes, csak az egyik kicsi, a másik nagy.
  Csakhogy a pénzéhes nagy cég nem állítja be magát non-profit vállalkozásnak.

  Blabla. Miért van szükség e rejtett partícióra? Mint korábban a Trusted Platform Computing keretében is elmondták: a usernek egyre kevésbé lesz ellenőrzése a saját gépe felett, lesznek olyan területek a merevlemezen, amikhez nem férhet hozzá. Te beveszed, hogy rendszervédelmi okokból van szükség erre, én nem.
  FUD. Tele volt fröcsögve annó az újság a TPM meg a Palladium kapcsán, hogy a Vistával így meg úgy eljön a világvége. Aztán ehhez képest mi lett? Még annyi sem, mint a Duke Nukem Foreverből. Szanálták a projektet. Egyedül a BitLockernek a teljes merevlemez titkosítása használ TPM-et, azt pedig sokmindennek nevezném, de az ellenőrzés elvesztésének nem, főleg mivel teljesen opcionális.

  Tehát ha működik nélküle, akkor mi szükség is van rá?
  Talán mert ha jön egy 3rd party boot manager és úgy dönt, hogy lecseréli a meglévőt, akkor nem a rendszerpartíciót cseszi össze?

  Hmmm ... Nem ertek a Win 7 -hez, de az azert gyanus, hogy 100Mb foglal egy boot loader
  Szerény személyes masinámon ebből a 100Mb-ból körülbelül 15Mb-t foglal el a boot manager. Maga a boot loader kábé 400k, ugyanennyi mellette a memtest, ezen kívül még 23 nyelv fájljai találhatók itt darabja 80k körül. Ami ebből a 15Mb-ból sokat foglal, az a távolkeleti és egyéb kriksz-kraksz nyelvek fontjai, össz kábé 12Mb.
  Ha már ennyire érdekel.
  Persze lehetne az egész egy 20Mb-s partícióban is, de partíciót mint tudjuk igen körülményes átméretezni, úgyhogy a ráhagyás nem árt senkinek. Egy átlag mai 1Tb-s lemez kemény 0,01%-át foglalja el. Katasztrófa.

  újratelepítés? az mi?
  Az az, amikor a Windows XP-t nyolc évi folyamatos használat (és öt komplett hardvercsere) után nem lehet upgradelni Windows 7-re

  Kicsit a biztonságról, mielőtt valaki ellent mondana nekem: a win rendszerek eredetileg egygépes rendszerek voltak, nem volt sok értelme a biztonságnak
  Kicsit a biztonságról, hogy csökkenjen a globális tudatlanság a világban. A Windows NT vonal (ami a Win2000-ben és az XP-ben teljesült ki használható asztali rendszerként) eleve többfelhasználós rendszernek készült mind server mind workstation oldalon.

  Az okés, de itt most nem ez volt a téma, hanem az, hogy user engedély kellett-e a kártevő aktivizálódásához. Az SQL Slammerhez sem kellett.
  Meg még jópár routereket célzó kártevőhöz sem. Ja, az erősebb routerek általában BSD-derivatívákat futtatnak, amit egyébként még a Linuxoknál is biztonságosabbnak tartanak.

  Egyrészt a játékok futtatása vállalati környezetben egyáltalán nem szempont,
  Nem, viszont vállalati környezetben a mindenféle irányítási rendszer futtatása a szempont, ami ha egyedi fejlesztés, akkor szinte biztosan nincs alternatívája másik platformon, de még ha általánosabb dobozos termék, akkor sem valószínű, hogy triviális a migráció két hasonló célú de különböző szoftver között.
  Ezen túl meg azért van kis különbség aközött, hogy egy jól belőtt Active Directory infrastruktúrát migrálnak egy későbbi Windowsra minimális változtatásokkal (amiben elég terjengős migration guide-ok segítenek), vagy lehet felépíteni a tök új management infrastruktúrát tök másik környezetben.

  Melyik levelező rendszer tárolja egy konténerfájlban az összes levelet? Tán csak nem az exchange...
  Mint ahogy az adatbáziskezelők nagyobbik része is egyetlen fájlban tárolja az egész adatbázist. Illetve konfigurációtól függően szét lehet kenni több fájlra illetve több fizikai eszközre. Namost a tisztességes (mondom tisztességes) adatbáziskezelőkre nem lehet azt mondani, hogy nincsenek szarráoptimalizálva.

  Mert ha az az egy fájl megdöglik, megdöglött az egész hóbelevanc.
  Mert nem triviális menteni.
  Ha egyetlen egy fájl megdögölhet, akkor a rendszergazda nem végezte megfelelően a munkáját és nem kellő redundanciával alakította ki a rendszert.

  Mert a konkurrens hozzáférés zűrösebb ilyen esetben.
  Miért volna zűrösebb? A konkurrens hozzáférést ugyanúgy egy szolgáltatás ütemezi.

  Mert nem tudod szétosztani az IO terhelést.
  Az "egytárolós" rendszerek többségét be lehet úgy üzemelni, hogy több filegroup-ból jöjjön össze egyetlen logikai adattár és finoman hangolhatók minden egyes fájl jellemzői pl. növekedési faktor, maximum méret, stb.

  Valahogy nem tudom elkepzelni magamrol, hogy egy olyan szerveren dolgozzak amin van GUI . Mar csak emiatt is nehez lenne megszokni a Win -t ( a tobbi dolgokrol nem is beszelve )
  Valahogy nem tudom elképzelni, hogy konzolból guberáljam ki, hogy pl. két kattintással kapjak az arcomba egy színes-szagos-részletes-diagramos jelentést az IT infrastruktúra állapotáról, ami azon túl, hogy első ránézésre elárulja, hogy milyen problémákkal érdemes foglalkozni a rendszerben még a főnök orra alá is dörgölhetem változatlan formában.

  A másik, hogyha konténer/adatbázis fájlokba pakolod a leveleket, akkor neked olyan funkciókat kell újraimplementálni (részben a zárolást, emellett a töredezettség mentesítést, üres helyek összepakolását), amit egyébként az oprendszer gyártója a fájlrendszerben egyszer már megcsinált. Felesleges plusz munkának gondolom ezt.
  Nem tudom, ismered-e a történetet, miszerint a Windows 7 kernelfejlesztői kölcsönvettek pár szakit az SQL teamtől, hogy a kernel ütemezőjében felmerült szinkronizációs bottlenecket segítsenek feloldani. Az eredmény: a Windows 7 csuklás nélkül skálázódik akár 256 magra is, a korábbiak már 32 magnál köhögtek. Bevallom engem igen meglepett, hogy az SQL team olyan technológiákban jár fényévekkel a "hivatásosok előtt", amihez elvileg közük nincs. Ez persze nem azért van így, mert a régi scheduler használhatatlan lenne, hanem azért, mert erre a célfeladatra egyszerűen nem elég jó (és azért nem lett elég jó általános célra, mert az órajelek növelése helyett az ipar a párhuzamosítás felé indult el). Ez ugyanígy igaz a fájlrendszerre, a virtuális memória kezelésre, stb. Lehet egy directory-ban tárolni fájlszázezreket, de az NTFS egyszerűen nem erre van optimalizálva.

  [ Szerkesztve ]

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