開源協議的選擇其實是一個老生常談的話題，其主要集中在GPL、LGPL、Apache 2、BSD和MIT協議上。雖然有時候也可能會加上MPL或者WTFPL，但絲毫不影響討論的主旨：商業。

在網上隨便一搜「開源協議對比」之類的文句，返回的結果一般都是在討論「哪個協議對商業更友好」之類的東西；結果基本都是或明或暗地在說：「避免GPL」，「選擇MIT、BSD、Apache」。

這一結論在其所限定的框架內的確沒錯，但處處透着不對勁。而我實在是太過習慣於發現不對勁後嘗試思考（雖然並不總是有結論）。於是，對這裏的不對勁，稍微思考便發現——和許多其他透着不對勁的話題一樣——它的問題出在前提上：開源的目的就是爲了商業使用？

畢竟這是個資本主義的時代，商業主導了我們的生活，同時也規約人們的思維模式。商人們不斷宣傳「成功人士」以及金錢的神話，將創新和商業進行綁定，從而導致人們不自覺地認爲商業就是對的，「允許商業使用」是必須的前提。 在上世紀末與本世紀初的時代，這一切都還可以被經濟增長所掩蓋。但到了這兩年，到了川建國同志撕下美國一直以來的面具和面子，進行保守主義轉向，並且對個別國家（比如中國）進行經濟 …

前兩天matrix.org的服務器掛了一天，但和人交流還是要有的。然而和人的其他交流方式主要是微信，實在是太難受（不說別的，沒有桌面客戶端這點就足夠了）。於是糾結了幾分鐘以後，決定自己搭一個XMPP服務器 臨時用着 ，並給要聯繫的人也創建一個賬號。

由於之前就看過相關軟件，直接就選擇了 ejabberd 來做後端。準備使用其他服務端軟件的可以不用繼續看下去了。

在網上找到一個 算是挺不錯的教程 ，但其中有一些細節寫得不是很好，讓我配置時候走了一點彎路。做好基礎搭建之後我又做了一些別的事情，都是在網上零零散散的內容。所以起心自己整理一下，順便交代一下自己遇到的問題（萬一有人知道呢）。

故而，本文會作爲 教程 的補充/修改而使用，多數內容請直接參看原文。這次配置用到的服務器是 ubuntu ，源中有ejabberd等軟件。下文假定軟件已經安裝完畢。

嘛，衆所周知yaourt項目死掉了，於是出了各種奇奇怪怪的問題。之後也沒有一個佔據統治地位的 AUR Helper 存在，所以就只能比着 wiki上的簡單對比 自己隨便挑挑用。但我又想找個“最好”的，wiki的對比內容並不足夠，於是就逐漸試用各個AUR Helper，故而有此文。

本文嘗試總結自己試用這些AUR Helper的體會，並簡單進行比較。我試用的雖然肯定不是全部，但也爲數不少，故而此文多少可以方便一下其他人（如果有人看的話，咕）。

本文尚未施工完畢，並且作者很懶於是沒有任何計劃 推薦閱讀互聯(Federated)社交網絡

Mastodon

整體而言，就如其協議所設計的目的一樣，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系統爲：

• Mastodon
• GNU Social
• Pump.io
• Diaspora*
• Friendica
• HubZilla

既然叫互聯系統，每個互聯SNS之內各個不同實例/服務器間的用戶可以互操作。事實上，這些系統主要分爲兩種協議（以及HubZilla的Zot），每個協議內不同系統也可互操作。

下文將以協議爲主要線索串聯不同互聯SNS系統特點與分別、大概歷史、以及我個人對其看法。其中內容來自我對不同互聯SNS系統的瞭解（包括使用），以及背景閱讀（尤其是下文中將會經常引用其圖片的這篇文章）。

The Federation與The Fediverse

（來自https://medium.com …

Rust中可允許自定義的類型僅有兩種： 結構體 和 枚舉 。其中枚舉用於特定場景，而結構體被設計用來支持廣泛場景。

Rust的結構體不支持繼承，所以雖然struct和trait的組合看起來像但其實不是通常意義（C++/Java）上的面向對象實踐。不過trait支持默認方法，可以部分填補該差別。

struct Point {
    x: i32,
    y: i32,
}

struct Product<'a> {
    value: i32,
    price: i32,
    name: &'a String,
}

struct Point<T> {
    a: T,
    b: T,
}

Point { x: 0, y: 0 …

Rust的enum可以存儲數據，且模式匹配（match）正是設計用來匹配enum發揮作用的。

未完待續...

壽元 是Rust因對堆棧的抽象及保證內存安全而生的（ 所有權 外的）另一概念。

基本而言，壽元代表的是值的有效範圍。許多語言（如C++）中的 作用域 即是壽元的一個方面，但Rust中的壽元是一更通用/抽象且明確要求的概念。

Rust中，對壽元的需求存在於引用之上——只有引用的值纔會有壽元不確定的情況，而所 擁有 的值壽元永遠足夠。理論上來說，每一引用均包含壽元，且每個引用的壽元均會被檢查；但出於方便考慮，許多情況下壽元不需要顯式標明（見後文）。

{
    let r;

    {
        let x = 5;
        r = &x;
    }

    println!("r: {}", r);
}