# 《The Purely Functional Software Deployment Model》重點整理
* 這篇 [Eelco Dolstra 在荷蘭烏特勒支大學的博士論文](https://nixos.org/~eelco/pubs/phd-thesis.pdf)是 Nix 套件管理工具的理論基石 ([Nix Community - Academia - NixOS Wiki](https://nixos.wiki/wiki/Nix_Community#Academia)) 。

## 大綱
> 論文第 1.6 節

本論文分為四部分：

### Part I
面臨的問題所屬領域、現況以及改進的動機。
- Chapter 1, *“Introduction”*，如題。
- Chapter 2, *“An Overview of Nix”*，會由使用者 (定義為：套件的包裝者和安裝者) 的觀點來介紹 Nix。

### Part II
Nix 背後的原則，以及嚴謹的語義定義。
- Chapter 3, *“Deployment as Memory Management”*，介紹了 Nix 背後的原則：用類似 (函數式？) 程式語言中記憶體管理的原則來解決軟體安裝、部署問題。
- Chapter 4, *“The Nix Expression Language”*，除了 Nix 語言——用來定義套件和系統的函數式程式語言——的語法和語義定義之外，也討論了一些 Nix 直譯器的有趣細節。
- Chapter 5, *“The Extensional Model”* 以及 Chapter 6, *“The Intensional Model”* 討論的是 Nix 的技術核心。解釋這兩章具體而言在講什麼的段落之後再補吧。

### Part III
討論 Nix 的不同應用。
- Chapter 7, *“Software Deployment”*，software deployment 就是 Nix 存在的理由啦！
- Chapter 8, *“Continuous Integration and Release Management”*，不只用來安裝套件，Nix 拿來建 CI 系統和用來發佈軟體也很有幫助。
- Chapter 9, *“Service Deployment”*，也可以用來部署服務：網站或一系列的機器之類的。
- Chapter 10, *“Build Management”*，還能拿來當 *Make* 用？

### Part IV
結論和未來發展，不解釋。（論文原文真的直接略過描述 Part IV 的內容。）

> 符號和字型的慣例寫在第 1.7 節。

總之，不同背景的讀者會對不同章節感興趣。所有人應該讀第二章 *“An Overview of Nix”*。如果只想使用 Nix 而沒有興趣修改 Nix 本體的話，可以跳過第二部的那些定義和理論，直接進到第三部那些最令使用者感興趣的應用討論。但不要跳過第七章 *“Software Deployment”*，因為所有第三部各章節討論的不同應用方式，都和第七章講述 software deployment 應用例時深入討論的 Nix expressions, builders, deployment mechanisms 以及 policies 有關。

Nix users and developers will also find the online manual useful.

# Part I
## 軟體部署的困境：環境相依性
> 論文第 1.1 節

軟體部署（或說安裝）看似個簡單的工作：把某軟體的程式碼複製到另一台電腦就好了；但實務上會遇到許多難題，作者將其歸為兩大類：
- **Environment issues**：如何確保系統具備執行某軟體所需要的環境，例如某路徑下要有某版本的函式庫、需要某個使用者帳號、設定檔要放在哪。
- **Manageability issues**：如何正確地管理一套軟體的生命週期，包含：安裝、移除、升級等。

## 現有工具
> 論文第 1.2 ~ 1.3 節

- **RPM & yum**：套件的 RPM spec 檔會告訴 RPM 該套件倚賴哪些套件，以及該如何編譯。
- 問題：環境沒有徹底隔離，套件開發者可能會忘了加上必要的 dependency，例如 `bash`，但大部分系統都內建 `bash` 所以很難發現有 bug。
- 問題：套件開發者可能會加了沒有必要的 dependency 而不自知。
- 問題：為了與其他套件的相容性，套件開發者通常不會寫死 dependency 的版本，而用例如 `>= 1.0` 的方式表示。但誰知道如後來推出的 `1.2.1` 就一定會向下相容到 `1.0` 呢？再說就算指定 `= 1.0` 也可能會壞掉，因為不同 Linux distributions 下，相同版號的套件也可能各有不同，例如施用了不同的 patch。
- 問題：升級套件時必須覆寫現有檔案，如果你一邊升級套件一邊執行正在升級的套件，就可能會出問題。
- 問題：RPM 會在安裝一個套件時幫你檢查系統中是否已有需要的 dependency，但不會自動幫你安裝他們。安裝大型套件，例如 X.org、KDE、GNOME 會需要手動層層安裝一大坨套件，相當麻煩 (*dependency hell*)。不過 `yum` 等工具解決了這個問題。事實上，這樣專業分工是一件好事。
- **FreeBSD Ports**：這種套件管理工具預設會用原始碼，而非編譯過的程式，來發佈套件。好處：更多彈性，使用者可以更改編譯期組態，增加或移除程式的功能、模組，為特定目的做一些最佳化等等。其代表 FreeBSD Ports Collection 就是用一些 Makefile 遞迴地定義如何下載套件的原始碼、打 patch、編譯並把執行檔搬移到系統的指定目錄下，透過傳遞參數給 make 指令或編輯那些 Makefile，使用者就能很靈活地客製化套件。
- 問題：耗時耗能，需要花時間編譯、需要更多磁碟空間下載套件原始碼和存放編譯期暫存檔，也更耗費路流量，還必須安裝各種編譯期而非執行期的套件，例如編譯器。雖然 FreeBSD 也有提供 *packages* 來解決這個問題，但 ports 與 packages 卻沒有整合得很好：例如當你為了客製化某套件而用 port 安裝它，如果沒有更動其 dependencies 的話，理論上其 dependencies 是可以用 packages 來直接安裝編譯好的程式，但實際上不行，一但用了 port，它底下的 dependencies 全都要用 port 慢慢編譯。
- 問題：同 RPM & yum，也有版本產生的各種問題。
> 那 Ubuntu、Debian 的 apt-get 呢？
- **Windows 和 Mac OS**：把 dependencies 包在 application 裡面一起發佈吧 (*monolithic deployment*)。除了少數肥大的 dependencies 之外，例如核心 GUI 程式庫、DirectX。實際作法可能是 static linking 或是附帶一包 dynamic libraries (e.g. `C:\Program Files\MyApp\Foo.DLL`) 給自己的程式集使用。
- 缺點：浪費磁碟空間，浪費下載 app 時的網路流量，有時候還會在執行期浪費 CPU 和 RAM (看看你系統裡的一堆 Electron app，每個都是獨立的 Chromium)。
- 缺點：程式開發者要手動把那些 dependencies 加到自己的程式裡，相當麻煩。
- 不過 macOS 的 *application bundles* 由終端使用者視角而言是個相當優美的設計，每包 `.app` 都沒有環境依賴 (例如登錄檔)，只要是在 macOS 下，移動到哪都能運作，可攜性高。
- **.NET**：Windows 因為沒有 macOS 的優美設計，和一些歷史因素，很多安裝程式都把共用 dependencies (DLL) 都塞在同一個系統目錄底下 (e.g., `C:\Windows\System`) 所以安裝、升級或移除某個程式，可能會動到那些共用的 DLL，以至於弄壞其他程式。~~好弱。~~.NET 平台就是為了解決這個問題而誕生，透過 *assemblies*，也就是一包可以全系統共用的程式資源，可以由發佈者用一個唯一的名字發佈，也可以倚賴其他 assembly。
- 不過這跟僅限於管理共用模組，而且是封閉給發佈和使用 .NET assemblies 的技術。
- **其他**：在講 *Zero Install system* 之類的東西之類的，我懶得寫了。

## 動機與貢獻
> 論文第 1.3 ~ 1.5 節

這篇論文的動機就是重新思考程式部署工具的本質，進而提出一套新的軟體部署模型來避免以上問題——即本論文將介紹的 *Nix deployment system*。

本篇論文主要貢獻的價值為描述作者研究出的 *purely functional deployment model*，也就是實作 Nix 背後的理論基礎。在這個模型之下，所有 binary component 都是由一組唯一的 build input 定義出來——這便使得任意 component instances (可以理解為同一套軟體，component class，的不同版本，component instances?) 得以並存。

對於那些在設計 (如何安裝？) 時並沒有將此一模型考量進去的軟體，作者也提出了能讓這套模型實際套用在那些軟體上的方法。

一些本論文的具體貢獻列於第 1.5 節。

⋯⋯那些具體貢獻讀起來有點像某產品的特點介紹。那樣未必是一個好的說法，因為只要給予足夠的靈活度，理論上我們可以在一個系統上加入任何功能。但其實那些功能都是源於一小套原則，其中最主要的基礎是純函數式的模型 (*the purely functional model*)。
（或解作：作為一篇學術論文，這樣羅列其提出之概念的功能特色似乎不太妙，會讓人對其理論基礎是否穩固、洗煉存疑，說不定又是一篇講了一堆這麼做可以這樣、然後這麼做再那麼做可以這樣又那樣，幾乎都在描述如何拿現有應用堆砌出某些特定功能組合，而沒什麼獨到觀點、大體上不會被其他文獻引用，以學術意義上沒什麼價值的論文。作為一套系統，如果基本模型夠精煉，要 hack 出任意功能也應該都要是可行的。所以要聲明一下，這裡列出的功能特色背後是有一套乾淨的理論模型的，大致上來說就是純函數式計算理論 (?) 的概念。）（← 藍色窗簾）

## An Overview of Nix

> TODO