Pa normalno je da proprietary sw bude manje bugovit, ljudi od njega žive. Zna se šta se hoće, imaš market-research, marketing, programere, i "onog na vrhu" koji daje konačnu reč.



Nisam baš siguran u istinitost ovoga. Ipak je to slashdot, svako tera vodu na svoju vodenicu

Svaka im čast za otkrivene bugove. ;)

Zaista,ima jako dobrog proprietary sw ali je velika vecina djubre, i to djubre kakvo ne mozete ni naci da je OSS. Evo primera: development tim pravi RPG, ali je menadzment odlucio da se koristi 3rd party engine koji nije pogodan za to, vec za FPS (jer je taj engine hypeovan npr.). Nema npr.koncepta zdravlja (hit points) ili magijskih poena? Sta sada? Dolazi do budzenja samog engine-a, ili direktno, prepravljanjem koda engine-a ili ekterno, npr.preko pythona. Medjutim, development tim koji pravi igru nema pojma kako je kao celina engine dizajniran (a prepun je ruznih hakova), a nema ni vremena, pa to povuce bagove u izvesnim situacijama. Nema ni jedne igre koja dobro radi dok se ne izbaci prvi patch. Neke su kao 1.0 bile toliko bagovite da uopste nisu mogle da ze igraju. Razlog za to je vrlo jednostavan, za igru nije potreban kvalitet, vec grafika, zvuk i ev. fransiza koja se prodaje i dobar marketing. Nikoga ne zanima da igra bude stabilna i bez bagova, kada je nakon sest meseci niko nece igrati, ali je izuzetno vazno da se time to market ne prebaci, recimo, cilja se Bozic, ili ne daj boze, da se oduzi pravljenje igre pa da rad 3d modelera i dizajnera padne u vodu, jer zastari za sest meseci. Ima i OSS softvera koji ne da ne radi out of the box, vec ne uopste, ali vam ga ne prodaju.
Ima i odvratnog proprietary softvera npr. iPod sw/iTunes npr. (za mac zealote, cini mi se da Microsoft ni u jednom svom proizvodu tako agresivno ne reklamira drugi, i ne sprecava 3rd party solucije, ako cemo o slobodi). Normalno je da ti sw na windowsu instalira i sta treba i sta ti ne treba (npr. Quicktime/iTunes), da automatski startuje servise bez tvog odobrenja i sl.

Istrazivanje je u domenima poredjenja krusaka i jabuka. Recenica covjeka koji je napisao originalni clanak (ne Slashdot komentari)



Problem, i to veliki, je sto se u kategoriju "proprietary software" trpa sve sto nije otvoren softver. Telekomunikacije i aerospace, to su klasicni primjeri "mission critical" aplikacija (aerospace vise nego telekomunikacije), gdje se softver razvija sasvim drugacije nego sto se to radi u "obicnom" softveru (u obicno spada sve sto koristi MS proizvode).

Sa ovim:


nema, valjda, uva koje se nece sloziti. Ali, vjerujte mi, u slicnoj situaciji, you don't want to fly MS.

Ne znam mission-critical aplikaciju koja je implementirana na MS infrastrukturi, cak ni na WinCE. Takodje, ni Linux kernel nije tamo gdje treba da bude za potrebe carrier-grade telekomunikacija ("6 devetki", tj. 10 sekundi down-time godisnje, zasad implementirano "5 devetki" sto je kategorija "enterprise"), a kamoli aerospace (i vojna industrija).

Bio bih zahvalan da me neko demantuje i istovremeno prosveti.

Isto tako niko nije tvrdio da je MS softver/OS pogodan za mission-critical primene u vojnoj ili saobracajnoj industriji.
Mada ga vidjam na ATM-ovima :)

Mission critical OS je disciplina za sebe, tako da tu i ne ocekujte da vidite nista nalik ni Windows ni
Linux-u.

Elem, pre nekih 12+ godina bio sam na intervjuu u biomedical firmi koja pravi lasere za hirurske namene.

U oblastima gde se radi sa ljudima (kao sto je medicinska praksa) i gde se vrlo lako potezu multimilionski
sudski procesi za odstetu, greske jednostavno ne sme da bude. Ako bilo sta ikada odkaze, ceo proces
mora da se 1000% sigurno prizemlji.

Jeste da sam bio prilicno mladji inzenjer nego sto sam to sada, ali ni pre ni kasnije se nisam nasao u
situaciji da vidim da uobicajene dizajn paradigme jednostavno ne vaze na nacin na koji ih vecina ljudi
posmatra.

Glavni twist u celoj prici je da se nista, ali ama bas nista ne uzima za gotovo. Release kod uvek pocinje
od validacije svega i svacega na cipu (sto nikome u normalnoj praksi dizajna softvera nikada ne bi palo na
pamet - mozda tokom pisanja programa, ali sigurno ne u Release verziji)
- da li pisanje/citanje u registar XYZ daje logicne rezultate.
- da li su svi sticky flags zaista sticky
- da li rade jump operacije kako treba
- da li je stack memorija ispravna (upis/citanje/poredjenje/testiranje)
- da li je heap memorija ispravna (ista metodologija)
- da li su inicijalizovane promenljive zaista dobile predvidjene vrednosti
- ....

Dalje, svaki algoritam (kontrola procesa moze da bude komplikovana) ima bar jos toliko koda koji vreba
greske.

Sve opisano se obavlja prilicno periodicno, na tajmer. Nisam zapamtio ko proverava tajmer da li radi ili
ne.

U svakom slucaju, mission critical dizajn zahteva specijalno uvrnut nacin ekspertskog razmisljenja, i koliko
mi se cini, nece se nijedan normalan operativni sistem tu hleba najesti.

Neš sam malo guglao, i pogodite koji OS koriste NASA-ini astronauti dok orbitiraju u space shuttleu stotine kilometara iznad majčice Zemlje?

Oh yeah:

http://www.spaceref.com/shuttle/computer/spoc/
(kliknite na linkove/shotke slijeva)

Izgleda da koriste NT-bazirane windowse za kontrolu life-support sustava uključujući sustave upozorenja (warning) i nadziranja (monitoring):

http://www.spaceref.com/shuttle/computer/spoc/cautwarn.html

Evo primjer jednog od tri dijagrama mrežne infrastrukture za space shuttle i ISS:

http://www.spaceref.com/shuttle/computer/106.LAN.nominal.html

Bar nekoliko od njih voze NT-bazirane windoze, a sudeći po softveru kojeg vrte kompovi sa neimenovanim OS-om, čini se da se opet radi o Windowsima

Nigdje ni spomena Linuxa....

PS: Ardence (PNA VenturCom) pruža hard real-time ekstenziju NT-a u obliku RTX-a koji pruža determinističke timere, scheduler te specijalne shutdown handlere koji dozvoljavaju apps da prežive rušenje OS-a i da nastave sa svojim radom bez OS-a, baš kao što bi mission-critical sustavi i trebali biti.

Pogle listu korisnika RTX-a, ima tu i industrijske automatike, vojske, aerospace, medicinski uređaji...ako to nije mission-critical, ne znam što jest

_{[Ovu poruku je menjao cynique dana 14.10.2006. u 14:51 GMT+1]}

Bolje reći, ne očekujte ništa slično glupim imperativnim jezicima koji podržavaju globalna stanja, in-state modifikaciju i mutabilne varijable uopće :D

Recimo masivni telekom sustavi koji su teški desetine milijuna linija koda se pišu u funkcijskom jeziku zvanom Erlang, koji npr. vrlo lako dopušta live upgrade sustava, i na taj način se može minimizirati downtime sustava na par sekundi u deset godina.

Kako bi išta slično obavio u jeziku tipa C++/Java/C#? Da kod reloada novu definiciju klase at runtime? Prvo serijalizirati svaku instancu klase na perzistentni storage, osloboditi njihov memorijski prostor, kreirani nove objekte, pokušati loadati serijalizirane podatke (i pri tome se nadati da stanje objekata pravilno migrira na nove definicije klasa), i pri tome svaki put iznova pisati kod za upgrade. I pri tome paziti da taj kod na razbije odnose između objekata, hijerarhiju i međuovisnosti.

U Erlangu samo odradiš diff koda i posebni alati samog jezika urade upgrade automatski :D

Također je interesantna priča o padu Lispa u NASA-inom JPL-u, gdje su prešli na C++ iz političkih razloga:

http://www.flownet.com/gat/jpl-lisp.html

Onaj dio o tome kako dobro dođe REPL kad otklanjaš bugove na softveru koji se vrti na letjelici teškoj 100 megadolara udaljenoj 100 megakilometara je antologijski :)

Dok si jos vruc i u igri:

VisualStudio standardno pruza 'modify code at run-time' opciju.

Daj malo detalja o tome - nedostaci, ogranicenja...

Ne vidim nigdje tu opciju...gdje se ona točno nalazi? Da ne misliš možda na /hotpatch mehanizam u detalje opisanom u registriranom patentu #20040107416? Ovaj zadnji je isključivo namijenjen apliciranju sigurnosnih zakrpa za neke trivijalne sigurnosne bugove (obično loša validacija arbitrarnog inputa), ne za upgrade funkcionalnosti koda.

Mislim na scenario koji se zove "Edit and Continue'. Cinjenica je da se radi dok je procesor u
'break' modu, dakle iskljucivo u debug verziji, ali opet se radi o modifikovanju koda 'u letu' i
nastavljanje bez restartovanja celog procesa/aplikacije.

Da, nešto poput E&C samo što je u slučaju Erlanga ovo primjenjivo i na produkcijskoj razini. Fundamentalna je razlika što je E&C svojstvo samog IDE-a + debuggera + C++/C# kompajlera. Jednom kad linker izbljuva optimiziran binary, nemoguće je "u letu" zamijeniti pokrenuti program sa novom verzijom ako su izgubljeni podaci iz npr. tablice simbola, različitih faza analize ovisnosti, kontrole toka izvođenja i sl. Već spomenuti hotpatching je nešto najbliže tome, ali on radi samo ukoliko signature funkcije nije izmjenjen, s tim da stara verzija koda ostaje beskorisna u memoriji.

U Erlangu je ovo svojstvo samog jezika, ustvari kao i kod svih funkcijskih (funkcionalnih) jezika posljedica modeliranja na Churchovom lambda računu, koji predstavlja formalni model izračunljivosti za kojeg se može pokazati da ima istu ekspresivnu moć kao i svepoznati Turingov stroj. U jeziku bez globalnog stanja i side-effecta, nijedna fja ne može modificirati vrijednosti "in place" izvan svog scopea, u svrhu korištenja od strane druge fje (npr. memberi klasa i globalne varijable). Na taj način se može dosegnuti sveti gral debuggiranja - pošto nijedna fja ne ovisi o vanjskom stanju koji je proizveo side-effect druge fje, bug nikad ne ovisi o nekom toku izvođenja nevezanom za trenutnu fju, tj. ne može se dogoditi (kao u imperativnom programu) da se bug događa samo nekad (na MySQL strojevima koji su pod opterećenjem tjedan dana :P).

Na sl. način su funkcijski jezici otporni na race conditione, deadlocke i ostale glupe MT bugiće, jer locking primitivi nisu ni potrebni! (pošto nijedno stanje ne može dvaput modificirati isti thread, a kamoli dva različita threada). Može se ustvari pokazati da je invokacija takve fje ekvivalentna message passingu a la Smalltalk (Sussman je IIRC napisao papir o ovome..), no ne bih sad ni o skalabilnosti erlang-style procesa niti o inherentnoj paralelizibilnosti koda napisanog u fjskim jezicima (paralelizirajući kompajleri bez neke dodatne anotacije preko pragmi ili kakoveć (OpenMP i sl.) su nedostižan san za kompajlere modernih algoloidnih derivata).

Također, koliko me sjećanje služi otkad sam posljednji put koristio VS, E&C ne radi svaki put, neke izmjene koda smatra "ilegalnim" i zahtjeva potpunu rekompilaciju i restart programa. Probaj npr. izmjeniti baznu klasu tipa :)

Moj je dojam da je primarna svrha E&C eliminirati gubitak vremena tokom debugiranja na otklanjanje najčešćih trivijalnih bugova (pogrešno (ne)inicijalizirane varijable, pre/post uvjeti u kontrolnim programskim konstruktima i sl.) - baš onih kojih ima najviše i na koje se gubi najviše vremena, a ne da bude univerzalno rješenje za live upgrade koda.

Ukratko - poanta je da je u Erlangu ovo osobina samog jezika i programske okoline (mutno je to za definirati, bilo tko tko je neš ozbiljnije radio u lisp dijalektima zna da granica između compile time i runtime, između koda i podataka... nije oštro definirana. Zato je onaj lik i mogao debuggirati raketu na 100 000 000 km udaljenosti :) - dok je E&C (ograničen) feature samog IDE-a + kompajlera + debuggera u (isključivo) MS VS okruženju.

_{[Ovu poruku je menjao cynique dana 15.10.2006. u 14:27 GMT+1]}

Znam za Ardence, ex Phar Lap, ali ljudi moji njihov kernel nije NT kernel, mada podrzava Win32 API, tj.onoliko je Windows koliko i Wine.

Za RTX si u krivu, on je samo ekstenzija NT kernela (kernel modul RTSS + custom HAL), win32 API tu nije emuliran, već je onaj izvorni MS-ov. Pogledaj npr. ovaj link:



Na sl. način funkcionira i INtime, ne dirajući bazni OS već samo dodaje real-time scheduler na način što OS i njegove threadove schedula kao zaseban task.

Hvala.

Ovo je stvarno... wow. Zahvaljujem, cynique.


Ne još. Uskoro: http://news.com.com/Linux+headed+into+Boeing+antisub+aircraft/2100-7344_3-6100043.html



Eh, sad... Ako ćemo tako, i LynxOS ima impresivnu listu korisnika, a poodavno i linux ABI kompatibilnost

Ali, niti ja LynxOS racunam u linux pricu (LynuxWorks ima svoju Linux pricu na temu Blue Cat), niti je ovaj RTX abomination Microsoftova prica.