Új hozzászólás Aktív témák
-
Azért nem eszik olyan forrón azt a kását. A cím alapján elsőre az ugrott be, hogy te jó ég 300 hiba a 12c-ben, merthogy számomra, ahogy gondolom a többség számára is Oracle = adatbázisszerver. Tudom megvette a sunt, ezért övé a java, MySQL-t is tőle lehet letölteni, sőt találkoztam a „csodás” vállalatirányítási rendszerével is, de elsőre akkor is a 12c ugrik be, mint a cég sikerterméke. Ha azt nézem mekkora portfolióra oszlik szét a 300 hiba nem is olyan sok. Ennyit szerintem az M$ vagy az IBM is megtermel…
Miért probléma, hogy csak negyed évente van frissítés? Egy adatbázisszerver nagyon nem Vér Pistike MySQL-el megtámogatott webszerverecskéje. Az egy dolog, hogy kijött a frissítés, az pedig egy másik, hogy a teszt síkra felrakják a javítást, letesztelik, és ha minden jól megy, akkor a következő change ablaknál mehet az éles síkra is. Szerintem kevés cégvezető van, aki attól parázik, hogy egy hete kijött a javítás, meg 3 hónapja ismert hiba, és még mindig nincs kint a patch az éles síkon. Inkább attól szoktak parázni, hogy pár napos tesztelécske után kimegy a javítás az éles síkra, és ledöglik a könyvelés.
Javaban írt programnál még nagyobb a kockázat, hogy megy-e az új Java-val is.
Szóval nem hiszem, hogy annyira SOS-be frissítenék nagyvállalati termékeket. Főleg, ha kívülről nehezen elérhető. Egy nyilvános webszerver más tészta, de ez nagyon más.
Kérdés: Mennyivel lenne jobb, ha havonta, két hetente adna ki javítást? Egyik hónap java, másik, MySQL, aztán Oracle 12c. Jah, hogy akkor is negyed évente jön frissítés a 12c-re? Ugyanott lennénk...[ Szerkesztve ]
-
A gond inkább akkor van, mikor a gyártó tesz arra, hogy bugos a terméke, és csak akkor kezd el javítócsomagot csinálni mikor a sebezhetőség publikus lesz.
Semmi baj nem lenne, ha a sebezhetőség felfedése után egyből megcsinálnák a javítást, és a következő ciklusnál - legyen az 3 hónap múlva - kiadnák és akkor jelentenék be a publikumnak is a sebezhetőséget.
Onnantól kezdve tényleg a használó vállalaton múlik a biztonság.Ameddig nincsenek automatikus tesztek addig nem lesz felgyorsítva a tesztelés menete, és marad ez a döcögős stílus. Tudom, ezer éve van rá program, és api is, de a cégeket nem igazán izgatja. Lényegesebb az ár. Egy fejlesztésnél pedig olcsóbb ha a tesztelés úgy megy, hogy van egy tesztelési forgatókönyv, azt az átvételnél lenyomkodják és kész. Hogy az később is jól jönne, hogy könnyedén le lehetne ellenőrizni, hogy egy másik átalakítás nem érintette-e ezt a modult, az már nem szempont.
Lehetne említeni a fejlesztők felelősségét is, hogy miért nem követelik meg, hogy ők csak automatikus teszteseteket hajlandóak összeállítani. Az egészen addig jól megy, míg a szoftver nincs más alkalmazással összekötve. Onnantól kezdve két fejlesztő cégnek kéne összedolgozni az automatikus tesztelésen. Ez megrendelői szándék nélkül nem lesz.Tegye fel az a kezét, akinél úgy rendeltek szoftvert, üzemeltetést, hogy a pénz (és az idő) nem számít, a lényeg, hogy stabilan működjön.
Új hozzászólás Aktív témák
it Mivel meghatározó piaci szereplőről van szó, ideje lenne átalakítaniuk a frissítési mechanizmust.
