開源協議的選擇其實是一個老生常談的話題,其主要集中在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的體會,並簡單進行比較。我試用的雖然肯定不是全部,但也爲數不少,故而此文多少可以方便一下其他人(如果有人看的話,咕)。

參與軟件及試用經歷

首先列舉一下我都試用了哪些軟件,然後描述我的試用感受……畢竟萬一這些軟件也死了的話,這篇文章的主體就沒什麼必要看了。

在選擇之前,我是抱着尋找一個「和yaourt一樣」的軟件的心態去的,於是找的主要都是pacman wrapper。下面先說明yaourt中哪些功能我很喜歡,然後介紹我對各個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系統爲:

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

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

The Federation與The Fediverse

(來自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中,對壽元的需求存在於引用之上——只有引用的值纔會有壽元不確定的情況,而所 擁有 的值壽元永遠足夠。理論上來說,每一引用均包含壽元,且每個引用的壽元均會被檢查;但出於方便考慮,許多情況下壽元不需要顯式標明(見後文)。

壽元與所有權

所有權 一節介紹過,值的所有權僅歸屬於一個變量,其他變量只能對其進行引用(或複製產生新值)。Rust規定值的壽元和其所歸屬變量的壽元是統一的。因而,如下代碼不合法:

{
    let r;

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

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

其原因就是 x 的值( 5 )的壽元和其所歸屬的變量 …