All posts by Hiroshi Yui

Rust 程式做 static linking

2017-08-27GeneralHiroshi Yui

這篇主要是參考 [Advanced Linking: Static linking] 這節。

因為平時在工作時如果有處理到 Go 程式，沒有意外的話，編譯過程會產出一個 static linked binary，這對 deploy 流程很方便，所以我想在 Rust 底下也比照辦理。

截自目前，在 Linux 底下，Rust 如果要這樣做，libc 標準函式庫要用 musl，而不是最常見的 glibc，所以要先安裝 musl，在 Arch Linux 底下就是執行：

sudo pacman -S musl

多裝 musl 不會有與 glibc 打架的情況，所以可以大膽放心裝下去。（又或者是我還沒踩到兩者打架的雷？）

然後利用 rustup 工具，新增一組支援 x86_64-unknown-linux-musl 這個 build target 的 Rust toolchain：

rustup target add x86_64-unknown-linux-musl

這樣基本環境其實就搞定了，當然，在建置時，除非是將 x86_64-unknown-linux-musl 設為預設 toolchain，不然都需要特別指定使用這個 target：

cargo build --target=x86_64-unknown-linux-musl

可以用 ldd 與 file 指令觀察、對照一下這組 target 的 binary 與預設的 target 有什麼不同。

實務上，我發現如果把這個 build 出來的 binary 丟進 Docker 裡，用 alpine:3.6 這個 base image 來做個無腦執行容器映像，則會發生 ld.so, ld-linux.so 路徑、檔名不符的問題，換用 debian:stable-slim 就沒這阿雜事了。

考慮到目前頻寬足夠充裕的現實，一個約 4MB 的 alpine:3.6 與一個約 55MB 的 debian:stable-slim，疊上一個約 20MB 的 static linked binary，在 push 效率上，其實對人來說，是感覺不到會覺得「煩」、「痛」這樣的差異的，我自己真的不太喜歡使用 Alpine 這種為了精簡而常常埋雷的 base image 來給自己找麻煩，不過這與本篇沒有直接相關，只是我的一點小抱怨罷了。

在 Ansible 新開機器時，運用 add_host 於執行時期立即加進 in-memory inventory 的方法

2017-08-17GeneralHiroshi Yui

最近在評估 GCP，不能免俗地要嘗試使用 Ansible 自動開 GCE 機器、設定組態，遇到一個之前在 AWS EC2 上印象中沒有遇過的問題。

一般來說，我們會先在 localhost 上用 gce module 透過 GCP API 發出建立機器的操作命令，大概會像這樣（註：這邊大量借用了 Ansible 這頁的範例）：

- name: Create instance(s)
  hosts: localhost
  gather_facts: no
  connection: local

  vars:
    machine_type: n1-standard-1
    image: 'ubuntu-1604-xenial-v20170811'
    service_account_email: unique-id@developer.gserviceaccount.com
    credentials_file: /path/to/project.json
    project_id: project-id

  tasks:
    - name: Launch instances
      gce:
          instance_names: running_man
          machine_type: "{{ machine_type }}"
          image: "{{ image }}"
          service_account_email: "{{ service_account_email }}"
          credentials_file: "{{ credentials_file }}"
          project_id: "{{ project_id }}"
          tags: consumer_server

然後在機器建起來之後，我直覺會利用 Dynamic Inventory 透過 tag 之類的資源定位方式，把開好的機器找出來：

- name: Provision instance(s)
  hosts: tag_consumer_server
  # 以下省略

但是可能是 GCE dynamic inventory script (gce.py) 預設的 cache 時效問題，我在這步常常需要「踩發」好幾次才能成功得出機器列表。

我找了一下網上的討論，才發現我沒有看到 Ansible 的 GCE 範例文件裡有個眉眉角角的地方，叫做 add_host：

---
- name: Create instance(s)
# 中略
# ...
  tasks:
    - name: Launch instances
      gce:
          instance_names: dev
          machine_type: "{{ machine_type }}"
          image: "{{ image }}"
          service_account_email: "{{ service_account_email }}"
          credentials_file: "{{ credentials_file }}"
          project_id: "{{ project_id }}"
          tags: webserver
      register: gce

    - name: Wait for SSH to come up
      wait_for: host={{ item.public_ip }} port=22 delay=10 timeout=60
      with_items: "{{ gce.instance_data }}"

    - name: Add host to groupname
      add_host: hostname={{ item.public_ip }} groupname=new_instances
      with_items: "{{ gce.instance_data }}"

當我們處理好機器開設時，可以設一個 register，讓接下來的 tasks 去捕捉這個 task 的處理結果。

在 ‘Wait for SSH to come up’ 我們就先使用 wait_for module 先偵測 SSH port (22) 是否起來了，來判斷這台機器是否「大致上可用」（因為 Ansible 主要原理還是靠 SSH 去遠端下一些控制命令）。如果是，我們接下來在 ‘Add host to groupname’ 就用 add_host 把這台跑起來的機器加進 in-memory inventory 當中一個叫做 new_instances 的 group，於是接下來我們就可以直接利用這份 inventory 列表來對這台（些）機器進行各種組態設定：

- name: Manage new instances
  hosts: new_instances
  connection: ssh
  become: True
  tasks:
    - name: Install essential packages
      apt:
        name: "{{ item }}"
        state: present
      with_items:
        - 'redis-tools'
        - 'ruby2.3'

這個 add_host 看起來不管用在哪家雲端服務業者都可以，因此還可以省去多 call 一次 API 重抓 inventory 的工。又學到了一課。

我的蕃茄鐘挑選之路

2017-08-17GeneralHiroshi Yui

先備知識

我的困難

無論在家工作或在辦公室工作，我都希望不要打擾到別人。
我希望這個蕃茄鐘也不要干擾到我，帶給我心理緊張感，保持「呼之即來揮之即去」這種程度的存在感就好。

我試過的各種蕃茄鐘（計時器）

Mac 上的 Be Focused Pro，因為那個紅色圖示以及不斷跳動的時間（這個可以切換）太容易讓我往頂端功能列瞧，反而讓我很緊張，於是用了幾次就不想用了。跟作者寫信反映過，跟我打馬虎眼，於是我也放棄了。
幾個 Android 上的蕃茄鐘 Apps，因為是另一個計時裝置，所以沒有被緊迫盯人的感覺，但是也常因為我蓋著手機套上蓋、或戴著防噪耳機而忽視了提示，這算非戰之罪，不是這些 Apps 的問題。
Apps 配合 ZenWatch，因為 ZenWatch 經常不明所以與手機之間的斷線（我可是有保持手機在它能收到藍牙訊號的安全距離內，也知道 Android Wear 那個「下次嘗試重連時間是當前的兩倍」，有做過功課，拜託各位路人工程師大大們就不要來戰我了，我兩邊都重開機也沒改善啊），加上最好的待機狀況下也只能撐兩天，各種麻煩，於是我也束之高閣了。我也跑過皇家俱樂部送修，但是維修跟我打「能開機、能動啊、沒問題」的馬虎眼，沒時間跟他瞎耗，算了。
生活五金行買的那種餐廚常見的計時器，除了音量因為適應原本的應用場景所以爆大聲的以外，沒有什麼缺點，單色液晶的數字顯示就算跳啊跳的也不會讓我覺得有壓迫感。但是就是怕吵到人。是說如果我稍微改個電路，可能這款對我來說就完美了。

COSCUP 2017 雜記

2017-08-07GeneralHiroshi Yui

關於我講的場次

前面花太多時間交待「我為何選擇 Arch Linux？」到了要講 ArchTW 社群、以及我的「期中報告」時，只剩三分鐘，超慘，很失敗，很對不起來聽我這場次的聽眾。如果您是在場聽眾，希望您有看到我在此表達的歉意。
事前有沒有排練？有！而且是大約 14 分鐘多講完。但是臨場表現太緊張，所以想試著在笑點上緩和一下心情，結果過猶不及，就出包了。

關於我講的公司短講

其實是把之前投閃電秀不成的題目拿來這裡講，也算是一償夙願，所以還是蠻感謝同事 Aaron 的推坑，以及聯絡人 Vivian 願意讓我來講這個題目。
電子節目表連接了「觀眾」與「電視網」→「頻道」→「節目」，我這個電視兒童阿叔至今還是覺得這東西的資訊加值很值得做。
當然，另外那個「窮人的電波時計」也很值得做。有空的話其實還蠻想拿一張 RPi 來做個 PoC。

關於場地

想找講者報到櫃台，連續碰壁兩次，到後來才看到櫃台終於貼上了指示牌。我絕對明白、也很感謝志工們的付出，不過還是希望這點小地方，來年可以提早到位。
今年在台大社科院，不像中研院有交誼廳（？），沒有一處可以歇腳、方便社群朋友坐下來聊天的地方，也讓我不像以往在中研院舉辦時會盡量撐完全場（況且之前我就住在中研院附近），而是兩天各來個大約半天就想走人了（所以因此錯過了 BoF 的求婚名場面…）。空間規劃上，我個人覺得這是稍微有點可惜的地方。

關於議程

今年讓社群自己安排議程，我還蠻喜歡這樣的設計。不過就像有人反映沒有 Swift 議程，我當初想投 Elixir 的議程也是遇到「找不到適合的社群可投」的尷尬狀況，建議或許來年可以保留一「misc 軌」或是開放 unconference。

最後

再次跟來聽我這場次的聽眾朋友道歉。
感謝各位志工朋友，辛苦了！

[COSCUP 2017] Arch Linux 臺灣社群：一個冷門社群的營造經驗

2017-08-06GeneralHiroshi Yui

（這篇文是我投稿 COSCUP 2017 開放社群經營議程的講稿。）

各位社群朋友大家好，我今天要來分享的是 Arch Linux 臺灣社群的營造經驗。我這份投影片採用 CC BY-SA 授權釋出，在我上台之前，應該已經放在我的 SlideShare 底下，歡迎自行取用，之後應該也會交給 COSCUP 大會放在官網。同時因為我這個人講話真憨慢，所以已經預先打了一份講稿，放在我的部落格，如果有朋友跟我一樣，週末大清早坐車上來，精神不佳想休息一下，或是覺得我口條結結巴巴，聽起來覺得不是很舒服，都可以直接或會後去看文字好讀版，謝謝。

首先介紹我自己，我是 Hiroshi，雖然這個渾名的東洋味頗重，不過我是不折不扣的正港臺灣人。這是我的 Twitter，還有我的 Mastodon，以及 email。我目前在 KKTIX 服務，想必絕大部分在場朋友要來 COSCUP 前都曾經來推過我們家的售票亭搶票。同時我目前也是碼天狗週刊的策展人之一，如果您還沒有 follow 這份技術刊物，現在推薦給您。當然，我也是 archlinux.tw 這個網站的小雜工，以及一個 Arch Linux 的愛用者。

說到我是一個 Arch Linux 的愛用者，我就會不由得想起咱們 jserv 夶發過的這則 tweet，嗯，好，對，我好窮。

如果一開場這個哏有逗到大家，那我今天硬著頭皮上台來就算成功一半了。我實在是很怕站在人群前講話，甚至是跟人一對一對話。

實不相瞞，我在公司還是拿 Mac 做主要工作環境，不過呢，我自己在家裡、下班後、上班前都還是使用 Linux，呃，我這邊為了順口，就不冠上 GNU(/Linux) 這個 prefix 了，大家知道就好。不過請大家務必明白，我是很尊重 FSF 以及 RMS 教主的，我也是個 GPL（不論哪個版本的）腦粉。總之，我覺得 Linux 在某些地方還是用得比其他作業系統、桌面環境順手，可以玩的東西也比較多、比較有趣，所以我多年來就一直是 Linux 用戶，不僅是在伺服器端，在桌面端也是。

之前翻到這張圖的時候，我本來很不服氣的，怎麼可以有這種刻板印象！？但是後來看到我團結在一起的肚子，嗯，好，中肯。（開玩笑的）

之所以把這張圖翻出來，其實是想舉例說 Linux 發行版的多樣性，大家可以去 distrowatch.com 這個網站上面看，林林總總，目不暇給啊！有些 Linux 發行版會針對某一特定用途而製作，所以玩不同的 Linux 發行版，或者說，不同於主流的那幾套發行版，感受一下不同的發行版設計文化，本身就是一件很有趣的事。

我大概是從 RedHat 4.x 那個時代，差不多是 1996 年開始用 Linux，不過那個時代雖然 Linux 也有桌面環境可以用，但是中文、桌面應用軟體、多媒體等功能需求都還是頗陽春的，裝起來頂多就是有一種「啊！我的電腦也變成一台 UNIX(-clone) 工作站了！好棒棒！」的虛榮感，但是遇到要做一些桌面應用的「正事」，像是文書處理，還是不得不切回 Windows。但是如果要架 BBS 這類伺服器，Linux 還真的頗好用。

在我用 Arch Linux 之前，我跟很多人一樣，也是 Ubuntu 的愛用者。在這之前我還用過一些把桌面環境做得很不錯、有的甚至中文輸入、輸出做得也很棒的發行版，很奇怪的是，它們正好都是 RPM 系的，所以那時我的刻板印象就是「Debian DPKG 系在伺服器端好用，RedHat RPM 系在桌面端好用」一直要到 Ubuntu 橫空出世，才打破我這種陳見。

那為什麼我當初會從 Ubuntu 跳到 Arch Linux 呢？其實這心路歷程總的來說是感性大於理性的結果，再講白一點，就是「森七七」（當代網路用語，生氣氣諧音），因為那時接連踩到好幾次 Ubuntu 升級新版的地雷，一不做二不休，我就是想換個發行版來用。

不過我在這裡特別要講的是，Open Source 的文化應當是要鼓勵融入、參與社群，而我當時遇到這些 Ubuntu 地雷的時候，只是自己在那邊生悶氣，事後想想，我也只是把它當成一般私有軟體模式的 OS 在用，沒有更積極地反饋，也沒有盡可能在新版還在 Beta 階段時就先試用、提前找出問題，我自己覺得這樣不是很好，也知道沒有人會喜歡在產品出正式版時還有明顯、惱人的臭蟲。只是我那時候年幼無知，沒有想那麼多，就是想換個發行版、換個心情。

那，所以我就到我剛剛提過的 DistroWatch 網站上面物色我中意的發行版。這次我想要一個可以 rolling upgrade 的發行版，也就是說，類似 Debian testing 或 unstable，讓我隨時都有「最新」的軟體版本可用。結果我找啊找的，就發現了 Arch Linux。

如果這邊有 Gentoo 的用戶朋友在場，可能就想對我喊話，要追新、要自訂，可以來用 Gentoo，事實上我之前也曾裝過 Gentoo，不過 Gentoo 裡萬事萬物都要編譯，我覺得這實在太苦了，而 Arch 處於一個我頗滿意的平衡點。它提供了預先編譯好的元件，所以安裝過程比較不用那麼刻苦，同時它的元件打包原則是，除非萬不得已，否則不會自己另外打 patch，優先遵照 upstream 預設的配置來編譯打包，但是如果萬一我們在編譯階段需要有什麼地方需要自訂，還是可以透過 ABS 把原始的打包設定檔，我們稱為 PKGBUILD，把它下載下來，自己再修改，我之前為了改 Linux kernel 做點小東西，就是這樣做的。Arch 這種預設不幫您加料，但還是提供您自己加料的彈性空間，而且做起來不會覺得綁手綁腳，是我很喜歡的一點。

再提到 Arch 的套件管理工具，這個 pacman，對，就是 Namco 的經典遊戲「小精靈」同名（對岸好像叫做「吃豆人」），是我們在 Arch 底下的 package manager，我平常就是只會用到這幾個指令，這邊要特別一提的是，我實在很喜歡 -Rsuc 這組指令，它會完整地幫我移除相依的套件，所以我的 Arch 系統很少會有孤兒 (orphan) 或冗餘的套件在裡面，系統因此就可以很乾淨。

再說到 AUR 這個東西，簡單講，AUR 就是還沒有收錄進去官方套件庫，但開放大家都可以上傳自己打包的套件上去的一個「準．套件庫」，那有人可能就會懷疑放在這裡的東西品質如何，沒錯，這裡是您自己上傳上去，如果品質夠好，就會有人投票支持您這個套件收錄進官方套件庫，像是我之前曾經維護過一陣子 ibus-chewing，對，就是 ibus 輸入法框架底下的新酷音輸入法，有一天就在我措手不及時被收到 [community] 套件庫裡。反之，如果品質還是有點問題，時好時壞的，或是授權上可能無法收錄進官方套件庫，它可能就會一直停在 AUR 裡。特別要講的是，官方套件庫裡，也常發生某個套件因為年久失修，還是其他各種問題，導致它被踢出去，這時它就可能回到 AUR 來。

我很推薦大家自己打包套件放到 AUR 去，一來是因為 PKGBUILD 的寫法不會很難，二來可以幫助您喜歡的軟體又能多給一個發行版的社群使用。

說了這麼多，大家可能會想，Arch 這個發行版無論我在台上怎麼宣傳，但是名氣啦普及度啦還是遜於某些「大牌子」，如果我跳過來用，那有問題求助無門不就好笑了？其實一開始我也是這麼想，但是我隨即發現 Arch 官方的 BBS 論壇，還有他們的 Wiki，社群在上面的活動都相當踴躍，很多時候我遇到問題，搜尋一下 BBS，早就已經有人遇到，甚至已經有解法了。再來說到 ArchWiki，它的豐富程度，嗯，就像這張圖講的，很多 Archer 都會勤於編寫 Wiki，所以成為一個很不錯的參考資訊來源。

所以說，如果考慮「出問題，找誰求助」這點，Arch Linux 在這方面其實是不用擔心的。

再說到 Arch Linux 最受到揶揄的一點，就是它的安裝上不像一些發行版那麼 user friendly，我覺得最誇張的一次是，Twitch 這個直播平台，平常大家對它的印象是電玩玩家直播打電動的實況，不過之前竟然出現這個接力直播安裝 Arch Linux 的活動！哇咧，是有沒有那麼誇張？

其實我當初安裝 Arch 的時候，就是照著 Installation guide 做而已，沒有遇到什麼困難。講到這邊或許也有人想問說，我安裝 U***tu, F***ra 有圖形介面輔助，好用又簡單，為什麼我就非得用你 Arch 這種安裝方法來折騰自己？我覺得是這樣，Arch 去除了那一層輔助介面，讓您用一種比較原始，但是您可以知道說一套 OS 的安裝過程裡要做哪些事，做了這些事就可以堆疊出一個屬於自己的操作環境，從中學到這點，雖然過程有點麻煩、有點痛，不過我想還是值得的。

我剛剛提到 Twitch 那個活動，感想是「哇咧！是有沒有那麼誇張？」其實我後來想想，會說出這種話，其實代表了我並沒有從一個純然 Linux 安裝新手的角度去看事情，這一點其實很重要，我後面會再提到說為什麼重要。

因為 Arch Linux 這種「裝一次，用很久」的 rolling upgrade 特性，所以我很放心，有人可能會想說，我用 Ubuntu LTS 版也可以「裝一次，用很久」，嗯，我電腦裡這套 Arch 已經裝了七年，而且裡頭的軟體幾乎都是最新的。

這邊跟大家講一下我鬧的笑話是什麼。

到這邊做個總結，就是因為我用 Arch 用得很開心，所以我就希望更多人知道 Arch 的好，所以我在 COSCUP 2012 曾經揪了一團 Arch BoF，然後再去註冊了 archlinux.tw 這個域名，與 Carl Su, Yushin Huang 等幾位社群朋友合作，架起這個網站。

這件事傳開之後，linux.org.tw 的幾位大大，比如說 WM Chang 就來幫忙，結果就促成了原有的 arch.linux.org.tw 指向 archlinux.tw，各位現在會發現這兩個域名其實都指向同一個站台。在這邊要佔一點篇幅感謝 Linux Taiwan 幾位大大們的幫忙。

我一開始以為有了這個網站，就會吸引很多很多很多人來，心想再怎麼不濟，至少也有來參加 COSCUP BoF 人數的「基本盤」，但是實際上是這樣子的。

這讓我想起了我在 COSCUP 2009 時曾經聽過 Franklin 馬哥在台上講過這麼一段話。老實說曾經有好一陣子我覺得很沮喪，也一直在想「我是哪裡做錯了，或是哪邊做得還不夠？」這個問題。但是後來再仔細想過，我覺得事情並不能光看表面數字，接下來我想講的就是我今天投稿這個題目，在台上想跟大家分享的一些心得，或者說，反省。

首先就是，我說 Arch Linux 臺灣社群「冷門」，但是要怎麼界定「冷門」這件事？人少就是冷門嗎？我們中華民國國軍的莒光園地節目常常出現「量少、質精、戰力強」這句話，雖然我到現在都還覺得這句話蠻好笑的，不過如果今天一個開源社群人少，但是做的貢獻影響力很大，那麼這個社群就算「冷門」又怎樣？

再來就是說，我自顧自的、一廂情願的開了一個網站，叫它做「Arch Linux 臺灣社群」，但是並不見得使用 Arch Linux 的臺灣朋友都想「被代表」、都想「參與」這個「臺灣社群」，有網站，不見得就有社群。

這些不想「被代表」、不想「參與」這個「臺灣社群」的 Archer，可能會去寫 ArchWiki 默默造福大眾，可能會去 ArchBBS 直接跟世界各地的 Archer 互動，他們就算不是「臺灣社群」的 Archer，也是在為 Arch Linux 貢獻。如果「Arch Linux 臺灣社群」沒有他們想要揮灑的空間，那也無損於整個 Arch Linux 社群。

所以，我後來會問自己這幾個問題。

於是我會發現說，有很多地方，我施力點根本就放錯了。一個在地社群，要有別於 global 的社群，其實應該回歸「在地」這個重點。

所以我會希望說，「Arch Linux 臺灣社群」未來可以多辦 Installfest，「Arch Linux 臺灣社群」這個「網站」也要重新定位成「臺灣 Archers 的 Hub」，透過這裡，可以找到適合的人協助您處理 Arch 的疑難雜症。

而且，我自己會希望達成這樣的目標，就是您不管是透過哪位社群朋友幫您裝好了 Arch，您也會跟我一樣覺得 Arch 好用，然後您就去用 Arch 做一些有趣、有生產力的事情，再讓別人發現 Arch 的好。

我自己以前也遇過說開課教人安裝 Linux，不過幾乎九成九的人就是「嗯，好」然後從隔天或是從當天晚上開始就沒再繼續用下去了。這樣子的 installfest 就算辦了，我覺得也無濟於事，對社群沒有什麼更積極面的幫助，真正有幫助的是每個 Linux user 都可以讓周遭的親朋好友感受到「你用 Linux 不是因為沒錢，而是因為它很有趣、更有趣」。

雖然我前面說「Arch Linux 臺灣社群」的網站其實重要性似乎不比辦一些在地的活動要來得高，不過作為一個「招牌」，我覺得經常更新，還是很重要的。

其中，官方公告翻譯，是我所能想到門檻最小、負擔最小、效益極高的內容貢獻，為什麼呢？

就是為了避開地雷！

我之所以這麼多年來能夠趨吉避凶，很多時候就是因為官方公告已經提前跟我講「升級這個軟體會有什麼變動需要處理」，照著做，很難有事。我有時候看到有些 Archer 朋友埋怨說他 pacman -Syu 之後就炸了，說 Arch 很多雷，這點我想為 Arch 說一句公道話，很多時候官方已經提前告訴您前方多少公尺處有雷了，請訂閱官方公告，不要只是盲目更新，甚至有人還會在更新套件時遇到卡關，就直接加上 — force 強制通關，千萬千萬不要這樣不假思索，還是先回頭看一下官方公告保平安。

所以，如果各位 Archer 可以幫忙翻譯官方公告，其實就可以幫助一些英文閱讀上可能比較不那麼流利的朋友，減少他們踩雷的機會。

那，就我之前收到的反饋意見，有些社群朋友其實不喜歡為了要貢獻內容給「Arch Linux 臺灣社群」的網站，還要特別裝 Ruby 等一些有的沒的，所以我們後來就提供了 Docker 配置方法，您用 docker 預覽過內容沒問題，commit，送出 PR 之後，其實就可以移除 Docker container 與 images 了，不會留下一堆您用不到、佔空間的東西。這個點子其實最早是 Carl Su 提的，這邊要給他 credit。

再提一個我們為了改進翻譯官方公告的流程所作的工具，Fiidhub，這個工具其實做的事情很簡單，就是每天定時去撈官方公告的 RSS feeds，如果有更新，就去 GitHub 上開票，開一個 branch，附上需要翻譯的 markdown 檔，寫明步驟，然後您就可以自由認領，下去翻譯過後，再送上來。

希望上面提到的這兩種改善內容貢獻流程的工具，也能夠給其他社群朋友一點參考。

最後一個小節，我想說的是，雖然我前面一直在講「這個社群沒有人」，但是實際上，並不是沒有人。

一開始想講的事其實沒有發生在 Arch 臺灣社群，而是我最近在規劃日本自由行的時候，我去某個背包客的網站上找資料，然後發現會有些「資深站友」會責備發問者「沒做功課」，這個問題其實過去也在一些 Linux 討論區上出現，我自己以前也會覺得說「問這種之前已經有人問過的問題」太不應該、浪費資源之類的，但是若我們設想自己是某個領域的新手、麻瓜，我們不曉得找到解決問題資訊的「關鍵字」是什麼，只好硬著頭皮發問，這時候如果得到這種責備，其實臉皮比較薄的人就被嚇跑了，這對社群來說並不是一件好事。而且如果新手沒有做過一定程度的功課，他也不會知道會來您這個比較專業的論壇發問，可能就會跑去奇摩知識+啦、LINE Q 啦之類的。

我們在 Gitter 上面有開設一個聊天室，一開始有好一陣子都沒有新朋友發言，直到最近才有新朋友上來問問題，我覺得這現象很有趣，就是新朋友會觀望說這個社群是不是高不可攀，如果實際上這個結界並沒有那麼冷冰冰，一個新人就會吸引第二個新人，第二個新人就會吸引第三個新人，比如像這樣。

所以我會建議像我們這類新成立、小貓兩三隻的社群，就算是閒聊灌水也好，在您們的交流管道上試著讓討論氣氛不要讓人覺得無法親近。

再提到說，有些想要貢獻內容的朋友，一樣，會被「好像夶都把事情做完了，自己使不上力」的氣氛弄得不敢喊聲說要幫忙，這其實就是我那時候會想要開發 Fiidhub 的緣故，在這之前我都是人工作業，自己檢查有沒有新的官方公告，看沒有人翻譯，就自己翻譯做掉了，現在透過這個程式開票，想要貢獻內容的朋友自然有跡可循、也有機可趁，知道有什麼公告翻譯是需要人幫忙的。

最後要說的是，很多我知道的臺灣 Archer 大大級長輩其實都有默默在關注這個社群，比如說，我之前才喊了一下某 mirror 好像 out of sync 了，xatier 長輩就冒出來幫我聯絡負責的另外一位大大，很感謝這些大大的幫忙。

總結，其實我覺得一個活躍的、或者說，活著的社群的運作永遠都不該有「總結」，所以我在這裡會把我今天講的當成一份「期中報告」。首先就是，網站只是招牌，不是主體，人才是社群的主體，但是有個經常擦亮的招牌還是很重要。再來就是，社群活動辦得再怎麼有聲有色，活動結束後，這個軟體有人用、用得好，才是維持它這個社群冷門或熱門的關鍵。

今天透過我在這裡的分享，我希望跟我一樣有類似境遇的其他新成立的社群朋友，可以不要重蹈我的覆轍，不要被數字迷惑，而是要想清楚您的社群定位，並且營造一個容易讓人親近、走進來的環境。

Arch 臺灣社群很缺人幫忙翻譯官方公告，也持續徵求大家登錄在地夥伴名錄，大家的螢幕若還塞得下一個 tab 的話，歡迎大家掛在我們的 Gitter 上，還有很歡迎大家辦 installfest 指導新手安裝 Arch。最後，最重要的一點，不管您用哪套發行版，不管您有錢沒錢，請繼續用 Linux 做些有趣的事。

謝謝！

hiroshi yui

個人雜記