破解納粹密碼的英雄,也因同性戀備受歧視——艾倫圖靈的傳奇一生

破解納粹密碼的英雄,也因同性戀備受歧視——艾倫圖靈的傳奇一生
Photo Credit: Ben Sutherland CC BY 2.0

我們想讓你知道的是

圖靈在世界史上具有核心地位,然而如果把他的人生劇場描繪成權力遊戲,或者以二十世紀的傳統政治議題框架他的故事,那會是一種誤導。確切的說,他個人的心靈自由,包括他的性取向,才是真正重要的。

二○○○年,戴維斯出版了一本書,實質上正是圖靈在一九四八年可能寫下的那本書。他的著作解釋了一九三六年通用機的起源,說明這臺機器如何演變成一九四五年的「內儲程式計算機」,並且舉證歷歷;約翰.馮紐曼(John von Neumann)建構他較出名的計畫時,必定參考了圖靈一九三六年的研究。圖靈最後發表的文章是關於「可計算性」的論文,一九五四年刊載於《科學新聞》(Science News)。這篇論文顯示,寫這樣的分析對他而言是駕輕就熟。然而即使在毫無爭議是他所發現的領域上,圖靈對自己領先的部分都略而不提。

網路上的搜尋引擎以驚人的速度和效率運作,靠的就是演算法,和圖靈機相去不遠。搜尋引擎也傳承了圖靈用來破解「恩尼格瑪密碼機」的那套演算法,也就是運用繁複的邏輯、統計學和平行處理,在這方面圖靈乃是先驅。圖靈的演算法就是打開「第三帝國」大門的搜尋引擎。然而,對於其後證明可以克服一切難題的發現——所有演算法都能有系統地寫成程式,而且在通用機上執行——圖靈並不企求,也沒有獲得多少公眾的讚譽。他明確宣示的,反而是他稱之為「智能機器」的主張,不過在一九五六年之後我們改稱為「人工智慧」了。

這項野心更大也引起更多爭議的研究計畫,並未像圖靈所希望的那樣發展,至少到目前為止還沒有。為什麼圖靈在人工智慧方面如此公開表態,對於鞏固自己在演算法上的大師地位,同時是程式設計的創始者卻不太在意?部分原因是,對圖靈來說人工智慧才是根本的科學問題。心智與物質的謎團是他最深切渴望追索的問題。然而在某種程度上,他必然受害於自己不得張揚的成功。他對於情報戰爭中的演算法知之甚詳,也知道這場戰爭創造出邏輯與電子之間的關鍵連結,然而陷入情報戰箝制了他的風格,也限制他的溝通。圖靈在一九四六年的報告中,小心翼翼地提到加密演算法的重要性,所帶來的抑制必然影響了後續所有發展。

直到三十年後,戰時圖靈在布萊切利莊園進行的密碼分析,其深度和廣度才洩漏出來,於是我們才能嘗試認真評價艾倫.圖靈的一生。此時正好遇上密碼學理論大爆發拓展成電腦科學,再加上全面重新評價第二次世界大戰,以及一九七○年代性解放的衝擊。必須先發生一九六八年的社會革命——那是圖靈所期待的,他的故事才能獲得解放。(即使如此,英國在一九九○年代審查法與軍事法才出現變革,直到兩千年才確立平等的法律原則。而二○一一年終止的「不要問不要說」原則,顯示第八章的議題在美國軍隊一直是不能說的禁忌。)

圖靈的故事透露了這個解放過程最初的力量出現在一九五二年的挪威,因為他聽聞的「只有男性的舞會」,大概是由剛萌芽的斯堪地那維亞同志組織策劃安排的。除了下冊三八四頁提到的同志主題小說,諾曼.勞特利奇(Norman Routledge)於一九九二年回憶道,圖靈是如何期待他閱讀安德烈.紀德(Andre Gide)的法文版原作。遺憾的是,他寫給琳恩.紐曼(Lyn Newman)的書信沒有保存下來。

信函的內容可以從琳恩一九五七年寫給朋友的信中略窺一二:「親愛的艾倫,我記得他如此直白又悲傷地跟我說:『我就是無法相信,和女孩上床與和男孩上床一樣美好。』而我能說的只是:『我完全同意你——我也更喜歡男孩。』」這段交談當時只流傳在小心謹慎的圈內人之間,現在則可能成為電視談話節目的笑哏,與他著名的「模仿遊戲」中的機智問答相映成趣。不過圖靈毫無遮掩的坦白來得太早,早了好幾個世代。

要想像那個時代的敵意和汙名並不困難,因為無論在非洲、中東或美國,這種憎恨和恐懼仍是主要的文化和政治力量。比較難以想像的是,在那個世界不僅迫害得理直氣壯,還認為是天經地義、不容質疑。圖靈面對著無法化解的反諷,他對誠實的要求衝撞了兩件事─國家安全和同性戀,這是一九五○年代最令人焦慮的問題。

毫無意外,結果證明一個腦袋無法同時包容這些事。他的死亡成為歷史的暗角,沒有人(除了他那位不凡的母親)願意談論。我將這些元素融合為單一的敘事,在一九八三年當然遭到批評。

不過「我們已經改變了一切」,從那之後,圖靈的生平和死亡與其他科學界重要人物一樣,聞名於世。休.懷特摩爾(Hugh Whitemore)的劇本《破解密碼》(Breaking the Code)是根據本書改編,由頂尖的演員搬上舞臺,擴大了公眾的接受度。這齣戲讓圖靈的一生成為一九八六年大受歡迎的故事,一九九七年的電視版本又推升其知名度。時代發展至那時,電腦網路已經改變個人隱私的開放程度。

奇特的是,圖靈預期到他的科技在這方面的運用,透過「模仿遊戲」中驚世駭俗的簡訊傳送暗示了世人。用曼徹斯特電腦來撰寫情書,關於挪威青年的訊息也以古怪的電腦列印方式呈現,在在顯示圖靈已經樂此不疲,把握機會和同好進行電子溝通。

二○○九年,英國首相布朗(Gordon Brown)發表聲明,為圖靈的審判和一九五二到五四年的刑罰道歉。從更寬廣的視野來看,我們見識到圖靈如何祕密協助我們轉變戰後歐洲公民社會的價值。這份道歉聲明透過風起雲湧的網路請願爭取得來,這在一九八三年是不可能的事,然而當時已露出端倪,這是「功能強大的微型電腦」所能帶來的變化。


猜你喜歡


挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

我們想讓你知道的是

企業如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署,減輕人力負擔,提升專案服務運作效率?

所謂現代化智慧 IT,所有工程師最希望的境界,莫過於只要輕鬆點幾下設定,系統就會自動跑起來,管理者再也不用隨時待命在機台旁邊,從此工作悠哉又快樂!儘管這樣情境還沒到來,但隨著敏捷式開發的流行,除了 DevOps 人員,有越來越多開發者將 CI/CD 概念融入到工作流程當中,例如從 build code、執行 unit test、到部署應用程式。

透過 AWS 增加雲端技能 在組織發揮影響力

上述種種反覆步驟自動化執行,也就能提昇服務品質、主動通知開發人員以減輕人力負擔,讓專案服務能持續運作。

其中,GitLab 是執行 CI/CD 常用的工具之一,也是開發者使用程式碼儲存庫的地方。為了讓 GitLab Runner 在雲端快速實踐 CI/CD,《AWS 開發者系列》透過影片分享,如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署。

以下節錄工作坊影音內容,幫助開發者快速理解如何運用 Amazon EKS 的高可用性且安全的叢集,將修補、部署節點、更新等關鍵任務,全部做到自動化設定。同時影片也會示範 Amazon EKS 搭配 GitLab 如何展開自動部署,幫助工程團隊實踐 CI/CD 價值。

Amazon EKS 對容器管理輕鬆簡單、維運省時省力

容器化服務越來越興盛,當容器(Container)越來越多,在複雜的微服務(Microservice)系統環境之下,運維團隊的管理成本可能相對會增加不少,為了有效調度容器部署, 導入Kubernetes 無疑是近年企業熱門的話題之一。

建構 Kubernetes Cluster 流主要可區分兩大塊,一是安排容器調度的Control Plane、另一則是容器運行時需要用到的 Worker Node。

Control Plane 裡面涵蓋有儲存狀態的 ETCD、CoController manager 、Scheduler 的調度管理、甚至是操作時進行互動的 APIServer,若是自己創建 的 Kubernetes Cluster ,需要自己安裝這些元件,後續仍需要對 Control Plane 進行相關管理、維護、升級工作。為了減少上述 Components 的繁複維護,在透過 AWS EKS 代管的 Kubernete Control Plane 部可以獲得以下三大好處。

Amazon EKS 一鍵式部署,展現三大優勢

第一,Amazon EKS代管的 Control Plane實踐了跨AZ的高可用部署,使用者不需要擔心單一節點故障的風險。

第二,Amazon EKS 支持至少四個 Kubernetes版本,持續跟進每季 CNCF 的發佈,同時 EKS 也完全符合上游 CNCF 規範。

第三,部署 Amazon EKS 之後,可直接使用 AWS 平台上現成的服務工具,在安全性管理、網路設定方面,可以做到無縫整合。

最後 AWS 台灣解決方案架構師也提到,若想在容器環境進行 CI/CD 及應用程式的管理,可以進一步透過 IaC 整合部署 Amazon EKS 叢集,透過使用 Console、把 EKS 變成 Cloudformation 的模板、使用 AWS 所開發出來的 eksctl.io、或指令是採用 AWS CDK 可以讓開發者用自身熟悉的語言,在 AWS 平台整合 CI/CD 工具進行維運及部署 EKS。

打造第一個在 AWS 上的應用程式

了解 Amazon EKS 整合 GitLab ,獲得三面向價值

對開發者而言,想把 Amazon EKS 整合到 CI/CD 工具之一的 GitLab 平台上,可以看到那些實際的優勢?

在 DevOps 開發者示範工作坊當中,GitLab 資深解決方案架構師指出,GitLab 使用到 Kubernetes 技術,主要有三種搭配方法,包含 GitLab Server、GitLab Runner、以及創建 Deployment Environment。

本次示範教學會主要聚焦在 GitLab Runner 如何採取 Auto-scaled 方式進行 Build、Test、Package Apps;以及在 Deployment Environment 運用 Kubernetes 技術,做到 Auto Deploy、Review App。

正因為 Amazon EKS 能夠在 DevOps 過程提供所需要的彈性計算資源,幫助開發者在 GitLab 平台上面獲得以下三個層次的優勢:

  • 在 GitLab 內建的部署工作流程當中,自動生成整套 CI/CD 最佳實踐腳本。
  • Review App 過程,從 Merge Request 中可直接訪問應用程式 /App 的 UI 介面,並且根據 Git branch 名稱、專案名稱,自動生成 Review App 的 URL,以及在 Merge 前的最後防線進行 Approval 檢查。
  • 加速 CI/CD 流水線,GitLab Runner 運行時候還可藉由 Amazon EKS Cluster 進行 Auto-scaled 的支援。

Amazon EKS 整合 GitLab ,需要兩大流程

影片最後,GitLab 資深解決方案架構師示範如何把 Amazon EKS 整合至 GitLab 執行 Auto Deploy,主要可分為兩大區塊流程,第一部分聚焦在 Amazon EKS cluster 的設置,第二部分則執行 Auto Deploy 設置。

第一塊可拆分為四個階段,首先教學怎麼創建 EC2 節點的 EKS cluster,第二階段示範把 EKS Cluster 連接到開發者的 GitLab Instance、Group 或 Project,下一步則使用 Cluster Management Project Template 創建一個 Cluster Management Project,以及最後一階段透過 Cluster Management Project 自帶的 Helm Chart,安裝在 Cluster 所需要的內建 App。

第二塊執行 Auto Deploy 設置,針對需要部署的 App 創建一個 GitLab Project,接著再把 gitlab-ci.yml 添加到 Project,並從 Web IDE 選擇及導入 Auto Deploy 的 CI 模版,讓 GitLab 自動生成最佳實踐的整套流水線。

幫助開發者更了解 Amazon EKS 整合 GitLab 的 QA 系列

Q:使用 Amazon EKS 之後,如何更有效率或優化資源去配置 Worker Node 的機器數量,以及如何有效空管開發維運的成本?

A:Kubernetes 除了本身有 HPA(Horizontal Pod Autoscaling)可根據使用程度自動調整資源流量,另外也能延伸使用 AWS Auto Scaling 方案,針對可擴展資源去設定自動擴展管理。另外在成本管控,雖然 Amazon EKS 會收取額外管理費用,但可透過 AWS 平台的 Calculato r計算每個 EKS 的價格,你會發現自動化部署及管理的費用,相對工程師人力的成本更加便宜。

Q:越來越多客戶考慮把現有 Application 變成容器部署,大多是爲了加快部署的效率,那麼變成容器模式之後,對 CI/CD 的工作流程有什麽影響嗎?

A:運用容器技術最直接的效果,可以讓應用程式的環境更一致化,例如 testing 環節、stage production,讓容器避開一些差異問題。至於 CD 部分要 delivery 一些 usage 不太一樣的時候,容器會幫忙做配置,所以 CI/CD 對容器的效益是相輔相成的。

Q: 客戶在開發流程漸漸會把 Infrastructure 變成代碼或文檔,是不是可以把程式碼跟現有的應用程式的 CI/CD 流水線整合在一起,達到一套完整的 CI/CD 部署流程?

A:觀察目前市場作法,主要分成兩個階段去做整體部署。如果規模比較小的團隊,會把 Infrastructure 代碼跟 App 代碼分開,在管理上會比較靈活;如果企業規模比較大,會有另外一個 Infrastructure 團隊來控制部署事情,這種情况之下,APP 的項目會生成一個 APP package,主要做到 delivery 這個階段爲止。而 Infrastructure 的項目會指定把需要版本的文檔,部署到他們的 Kubernetes Cluster。

填寫表單 找到適合的快速上雲服務與工具!


猜你喜歡