C/C++程序員應當對堆棧的區別很熟悉，畢竟這是和操作系統/低層直接相關的概念。如Java等不需要考慮堆棧的語言，其實質（從某種意義上可以認爲）是儘量使用堆而不用棧，但這樣不可避免地帶來了性能問題（計算和存儲雙方面的性能）。由於Rust目的是作爲一門系統編程語言，故而其不能選擇Java一類的方案；但同時，它也努力從語言中剝除堆棧的直接出現，以便降低概念的雜亂。
事實上，前文已經提過Rust對於剝除堆棧的努力之一：壽元。壽元的存在使得思考值是否有效時不需要同時考慮堆棧（操作系統特性）+作用域（語言特性）這兩組有所重疊的概念，而僅需要考慮作用域和壽元的組合（皆爲語言特性）。
在絕大多數時候，壽元和借用機制足以滿足對堆棧的抽象。但仍然有個別時候會有繞不過去的必須將值分配在堆上的需求，這時候可以使用Box<T>類型。
Box<T>告訴編譯器將值分配在堆上，然後返回這麼一個對象（類似於一個智能指針）。提取值時和引用一樣，使用*來獲取值。
（官方教程中有一個Box<T>的例子。）
開源協議的選擇其實是一個老生常談的話題，其主要集中在GPL、LGPL、Apache 2、BSD和MIT協議上。雖然有時候也可能會加上MPL或者WTFPL，但絲毫不影響討論的主旨：商業。
在網上隨便一搜「開源協議對比」之類的文句，返回的結果一般都是在討論「哪個協議對商業更友好」之類的東西；結果基本都是或明或暗地在說：「避免GPL」，「選擇MIT、BSD、Apache」。
這一結論在其所限定的框架內的確沒錯，但處處透着不對勁。而我實在是太過習慣於發現不對勁後嘗試思考（雖然並不總是有結論）。於是，對這裏的不對勁，稍微思考便發現——和許多其他透着不對勁的話題一樣——它的問題出在前提上：開源的目的就是爲了商業使用？
畢竟這是個資本主義的時代，商業主導了我們的生活，同時也規約人們的思維模式。商人們不斷宣傳「成功人士」以及金錢的神話，將創新和商業進行綁定，從而導致人們不自覺地認爲商業就是對的，「允許商業使用」是必須的前提。 在上世紀末與本世紀初的時代，這一切都還可以被經濟增長所掩蓋。但到了這兩年，到了川建國同志撕下美國一直以來的面具和面子，進行保守主義轉向，並且對個別國家（比如中國）進行經濟 …
前兩天matrix.org的服務器掛了一天，但和人交流還是要有的。然而和人的其他交流方式主要是微信，實在是太難受（不說別的，沒有桌面客戶端這點就足夠了）。於是糾結了幾分鐘以後，決定自己搭一個XMPP服務器 臨時用着 ，並給要聯繫的人也創建一個賬號。
由於之前就看過相關軟件，直接就選擇了 ejabberd 來做後端。準備使用其他服務端軟件的可以不用繼續看下去了。
在網上找到一個 算是挺不錯的教程 ，但其中有一些細節寫得不是很好，讓我配置時候走了一點彎路。做好基礎搭建之後我又做了一些別的事情，都是在網上零零散散的內容。所以起心自己整理一下，順便交代一下自己遇到的問題（萬一有人知道呢）。
故而，本文會作爲 教程 的補充/修改而使用，多數內容請直接參看原文。這次配置用到的服務器是 ubuntu ，源中有ejabberd等軟件。下文假定軟件已經安裝完畢。
我並不知道 ejabberd 是否可以配置爲不使用SSL加密（我參考的 教程 什麼都沒說直接就開始配置SSL），但出於安全考慮，能使用SSL還是用SSL比較好。
那既然要用SSL，證書就要準備好。像我這種臨時使用的，生成證書肯定是選擇Let's Encrypt，免費又快捷 …
嘛，衆所周知yaourt項目死掉了，於是出了各種奇奇怪怪的問題。之後也沒有一個佔據統治地位的 AUR Helper 存在，所以就只能比着 wiki上的簡單對比 自己隨便挑挑用。但我又想找個“最好”的，wiki的對比內容並不足夠，於是就逐漸試用各個AUR Helper，故而有此文。
本文嘗試總結自己試用這些AUR Helper的體會，並簡單進行比較。我試用的雖然肯定不是全部，但也爲數不少，故而此文多少可以方便一下其他人（如果有人看的話，咕）。
本文尚未施工完畢，並且作者很懶於是沒有任何計劃 推薦閱讀互聯(Federated)社交網絡
整體而言，就如其協議所設計的目的一樣，Mastodon是一個微博客服務，其功能也是微博客相關的東西：有長度限制的狀態發表（文本、圖片），發表狀態的可見性，轉發、評論、讚，關注，還有個人介紹頁。當然，類似於多數“現代”系統，狀態發表內容中可以標記預警（包括但不限於NSFW），默認顯示替換文字，展開後顯示原始文字。
發表內容有四檔可見性，除去正常的全部可見、僅關注者可見及僅被提及者（還有自己）可見外，另一個比較特別的是不顯示在公共時間軸上但人人可見。
默認UI糅合了一定的Material Design、一定的Flat Design。其顏色我比較喜歡，但部分細節可能還有改進空間。Mastodon默認擁有四個分欄，分管不同功能。我在其他服務中並未見到這種設計，算是一個不大不小的優秀創新點，畢竟可以同時處理回覆以及查看動態，有利於提高效率（但該設計對那些只會單線程思考的人來說並沒有什麼用，反而新鮮的設計會導致他們產生失控感進而憤怒）。
Mastodon支持OStatus和ActivityPub協議，因而可以和相當多數系統互聯 …
互聯社交網絡是除了互聯即時通信系統/IM以外的另一主要互聯系統類型。從來沒有接觸過這類系統的人可以類比互聯的效果爲：直接在新浪微博關注騰訊微博的人（而不需要去騰訊微博重新註冊賬號）。
之前在跟人介紹時，我發現有人會將互聯系統和SSO的效果搞混。事實上，兩者完全不同。仍然以上面在新浪微博S關注騰訊微博T爲例：SSO的本質仍然是在T上註冊了一個新賬戶，然後使用T上的賬戶去關注T上的另一個賬戶，而你的S賬戶上仍然是沒有對T上的關注；但互聯SNS的效果是你直接在S上關注T上的人，不需要在T上重新生成一個賬戶。如果仍然不理解，那請思考在你不登錄T時，即使你做過了“關注”，在你的S賬戶能否看到T上被你關注的人的消息。
幾大比較知名的互聯SNS系統爲：
既然叫互聯系統，每個互聯SNS之內各個不同實例/服務器間的用戶可以互操作。事實上，這些系統主要分爲兩種協議（以及HubZilla的Zot），每個協議內不同系統也可互操作。
下文將以協議爲主要線索串聯不同互聯SNS系統特點與分別、大概歷史、以及我個人對其看法。其中內容來自我對不同互聯SNS系統的瞭解（包括使用），以及背景閱讀（尤其是下文中將會經常引用其圖片的這篇文章）。
（來自https://medium.com …
Rust中可允許自定義的類型僅有兩種： 結構體 和 枚舉 。其中枚舉用於特定場景，而結構體被設計用來支持廣泛場景。
Rust的結構體不支持繼承，所以雖然struct和trait的組合看起來像但其實不是通常意義（C++/Java）上的面向對象實踐。不過trait支持默認方法，可以部分填補該差別。
基本的結構體聲明和C語言很類似：
struct Point { x: i32, y: i32, }
值得一提的是，Rust的結構體的可變性是一個整體，也就是說無法對某一個域單獨聲明可變性。
若結構體某成員是引用，其壽元需要在聲明結構體時一起聲明：
struct Product<'a> { value: i32, price: i32, name: &'a String, }
結構體也支持泛型：
struct Point<T> { a: T, b: T, }
構造一個結構體的語法也很直觀：
Point { x: 0, y: 0 …
壽元是Rust因對堆棧的抽象及保證內存安全而生的（所有權外的）另一概念。
基本而言，壽元代表的是值的有效範圍。許多語言（如C++）中的作用域即是壽元的一個方面，但Rust中的壽元是一更通用/抽象且明確要求的概念。
我見到不少中文Rust相關材料中將lifetime翻譯爲「生命週期」，實在是令人瞠目結舌：「生命週期」是對lifecycle的翻譯，而這些人似乎完全沒有看到Rust中這個概念是lifetime。
當然，完全存在另一種可能：他們看到了，仍然將其翻譯爲「生命週期」。這樣則是體現了當代中文翻譯中的一大問題：墨守成規和懶惰——固守已有的「詞」，寧可用錯也不願意另外造詞。當然這也是環境造就的，畢竟中文本以字爲基礎，但一則現在的教育讓人們習慣以詞（字組）爲基礎，二則現在通行的漢字數字化方案對新造漢字很不友好。
「壽元」未必是最優的翻譯，但卻是我現下能想到的最信達雅的翻譯。如果有達成共識的不更差的翻譯，我個人很願意遷移。
Rust中，對壽元的需求存在於引用（借用）之上——只有引用的值纔會有值的壽元不同於變量壽元的情況 …
