前兩天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的試用體會。說來也有趣,在使用過程中,我發現一些工具提供的一些新功能超出了我的預期,甚至有些連想都未曾想到 …

(本文是發佈在 前博客 的文章的鏡像。其中部分措辭可能會顯得彆扭。)

太長不看:博客遷移至 https://renyuneyun.gitlab.io/ ;wikiblog廢棄;在is-programmer的博客或許仍會同步更新技術相關文章。

博客在is-programmer安家很久了,稍微一算已有八年。回頭看看,這八年我經歷了許多事情,國際互聯網也經歷了很多事情。不說其他,單單是對隱私的要求便已經比八年前強了許多。

而is-programmer平臺已經很久沒人維護了( 百合仙子的這篇博文 有更多一點信息),其令人擔心的有兩點:安全性和可靠性。

安全性主要是指https。因爲網站登錄需要輸入密碼,沒有加密的話很容易就會被有心人竊取到。很不幸,這個平臺的登錄並沒有自己在應用層進行加密(忽然想到了之前自己本科學校WiFi登錄的密碼是用base64轉換了一遍權當加密),所以隨便一監聽就能拿到完整的用戶名和密碼。(因而我也將我在這裏的密碼改成了一個萬一真的被他人竊取到也影響不大的。)

而對可用性的擔心則是在於萬一服務器或DNS解析停止工作(比如沒有續費),那麼該如何將自己的數據導出並搬遷到其他地方則是一個很大的問題。雖然我每次發佈新的博文後都會wget -R一遍,但由於數據不是結構化存儲的,所以對於遷移到其他平臺的方便程度還是有所擔心的。(很神奇的是,這麼多年過去了,這個網站居然還在正常工作。)

所以,在考慮一段時間以後,決定要將博客遷移,改成靜態網站。其主要因素有二:

  1. 靜態網站託管服務有很多,而且再度遷移的成本很低;
  2. 數據是純文本 …

去年冬天便開始看到《流浪地球》電影的宣傳,宣傳圖和預告片看起來都還不錯,且有原著作者的背書。恰好我前些年(大四前後)看過小說,感覺如果能拍成電影且有宣傳片中的特效成就,那麼實在值得觀看。故而和同學相約大年初一下午去看,看完簡單提了一句“算是同人作品,但各方面都不錯”,但感覺還是想寫篇文章詳細描述一下個人觀感。

警告:本文涉及劇透,對此敏感者慎讀。

本文主要涉及電影和小說的對比,以及對電影部分設定的個人看法。

世界觀與故事

世界觀方面,電影完全沿用了小說的設定,背景定在想像中的(不是很久遠的)未來,太陽因爲不明原因加速老化。而從已有科學知識推導,太陽老化的結果是首先形成紅巨星,會導致太陽系大部被吞沒。於是地球人決定將地球改造爲“飛船”,推動地球前往最近的恆星系(比鄰星)。

這裏有一個“問題”:小說寫作時,比鄰星並沒有發現宜居行星。

電影中沒有交代一件事,就是地球上爭論過究竟是應該建造飛船逃離還是驅動地球逃離,所有人都明白建造飛船所消耗的能源更低。但小說中交代了經過一系列實驗(包括人造生態球),最終人們認定飛船的生態系統無法長久維持,最佳選擇就是驅動地球逃離。

小說主要展現的是整個事件中,各個時代的人的行爲,其時間跨度從發現問題一直到驅動地球逃離太陽系。由於我是幾年前讀的小說,對於具體結尾在哪已經不記得了 …

說來人已在愛丁堡待了兩年,但從來沒正式去其他地方玩過。索性趁着艾寧還未回國,去倫敦遊覽一番,也算了卻自己長期的一個心願。雖說冬天不太適合去(白晝太短),耶誕節前後尤其不適合去(許多景點關門),但最終仍是安排下了七天的行程且未空候任何一天,並且行程中發現一些有趣之事。

國王十字車站與金色飛賊

早上從愛丁堡坐火車到倫敦國王十字車站,順便圍觀了一下九又四分之三站臺(並不在站臺區)。站臺旁邊是一家哈利波特主題店,據說是電影中弗立維的演員開的。

九又四分之三的哈利波特店

店中有一店員在玩一個浮在空中的金色飛賊,球隨着她的動作來回飛動,但始終就在她周身。時不時還用手上下隔空約束着球做出一些花樣。

艾寧與其進行簡單詢問,但由於英語(艾寧英語不太好,店員歐洲不知哪的口音)問題,僅知道是鈕釦電池驅動,且需要在身上(耳朵上)戴個什麼東西;盒子上寫其中有很結實的什麼東西,比頭髮細比鋼鐵結實。思來想去,我覺得即使是作爲裝飾品也可以,最起碼對得起追《哈利·波特》。

買下,後來打開之後,我發現自己想多了。我高估了現在的技術實力,以爲那麼結實的那個東西是翅膀,純靠電動機可以維持浮空。結果發現其實是靠一根絲線,兩頭分別在人身上和球上,翅膀僅僅是爲了看。

大英博物館

大英博物館在週五會延長開放時間,故而理所當然地設計在到倫敦的第二天去(畢竟行程還是不太寬裕 …

本文尚未施工完畢,並且作者很懶於是沒有任何計劃 推薦閱讀互聯(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 …