Teleskop Jamese Webba používá JavaScript se speciálními rozšířeními. Skripty pro specifické úkoly jsou uloženy jako ASCII a NASA je může ze Země spouštět. Interpretuje je Script Processor v Integrated Science Instrument Module (ISIM) Flight Software.
Zároveň může běžet 10 skriptů. Autory software jsou Ilana Dashevsky a Vicki Balzano ze institutu Space Telescope Science. Více detailů naleznete v článku NASA.
(zdroj: slashdot)
To je zajimave. Nikdy by me nenapadlo, ze se na techto mission-critical pristrojich objevi JS nebo jakykoli interpretovany jazyk. Chapu, ze se snazi usnadnit psani programu pro vedce s jinou specializaci, kteri asi Adu opravdu neovladaji, ale i tak. Jsou k tomu nekde podrobnosti? Jako treba zda je jejich custom JS engine k dispozici jako OS? V linkovanem clanku se o tom zminuji jen velmi obecne - ze byl napsat, ze byl JS obohacen o plnohodnotnou konkurenci, atd. Ale uz se neuvadi, zda a kde se k tomu da dostat. Celkove by me zajimalo vice detailu co se tyce rozhodnuti pouzit JS, atd.. Jsou k tomu nejake dalsi clanky? Ma k tomu nekdo nejaky vhled? Diky
Treba taky jde o to, ze skript se jednoduseji kontroluje na spravnost nez binarka, at uz funkcionalni, nebo transportni - coz muze mimo jine hrat taky roli.. skript prenesete jako diff/patch, binarku nikoliv.
Ja uz videl v profi kamere UI udelane v Adobe Flash-i, ktery bezel na PowerPC jadru ve fpga soc-u :-)
> Treba taky jde o to, ze skript se jednoduseji kontroluje na spravnost nez binarka, at uz funkcionalni, nebo transportni - coz muze mimo jine hrat taky roli.. skript prenesete jako diff/patch, binarku nikoliv.
a tuhle ptakovinu jste si vycucal jak ?
Odborník nejsem, ale tady je cosi, i s dalsím obrázkem
https://oicanadian.com/the-james-webb-space-telescope-is-largely-controlled-by-javascript-files/
Ty javascripty (fakt to tak v dokumentech nazývají, například “10 Javascripts”) se používají pro pozorovací plány — přímo uvádějí, že pozorovací plán je “JavaScript object” a mluví o slovnících (dictionaries), takže žádná magie v tom není a nic kritického se tím neřídí.
Já mám osobní zkušenost jen s plánováním a řízením pozorování pro teleskop v Tenerife (kdysi dávno jakožto student astrofyziky), kde se používá (nebo tehdy používal) hlavně Python a plány byly většinou na dvě věci, protože tam furt fouká, takže systém kupoli automaticky třeba na hodinu zavře a plánuje se hezky od začátku :)
Tak především to není "deset mega", ale deset giga. Takže při plánované životnosti 10 let (samozřejmě se doufá, že bude delší) vychází jedna sekunda pozorovacího času na 32 dolarů a vzhledem k tomu, že typická délka pozorování jsou desítky minut až hodiny, to, že teleskop "bude chvilku stát", v podstatě znamená vyhodit desítky až stovky tisíc dolarů.
Jestli umíte navrhnout snímače s takovou citlivostí, jako mají ty na JWST, tak, aby zároveň vydržely pohled do Slunce, aniž by to mělo vliv na jejich funkci a parametry, měl byste asi NASA nebo ESA nabídnout své služby. Myslím, že by vás královsky zaplatily.
Ono to ale naštěstí není tak jednoduché, protože teleskop je od Slunce odstíněn štítem a tipoval bych, že se tím směrem dost možná ani natočit nedá. To ale na druhou stranu zhoršuje dopad případných prostojů z důvodu chyby, protože je omezená oblast, kam lze teleskop namířit, v závislosti na tom, kde na oběžné dráze se zrovna nachází.
Není to nijak podstatné, nicméně:
https://blogs.nasa.gov/webb/2022/01/21/webbs-journey-to-l2-is-nearly-complete/
...
it would require Webb to turn 180 degrees in order to thrust toward the Sun, which would have exposed its telescope optics and instruments directly to the Sun, thus overheating their structures and literally melting the glue that holds them together.
...
Bona Flute: Jste fascinující případ. Víte minumum o kosmonautice, orbitální mechanice, infraoptice, ale přesto jste schopen napsat:
"Jinak prostě žádná mission critical"
"si přijít o ten stroj zaslouží"
"spoj, který by vydržel nějakou teplotu bych si navrhnout troufnul"
Mít Vaši důvěru v sebe sama, tak už jsem ředitel zeměkoule :)
Spis se stavaji jine "zajimave" nadpozemske prusery. A to treba pokud dojde ke studenemu svaru kdyz se dotknou dva kovy za urcitych podminek.
Tady je k tomu takovy kratsi propagandou schvaleny material http://esmat.esa.int/Publications/Published_papers/STM-279.pdf
@Trident Vasco
O vesmíru vím ho*, ale jsem původně strojař, takže vím ledasco o spojích a spojovacích materiálech - a třeba také o ochraných vrstvách, nátěrech, stínění, etc. ...
Evidentně, jelikož zařízení jako teleskopy ve vesmíru fungují, tak musí být známo nějaké funkční řešení, i kdkyž nikdo nenajde nějaké lepidlo, které samo o sobě nemá nějaké vlastnosti.
Altan Sarnai: Jenže on nikdo netvrdil, že neexistuje funkční řešení. Ostatně JWST funkční řešení má. Akorát možná požadavky na některá řešení na JWST byly takové, jaké ještě nikde dříve nebyly. Například pozorovací část je trvale chlazená, to není úplně běžné u jiných satelitů. Na pozorovací část nechcete přenášet vibrace z jiných částí, to se také neřeší na každém satelitu.
@Filip Jirsák
Ano, ono to bylo totiž takové podivné netvrzení ve tvaru tvrzení.
Ostatně to lze vidět i z Vaší odpovědi. Plynule jste navázal podobným polotvrzením, že řešení jsou ale záleží na požadavcích, které ale nezmiňujete, takže zase taková modelína, ze které lze přeplácat kdykoliv cokoliv.
Co vám na to říct? Snad jen souhlasit, že na řešitelné problémy jsou řešení. To by tak odpovídalo této "debatě".
24. 8. 2022, 19:04 editováno autorem komentáře
Dobásnil jste se, že ve vesmíru všechno shořelo. Nebo jste si dobásnil, že neexistují lepidla, která by nevydržela teplotní rozsah, kterému je vystaven JWST.
Zkrátka někdo napíše „v tomto případě platí…“ a vy na to reagujete sarkastickým komentářem „pokud by vždy platilo…“. Zkuste se smířit s tím, že když někdo tvrdí něco o jednom případě, neznamená to, že to platí vždy.
@Filip Jirsák
To byl sarkasmus k výroku "Ve vesmíru shoří pájka" (a milion dalších věcí milion dalších věcí ne), takže výrok je k debatě absolutně nic neříkající.
Nebo jste si dobásnil, že neexistují lepidla, která by nevydržela teplotní rozsah, kterému je vystaven JWST
Lež. Nic takového jsem nenapsal. Protože to prostě nevím.
"„v tomto případě platí…“"
Nic takového nikdo nenapsal. "V tomto případě platí" jste nenapsal ani vy, protože taky víte kulové o použitých materiálech. Jenom jste se navezl do obecného mudrování obecným mudrováním - což je přesně to na co letěl můj sarkasmus původně. To je celé.
takže výrok je k debatě absolutně nic neříkající
Pomohlo by, kdybyste nepsal do debaty výroky, které jsou k debatě absolutně nic neříkající.
Lež. Nic takového jsem nenapsal. Protože to prostě nevím.
Já jsem netvrdil, že jste to napsal. Vy jste si to v hlavě dobásnil ke komentáři a pak jste na tohle dobásnění reagoval.
Jenom jste se navezl do obecného mudrování obecným mudrováním - což je přesně to na co letěl můj sarkasmus původně.
Tak příště zkuste nereagovat na každé tvrzení, které se vám nezdá dokonale konkrétní. Lidé se baví o reálném světě, takže obecná tvrzení běžně používají a všichni ostatní jim rozumějí. Zkuste se tedy smířit s tím, že jsou věci, kterým nerozumíte, a nereagujte na ně.
Trident Vasco: a nejen teploty. Z lepidla se nesmi casem uvolnovat latky, ktere by pak zaprasily optiku. A musi byt dost pevne kvuli namahani behem startu rakety. A nejspis hromada dalsich podminek.
Jinak lepidlo s takovym teplotnim rozsahem snadno sezenes - kup si medenou lepici pasku, ma na jedne strane lepidlo, ktere vydrzi 4 kelviny ve vakuu (a samozrejme pokojovou teplotu). Osobne vyzkouseno pro odbobi 1 mesice. Jen nevim, jestli se z neho neco neuvolnuje, tenhle pozadavek jsem nemel. A samozrejme to lepidlo je hodne slabounke, urcite by nevydrzelo otresy a namahani behem startu rakety.
Proč mamlasové? Já nevím, co všechno se tím řídí. Ale třeba takovou operaci rozevření slunečních panelů dělá ten teleskop jednou za život. Nedává smysl mít na to tam software trvale – dá se tam nahrát až teleskop dorazí na místo a po rozevření panelů zase smazat. Klidně to může být nějaký vysokoúrovňový skript, který dá povel „tohle rameno otvírej až do polohy X“, a nízkoúrovňový kód už se postará o to, aby točil motorem tak dlouho, dokud nedosáhne polohy X. A zároveň tahle operace může znamenat ztrátu celého teleskopu, když se udělá špatně – kdyby se třeba při otvírání panely srazily a poškodily.
Já se nepovažuju za nějakého extra super programátorského génia. Prostě jen programuju už fakt dlouho. Pro NASA dělají určitě jinačí borci. A i já, kdybych designoval takové běhové prostředí, tak jedna ze ZÁKLADNÍCH vlastností, které by muselo splňovat by byla bezpečnost - aby nebylo možno skriptem spuštěným v tom prostředí teleskop žádným způsobem trvale poškodit.
Troufnu si tvrdit, že složitá rozkládací procedura byla určitě dělána jiným SW, který byl dlouho a pečlivě testován a byl v teleskopu od začátku. On ten sluneční panel (byl jeden) se otevíral v T+33 minut, takže by ani moc nebylo kdy to tam nahrát.
aby nebylo možno skriptem spuštěným v tom prostředí teleskop žádným způsobem trvale poškodit
K čemu by to bylo dobré? Jenom byste tím obrovsky zkomplikoval ten program pod tím, který by tohle musel kontrolovat. Daleko jednodušší je tady na Zemi ten skript důkladně otestovat.
Ano, sluneční panel nebyl dobrý příklad – myslel jsem to, co se dělo a v průběhu cesty do L2 nebo až v L2. Pokud vím, třeba u planetárních sond je to běžný postup, že mají software na cestu, a když se dostanou na místo, ten se nahradí softwarem pro průzkum. A ten se ještě později aktualizuje.
Jenom byste tím obrovsky zkomplikoval ten program pod tím, který by tohle musel kontrolovat.
Kdo tu mluví o kontrole? Především jde o design. Například aby nemohl SW zavřít sluneční panel a tím přerušit přívod elektřiny, tak nad ním nebude mít vůbec kontrolu, protože ji nepotřebuje. Jednoduché.
Stejně tak nebude mít skript kontrolu přímo nad orientačními motorky, ale má v definici napsáno "chci se dívat tam a tam" a teprve vrstva pod tím vydá příslušné rozkazy motorkům a navíc zkontroluje, zda je to v povolené oblasti. Což je poměrně triviální kontrola.
Daleko jednodušší je tady na Zemi ten skript důkladně otestovat.
SW se na Zemi samozřejmě testuje. Ale chcete dosáhnout vysoké spolehlivosti, nemůžete se spoléhat na jednu vrstvu (opatření), ale musíte jich mít několik. Zvlášť u takhle rutinně dodávaného SW.
Stejně tak nebude mít skript kontrolu přímo nad orientačními motorky, ale má v definici napsáno "chci se dívat tam a tam" a teprve vrstva pod tím vydá příslušné rozkazy motorkům a navíc zkontroluje, zda je to v povolené oblasti.
A ta "vrstva pod tím" snad není další software napsaný lidmi?
Kdo tu mluví o kontrole?
Že by vy?
tvl jirsaku, fakt nechapes elementarni princip vrstveni?
K cemu mame hypervisor, kernel, userspace, mmu, iommu, secure enklavy a sandboxy? Kdyz podle vas neni potreba si nic komplikovat a muzeme vsechno zmastit dohromady, prece kdyz je to zkontrolovany tak se neni o co bat. Jste spadl z Win 2.0 nebo co jako?
Je velice smesne, jak se vzdy chcete hadat v diskuzich a tvrdite jeden nesmysl za druhym, a jeste 90% vasich prispevku tvori citace vytrzene z kontextu, protoze co nechcete videt a slyset, to jednoduse ignorujete.
RDa: Jasně, na teleskopu běží OS, v něm hypervizor, v něm další OS, v něm sandbox, v něm prohlížeč a k němu se operátoři ze Země připojují přes RDP.
Pokusím se vám to vysvětlit ještě jednou. Nepsal jsem nic o tom, že tam žádné vrstvy nejsou. Psal jsem o tom, že obecně když je někde nižší vrstva zajišťující přímou komunikaci s hardwarem a nad tím vyšší vrstva pro operátory (aby nemuseli zadávat příkazy "otoč tímhle motorem, ověř, zda je v cílové poloze, pokud ne, znovu otoč motorem" ale mohli zadat jen příkaz "otoč do polohy X"), neznamená to, že nižší vrstva musí bránit všem chybám z té vyšší vrstvy, které by mohli způsobit poškození hardwaru.
Zkuste si to představit třeba na autu nebo lokomotivě. Rozhodně je dobré mít tam oddělené systémy pohonu a brzd. Pohon sice také může brzdit, ale když to selže, vždy tam musí být systém brzd, který se nenechá selháním pohonu nijak ovlivnit. No a když jsou ty systémy na sobě nezávislé, může samozřejmě dojít k situaci, že pohonný systém bude mít příkaz táhnout a brzdný systém příkaz brzdit. O to, aby k tomuhle nedocházelo, se stará teprve systém nad nimi, který reguluje jízdu a podle potřeby se rozhodne, zda k tomu použije pohonný systém, brzdný systém nebo oba dva.
Ten system v JWST je navrzen tak, ze jako operator (v jejich terminologii jako uzivatel - coz je treba vyzkumni ustav, skola a pod) nemate zadne moznosti zpusobit havarii.
Namisto vaseho otoc do X, tam je "zvol filtr(enum{r/g/b}): bool", a je ulohou tvurcu nizsi vrstvy zarucit, ze kazdy ze zde sesti prechodu - zmeny - se provede spravne, pripadne se neprovede vubec, protoze mate vycerpany power budget nebo pocet cyklu za jednotku casu.
Je zbytecne fabulovat o raminku nebo lokomotive. Drzte se tematu a nastudujte si linkovane materialy.
RDa: Já se držím tématu, na rozdíl od vás. Tématem je, zda obecně u kritických systémů musí nižší vrstva bránit všem kritickým chybám vyšší vrstvy. A odpověď je že samozřejmě ne - ty vrstvy jsou tam od toho, aby každá vrstva řešila to, co se na její úrovni řeší nejlépe.
Fungování konkrétně JS v JWST se řeší v jiném vlákně, to jste zabloudil.
To je blbost.
1. Rozevreni panelu je zde jednocestna funkce. Cili zavreni panelu nelze ucinit. Ta konstrukce byva i blokovaci. Mechanicky! Zpetna funkce sbaleni nedava ani vzhledem k nastaveni mise smysl.
2.I kdyby to byla pravda, preruseni privodu elektriny by se nekonalo protoze jsou tam i zalozni akumulatory. Tech par desitek Ah vydrzi na failsafe mod a telemetrii. Topeni Aku byly primarne na pocatecni fazi mise a rozbaleni panelu, sekundarne na osetreni spicek a anomalii v napajeni z panelu. Mise je udajne prosta významných zakryvu teles takze ok.
Testovani je viceurovnove protoze u techto aplikaci to neni architektura typ nagelovany patlal ze startupu na mesicni kontrakt. Takze interpret v jwt a vysokourovnova volani jsou az predposledni bariera. Predtim je tam simulace na zemi.
Ano, viz obrazky z puvodniho PDF zdroje (Fig.22) nebo i dalsich webu co zverejnili vice nez jeden ... ISIM FSW tam ma napsano ze resi "Health and Safety".
Jinak sekce 3.7 popisuje jak presne ten JS tam funguje, v podstate to jsou "callbacky" ktere nastanou az se teleskop diva spravnym smerem - takze resi jenom vedecke ulohy - volbu a konfiguraci instrumentu. Do rizeni nekeca - v tomto ohledu to jsou zcela pasivni skripty.
Kdyz nevite tak si to nastudujte:
3.7 Operations Scripts System
https://www.jwst.nasa.gov/resources/ISIMmanuscript.pdf
TLDR: ridi se instrumenty (zda a co snimat), ne provoz sondy jako takove.
Nevarte z vody.
Ten skript dava instrukce co to ma delat, a obsahem neni nic kritickeho - prikladem treba - "natoc se na XYZ a udrzuji konstantni rychlost X'Y'Z', pricemz snimkuj 10x 30s snimky"... protoze se snima objekt ktery se pohybuje. Co na tom jako chcete zvorat?
To skriptovani zde ma vyhodu ze fakt nic neridi - je to jenom meta jazyk a kontrolu fyzikalnich moznosti provadi redundantni runtime.
@Filip Jirsák
Bavíme se o tom, zda bezpečnostně kritický kód má být vždy nízkoúrovňový, nebo je někdy naopak lepší vyšší úroveň abstrakce.
To je celkem jedno. V obou můžete udělat fatální chybu, některé dokonce mohou být v obou jazycích stejné. Bezpečnost má být zaručena až řádným otestováním (SW), jak píšete výše, a i deálně ještě "na železe", ideálně na stejném.
Mohu dát jako př. přetečení integer counteru (Boeing tuším). Prostě se počítalo že se letadla při údržbě restartují každý měsíc, nicméně v praxi to neudělali někdy ani za půl roku ... např. na toto by imho úroveň jazyka němala vliv.
Altan Sarnai: Přetečení integeru je vlastně chyba analýzy, že nepožadovala dostatečně velký datový typ. Jinak samozřejmě existují typy chyb, které se udělají v jakékoli úrovni nebo v jakémkoli jazyce. Ale některým chybám lze volbou jazyka předejít. Třeba operátor, který řeší samotnou práci teleskopu (kam bude zaměřen, jak bude snímat), by neměl řešit dereferencování ukazatelů a vracení paměti – protože je to úplně mimo oblast, kterou řeší. To se vyřeší tím, že se zvolí jazyk, který nedává programátorovi přímý přístup do paměti.
@Filip Jirsák
Detaily neznám, ale asi měli prostě platformou* omezenou velikost s tím, že by to mělo stačit protože pravidělný restart. Což ale evidentně nevěděli ti co to měli restartovat. Takže nejspíš chyba v dokumentaci, ve změně dokumentace, nebo jejím čtení.
Proto jsem zvolil tento příklad, protože je úplně jedno co to je za jazyk. Existuje jazyk kde by nepřetekl, a záleží tona úrovni jazyka? Podle mě ne, a ne.
* asi nějaká průmyslová deska - jeden z přístrojů v letadle
22. 8. 2022, 12:54 editováno autorem komentáře
Za prvé, interpretovanost není vlastnost jazyka, ale běhového prostředí. Existují třeba interprety C, proto bych ale nenazýval C interpretovaným jazykem. A třeba deno umí z JavaScriptu vyrobit binárku (byť je to pořád interpret a k němu připojený skript).
Za druhé, to jestli je jazyk interpretovaný nebo kompilovaný, nijak nesouvisí s jeho bezpečností. Pokud vám jde o to, že při kompilaci se musí zjistit, zda je kód vůbec syntakticky správně, nic vám nebrání to samé zjistit i u skriptu před tím, než ho někam pošlete.
Bezpecnost s tim sakra souvisi. Doplnte si znalosti z realne informatiky.
Priklad - jak podle vas vyvolate segfault (neplatnou dereferenci pointeru) v skriptu (rekneme v PHP / Bash / JS ) ? V binarce totiz takova vec muze nastat raz dva, kdyz si neohlidate co kam jste dali, ci alokovali/dealokovali.
Skripty nepadaji. Binarky padaji. A to je to, o co tam hlavne jde.
21. 8. 2022, 09:14 editováno autorem komentáře
RDa: Proč píšete o věcech, o kterých vůbec nic nevíte? Dereferencování nulového ukazatele vůbec není vlastností binárky. Můžete mít binární kód, ve kterém segfault nastat nemůže, stejně tak můžete mít skript, ve kterém nastat může.
Rozdíl je ve skutečnosti v tom, jestli se používá ruční správa paměti (tedy programátor má v ruce odkaz na konkrétní místo v paměti a s tím pracuje, může ho měnit apod.), nebo jestli se používá automatická správa paměti (programátor nikdy nedostane do ruky odkaz do paměti, vždy má jen odkazy na objekty).
Třeba Java bajtkód, řízený kód .NET, AOT kompilovaný kód Javy, zkompilovaný program v Go - to všechno jsou binárky a segfault v nich nemůže nastat, dokud nezvolíte speciální režim přímého přístupu do paměti (a samozřejmě pokud není chyba v kompilátoru nebo běhovém prostředí, i to se stává).
Nejprve si ujasnime co je binarka - pro vetsinu opravdovych informatiku to znamena kod, ktery procesor primo vykonava. Tj. je to kod v konkretni architekture procesoru, ktery zajistuje beh.
Java bytecode, CLR, a jine pseudoreprezentace opravdu nejsou binarkou. Jen proto, ze nemaji lidsky citelnou reprezentaci, je tak nazyvat nemuzeme - je treba zohlednit zda bezi, nebo se interpretuji. Je brainfuck zdrojak binarkou, skriptem nebo zdrojakem? Java VM je fancy nazev pro "java interpret s akceleraci zalozenou na JIT". Je to interpretovany a nazdar.
V kazdem binarnim kodu muzete dereferencovat cokoliv nesmyslneho, od toho to je binarni kod a nastupuji dalsi urovne ochrany jako MMU.
RDa: Nejprve si ujasněte, že slovo "binárka" pochází od fráze "binární kód". Zjistěte si, co to znamená.
Slovo, které jste chtěl použít, je "nativní kód" nebo "strojový kód". Java se dá pomocí AOT kompilátoru kompilovat do nativního kódu, z řízeného kódu .NET nebo JavaScriptu (a mnohých dalších) se JIT kompilují do nativního kódu alespoň části kódu. Z vašeho tvrzení by plynulo např. to, že když javovský kód zkompiluju do bajtkódu a spustím, nemůže segfaultovat, ale jakmile ten samý zdroják přeložím do nativního kódu, segfaultovat může. Nepřipadá vám to divné?
Už jsem viděl segfaultovat aplikaci v Javě (chyba v optimalizátoru v JVM). Prakticky může segfaultnout naprosto cokoli, akorát u aplikací bez dynamické alokace paměti je ta pravděpodobnost o něco menší...
Jsem zvědav, jak bude Rust pokračovat - zda se dostane do stavu, že bude mít tak bohatý ekosystém, aby se daly aspoň nějaké netriviální aplikace napsat čistě v Rustu, bez "unsafe".
Zas tak překvapivé to není, NASA používala na sondách Lisp a během letu programy v něm napsané měnila. V případě JWST jde o převážně deklarativní “skripty” napsané v něčem, čemu říkají “customised JavaScript”, a interpretované procesorem napsaným v C++. Lze si je představit jako nějaký YAML s popisem, co se má dělat, jen prostě s jinou syntaxí. Proces interpretace je podobný zpracování například GitHub Actions, takový mix deklarativního a procedurálního zápisu.
pár informací je tady https://jwst.nasa.gov/resources/ISIMmanuscript.pdf. Nepředstavoval bych si to jako plnohodnotný js vč. mnoha npm modulů, budou to jen relativně jednoduché scripty, které něco nastavují podle údajů, které si dopočítají.
Odhaduji, že se jim líbila single event loop a schopnost spouštět více skriptů v jednom procesu. Stejně tak mohli použít luu či něco podobného.
Pro obsluhu to je určitě jednodušší než luštit ASM nebo ADA kód a to bude asi i důvod, proč tam vyšší jazyk dali, chtěli minimalizovat chyby lidí a zjednodušit kontrolu.
Enginů pro JS bylo a jedno celá řada, tak je klidně možné, že tam mají něco opravdu malého a jednoduchého.
Rozdělil bych software sond na operační systém, který je tam nahraný už od začátku a nemění se, a aplikace, které se mění v průběhu mise. Ta hranice nebude úplně ostrá, stejně jako u jiných počítačů – ale stejně jako bych nečekal, že realtime OS tam bude v JavaScriptu, nečekal bych ani to, že aplikace tam budou v klasickém C nebo C++.
Každý jazyk se hodí na něco jiného.
@oss
To, že se s nějakým jazykem dobře matlá neznamená, že v něm někdo něco zmatlal.
BTW, v tom článku který jsem linkoval nahoře mluví něco o řešení z 2002, takže kdoví jaký přesně Javascript tam běží. Navíc se mi zdá, že si tím velmi lehce pomohli k až 10 nenáročným paralelním procesům.
Kdoví co je tam za verzi. Pravděpodobně nějaká stará kostra, z dnešního pohledu.
Ako sa tu ľudia hádajú za JavaScript.... a pri tom akýkoľvek programovací jazyk je len definícia (špecifikácia) syntaxe a sémantiky, bez reálnej implementácie... to či už niekto urobí pre JavaScript behové prostredie (Node, Deno, Bun), kompilér do natívneho kódu (NectarJS - aj keď je v plienkach) už nerobí rozdiel medzi jazykom... ako C/C++ je jeden a ten istý jazyk pri všetkých tých desiatkách kompilérov, či už GCC, KCC, Clang, a neviem ešte aké. Aký je vlastne rozdiel v bezpečnosti medzi kódom:
console.log("Hello");
a
printf("Hello");
v pozdstate obe sa môžu preložiť do úplne zhodného strojového kódu... a ak sa prekladajú do zhodného strojového kódu, aký je potom rozdiel v bezpečnosti medzi nimi?
Asi toľko k tomu bučaniu na JavaScript a haterom JS...
Prosim..
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
typedef void (*typFunkce)(void);
void funkce() {
printf("Funkce: PASS\n");
}
void vyjimka(int sig) {
printf("Undefined is not function.\n");
exit(-1);
}
int main( int argc, char* argv[] ) {
// exception handler setup
{
struct sigaction sigHandler;
sigHandler.sa_handler = vyjimka;
sigemptyset(&sigHandler.sa_mask);
sigHandler.sa_flags = 0;
sigaction(SIGSEGV, &sigHandler, NULL);
}
// test calls
{
typFunkce fnPass = &funkce;
fnPass();
}
{
typFunkce fnFail = NULL;
fnFail();
}
return 0;
}
$ ./test Funkce: PASS Undefined is not function.
Kdysi jsem delal pohovor do firmy co dela software pro satelity. Samozrejme me nevzali :)))) Je potreba mit oddelene vrstvy. Software se da updatovat ze zeme a je potreba aby vyssi vrstva nenaborila nizsi a delala jen to co ma. Jsou na to nejake protokoly. Telemetry commands a tak. Pouzivali tam javu.
No, podle mě nejdůležitější část (a ta kterou většina diskutujících přehlíží) je ta, kdy dáte vědcům nějaký jazyk (R, Python a teď i Javascript? :) ) a řeknete "naprogramuj to".
Už jste někdy takový kód od člověka, kterého neživí programování ale věda, viděli?
Leckdy fakt mazec. Tohle někdo předvést na přijímacím pohovoru tak buď junior a nebo vůbec, přesto to jsou kapacity v oboru, jen tohle zkrátka není jejich píseček.
Pokud do rukou dostanou něco zjednodušeného, tak je to jen a jen plus. Na co celý python, na co objekty, když si ve skutečnosti vystačí s pár věcí s syntax JS a slušnou math knihovnou...
ČLÁNKY DO MAILU