《代碼英雄》第三季（5）： 基礎設施的影響

本文是《代碼英雄》系列播客《代碼英雄》第三季（5）：基礎設施的影響的音頻腳本。

導語：用在 IT 基礎設施中的語言是沒有有效期的。COBOL 已經存在了 60 年 —— 而且不會很快消失。我們為大型機維護了數十億行經典代碼。但我們也在用 Go 等語言為雲構建新的基礎設施。

COBOL 是計算機的一次巨大飛躍，讓各行各業變得更加高效。Chris Short 介紹了學習 COBOL 是如何被視為安全的長期投注的。60 年後的今天，還有數十億行並不容易被替換掉的 COBOL 代碼 —— 懂這門語言的專家也很少。Ritika Trikha 解釋說，有些事情必須改變。要麼更多的人必須學習 COBOL，要麼依賴 COBOL 的行業必須更新他們的代碼庫。這兩個選擇都很困難。但未來並不是用 COBOL 編寫的。今天的 IT 基礎架構是在雲端構建的，其中很多是用 Go 編寫的。Carmen Hernández Andoh 分享了 Go 的設計者是如何想要設計一種更適合雲計算的語言。Kelsey Hightower 指出，語言通常都是超專註於一種任務。但它們正變得越來越開放和靈活。

00:00:00 - Saron Yitbarek：

1904 年，紐約市地鐵首次開始運營時，它被驚嘆為現代的一個奇蹟。但是……當今天的通勤者仍依賴一個多世紀前設計的基礎設施時，會發生什麼？列車擠滿了人，而且常常晚點。紐約每年有 20 億人次地鐵出行，再也沒有人為此感到驚嘆了。我們還在依賴昨日的過時基礎設施，我們必須找到新的好辦法，讓它發揮作用。

00:00:44：

過去，基礎設施項目通常是些可見的大而具體的事物，例如地鐵。而且由於這種物理可見性，它們損壞時也顯而易見。高速公路開裂、電線杆倒下，我們很清楚這些東西何時需要維修。為了使我們的生活與老化的基礎設施保持協調，大量的工作是必不可少的。

00:01:12：

但是事物並不總是那麼一是一、二是二。如今，我們還擁有 IT 基礎設施，在偏僻地區嗡嗡作響的伺服器農場，跨越海洋的光纖電纜，還有軟體基礎設施。而像遺留的操作系統或沒人敢替換的 shell 腳本，這些 IT 基礎設施變得陳舊和破舊時，我們是無法看出的。但是，造就了今日發展的基礎設施卻正在老化，就像舊的地鐵軌道一樣。這可能會擾亂我們的現代生活。如今命令行英雄們正努力確保我們不會被過去束縛，因此出現了大量新的挑戰。

00:02:02：

這是我們第三季進入編程語言世界探索的第 5 期。我們將研究兩種編程語言，它們與最初設計的目標基礎設施密切相關。COBOL 是一種大型機的原生語言，而 Go 是雲計算的原生語言。它們都深受其起源的影響。理解這一點可能會讓明天的開發者不至於像紐約人一樣被塞進賓夕法尼亞州的車站。

00:02:33：

我是 Saron Yitbarek，這裡是紅帽的原創播客，《命令行英雄》的第三季。

00:02:43 - 格蕾絲·赫柏 Grace Hopper ：

我們面前有很多事情需要去做，但是我們首先需要大量相關的且易於訪問的信息。我們才剛剛開始。

00:02:53 - Saron Yitbarek：

海軍上將 格蕾絲·赫柏 Grace Hopper 在 20 世紀 40、50 年代率先開發了高級編程語言。而她之所以能夠實現這種巨大的飛躍，是因為當時的基礎設施，大型計算機。

00:03:08 - Chris Short：

嗨，我叫 Chris Short。

00:03:10 - Saron Yitbarek：

Chris 是紅帽的首席產品營銷經理，而且他也是一位歷史愛好者。

00:03:17 - Chris Short：

上世紀 40 年代的赫柏上將創造了 FLOW-MATIC，這在當時是革命性的，她被廣泛認為是 COBOL 的祖母。因此，她能夠坐在那裡說：「嘿，只需將其放在大型機上」，或「嘿，只需將其存儲在大型機上」即可。

00:03:31 - Saron Yitbarek：

這是一個重大的遊戲規則改變。突然，你有了這種機器無關的語言，即 COBOL，它是大型機環境特有的。可能性開始逐步打開。

00:03:42 - Chris Short：

大型機和 COBOL 真正使得每個組織能夠說，它們不再需要充滿了帶著鉛筆、紙、計算器和滑尺的人的辦公室，他們可能只需要半個辦公室來安裝大型機。然後，他們可以僱人用 COBOL 來編寫一些應用程序來完成整個財務團隊做的所有的數學、邏輯運算以及賬目。因此，你需要的財務團隊人數少了，僅僅是因為更多的輸入可以被數字化，而不是全手動操作。

00:04:17 - Saron Yitbarek：

如果你是那些新來的 COBOL 程序員之一，你會覺得你有了一份終身的工作。因為你的工作所基於的基礎設施 —— 所有那些大型機 —— 始終會在那裡。

00:04:30 - Chris Short：

那時侯摩爾定律還未出現，所以你可以整整十年都在同一個大型機上工作，對吧？就像你不用去考慮下一個操作系統，或者下一個類型的容器編排器，又或者下一個出現 AI 之類的東西一樣。你可能會整個職業生涯都在從事 COBOL。而且你知道自己的生活將會非常穩定。

00:04:55 - Saron Yitbarek：

但是，摩爾定律最終還是來了。新的基礎設施也出現了。現如今，程序員不太可能去學習一種半個世紀前的舊語言。但實際上，那些老舊的大型機其實並沒有消失。這意味著我們對 COBOL 開發人員的需求也沒有消失。

00:05:17 - Chris Short：

尋找 COBOL 開發者變得越來越困難。最終會發生的事情是這些大型機可能已經存在了 50 年。這些仍然可以編寫出色 COBOL 程序的開發人員將獲得巨額收入，以幫助項目運行並完成大型機中的數據重組。而且，該技能肯定會絕跡，並且正在成為一個利潤豐厚的職業領域，如果你……現在寫 COBOL 絕對可以賺很多錢。

00:05:49 - Saron Yitbarek：

尤其是在製造業和金融業。你無法超越幾十年前建立的所有基礎設施。遺留代碼遍及全球。忽略這些老舊的基礎設施及其相關的語言，將是一個巨大的錯誤。

00:06:08 - Chris Short：

有兩千億行代碼擺在那裡，要重構這些代碼真的很難。不，我不認為在有生之年我們會看到它消失，真的。

00:06:21 - Saron Yitbarek：

Chris Short 是紅帽的首席產品營銷經理。

00:06:28：

我想花一秒鐘解釋一下 Chris 的觀點。你想想看，95% 的 ATM 交易中都有 COBOL 代碼，那就是我們與這種語言的聯繫。但是，COBOL 程序員的平均年齡並不比該語言年輕多少。他們 45 歲，或許 55歲。新人們並不感興趣這門語言。這就是為什麼我想向你介紹一個人。

00:06:56 - Ritika Trikha：

嘿，我是 Ritika Trikha。

00:06:59 - Saron Yitbarek：

Ritika 是一名技術編輯，曾在 HackerRank 工作。她對 COBOL 的這個問題著迷：人們認為 COBOL 是後大型機時代無意義的殘留品。

00:07:12 - Ritika Trikha：

如今的開發人員根本不會考慮 COBOL 了，見也沒見過，想也沒想過。

00:07:17 - Saron Yitbarek：

但這可能是災難的根源。

00:07:21 - Ritika Trikha：

如今，仍然有大量的 COBOL 代碼在驅動企業的業務。每年至少新增 15 億行 COBOL 新代碼。我認為當你看特定行業時，真的很有意思。就像美國國稅局有 5000 萬行代碼。社會保障局有 6000 萬行代碼。 因此，這些單位和實體正在處理一些如今最敏感、重要的信息，如果我們不繼續為這些大型機提供支持和維護，就會造成很大的破壞。

00:08:04 - Saron Yitbarek：

因此，如果我們無法擺脫舊的基礎設施，又無法揮舞魔杖來重建整個大型機業務，我們該怎麼辦？編碼人員有時候僅考慮未來，該如何接受過去？我們首先需要直面該問題。

00:08:25 - Ritika Trikha：

你知道，年輕一代將不得不重拾這些技能。或者，必須對這些大型機進行某種現代化改造。無論是哪種方式，這個問題都不會消失。這就是為什麼 COBOL 還活著的原因。

00:08:35 - Saron Yitbarek：

這並不容易。 Ritika 認為我們已經忽略這個問題太長時間了。

00:08:42 - Ritika Trikha：

這非常昂貴、艱巨，並且替換數十億行 COBOL 代碼的風險也非常高。它是用於關鍵任務的代碼，比如社會保障和金融信息。COBOL 是專門為此類大量交易而設計的。因此，它由格蕾絲·赫柏在 60 年代為商業交易而設計。自上世紀 60 年代以來，一直存在「如果沒壞，為什麼要修復它」的說法，現在我們處於這樣一個關頭，即延續了數十年的大量的高價值數據運行在 COBOL 上。

00:09:22 - Saron Yitbarek：

從某種意義上說， Ritika 在呼籲一種文化的轉變。改變對 "進 "與 "退 "的態度。由於發展的世界慢慢有了越來越久的歷史，我們會更加地接觸到自己的歷史。你無法擺脫老化的基礎設施。這意味著你也不能忽略編程語言的歷史。

00:09:47 - Ritika Trikha：

有些事情必須得做。當我在 HackerRank 時，我親眼看到了多少銀行和金融機構對 COBOL 開發人員的傷害，幾乎是絕望的。這不是一個會被解決的問題，我認為要麼必須有某種現代化的系統，要麼我們繼續培訓人員並激勵他們。我個人認為將會有 COBOL 再次出現的一天。真的，當所有擁有 COBOL 知識的開發人員退休，並且沒有新一代的開發人員學 COBOL 時，將會發生什麼？總得做點什麼，對吧？所以，當從 COBOL 轉向新的基於雲的基礎設施時，需要有更多的系統化和制度化的改變。

00:10:37 - Saron Yitbarek：

Ritika Trikha 是一名舊金山的技術作家。

00:10:49 - Saron Yitbarek：

那麼 Ritika 提到的那些基於雲的基礎設施呢？我們今天建立的基礎設施是否會將後代綁定到特定的語言，像我們仍綁定找 COBOL 上一樣？ 亞馬遜 Web 服務 Amazon Web Services （AWS）可能是最大的單一雲基礎設施，於 2006 年推出。 Google 雲平台 Google Cloud Platform （GCP）於 2008 年問世，微軟 Azure 於 2010 年問世。 Go 語言以並發為重點，定位於在新的雲基礎設施上蓬勃發展。這是這個時代的語言。

00:11:26 - Carmen Andoh：

嗨，我叫 Carmen Andoh， 我是谷歌 Go 團隊的項目經理。

00:11:34 - Saron Yitbarek：

Carmen 對 Go 語言與今天的基礎設施有怎樣的聯繫有深入的理解。這要從 Go 的創作者和編程語言歷史的緊密聯繫說起。

00:11:47 - Carmen Andoh：

Robert Pike、Robert Griesemer 和 Ken Thompson。這些名字算是從上世紀 60 年代就開始出現了。Ken Thompson 發明了 B 語言，然後他在夏天的假期繼續發明 UNIX 操作系統。Rob Pike 發明了字元串編碼 UTF-8，他還發明了 ASCII。他幫助 Ken Thompson 共同編寫了 UNIX 編程環境。所以，這兩個人是很多、很多年前的同事，他們一直在研究和發明用以前的編程語言編寫的操作系統，這些語言包括 Ken Thompson 最終幫助 Dennis Ritchie 一起編寫的 C 語言。

00:12:28 - Saron Yitbarek：

Pike、Griesemer 和 Thompson 在 Google 工作之後，他們發現了一個嚴重的問題。並沒有出現大規模的並發。人們等待了幾個小時編譯出來。他們使用的是 C++，並且必須得編寫所有這些回調和事件調度器。那是在 2009 年，我們的基礎設施再次發生了變化。諸如 C++ 之類的語言越來越不適應這種新的現實。

00:12:59 - Carmen Andoh：

多核處理器、網路系統、大規模計算集群和 Web 編程模型等正在引入這些問題。而且，還有這個行業的增長，程序員數量在 2010 年就會達到成千上萬。因此，直到那時，所有的編程語言都是在規避問題而不是在正面解決問題。

00:13:24 - Saron Yitbarek：

最終，將達到一個臨界點，必須開始改變。

00:13:30 - Carmen Andoh：

嘿，我們討厭 C++ ，我說：「好吧，讓我們看看我們是否能發明些新的東西。」

00:13:37 - Saron Yitbarek：

這種新語言需要完美地適應我們最新的基礎設施。

00:13:43 - Carmen Andoh：

2005 年雲技術到來以後，你不再需要自己的計算機，在某種程度上在其他地方租用它，你就可以得到一個分散式系統。但是在分散式系統中，以及在雲計算中，存在並發消息傳遞問題。你需要確保採用非同步對你來說沒有問題。Go 預設就是非同步的編程語言。基本上，這意味著你執行的每個操作（例如將所有這些不同的消息發送給系統中的另一個計算機）都無需等待另一個機器對你的響應即可完成。因此，它可以在任何給定時間處理多個消息。

00:14:28 - Carmen Andoh：

就是說，雲計算是分散式的。因此 Go 的開發就是來滿足這一確切需求。Go 早就成為進行這種分散式計算的標準方法之一。這就是為什麼我認為它立即引起了開發人員的廣泛關注。Go 絕對是雲基礎設施的語言，無論是其設計，還是所有雲基礎設施工具，以及在過去十年中如雨後春筍般出現的模塊的生態。

00:15:06 - Saron Yitbarek：

很快，諸如 Kubernetes 之類的關鍵應用都用 Go 編寫了。谷歌還創建了 Go Cloud，這是一個開源庫和一系列工具，使得 Go 更具吸引力。很顯然，它是新生態系統的語言。它是雲的語言。而且，它的創造者們因開發生命力持久的語言而享有聲譽，這絕對沒有壞處。

00:15:33 - Carmen Andoh：

我認為業界的其他人會說：「嘿，我認為這不會很快消失。」這種語言的發明者恰巧也發明了語言有 50 、60 年了。

00:15:47 - Saron Yitbarek：

Carmen Andoh 是谷歌 Go 團隊的項目經理。

00:15:54：

因此，我們有了一種新的語言 Go ，旨在提供雲基礎設施必需的並發性。聽起來不錯。Go 的設計師傾向於創造可以持續半個世紀的語言。這也很棒。但是我的問題是，從現在起，50 年後，當 Go 更像是 COBOL 時，這到底意味著什麼？當世界上充滿了只有老開發人員才能理解的舊版 Go 代碼時，這又意味著什麼？在當今的雲基礎設施老化的時候，我們是否會做好準備？我們是否從 COBOL 和大型機領域吸取了教訓，可以幫助我們為 Go 和雲設計更美好的未來？

00:16:40：

幸運的是，我找到了問所有這些問題的合適人選。這就是下面這位。

00:16:51：

我們如何使我們的語言能面向未來？我們知道他們與當今的基礎設施息息相關。我們也知道，隨著數十年的發展，新的基礎設施必將取代舊的基礎設施。那麼，我們今天做些什麼以確保將來能平滑演進？

00:17:10 - Kelsey Hightower：

我是 Kelsey Hightower ，我在谷歌，是一名開發人員推廣大使，我致力於引入開放性技術並將它們應用於谷歌雲上的產品。

00:17:19 - Saron Yitbarek：

Kelsey 花了大量時間思考編程的未來。我很好奇，是否有一天我們將陷於握有 Go 語言技能的是另一批老齡化的程序員的問題，就像我們現在缺少 COBOL 的引導一樣。我們是否在為這個長遠的未來做計劃？因此，我和 Kelsey 坐下來進行討論。

00:17:42 - Kelsey Hightower：

...等等。但是，如果你考慮到今天面臨的一些新的挑戰，如應對互聯網，這種網路，你將面臨許多用戶，成千上萬的並發用戶，以及不同的機器和架構類型的組合。考慮到這些新的場景，因此你通常希望有一種新的語言來解決。例如， JavaScript 是用於 Web 的，你不會想改造 COBOL 以便可以用它來進行 Web 編程。最終，我們今天已經有了數百種相當完善的語言，而且它們都非常專註於他們的優勢。

00:18:15 - Saron Yitbarek：

那麼，在那種情況下，我們是否需要積極推動人們走向 COBOL ？如果我們正在為這些新問題開發新語言，並且它們是高度定製化的，而 COBOL 仍在堅持不謝幕，我們是否需要鼓勵人們選擇它，以便我們可以維護我們的舊代碼？

00:18:32 - Kelsey Hightower：

好吧，我認為這將對企業是個挑戰吧？所以，你已經在 COBOL 上投入了 10 到 20 年，沒有人會主動想學習一些新的 COBOL。或者你不會像剛從大學畢業那麼「我要加倍努力……」。

00:18:45 - Saron Yitbarek：

沒錯。

00:18:46 - Kelsey Hightower：

「...這種語言比我父母的年齡都大。」 因此，在那個領域，你必須問自己，繼續使用 COBOL 的風險是什麼？未來是否仍然有意義？我認為它仍然有益於某些類型的工作任務，但是我們必須問自己一個問題，是時候推進了嗎？是時候進化一點了嗎？因此，如果你仍然有數十億行的 COBOL 代碼，那麼你將必須尋找所有剩餘的 COBOL 人才，並將其招進來，但也許我們該開始考慮其他語言能從 COBOL 學習些什麼，並將某些功能和庫加入到其他語言中。

00:19:26 - Saron Yitbarek：

COBOL 終止以後的日子，將會是一個巨大的基礎設施項目。用我對紐約地鐵的比喻，就像是要替換每條地下隧道。因此，展望未來，我想知道我們是否可以預見到這些問題，甚至將來對自己也能有所幫助。

00:19:48：

如果我們將今天的雲計算與大型機進行比較，我們是否會在最終到達同一條船上，有著這些舊代碼庫，使用著舊的但非常穩定的語言，而且我們也到了必須做出選擇的時候，我們應該繼續前進還是保持不變？

00:20:05 - Kelsey Hightower：

雲有點不同的是它不是來自一個製造商，對嗎？許多雲提供商通常提供了一系列技術集合，你就可以選擇編程語言、編程範式，無論你是要事件驅動還是基於 HTTP 的全 Web 服務。這意味著你可以選擇編程的方式，然後只需專註於要解決的問題。因此，數據進進出出，但是你來選擇處理數據的方式。

00:20:36：

大型機通常只有一個主界面，對嗎？就像你編寫一份任務一樣，這就是你提交任務的方式，這就是你監控任務的方式，這就是結果。這本身就是一個限制。如果你考慮一些較新的大型機，它們也會支持些較新的技術，因此即使在大型機領域，你也會開始看到可用於運行任務的編程語言擴展。

00:20:58：

那麼我們開始問自己，好吧，既然我有了新的選項，該什麼時候離開這種特定的編程範式繼續前進呢？我認為我們不會陷入困境。

00:21:08 - Saron Yitbarek：

正確。

00:21:08 - Kelsey Hightower：

我認為新的分散式機器很不錯，可能起步成本更低，你不必購買整個大型機即可開工。但是我們仍然希望易用性和之前一樣：給你我的工作，你為我運行它，完成後告訴我。

00:21:24 - Saron Yitbarek：

絕對是這樣，你覺得發生的事情，或者說 COBOL 所發生的事情，會發生在今天的任何一種語言上嗎？ 以 Go 語言做例子，你看到我們在努力地改進 Go 從而吸引人們在 30 年後還想用 Go ？

00:21:38 - Kelsey Hightower：

我認為所有語言都會遭受這種命運吧？如果你仔細想一下，其實 Python 已經存在很長時間了。我想差不多 20 年了，甚至更久。因此，我認為會 …… Python 重新流行起來了，它現在是機器學習的基礎語言。

00:21:53 - Saron Yitbarek：

是的。

00:21:54 - Kelsey Hightower：

對於 Tensorflow 之類的庫，如果我們僅用時間來衡量，我認為這可能不是看待它的正確方式。還應該有社區是否活躍？語言的適配意願是否活躍？我認為 Python 做得確實非常出色……社區看到了使其他語言更易於使用的能力。例如，Tensorflow 底層有很多 C++ ，使用這種語言編程可能沒有 Python 這樣的用戶友好性。你可以用 Python，並用它來生成人們正在使用的一些東西，例如 Tensorflow 。現在機器學習非常熱門，人們將 Python 引入了這個新領域，那麼你猜怎麼著？ Python 仍然是活躍的，並且在未來的一段時間內都是活躍的。對於 Go 來說，這同樣適用。如果 Go 能夠繼續保持活躍度，那麼，它就像許多基礎設施工具和許多雲庫的基層一樣，它也將保持活躍。因此，我認為都是這些社區確保了它們將來佔有一席之地，並且當未來出現時，確保那裡仍有它們的位置。

00:22:58 - Saron Yitbarek：

是的。那麼，我們如何讓我們的語言面向未來呢？就是說，我們如何有意地設計一種語言，使其能持續存在，並在 20、30 年內都保持活躍呢？

00:23:10 - Kelsey Hightower：

使用語言的人，我認為這在開源世界中確實是獨一無二的。現在，我們已經不再使用商業語言了，對吧，過去曾經來自微軟的語言或太陽微系統的如 Java™ ，那時侯，每個人都依賴於供應商來盡心儘力來對語言能幹什麼以及對運行時環境進行新的改進。現在，我們看到的諸如 Go、Node.js、Ruby 之類的東西，所有這些都是社區支持的，並且社區專註於運行時環境和語言。這樣任何人都可以添加新庫，對吧？有一個新的 HTTP 規範，對，HTTP/2 幾年前問世了，每個社區都有貢獻者添加了那些特定的庫，猜猜現在怎麼樣？所有現在這些語言，都兼容於大部分的未來網站。

00:24:01：

我認為現在是個人真正地擁有了更多的控制權，如果他們想讓語言適用於新的用例，只需要自己貢獻即可。因此，我們不再受限於一兩家公司。如果公司倒閉，那麼運行時環境可能會因此而消亡。我們不再有這個問題了。

00:24:23 - Saron Yitbarek：

我們之前在這個播客上已經說過了。未來是開放的。但是，令人著迷的是考慮怎樣能做到再過幾十年，過去也將是開放的。它們將繼承能夠變形和演進的基礎設施和語言。

00:24:39 - Kelsey Hightower：

太棒了，感謝你的加入，我期待人們的工作，而且大型機仍然有意義。它們是經典技術，因此我們不稱其為遺產。

00:24:47 - Saron Yitbarek：

哦，我喜歡，經典，非常好。

00:24:51：

Kelsey Hightower 是 Google 的開發者推廣大使。

00:24:57：

我正在想像一個充滿經典編程語言以及尚未誕生的新語言的未來。那是我為之興奮的未來。

00:25:07 - 演講者：

請離關著的門遠一點。

00:25:12 - Saron Yitbarek：

要知道，2017 年 Andrew Cuomo 州長宣布紐約市地鐵進入緊急狀態。他的政府撥出 90 億美元投資於老化的基礎設施。這應該提醒我們，遲早我們得注意遺留的系統。你不僅需要繼續前進，面向未來。你還背著歷史包袱。

00:25:37：

在開發的世界中，我們傾向於偏向未來。我們認為我們的語言僅在它們流行時才有用。但是，隨著信息基礎架構的不斷老化，開發的歷史變得越來越真實。事實證明，過去根本沒有過去。記住這一點是我們的工作。

00:26:05：

你可以前往 redhat.com/commandlineheroes ，以了解有關 COBOL 或 Go 或本季我們要介紹的其他語言的更多信息。那裡有很多很棒的材料在等你。

00:26:19 - Saron Yitbarek：

下一集是關於 Bash 的。我們將探索 shell 腳本的起源以及自動化的關鍵。

00:26:30 - Saron Yitbarek：

《命令行英雄》是紅帽的原創播客。我是 Saron Yitbarek 。下期之前，編碼不止。

什麼是 LCTT SIG 和 LCTT LCRH SIG

LCTT SIG 是 LCTT 特別興趣小組 Special Interest Group ，LCTT SIG 是針對特定領域、特定內容的翻譯小組，翻譯組成員將遵循 LCTT 流程和規範，參與翻譯，並獲得相應的獎勵。LCRH SIG 是 LCTT 聯合紅帽（Red Hat）發起的 SIG，當前專註任務是《代碼英雄》系列播客的腳本漢化，已有數十位貢獻者加入。敬請每周三、周五期待經過我們精心翻譯、校對和發布的譯文。

歡迎加入 LCRH SIG 一同參與貢獻，並領取紅帽（Red Hat）和我們聯合頒發的專屬貢獻者證書。

via: https://www.redhat.com/en/command-line-heroes/season-3/the-infrastructure-effect

作者：Red Hat 選題：bestony 譯者：messon007 校對：wxy

本文由 LCRH 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive