Leállás: Unix helyett MS a dél-kaliforniai légirányításban

Hali!

Ha feltetelezzuk hogy a szobanforgo oprendszerek nem hordoznak eleve hibat, es ha megallna az ido vagy fejbelonek az osszes hibat feltaro es azt kihasznalo programozot, szinte barmely rendszer jo hardveren evtizedekig futhatna... hogy megis miert szeretnek egy olyan repulogeppel utazni amit unixos rendszerek segitenek?

Pont a fejlesztok, programozok miatt:

Szubjektiv velemeny es 100 bol nemi is igaz 100 szor, de en a magam reszerol sokkal inkabb megbiznek egy olyan ember munkajaban aki hajlando megtanulni es ezaltal hatekonyan hasznalni pl a vi editort ami elsore valoban tenyleg nem "felhasznalobarat"... Hajlando megtanulni melysegeiben megismerni azt a rendszert amire programot ir.

Semmikeppen nem biznek tul sok mindent egy olyan oprendszerre, es fejlesztokornyezetere, ami ugy reklamozza magat hogy kulonosebb programozoi ismeretek nelkul harom kattintas es ket programsor beirasaval mar elo is all a kivant alkalmazas. Ugyanis ez magaban hordozza hogy egy ilyen mokus meg is teszi ezt.

felreertes ne essek, gagyi feluletes hasznalhatatlan programok irodnak open source rendszerre is, a gyakorlat megis azt mutatja, (az en tapasztalatom) masolhato jolmukodo orba-szajba kitesztelt forraskod atvetele mindig jobb eredmenyt hoz mint a gyors panelelemekbol epitkezo ganyolas.

Sajnos cegunk egy reszlege is allit elo easy to use rapid development es hasonlo szlogenu fejlesztoeszkozokkel programokat melyek lassuk be a valodi elet valtozatos vilagaban neha meg sem kozelitik a sz@rt se er szintet.

Akit megvert mar a sorsa olyan feladatokkal amik peldaul egy felnap alatt megirt konyvelo clipperprogram eves adatmentese es visszaallitasa jelent, az tudja mirol beszelek. es itt sem a dos 6.22 a hibas hanem a programozo.

Sajnos a nepi megfigyelesek azt mutatjak, hogy az ilyen selejt progikkal gyakrabban talalkozhatunk a fenti csabitasnak koszonhetoen a zartkod mint az opensource oldalan.

Termeszetesen ez altalanositas, es mint ilyen eleve szubjektiv. van pelda az ellenkezojere is.

Utolso gondolatkent had szabadjon megemliteni a cikk utolso sorai kozt fellelheto mondatot miszerint a backup rendszer technikai hiba miatt nem indult el.... tisztelettel megkerdeznem, hogy ezt is a porba alazott programozo szurta el?

Elvtarsi udvozlettel

Meng

IMHO az API fosch, de nagyon. Utalok megint ezzel jonni, de Amigan (erted, reg halott gagyi jatekgep) alapbol 64 bites erteket ad vissza a timer.device, nem is tudsz mast kerni tole. Plusz tudsz delta erteket is kerni, vagyis az elozo lekerdezes ota eltelt idot, szinten 64 biten. Na ezt csorditsd tul. (Persze lamer programozon semmi sem segit, de legalabb nem az API hathatos segitsegevel generalta a bugot.) Ezenkivul csokoltatom az Unixok es az M$ API dizajnereit, lamerz. (Tetelezzuk fel, hogy volt olyan, hogy megterveztek, nem csak ahogy esik ugy puffan...)

Egyebkent latszik h. megy az egymasrol lopas. Varatlan fordulat, az OS/2 belso idozitoje is 49.7 naponkent csordul tul... Szanalmas az egesz szamtech, ez van.

Gondolom a cikkbekuldo azert most kuldte be, mert most zarult le a vizsgalat. Ahogy a cikkben is irta.

A magyar abc betuinek megfelelo sorrendben valo ertelmezese (gy.k.: olvasas) nem lehet az erosseged :-D

Mint ahogy mar mas is irta, van ra megfelelo fuggveny...

Erted, ez most olyan, mint ha fogkefevel tisztitanad ki a szobat es utana leszolnad a fogkefe gyartojat, hogy mennyire nem praktikus vele takaritani.

BTW: bar nem ertek hozza, de eltudom kepzelni, hogy valami posix dolog miatt kell ez a fuggveny es azert van benne OS/2-ben is, meg Linux-ban is.

Van ra fuggveny. Most mar van, de ez nem "tunteti el" a regi API gyengesegeit. En meg emlekszem arra az idore, amikor maga a Windoz is lehalt 50 naponkent, es bizony az NT is...

Tovabba nem szolnam le a fogkefe gyartojat, ha ezt a fogkefet nem arulta volna takaritasra es legifolyoso-tisztitasra is alkalmas eszkozkent...

Az OS/2 egyebkent alapbol nem POSIX, viszont szinten 1000hz-n ketyeg az utemezoje... Eleg gyanus, h. a regi Linux kernelben meg, ami 100hz-n ketyegett 497 naponkent jelentkezett ugyanez a problema... Szoval teny, hogy egy tipushibarol van szo, ami gyanusan osszecseng azzal amit Matt Dillon (varatlan fordulat: regi Amigas programozo) ir a DragonFly BSD oldalan arrol, hogy barmi ujat ir mindjart megkerdezik tole, hogy mi alapjan irta, az hogy valodi innovaco, fel sem merul, a tenyleges ujito szellem pedig meg ritkabb.

Egyszoval en nem azt mondom, amivel gyakran megvadolnak, hogy az Amiga-szeru rendszerek mindenben jobbak mint masok. Viszont megtanitanak maskepp gondolkodni es felmerni hogy mi lehet a valodi erteke egy-egy ujszeru, vagy a bevettol gyokeresen eltero megoldasnak.

m$ vagy nem m$, hasonlot BARMILYEN rendszerrel lehet produkalni ha ilyen gondolkozassal es odafigyelessel uzemeltetik ;-( Bar ezt az X naponta ujrainditast mar winnel kapcsolatban m$ certified engineer (?) emberkektol is hallottam hogy kell kisse rotfl.

Ezt a hírt kb. egy hónapja olvastam hwsw-n, mindenesetre megrázó... Bár ilyen helyeken, ahol kritikus dologra kell, felébredhetnének... Egyébbként a szoftver volt a hibás ott, és nem a windows...

>decemberben lezárt vizsgálat az alábbi tényeket tárta fel

Egy honapja meg csak november volt :-) Egyebkent szerintem ez mar sokkal-sokkal korabbi hir.

Látszik, hogy nagyon hozzáértő vagy, meg ezek szerint az MCE haverod is...

Te tényleg komolyan gondolod, hogy egy Windows 2000 szervert ilyen okból újra kell indítani? Látható, hogy közöd nincs ismét a témához. Egyre jobban lejáratod magad az ilyen jellegű anti-"m$" hozzászólásaiddal...

Azért hogy tiszta legyen, elmondom, hogy nem a Windows volt a hibás ebben az esetben sem, hanem az a programozó, aki légiforgalmi irányítórendszert olyan függvény felhasználásával írta amelynél a Microsoft az SDK-ban [msdn.microsoft.com] külön kiemelte, hogy ez a függvény a rendszer indulása óta eltelt millisec értéket adja vissza, amely egy DWORD változóban van tárolva, ezáltal 49.7 naponta lenullázódik. Persze, ki is számolhatod, ha képes vagy rá:

0xffffffff = 4294967295

4294967295 / (24*60*60*1000) = 49.7

Arról, nem tehet az MS, hogy ilyen balfék programozók vannak, akik a hiba kiderülte után is ahelyett, hogy megfelelő függvényt használnák inkább a rendszergazdákra hárítják a felelősséget azzal, hogy indítgassák újra a rendszert 30 naponta...

Mielőtt még jönnél a "bezzeg a Linux" okoskodással, elmondanám, hogy ott is megtalalható egy hasonló függvény, amely szintén 49.7 naponta lenullázódik... Akkor a Linux is xar? Vagy csak meg kellene tanulni programozni?

Gondolkodj már, mielőtt baromságokat irogatsz...

A bixnél 1-2 éve kapcsoltunk le egy NT szervert 680 napos uptimeal, akkor az délibáb lehetett? Persze jelenleg is fut a környékemen jópár Windows 2000 szerver több száz napos uptimeal, de szerintem ezt bárki meg tudja erősíteni aki kicsit is komolyabban foglalkozik Windows szerverekkel és nem csak hallomásból tud róluk...

"The elapsed time is stored as a DWORD value. Therefore, the time will wrap around to zero if the system is run continuously for 49.7 days."

Az incidens megtörtént valamikor (novemberben?). Elkezdték a vizsgálatot. Decemberben lezárták. Ennyi.

Mint az eredeti angol cikkek datuma mutatja szeptemberben, de reszletkerdes.

és?

aki winre irta azt a szoftfert az egy balfek a unixos szoftverrel nem volt ilyen gond mert a unixos programozo jol irta meg.

innetol les_z_a_r_om

tanuljanak meg kodolni

Ja, és mint az a fenti cikk első mondatából is kiderül. :-)

Érdekel, hogy hogyan adták volna el a sztorit ha lezuhan 1-2 gép.

Nem működött a windows éppen, (nem volt) >> "windows nélkül veszélyes az élet" vagy "where do you want to die today"

Egyébbként az a legviccesebb, hogy a szoftver, amit használnak, létezik UNIX-okra is, ezt írta a HWSW-n. Nem tudom, nekik miért kellett win2k server...

Teljesen igazad van hunger!

Ugy latszik meg vannak itt azert normalisan gondolkodo emberek is.

GetTickCount-ot hasznalni? rotfl

Helyette szokas a QueryPerformanceCounter es a QueryPerformanceFrequency hanyadosaval merni az idot (foleg server-en), mert az sokaig birja es meg pontos is.

Ez mar egy 1000 eves szakallas tortenet, jo hogy nem 2 ev mulva raktatok ki

Gondolom baromira érdekelete volna a hozzátartozókat ha lezuhan a gép hogy milyen változókat használt a programozó, mégha _valóban_ Ő is hibázott ez felhasználói szemszögből rohadtul nem érdekes.

Csak nem öröklétű vagy? 1000 év, pff! :-D

Biztos azért került ki, mert kkemenczy küldte be :)

Akkor mé nem a programozót fikázza mindenki? Mer itt azon van a hangsúly, hogy Win milyen fos, mert negyvenvalahány naponta újra kell indítani.

Nem a Windows nem működött. A program, amit futtattak rajta. Tényleg nem fér a pici kobakotokba? :-)

Mindez szep es jo de gondold at ujra... Ha az ertek nullazodik a rendszer nem akad ki ... Kivetel ha a DWORD ertek kitolodik akkor viszont az tenyleg freez...

?????

"kitolodik"

?????

"freez"

?????

Ezt nevezzuk inkabb az ms SDK a programozo es a rendszergazdak egyuttes hibajanak...

Miert is? :)

Linux alatt letezik hasonlo de tudomasom szerint az uptime ot nem dword be tarolja a rendszer...

Nem voltam eleg vilagos? A Windows sem dwordben tarolja az uptimeot. A fuggveny amelyet a programozo hasznalt nem az uptime lekereset szolgalja...

turcsordulas eseten nullazodik erre kulon fugveny ugyel...

Windowsnal szinten ez tortenik, lasd az eredeti angol sdk idezetet... :)

De egyebkent lehett tobb szaz napos az uptime ja egy window 2000 nek de mak kell hozza ugyebar hogy dcom-ot updateld ahhoz reboot kell es ugye voltak erdekes secholt fogo fergek...

Ez mar gyakorlati kerdes... Nyilvan letezik tuzfal... meg intranetes windows 2000 szerver, amelyet nem feltetlenul updatelnek allandoan... stb.

Persze en ehhez az egeszhez hulye vagyok...

:)

Teljesen igazad van hunger!

Ugy latszik meg vannak itt azert normalisan gondolkodo emberek is.

Kosz, orulok, hogy valaki legalabb megertett. :)

GetTickCount-ot hasznalni? rotfl

Helyette szokas a QueryPerformanceCounter es a QueryPerformanceFrequency hanyadosaval merni az idot (foleg server-en), mert az sokaig birja es meg pontos is.

Ott a pont! ;)

>Ez teljesen így van. A legszomorúbb az egészben, hogy a migráció előtt bevizsgálták [www.harris.com] és 0.9999999 -esnek találták a fejlesztett rendszert....

Naja, azokat kellene bevizsgálni, akik ezt a rendszert bevizsgálták és rábolintottak... :)

és?

a unixra irt szoftver is tartalmazhatta volna ugyanezt a hibat, hisz ugyanilyen fuggveny unix/linux alatt is elerheto. Ebbol max. azt lehet levonni, hogy a unixos programozo jobban ertett a mestersegehez, mint a windowsos tarsa, de ez se nem library hianyossag, se windows specifikus problema.

ez a lenyeg.

Ez mar gyakorlati kerdes... Nyilvan letezik tuzfal... meg intranetes windows 2000 szerver, amelyet nem feltetlenul updatelnek allandoan... stb.

Hat en intranet-en is update-elnem azer' azt a win2k servert...

Mennyivel jobb ha belulrol dogleszti meg valami beszopott virus/fereg? Max. kissebb az eselye, de megteszi...

Madman wrote:

> Ez mar egy 1000 eves szakallas tortenet, jo hogy nem 2 ev mulva raktatok ki

Es ugye ezt most neked roppantul fontos volt elmondanod? Ha nem erdekel,
akkor lepj tovabb, nem fontos hozzaszolni. Amugy nekem ez hir erteku
volt, mert nem gyakran olvasok hwsw -t, plane nem kulfoldi oldalakat...


IroNiQ
p.s.: mongyuk az igaz, hogy nekem is folosleges lett volna valaszolni,
de nem tudtam kihagyni...
--
Member of Frugalware Developer Team
Email: iron_uh.qinori

Hat en intranet-en is update-elnem azer' azt a win2k servert...

Mennyivel jobb ha belulrol dogleszti meg valami beszopott virus/fereg? Max. kissebb az eselye, de megteszi...

Jo, ebbe most ne menjunk bele, mert megint elterunk a targytol... A lenyeg, hogy futtathat olyan specifikus szolgaltatast egy win szerver, amelyen kivul mashoz nem ferhetnek hozza sehonnan, igy a publikus hibak kihasznalasanak valoszinusege minimalis. De mondtam, ez mar gyakorlati kerdes... Ha egy Linux szervernel is allandoan minden kernelre kijovo hibat javitananak, akkor 1 honapnal tobb uptime ott se nagyon lenne. ;)

Mert a Windowst meg a Microsoftot jobb és megszokottabb szidni, még ha nem is igaz amit állítanak róla... :) Mindegyik anti-"m$" hülegyerek megszokta már, hogy ha valamivel kapcsolatban jól leszólja a win-t meg az ms-t, akkor gondolkodás nélkül mögé áll még jónéhány hasonló egyed és együtt élvezik a falkában való szitkozódást, ami számukra felemelő érzés, függetlenül attól, hogy igaz-e amit irogatnak/mondogatnak vagy sem... :)

Aki meg esetleg megpróbál gondolkodni és az MS-t megvédeni, hogy jogtalanul ne becsméreljék, azt meg Window$ imádónak és M$ megszállottnak hívják. :P

hat akkor hasznalj windozt, minek szarakocc unixal? sok .conf meg fapados karakteres kornyezet. klikkelni egyszerubb

btw.

wines programozo >>win

unixos programozo>>>unix

ez az asszociacio benne van az emberekben.

a masik dolog hogy ez egy bevizsgalt rendszer. ki vizsgalta be? nyilvan valamilyen 3diplomas certified MS kollega aki szinten IT zseni.

a windoznak is megvan a maga helye:

-jatek

-multimedia

-vallalati desktop kornyezet word, excel, access, viso etc.

de nem legiiranyitas server.

hat akkor hasznalj windozt, minek szarakocc unixal?

hasznalok azt is es unixok kozul is eleg sok felet. mindegyiknek meg van a maga keresztje, ezert nem szeretem az allando anti-"m$" propagandat.

a masik dolog hogy ez egy bevizsgalt rendszer. ki vizsgalta be? nyilvan valamilyen 3diplomas certified MS kollega aki szinten IT zseni.

ebben azert en ennyire nem lennek biztos. Nem tekintheto megfelelo megoldasnak egyik operacios rendszeren sem, hogy egy third-party applikacio megkoveteli az x naponta valo teljes rendszer ujrainditast... Ilyet egy komoly bevizsgalo ceg nem hiszem, hogy engedelyezne, fuggetlenul attol, hogy az az applikacio unixon vagy windowson fut.

a windoznak is megvan a maga helye

de nem legiiranyitas server

Ez szerintem megint csak hit kerdese. Olyan mint amikor a BSD-ket beskatulyazzak "csak tuzfalnak jo" kategoriaba. Egy Windows rendszert is lehet clusterezni, jo hardveren nagyon stabilan tud futni, de arra is lehet rosszul fejleszteni, mint ahogy barmi masra is.