進度條

用4KB的記憶體登陸月球? 從阿波羅11來看「軟體」和「程式語言」的力量

4K高畫質電影與登陸月球火箭程式,哪個佔用的記憶體多呢?

作者: Vincent Ke 更新日期:

1969年7月21日,美國探月小艇-老鷹號,終於降落在月球寧靜海(sea of Tranquility),也在當天的凌晨2點56分(UTC時間),38歲的太空人阿姆斯壯,左腳終於踏上了當時夢想的地圖,成為了第一個踏上月球表面的人類,而那句成為後人流傳,永垂不朽的名言

 

That's one small step for (a) Man, one giant leap for mankind

「個人的一小步,是人類的一大步」

 

 

這個畫面想必大家多少透過電影、或是記錄片看過,僅管我們現在已經生活在被科技裝置環繞的年代,登入月球對我們來說,似乎已經不像約末50年前的那麼遙不可及,在阿波羅11號上,沒有我們現在不可或缺的iPhone,沒有Mac麥金塔電腦,沒有Microsoft,在一切資源貧乏的那個年代,這項艱鉅的任務,似乎只能用「遙不可及」的夢想來形容。

 

但你知道嗎?微軟公司成立在1975年,蘋果成立在1976年,但我們卻在1969年,完成了登陸月球的這個「滔天白日夢」,而你現在口袋裡的手機,甚至是家裡昂貴的智慧烤麵包機,裡面的硬體技術,都比阿波羅11號上的硬體來的先進嗎?

 

 

根據https://www.metroweekly.com/2014/07/to-the-moon-and-back-on-4kb-of-memory/上的報導,當時的設備主要都是透過IBM來提供的,但這樣的運算速度,連現在的USB都可以海放。當初阿波羅11號搭載的嚮導電腦上,只有1Mhz左右的運算速度,4kb的記憶體,32kb的儲存空間。

 

現在來看這些數據似乎有點模糊,那我們用比較法吧,iphone5s 16G的容量可是32kb的500,000倍,處理速度Samsung Galaxy 5S可是比他快了10,000倍呢,但這樣溫吞又慢速的電腦,在了解當初的時代背景之後,我們才知道這些古董,其實在當初都是所謂的「奇蹟」。

(現在的iPhoneX 又更快了,但大多數人做最耗效能的事情是拿來玩手遊)

 

在1960年代時,是電腦硬體飛黃騰達演進的一個重要元年,當時的電腦並沒有所謂的晶片、或是積體電路等,主要都是透過較大體積的真空管來當作功率元件的核心,直到了電晶體(transistor)的問世,才有效將電腦的體積和重量進行縮減。而除了硬體上的突破外,我們都知道現在在IoT的概念上,將裝置導入作業系統(Linux),或是晶片導入python 或是 JavaScript 解析器都已經是常見的手法了。

 

但當時沒有這些技術,有的只是僅4kb的記憶體,如何去做軟體上的搭配運算,才有辦法成功的把太空人送上月球,並且送回家呢

 

 

這時候不得不提當初一位著名的女工程師,Margaret Hamilton,在阿波羅計劃啟動的同時,他加入了,也改變了數位世界的歷史。1961年為了讓阿波羅計劃提高成行的可行性,麻省理工學院的儀器實驗室也全力進行研發,最後Hamilton 和她的同事們,發明了世界上第一台可攜式電腦的程式碼,從此也奠定了「軟體」在阿波羅計劃,以及世界的地位。

 

 

資料來源: https://en.wikipedia.org/wiki/Margaret_Hamilton_(scientist)

 

在阿波羅計劃裡,Margaret Hamilton完成了模擬阿波羅著陸器如何運作的程式碼,也就是「阿波羅登月計劃程式」,讓太空人可以在出發前,模擬一切可能發生的狀況,不過,別忘記,程式需要在巨型Honeywell電腦上運作,往往每小部分都需要通宵達旦才能完成。

 

「我們不單要確保所有東西運作良好,而且軟體還要配合硬體、人手和任務本身一起工作。」於是史上首套由人手操控,但具備線傳操控(fly-by-wire)技術的太空機艙電腦導航系統誕生了,也成為現今商業客機中導航系統的先驅。

 

 

除了軟體本身的建構外,在阿波羅 11 號的著陸上,也因為有 Hamilton 和其他工程師的努力,讓本來警報頻繁的登月計劃,最後化險為夷。

 

 

誰能想到從1961年的小實驗室,在接下來的 8 年,已有超過 400 人同時為阿波羅計劃寫程式,「軟體」不僅成功登月的關鍵,也受到了產業界的高度重視,更孕育出之後超過4000 億美元的產業,也就奠定了軟體和系統工程的專業性地位。

 

一台只有 4kb記憶體的電腦,最後靠著Margaret Hamilton以及眾多工程師的努力,賦予了他智慧,這中間巧妙的連動和設計,都是必須依靠著軟體和系統整合的力量,才有辦法完成的艱鉅任務,也許你懂Python 、PHP 、Ruby On Rails或是 JavaScript,但別忘了,所有先進的技術或語言,都只是解決問題的工具,而非是解決問題的核心。因為技術並非萬能,像現在許多IoT與裝置串聯的解決方案裡,往往因為預算考量,僅能透過C/C++成為與機器元件或是裝置互動的核心語言,而身為軟體工程師的我們,更應該具備本身處理問題的核心技術,最底層的技術,往往通常才是最可行的解決方案。

 

所以在追求革新的同時,如何有效應用現有資源,結合硬體的運作,才是身為一位軟體工程師可以破釜沉舟的不二法門。

 

 

最後附上NASA的Github讓大家參考參考

 

校正小編補充:

Nasa的Github其實滿有趣的,當然並不是什麼小編都看得懂,但是大概看敘述與語言分布的話。C語言(28個結果)、 C++(22個結果)、python(20個結果)、JavaScript(14個結果)算是比較多的。但是這些多半都是不同層級的Framework與Library,其中受矚目中最高的一個應該是JavaScript Library: OpenMCT 是一個基於Web的即時監測運用。至於Java,可能怕出一些商業上的問題,所以使用看起來比較少一些(10個結果),但是OpenMCT在移植到Web之前的版本是桌面版,看起來是使用Java去撰寫的。

不過Nasa對於網站的建置,主要還是靠PHP與Rails。用Ruby去找的話,會出現5個結果,其中4個是Rails網站運用程式。裡面看起來比較厲害的是關於地球資料的網站。但是Nasa的官網在Buildwith的幫忙下,看起來是用PHP框架Drupal架的,不過這並沒有釋出原始碼。(打一下廣告,我們的網站也有Rails教學喔,但是當然跟Nasa會有些強度上面的差異,只是當做個開始也不錯)

所以Nasa的選擇跟一般對於語言與框架特性的理解差不多,為了效能使用C與C++,作為運用則使用python作為接口。網站則是快速架站,使用PHP與Rails。前端與跨平台桌面程式則使用JavaScript。

不過這只是單就Github上面釋出的程式碼,Nasa內部的使用則不得而知。但是分佈可能也是偏向這樣。

 


最後,如果你喜歡我們的文章,別忘了到我們的FB粉絲團按讚喔!!

Medium vincent

Vincent Ke

喜歡把混亂的事情變的簡單 用嘴巴做事其實很可以 但要結合靈活的腦袋思考 就一起來拆解吧