Key Takeaways

  • 不要修補有缺陷的抽象層。架構應源自真正的技術挫折，從根本解決問題，而非在上面堆疊更多複雜性。
  • 依賴單體式 Linux 核心進行容器隔離是安全瓶頸。由於核心記憶體共享，namespace 與 cgroup 抽象層往往不足以提供真正的多租戶隔離，因此需要轉向更好的虛擬化／隔離模型。
  • 使用 LLM 協同快速原型開發，但需保持技術謙遜。盲目信任 AI 輸出會產生技術債——你必須充分理解底層系統，才能在 AI 失效時進行除錯。
  • 我們正強迫為渲染最佳化的 GPU 擔任安全的 AI 加速器。這在根本上既低效又不安全。長期而言，TPU 或自訂核心驅動程式等專用硬體才是必要的。
  • 法規是必要的「推力」，但真正的安全應成為競爭優勢。技術人員必須主動追求軟體主權，而非視其為合規負擔。

Transcript

Olimpiu Pop: 大家好，我是 Olimpiu Pop，今天邀請到一位充滿熱忱、希望有意義作為的年輕技術專家——Edera 技術長暨共同創辦人 Alex Zenla。Alex，能否請你簡單介紹一下你的理念，以及 Edera 希望為我們帶來哪些安全改善？

Alex Zenla: 當然可以，非常感謝邀請。我是 Alex。我開發軟體已經超過 12 年了。重要的背景是，我很早就開始接觸程式設計——大概 10 歲左右。我爸爸在大學的 IT 部門工作，我跟著他去上班時，會在電腦教室玩弄電腦，那大概是 6、7 歲的事。之後我慢慢對程式設計產生興趣。

我記得當時拿到一台二手筆電，安裝了 Ubuntu，那大概就是我走上非主流思考模式的起點。我在 14 歲時開始我的科技職涯，進入物聯網領域。那段經歷大概可以另外開一集 podcast，不過基本上，有一天我收到陌生網友的來信，他喜歡我做的開源專案，於是就在我 14 歲生日那天，轉化成一份有薪工作。

從那之後，我已經全職工作了 12 年。其中大約 10 年在物聯網領域，到了 2023 年底，我開始考慮從物聯網領域「退休」，轉做其他事情。我一直對開發工具、軟體系統與作業系統抱有熱情。Ariadne Conill 是 Alpine Linux 的維護者之一（或曾是），她開發了 APK-tools、Audacious 等軟體專案。我們是朋友，而當時我正在 Google 構思一個能原生執行容器的 hypervisor。

Ariadne 對這個想法非常感興趣，因為她當時在 Chainguard，是 Wolfi 的主要創建者之一。後來這個想法獨立成一個專案。她也想做些不一樣的事，於是我們一起創立公司，最後形成了 Edera。我們開發的技術稱為 Edera，專注於將容器、VM 與系統映像彼此隔離。我們的概念稱為「zone」，讓你能在安全的虛擬機器內執行隔離的工作負載。產品非常注重企業需求，效能是重點，我們也致力於讓企業能輕鬆使用。

不要接受有缺陷的現狀——改善它！[03:46]

Olimpiu Pop: 你提到 Ariadne，在 QCon 的演講中你也再次提及她，主要是因為一種哲學。我認為這非常重要，因為正如你所說，一切源自憤怒，也就是「spite」。

Alex Zenla: 是的，這是我最相信的軟體開發根本哲學。演講中的那張投影片正是關於「spite-driven development」（怨氣驅動開發）。我在 Google 工作時，開發 Edera 技術的目標，就是想解決一個我覺得「早就該解決卻一直沒人解決」的問題。

Ariadne 的許多作品也來自這種源於挫折、想讓事情變得更好的開發方式——看著世界說：「我對現狀不滿意，有點生氣它為什麼要這樣運作。」在軟體開發中，我們很擅長把事情變複雜，卻不擅長簡化。

「Spite-driven development」是我重新思考世界的方式。當我對某件事的運作方式感到不滿時——我並不是在鼓吹「Not Invented Here」症候群——而是想說：當你知道某件事行不通時，你不必非得讓它繼續以那種方式運作。

我在演講中舉的最大例子就是作業系統。雖然大家都在用 Linux，但我可以告訴你，Linux 並不完美。任何說 Linux 完美的人，都從未真正開發過 Linux 核心。核心裡有各種問題、邊緣案例。它是個很棒的核心，但其根本運作方式在某些方面正在崩壞。我們必須正視這點，並開始思考不同的開發方式。

這不代表要全盤推翻，而是改變架構、更熟悉堆疊的不同層級，並真正深入你不理解的領域去解決問題。當我開始處理核心層級與虛擬化相關工作時，我完全不知道自己在做什麼。但我沒有停下來，遇到障礙時，我就試著去理解。

當 Edera 剛成立時，LLM 還處於非常初期的階段，所以我沒有那種可以隨時詢問的 AI 助手。我就是不斷地動手、硬幹，讓 hypervisor 運作起來。我認為這是軟體開發中被低估的部分——真正去打破事物，並在不了解的情況下仍能往前推進。如今，AI 輔助開發讓我們更容易進入從未接觸過的領域。

雖然可維護性等問題仍待討論，但你確實可以在完全不了解的領域做出能運作的東西。不過我認為另一個被低估的部分——也是我個人使用 LLM 的方式——就是我會把某個規格丟給 Claude，請它解釋我需要知道的所有資訊，然後我會真正吸收這些知識。所謂「vibe coding」的問題，以及為什麼我認為它與「spite coding」可能不相容，是因為到最後你必須理解自己做了什麼。這也是從 spite-driven development 中獲得滿足感的重要關鍵。

用 LLM 加速理解 [08:09]

Olimpiu Pop: 也許這段討論的座右銘就是「vibe 還是不要 vibe」，對吧？……但我認為你說得對。我也有同樣的感覺，因為當你越往上爬、責任越多時，就越難動手，尤其是在快速演進的領域。我現在想到的是 cloud-native 的成長——現在一切都強調「native」。更不用提 JavaScript 生態系，你眨個眼就又多出四個號稱「最好的」函式庫。

但使用 AI 輔助開發的好處（我不會稱之為 vibe coding）在於，如果你如你所說，是從解決問題（無論是自己的或更廣泛社群的問題）出發，你會更快獲得滿足感。你不會花一堆時間做東西，做到後來發現自己根本不知道發生什麼事，然後必須回頭理解，之後又全部忘光。因此，你更有機會在文件較完善的領域快速前進。

我最近和很多人聊天，例如 Gunnar Morling。他開發了第一個幾乎零依賴的 Java Parquet 函式庫。據我所知，這可能是第一個從零開始、完全由 LLM 協助開發的開源函式庫。它讓他能快速迭代，而這來自於 Parquet 文件非常完善，讓他能清楚掌握方向。每個專案都從設計文件開始，讓他理解現有內容與運作方式，我認為這非常重要。

另一個擔憂是，這就像 App Store 剛出現時，人們只是到處「用膠帶黏起來」，然後說「沒關係，這些東西有漏洞，但我不在乎，因為我必須上架」。這些正是我們需要小心的地方。

但總體來說，我認為現在是很好的時機。例如前幾天，我快速做出一個能爬取線上資料並發送通知的東西，使用了以前從未用過的雲端服務。雖然過程很快，但我後來還是說：「好，大多數東西我只懂高層概念，現在請一步步帶我走，挑戰我、拷問我，讓我真正理解。」我認為這很重要，因為這帶來雙重滿足感。

一方面，我有快速完成的快感；另一方面，我真正理解了概念，也知道如何建構它。我想到系統設計面試——現在你真的可以在一、兩小時內做出東西，這已經相當可行。就像你說的，看著一個問題，並延伸「Girl Scout／Boy Scout 規則」，讓程式碼變得更好。但如你所說，你是從需求出發的。而在你 QCon 的演講中，你提到靈感或安全哲學有部分來自 Minecraft——特別是不同層級的堆疊方式，以及你如何看待它。那麼，我們目前在 cloud-native 堆疊中處於什麼位置？

太多抽象層 [11:21]

Alex Zenla: 是的，絕對如此。我在開場沒提到的其中一件事是，Minecraft 是我童年很重要的一部分，而且我認為它真正催化了我對程式設計（而非只是 shell script 與系統管理）的興趣。那是我能指認的、真正改變我思考方式、想真正開發軟體的時刻。Minecraft 是用 Java 寫的 JVM 應用程式，這讓它非常適合被檢視、分析與修改，這也幫了大忙。

它教會我很多有趣的事情，其中最重要的是系統的層級，以及如何思考系統分層。實際上，我在演講中沒有深入討論的是，Minecraft 作為遊戲架構也有層級。我喜歡這樣想：如果你拿出演講中展示的某一層堆疊，再用顯微鏡看，你會看到裡面還有成千上萬層，但你必須在某個點切斷。

我主要聚焦的是系統層級，以及硬體建立在韌體之上、韌體建立在核心（或大多數系統中的虛擬化堆疊）之上、接著是核心，然後是容器（runc、Docker、containerd 等），這些層級最終執行與核心溝通的容器。之後還有 Kubernetes，以及你的應用程式或其他編排層。當你開始這樣思考時，你會開始忘記系統底層到底是什麼。

我認為，聽這集 podcast 的大多數人，可能都非常專注於我所謂的「應用程式或應用程式編排層」，也就是 cloud-native 所在的位置。Cloud-native 的一切都是 API——都是關於「我能不能呼叫你的 HTTP API？能不能呼叫你的 gRPC API？能不能傳輸或刮取資料？」說清楚一點，在這一層開發並沒有錯，這是系統中非常重要且關鍵的一層。

不幸的是，我認為我們在系統中創造了太多層級。這意味著 cloud-native 開發者坐在最上層，而核心與系統則在最底層。這是一個巨大的問題，因為核心與提供核心子系統的元件，對上面每一層都有非常明確且關鍵的影響。如果 Linux 核心很爛，那上面的一切都會很爛。

這是個真實存在的問題。我在演講中試圖聚焦的安全問題是：當 Linux 壞掉、Linux 的安全性崩壞時，上面的一切就完全失效。如果你有核心 CVE，不管你的 Kubernetes 叢集有多安全都沒用，因為核心是整個 Kubernetes 節點共享的。於是安全性瞬間完全崩解。

從根本上來說，我們已經忘記這件事有多重要，並且非常習慣創造抽象層。但如果你認真思考最安全、最好的做法，通常是減少層級、減少攻擊面、減少這些可能性。

這也是我思考系統的根本方式。我在演講中舉了很多例子，很多 cloud-native 工程師會用他們不理解的 Linux 核心方式來 workaround。他們會使用可能並不適合他們真正想做的事的高階抽象層。這是因為當你坐在系統的這一層，如果你對核心沒有非常根本的理解，那麼在開發軟體時就會成為真正的問題。

我特別談到「限制」。我們新增的每一層系統，都會對上面的層級施加限制。Linux 核心及其運作方式，嚴重限制了上面應用程式的行為方式。我們之所以有現在這種運作方式的容器，是因為我們能把能用的技術黏在一起，讓 Linux 核心適合容器系統。但你完全可以設計一個不同的核心，擁有不同的特性與思考方式，從根本上改善或改變容器執行的方式。這正是我們在 Edera 嘗試做的事——開發一個真正原生理解容器的虛擬化系統，而不是以「只是跑 microVM」的方式硬塞，而是真正深入理解容器是什麼，並直接為此打造技術。

單體式 Linux 核心的安全風險 [17:01]

Olimpiu Pop: 所以在某個時間點，你必須批判性地看待現狀，而不是只在搖晃的基礎上繼續堆疊——有時候退一步可能會帶來多方面的好處。我知道有很多例子，但讓我們看看目前的堆疊，系統工程師、架構師（隨你怎麼稱呼這些需要關心這些事的人）應該注意的主要關鍵問題有哪些？

Alex Zenla: 我認為在有 Mythos 這樣的東西之後，你比以往任何時候都更需要至少了解核心。如果我能稍微修改演講內容再回去改進，我會做的一件事是承認人們並非完全忽略核心。人們與核心互動的方式可能是透過 eBPF，或是如果你是 Linux 桌面／筆電愛好者，可能需要管理感測器或風扇控制等。但我認為，人們與核心的互動程度比我之前給予的肯定更多。

但理解支撐這些東西的底層，與實際與它互動是完全不同的兩件事。你需要理解為什麼在 Linux 中，process 在根本上是不安全的東西，會在不同 process 之間洩漏資訊，才能建構安全的系統。我們從非常基礎的層級思考，但我們並沒有真正思考為什麼 Linux 核心對此無能為力。

（不劇透太多）Linux 核心之所以這樣運作的主要原因是因為它是完全單體式的核心。當你進入核心層級時，Linux 核心中的一切實際上是一個單一共享的 process。雖然有很多細微差異，但重點是，大多數情況下，核心記憶體可以洩漏任何其他 process 的記憶體。它擁有控制系統的完整能力，因此透過系統呼叫的攻擊是個非常嚴重的問題，因為它可以真正影響一切。

我認為這件事需要被批判性地理解，而不僅僅是「我理解檔案描述元可能會洩漏」這種表面層級，還要理解我們現有系統無法真正幫助的各種方式。例如，Linux namespace 無法防止你從一個 process 洩漏檔案描述元到另一個 process。Linux cgroups 無法完美控制 process 使用的資源，因為如果我發出某個系統呼叫，我可能會影響核心中的其他 task 產生不同行為，進而無法完整計算我透過該呼叫消耗的 CPU 與記憶體資源。

因此，如果你試圖將這些機制用在它們並非設計用來處理的完整多租戶安全模型上，你會遇到一大堆問題。所以我認為更多人需要了解核心，而我認為大多數情況下，你不需要再往下挖得更深。回到我們之前的 AI 討論，現在了解核心比以往容易多了。特別是 Claude（我相信 Codex 與其他模型也是），Claude 模型裡面應該有整個 Linux 核心原始碼。你甚至不需要去抓核心程式碼來問它核心相關問題，它就是知道。當然，是的，要查證來源，AI 可能會出錯，但如果它有 90% 正確，那你就比原本多學了 90%，對吧？而這正是我在這些層級工作時非常關鍵的部分——不要害怕去研究它們，即使是你從未接觸過的東西。

與 LLM 共生合作 [21:33]

Olimpiu Pop: 我認為，正如我之前提到的，這是比較容易的部分。因為我想到五、六年前我做研究時，會開一堆分頁、到處做筆記，然後試著把一切拼湊起來。現在則是非常線性的過程，你直接得到答案——也就是說，你更容易深入兔子洞，因為你有一部電梯可以帶你上下，然後就很容易去嘗試。

但回到之前，把兩個討論合在一起，正如你所說，理解那些即使你只有大學知識或基本知識也很難掌握的概念，現在變得比較容易了。從我的觀點來看，當人們進入他們不該進入的領域時，他們並不完全理解，也不願意花時間去看所有的視角，然後 Reddit 上就充斥著「我不會寫程式，但我創了一家賺那麼多錢的公司」，五週後你又看到「求救，因為一切都爆炸了」。你會如何建議別人減輕這種情況？我在問你，因為你處在這個層級——如果你玩核心，事情可能很快就會變得很糟糕。

Alex Zenla: 是的，我認為你必須有一點謙遜，去理解你真正知道什麼，以及你以為你知道什麼。我認為人們對 vibe coding 之類東西的第一直覺是「我要用 AI 快速做出東西」，或「我要用 AI 致富」。就像你提到的那些 Reddit 例子，這正是很多人使用它的方式，而我認為這是一種非常糟糕的看法。因為如果你想做快速致富的把戲，那本來就是個問題，通常也是騙局，今天也一樣。

所以，你需要理解，你不能只是做出東西、認為自己懂了，然後就這樣成功並持續下去。我認為謙遜的部分在於理解你真正知道什麼。而這也是 Claude 與 AI 的一大問題——當你不知道某件事時，真的很難判斷你收到的資訊是否正確。這就是為什麼我認為永遠不要盲目用 AI 寫程式碼。

我並不是建議人們在完全沒有核心知識的情況下，用 AI 去建構核心模組。事實上，我會說「one-shotting」這種概念本身就是個很荒謬的想法，因為我認為 AI 應該是個助手。而我之所以這麼相信，是因為你需要能與它一起學習。

關於 one-shotting 以及「只開發一次，之後就能坐享其成」的想法（我認為這正是那些「我做出很酷的東西、正在賺大錢，隔天就爆炸」的案例的問題所在），我認為差別在於你需要能隨著時間推移，不斷 prompt 並理解事情如何運作。如果你真的把 Claude 當成助手來使用，你會發現它有 20%、30% 的時間是錯的。

但我一直覺得有趣的是，你可以從它的錯誤中學習。因為雖然 AI 可能對你說謊、可能不正確，但當你實際套用它說的東西到程式中、執行之後發現不行，這就證明它是錯的。

我舉一個幾小時前剛發生在我身上的有趣例子。我不知道怎麼搞的，在 macOS 上把整個系統的開啟與儲存對話框弄壞了。我後來知道這是因為它是共享的 XPC 服務——在 macOS 中，所有應用程式共享的服務，而且是出於安全考量。我觸發了這個 process 的無限迴圈。當時我正在用 Claude 建構一個做分析的應用程式，我告訴它：「我的開啟對話框壞了，你能幫我修嗎？」因為它想不出任何可能的原因，就完全失控，開始做一些非常瘋狂的事，比如把儲存面板與開啟面板的載入移到另一個執行緒，然後顯示載入對話框，儘管它永遠不會真正載入，因為真正的問題是 macOS 的服務壞掉了。

如果我對 macOS 的了解不足以知道它是 XPC 服務、因此應該去檢查它，我可能會坐在那裡想：「一切都壞了，一切都毀了」，因為 Claude 根本無法想像 macOS 會以這種方式壞掉。你仍然需要擁有足夠的知識，才能深入調查並除錯你的系統，因為當 Claude 錯了時，你需要能告訴它哪裡錯了。所以你不能盲目相信它說的一切，我認為這是一種共生關係——你餵給它資訊，它也餵給你資訊。就像如果你告訴它某件事、它認為是錯的，它會告訴你（新模型會告訴你，舊模型據稱會對你說謊）——同樣地，如果你這麼做，你也需要能檢查它的假設，就像它檢查你的假設一樣。所以當 Claude 告訴你某件事、聽起來不對時，你要質疑它。你不必盲目讓它留在那裡。我認為這是有效使用這些工具的最佳思考方式。

GPU 瓶頸：重新思考 AI 硬體與多租戶 [28:08]

Olimpiu Pop: 好的，所以要對你做的事負責、檢查它、圍繞它建立護欄。但因為我們談到 AI，大約兩、三年前（我不太記得確切時間），Linux Foundation 的 Keynote 舞台上放了一個很大的愛心符號，在「AI-native」與 Kubernetes 之間。Kubernetes 眾所周知是為許多工作負載提供編排的平台，所以 AI 當然會從中受益。但因為你提到我們不能再深入核心了（當然我們可以，我們可以到裸機），我們也知道 GPU 從來不是為這些事情設計的。就像計算領域中的大多數東西一樣，它們原本是為其他目的設計的——特別是大量視覺計算等等，後來有些聰明人發現它也可以用於機器學習，然後開始使用它。AI-native 擁抱 cloud-native 給我們帶來了什麼樣的問題？

Alex Zenla: 是的，這是個非常有趣的議題，我們在 Edera 花了很多時間在 GPU 上。我一直談論的一件事是，我用來玩遊戲的 Linux 核心 GPU 驅動程式，和人們用來部署 GPU 工作負載、訓練等等的驅動程式是同一個。這對我來說很瘋狂。首先，它們不必是同一個，而且有各種理由說明為什麼把 GPU 的渲染系統與 LLM 相關工作共享，以及 GPU 複雜的架構，在很多方面實際上是根本不同的。其中之一是，GPU 上的資料極度敏感。大多數時候載入 GPU 的資料，要嘛是專有模型（想想 Claude），要嘛是應該保密的使用者資料——但在相當多情境中，這些資料實際上並不私密，雖然我會說 Anthropic 在這方面做得很好。

我一直覺得很有趣的是，多年來渲染我的 Minecraft 的那個東西，現在正在做這份工作。我曾經和某人有一段非常有趣的關於渲染的討論。正如我的 Minecraft 背景所顯示的，我的很多朋友都是遊戲相關的人，大多是遊戲開發者。我曾經參與過一點 SDL3 的專案（如果你知道那是什麼的話），它是一種很酷的圖形技術，基本上就是 Linux 與其他作業系統的 DirectX。

根本問題是，安全性在遊戲中根本不是考量。如果能渲染得更快，他們寧可完全不要安全性。我不知道你有沒有遇過真正的高效能玩家，但他們絲毫不關心遊戲的安全性。事實上，遊戲圈有很大的反 DRM 聲浪（理由很充分），以及反作弊機制等等，這些東西在某些情況下確實會大幅降低效能。把這個用來做 LLM 的複雜計算，真的很瘋狂。

我實際上認為 Google 的 TPU 方法以及其他類似系統，長期來看會是贏家，因為它們從根本上就是為這個任務打造的。你提到 AI-native 與 Kubernetes。Kubernetes 在 GPU 領域被大量使用，這在邏輯上說得通，因為 GPU 本質上是一個排程問題，而 Kubernetes 正是為了讓排程變得簡單。但任何了解 Kubernetes 內部的人可能都會有點皺眉，因為它不一定乾淨。

事實上，Kubernetes 有動態資源分配（dynamic resource allocation），就是為了嘗試解決 Kubernetes 原本不了解複雜裝置拓撲與 GPU 複雜性的問題。我認為 cloud-native 對 AI-native 領域是件好事，但回到層級問題，也許核心層的這些層級並不適合它。

一個很好的例子是，GPU 本質上就是單租戶系統。所有記憶體都是共享的，如果你曾經使用 CUDA 並試圖同時執行多個 CUDA 工作，你會發現那基本上是一種幻覺。它真的不理解 process 或任何形式的隔離概念，即使是 MIG 這類技術也做不了太多。所以你有一個根本問題：在 Kubernetes 叢集中存取 GPU 的某個租戶，可能（而且經常發生）導致 GPU 發生錯誤，並讓其他使用它的人也無法使用。工作負載常常執行效率低下，因為它們實際上無法共享 GPU。

此外，當它們在容器系統上執行時，如果沒有使用 Edera、Kata Containers 之類能將每個容器真正隔離到獨立安全 zone 的東西，最大的問題是 GPU 攻擊可能會影響其他客戶。這些就是你把某樣東西重新用在它並不真正有意義的領域時會遇到的問題。這也是為什麼我認為 TPU 之類在完全不同層級運作的系統，會在這個領域更成功——因為它們從根本上就更適合這種情境。我一直用的那句話是：「GPU 是為渲染打造的，而不是為 LLM 打造的。」這就是事實，而且至今沒有改變。

我的希望是，如果我們繼續使用 GPU 來跑 LLM，我們需要考慮也許、只是也許，我們應該開發自訂核心驅動程式、自訂軟體，甚至在 GPU 本身上執行（GPU 任務的編排等等），甚至把多租戶功能建到硬體裡。否則我們正在犯一個巨大的錯誤。最近有傳聞（只是傳聞）說 Apple 正在考慮為即將推出的 Gemini 採用 Nvidia，並同意在 Nvidia GPU 上使用機密運算（confidential computing）。Apple 非常注重隱私，他們非常在意使用者資料隱私，你可以從他們建構的 Private Cloud 看出來。我認為他們要求機密運算這件事非常有趣，而這也是新聞。當這集 podcast 播出時，我們就會知道情況是否屬實。

技術主權與法規 [35:48]

Olimpiu Pop: 所以，TPU 與 GPU 的例子，正如你所說，是不把現狀視為理所當然、挑戰它並改善它的好例子，這是很好的例子。Amazon 有自己的專案，其他公司也有，但從我的觀點來看，我認為 Amazon 與 Google 是這個領域中成果最好的——我們在討論硬體，所以我很高興看到這些進展，特別是它們大多被 Anthropic 這類公司使用。

Google 與 Anthropic 有大型合作關係，這意味著這實際上會改善整個生態系，所以這非常幸運。當我看你的演講時，我感到相當驚訝（我非常喜歡你的演講），因為現場還有其他人，例如 Victor Petersen，他在談論歐洲法規如何試圖為我們帶來更好的軟體，而我很驚訝來自大西洋另一端、來自美國西岸的人，會對我們在歐洲所做的努力感到相當滿意。這件事相當重要，因為現在感覺歐洲與美國之間有點像在掙扎，甚至可以說是對抗，而能看到像你這樣（還有其他人）的技術人員有同樣的感覺，真的很棒。那麼，作為技術長與共同創辦人，你如何從這個角度看待法規，以及歐洲對待它的方式？

Alex Zenla: 是的，這真的很有趣。我絕對相信對影響社會的事物進行適當的法規管制，同時承認個人的自由——這是美國人很自然會說的話。我從根本上相信，網路安全的法規管制極其重要，因為網路安全正是那種「你必須強迫人們去做」的事情。我在很多草創的 startup 工作過。Edera 並不真正屬於這類完全不關心安全的麻煩製造者，因為我對它有更多控制權，但確實有很多 startup 完全不在乎安全。

我在物聯網領域親身經歷到的是，很多公司不管規模多小，在某些產業中可能會控制非常關鍵且重要的資料與系統。所以我認為這類法規管制是非常重要的。我也認為（這比較是歐洲法規的整體現象）這裡面有一個微妙的平衡。歐盟法規中有些我不同意，但也有相當多我同意的。我不同意的例子包括任何反加密相關的東西（雖然我認為沒有通過，但這是人們曾經提出、我不認為很好的例子）。

但要求公司去做它們本來就應該做的事，對人們來說是很自然會站出來支持的。而當你談論軟體主權時，我認為歐洲地區擁有自己的能力——A. 創立能正常運作並提供優質服務的 startup，B. 交付能為人民服務的軟體——這是非常重要的。這對每個國家都一樣。我認為美國同樣應該有能力創造能為人民服務的軟體。你只需要看看我們在美國的稅務系統，就知道這件事並沒有真正發生。所以我認為，當這些事情通過並真正保護與幫助社會時，在政治與社會層面上都是巨大的勝利。

Olimpiu Pop: 好的，所以要對你做的事負責、檢查它、建立護欄，並持續學習。但因為我們談到 AI……我會用這座橫跨大西洋的細薄橋樑來結束我們的討論，希望我們能建造更多，因為我們終究生活在同一片天空下。謝謝你，Alex。

Alex Zenla: 是的，非常感謝。我真的很享受這次對話。

Mentioned:

About the Author

Alex Zenla

你可以透過我們的 RSS Feed 持續追蹤 podcast，也可以在 SoundCloud、 Apple Podcasts、 Spotify、 Overcast 與 YouTube 收聽。 從本頁你也可以取得我們錄製的節目附註。這些附註都包含可點擊的連結，能直接帶你到音訊的對應段落。