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的體會,並簡單進行比較。我試用的雖然肯定不是全部,但也爲數不少,故而此文多少可以方便一下其他人(如果有人看的話,咕)。

參與軟件及試用經歷

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

在選擇之前,我是抱着尋找一個「和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相關材料中將lifetime翻譯爲「生命週期」,實在是令人瞠目結舌:「生命週期」是對lifecycle的翻譯,而這些人似乎完全沒有看到Rust中這個概念是lifetime

當然,完全存在另一種可能:他們看到了,仍然將其翻譯爲「生命週期」。這樣則是體現了當代中文翻譯中的一大問題:墨守成規和懶惰——固守已有的「詞」,寧可用錯也不願意另外造詞。當然這也是環境造就的,畢竟中文本以字爲基礎,但一則現在的教育讓人們習慣以詞(字組)爲基礎,二則現在通行的漢字數字化方案對新造漢字很不友好

「壽元」未必是最優的翻譯,但卻是我現下能想到的最信達雅的翻譯。如果有達成共識的不更差的翻譯,我個人很願意遷移。

Rust中,對壽元的需求存在於引用(借用)之上——只有引用的值纔會有值的壽元不同於變量壽元的情況 …