覆沉

使用ejabberd搭建XMPP服務器
by renyuneyun, post on Tue 16 April 2019

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

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

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

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

域名配置

我並不知道 ejabberd 是否可以配置爲不使用SSL加密(我參考的 教程 什麼都沒說直接就開始配置SSL),但出於安全考慮,能使用SSL還是用SSL比較好。

那既然要用SSL,證書就要準備好。像我這種臨時使用的,生成證書肯定是選擇Let's Encrypt,免費又快捷 …

Read in 1 mins
AUR輔助器試用記錄
by renyuneyun, post on Tue 09 April 2019

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

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

參與軟件及試用經歷

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

在選擇之前,我是抱着尋找一個「和yaourt一樣」的軟件的心態去的,於是找的主要都是pacman wrapper。下面先說明yaourt中哪些功能我很喜歡,然後介紹我對各個AUR Helper的試用體會。說來也有趣,在使用過程中,我發現一些工具提供的一些新功能超出了我的預期,甚至有些連想都未曾想到 …

部分互聯社交網絡測試感受
by renyuneyun, post on Fri 24 August 2018

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

Mastodon

整體而言,就如其協議所設計的目的一樣,Mastodon是一個微博客服務,其功能也是微博客相關的東西:有長度限制的狀態發表(文本、圖片),發表狀態的可見性,轉發、評論、讚,關注,還有個人介紹頁。當然,類似於多數“現代”系統,狀態發表內容中可以標記預警(包括但不限於NSFW),默認顯示替換文字,展開後顯示原始文字。

發表內容有四檔可見性,除去正常的全部可見、僅關注者可見及僅被提及者(還有自己)可見外,另一個比較特別的是不顯示在公共時間軸上但人人可見。

默認UI糅合了一定的Material Design、一定的Flat Design。其顏色我比較喜歡,但部分細節可能還有改進空間。Mastodon默認擁有四個分欄,分管不同功能。我在其他服務中並未見到這種設計,算是一個不大不小的優秀創新點,畢竟可以同時處理回覆以及查看動態,有利於提高效率(但該設計對那些只會單線程思考的人來說並沒有什麼用,反而新鮮的設計會導致他們產生失控感進而憤怒)。

Mastodon支持OStatus和ActivityPub協議,因而可以和相當多數系統互聯 …

互聯社交網絡
by renyuneyun, post on Fri 24 August 2018

互聯社交網絡是除了互聯即時通信系統/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學習筆記/結構體和方法
by renyuneyun, post on Tue 07 August 2018

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 …

Read in 1 mins
Rust學習筆記/壽元
by renyuneyun, post on Mon 06 August 2018

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

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

我見到不少中文Rust相關材料中將lifetime翻譯爲「生命週期」,實在是令人瞠目結舌:「生命週期」是對lifecycle的翻譯,而這些人似乎完全沒有看到Rust中這個概念是lifetime

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

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

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

Read in 1 mins
Rocket使用小結
by renyuneyun, post on Fri 03 August 2018

在今年Increase Rust's Reach中,我參與Rust新網站的i18n及l10n。其中新網站要基於 Rocket 構建,所以也就(跟着 官方教程 )學習了一下Rocket。 既然學了,就順便記錄一點心得和體會,以方便後來者。

Rocket是一個 web框架 。我個人對web編程(尤前端)並不太感興趣(主要是感到 web技術棧 太過麻煩/複雜),所以涉及不太多,之前也只用過Python那邊的Flask以及(一小段時間)Django以及Go自帶的http服務器,故而本文不怎麼會涉及和其他web框架的對比。

本文不打算成爲通常意義上的Rocket教程,而只是打算給有興趣者一個快速的(對rocket的)觀感。其中也會有一些個人的經驗教訓等。

Rocket概覽

類似我之前用過的框架,Rocket也將函數作爲不同的路由的處理器。Rocket在每個函數之前使用形如 #[get("/myroute")]屬性 作爲標記,之後在Rocket入口對象/結構體上對所需要的路由(函數)進行 mount 即可。

#[get("/")]
fn …

Rust學習筆記/所有權+引用+借用
by renyuneyun, post on Sun 29 July 2018

Rust的一大特色(甚至在官方教程中 被稱爲the most unique feature )就是其借用及所有權機制。這兩個機制由編譯器進行強制,並且可以極大限度地保證變量安全(並行安全)。

所有權

前面說過,同C/C++一樣,Rust中區分堆和棧(但不直接提及)。C/C++中語義上禁止從函數中返回指向局部變量的指針,是因爲當離開函數時,棧會被回收,所以局部變量也會被回收,導致指針失效。

在C/C++中,該禁止並非語法上的禁止。而在Rust中,所有權機制將該概念顯式表達,編譯器會拒絕編譯不滿足所有權機制的代碼。並且Rust設計者們希望通過所有權機制讓程序員不需要考慮堆棧,只需要考慮所有權即可(應當是出於一致性以及或許對未來自動優化的考量?)。

Rust中的 壽元 機制也涉及堆棧的區別。 兩者共同使得Rust不需要GC也可以保證內存安全。

所有權機制實際上就是三條規則:

  • 每個值具有唯一的所有者變量

  • 在同一時刻,所有者唯一

  • 所有者離開作用域時,值會被丟棄

    或者說(我個人的記法):每個值在每個時刻只有唯一的所有者,且有效性跟隨所有者。

所有權本身不涉及特殊語法,只要記住上面三條規則即可 …

Read in 1 mins