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

• #23 Gregorius őstag Nagy Gábor #22

  Új Válasz 2007-01-24 23:20:54 #23

  Ú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 Nagy Gábor #22 üzenetére

  Pár dolgot szeretnék tisztázni.
  
  1. Nem a nyílt forrású, hanem a tisztességesen megírt, átgondoltan megtervezett, a valós felhasználói igényeknek megfelelő és hasonnló szellemben rendszeresen frissített szoftverek hozhatják el a kánaánt.
  Ezzel egyet értek, úgyhogy ezt inkább a kérdéses cikkek íróinak/hírforrásainak kellene felvetni, nem nekem. Személy szerint nem látok korrelációt egy szoftver open source volta meg a minősége között.
  
  a vásárló nyíltan felvállalt semmibe vételét jelenti, hogy úgy kezdik el egy szoftver tömeggyártását, hogy abban még tudottan komoly biztonsági és egyéb hibák vannak.
  Félreértesz. Kódzárás után nem fogják hagyni porosodni a kódot, hanem tovább nézegetik, a hiba akár a tömeggyártás közben is kiderülhet. Namost egy kritikus rést nem lehet csak úgy betömni, hogy a glass master már a gyárban van, ad abszurdum a szállítmány már le is került a futószalagról. Ugyanígy van az SP-kkel is, gyakran már vannak előretolt poszt-SP hotfixek, amik a pár nappal később megjelenő SP-ben nincsenek benne. Meghúzták a határt, hogy eddig és ne tovább, ez a csomag fog végigmenni a hosszadalmas QA-n, és nem nyúlnak hozzá, mert akkor lehetne az egész QA-t előről kezdeni újra meg újra. (Különböző okok miatt egy SP QA jóval alaposabb, mint egy önálló hotfixé.) Még mindig jobb, mintha kiadás után még egy darabig lapítanának a hibával. Ha meg lehetne azt csinálni, hogy varázsütésre az utolsó build a programozók dekkjéről zéró időn belül átmegy a minőségellenőrzésen és kikerül a boltok polcára, akkor valóban nem fordulna elő olyan, hogy ismert bug van már a polcrakerülés előtt, de ez a folyamat sajna hónapokig is eltarthat.
  Tovább megyek, SP-k esetében akár még kívánatos is lehet, hogy nem várják be az összes készülő fix-et a kiadással.
  
  Szóval az én tapasztalatom az, akár hiszed, akár nem, mindig akad (sajnos) olyan főnök, aki pozícióját kihasználva arra utasít, hogy adjak neki a gépén adminisztrátori jogokat, különben otthon, amikor munkára hazaviszi a noteszgépét, nem tudja kedvenc játék- és egyéb programjait telepíteni és zavarja
  Akkor egyrészt a kérdéses laptop karanténban kezdi minden nap a céges életét, a kérdéses főnök meg csak a saját gépére kap rendszergazdai jogokat. És mellesleg elgondolkodhat azon, hogy szeretné-e minden napját úgy kezdeni, hogy az RG négy órán keresztül exkluzív módban takarítja a gépéről a szemetet. (Arról nem is beszélve, hogy még ha a saját laptopját a főnökre bízzuk, a központi rendszereket, DC-t, adatbázisokat talán nem kéne.)
  
  a mindenféle hardver és szoftvereszközök csak akkor képesek feladatukat (közel) maradéktalanul beteljesíteni, ha a felhasználók legalább némi tudatosságot mutatnak a szoftverek és számítógépük használatában.
  Ez nem egészen a tudatosságról szól. Ha lehetőséget adsz egy bármilyen művelt vagy egybites júzernek, hogy a cég biztonságát akár katasztrofális szinten veszélyeztesse, az régen rossz. Mert ha nem csinál disznóságot, majd a vírus csinál helyette. Nem várhatod el tőle a felelősségteljes használatot, mert - ellentétben velünk - neki nem az a dolga, hogy naponta figyelemmel kísérje az újabb meg újabb social engineering módszereket, 0-day exploit-okat meg hasonlókat. Kap tűzfalat, vírusirtót meg központi policy-t az IT departmenttől, ha ez neki nem tetszik, akkor majd érdeklődhet, hogy miért nem tudja ezt meg azt megcsinálni, a felsővezetés meg visszaérdeklődik, hogy mit csinál munkavégzés helyett.
  
  Ha a nyúzer nem érdekelt abban, hogy betartsa az IT-biztonsági előírásokat, és ezt nem is kérik számon rajta, mindig lesz, aki szétbarmolja a rendszert.
  A ''nem kérik számon rajta'' ismételten felmondási ok a biztonsági főnök felé. Ha pedig számonkérik a júzeren és ő nem tartja be, akkor jobb esetben csak kirúgják, rosszabb esetben meg még csengetnie is kell az ügymenet akadályozása és/vagy szándékos károkozás miatt.
  De most már nagyon elmentünk az irányelvek felé, amik már nem függenek a használt szoftvertől.

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