Java 學習之路
TechTalk 專訪 Episode 28 逐字稿 - Interview with PCMan about LXQt
|
TechTalk 專訪 Episode 27 逐字稿 – Linux Container (LXC) << 前情 HC – Hao Cheng MY：大家好，歡迎收聽 Techtalk@TW 第二十八集，今天是 2014/09/30 星期二，我是Mao Yang。 HC：我是Hao Cheng。今天很高興能夠邀請到大家還蠻熟悉的 PCman 來接受我們的訪問，很多人都是用他寫的 PCMan 來上 PTT，不過今天要跟他聊的是另外一個 Linux 桌面專案叫做LXQT。PCMan你好。 PC：你好。 HC：可以請你先跟聽眾做個簡單自我介紹嗎？雖然應該蠻多人都認識你。 PC：好，我是 PCMan，不過其實我自己現在也很少上 BBS。 HC：PTT 上的人還是超多的。 PC：但是當年 BBS 蓬勃發展的時候有很多站，現在幾乎都已經不見了。 HC：現在基本上剩PTT。 PC：對，那我自己本來都是寫Windows的程式，可是從 2004 年之後，就換用Linux，所以後來就轉到開發 Linux 的程式。 HC：我現在就是用 PCmanX GTK 這個版本。 PC：不過那個現在不是我在維護。 HC：好像是 jserv 他們接手？ PC：對，和 fourdollars。 HC：上一集才跟 fourdollars 聊過。 PC：對，現在是 fourdollars在維護。我目前是自由軟體開發者，就有參加各種自由軟體專案，不過我自己主要做的是 LXDE 桌面環境，最近移植到 Qt，所以就變成 LXQt，另外我還有參加新酷音輸入法的 Windows 軟體開發，和參與開發一些 Firefox 的 plugin。 HC：可是你不是沒有用 Windows 了嗎？所以新酷音輸入法還是有在開發？ PC：對，因為偶爾還是會用到 Windows。 HC：ok，了解。 PC：只是速度比較慢。 MY：其實我剛剛有看一下 PCMan 的 Wiki，我發現 PCMan 好像忽略跟大家介紹你白天的工作。 PC：我本來其實是念醫學系的，所以並不是科班出生的。 HC：應該寫得比很多科班都還要更多。 PC：對，自我介紹大概是這樣子。 MY：接下來可以跟大家介紹一下 LXQt 這個專案嗎？ PC：好，其實這個專案是從 LXDE 來的，我想很多人沒有聽過，因為在台灣不是很流行，全名是 Lightweight X11 Desktop Environment，不過 X Window System 已經快要被 Wayland 取代了，所以有人一直笑我們說，是不是 X 要換成 W，不過目前是沒有這個計畫。我們都會宣稱 LXDE 是世界第四大桌面環境，那時候是 2006 年。 HC：僅次於 GNOME, KDE 跟 Unity 嗎？ PC：Unity 搞不好比我們多了，沒關係，都是我們自己喊的。主要是 2007 年那時候有朋友送我一台非常慢的筆電，Pentium 3 600MHz，然後記憶體只有128MB，根本就不會動了，所以我就是想知道說到底是什麼問題，因為同一台機器裝 Windows XP 明明就會動，那為什麼裝了 GNOME 就不會動，尤其每次開資料夾都要讀很久，我就想說不然我自己來寫一個看看有沒有辦法比較快，當時就弄了 File Manager， HC：人員不夠是不是？ PC：兩邊的人力都不夠，目標又都是一個輕量的 Desktop，又都用 Qt，為什麼不乾脆合併就好了？這個事情大概洽談了一兩個月，經過很多溝通，因為兩邊的成員都有一些不同的聲音這樣，最後還是成功的整合了，本來要叫 LXDE-Qt，但是大家都覺得太長了，所以最後就變成 LXQt。 HC：ok。 PC：雖然不是一個技術上了不起的專案，但是它還是有一個歷史意義，是 Linux 歷史上，第一次有桌面環境合併，因為之前都是你不斷地看到 Fork，但是從來沒有看到合併的，而且這是第一個合併成功的。 HC：通常都是有些理念不合，我可能就是在 Fork 出去變成另外一個 Environment。 PC：而且最近 Fork 越來越多了，多到有些名字都記不起來。這應該真的是史上第一次合併。 HC：應該談蠻久的吧？比如說在決定名字，或者是之後要開發什麼功能的時候？ PC：對，其實我們私下談了一個多月，剛開始的合作是我們把一些程式移植，讓它在那邊可以跑，然後就是互相讀設定檔，確保程式在兩邊都可以跑，到後來才開始談要不要乾脆進一步合作。剛開始談不攏的就是專案名稱，兩邊都想用自己的名字，最後的結論就是，不然我們就用個新的，可是這樣會有個問題就是突然換一個新的品牌，那一般的使用者很難去知道這到底是什麼東西。 HC：對，不知道你們是之前的那個專案。 PC：對，原本的社群可能會因為這樣丟掉，所以協商之後，最後大家就妥協了，就說不然就暫時先叫 LXQt ，因為我們出 LXDE，他們出 Qt，其實他們是當時是不太高興。 HC：他們想直接叫 RazorQt 嗎？ PC：可是 RazorQt 有其他專案在用。 HC：okok。 PC：當然他們心理上會不太舒服，所以… HC：捨不得。 PC：對，一定是，所以經過一段時間討論，我們就先暫時叫 LXQt，之後有更好的名字再換，不過叫久了大家就習慣了，最後就變成 LXQt ，暫時沒有要換。 HC：了解，雖然我知道台灣 Linux user 可能不是那麼多，不過大多數人比較熟悉的就是像剛提到 GNOME, KDE，然後 Ubuntu Unity 是因為Ubuntu大力在推。 PC：對對對。 HC：比較輕量級的可能就是 XFCE 或是 LXQt。 PC：主要取向不太一樣，不然已經有這麼多桌面，不需要再做一個，像 GNOME 已經朝向觸控/Mobile 方向，那 KDE4 從 Qt4 到 Qt5 之後，其實也是比較 Focus 在QML，也是偏向 Mobile 的整合，那 XFCE 現在卡在 GTK2 還要升到 3，另外就是像原本的 LXDE其實也是卡在… HC：也是卡在GTK就對了？ PC：我們其實想換 Qt，因為 Qt 對開發效率的提升有幫助，而且會 Qt 的人比較多，所以比較容易找到開發者，當然像 GTK 的話，很多人他會用 python 寫，可是如果要在一個記憶體受到局限又要比較快的環境下，通常還是會需要用 C 來寫，其實蠻難寫的，也不容易找到開發者，所以就長遠的維護來說，其實 Qt 會比較有利，而且文件非常完整，這也是換到 Qt 其中ㄧ HC：你覺得 LXQt 相對於其他桌面環境的優點，一方面是輕量，另外一個是專門針對 Desktop 嗎？ PC：對，應該說我們目前的特色是比較屬於 Classic 的設計，你可以看到現在很多趨勢都是往Mobile 跟 Touch 方面靠攏，可是我們對桌面工作的需求並沒有消失，那 Windows 8 又變得很奇怪，Windows 9 還沒出，Windows 7 可能過一陣子就會停止支援，傳統的桌面都被迫升級到類似 Mobile 介面，其實不是每個人都很習慣，XFCE 最近也是遇到人力短缺的問題，所以各個專案目前都有些狀況，比較 Focus 在桌面這邊，大概只剩下 XFCE 跟我們，那像 Enlightenment 也是做了很多不錯的東西，但是相對比較小眾。在選這些 Libarary 的時候，其實還是要考慮到一些多國語言的支援，還有會的人多不多，因為這是關係到之後會不會容易找到開發者，還有文件多不多，所以有時候這東西實際上不一定是最好的，但是要做到整體的考量。目前如果你要找一個以 Qt 為基礎，相對比較輕量的桌面，大概就是我們這個專案的目標。 HC：對，因為像 Unity 其實現在想要支援多平台，就是同樣的介面在每個平台上都可以用，所以很多設計如果以純 Desktop 來看其實還蠻奇怪的。 PC：對，其實並不會有一種設計可以適用於所有的情境，各個不同的使用情境，還是會需要一些不同的環境，雖然說現在新的裝置一直在發展，但是我們對於桌面工作上的需求並沒有消失，而且事實上，你要做的事情一直都是一樣，那為什麼要為了換新的桌面就一直去升級機器，也蠻奇怪的。 MY：ok，目前有哪個 Distro 已經有內建 LXQt 桌面環境？ PC：有，其中有兩套，一套是那個我不會念，M開頭的 (Manjero)，就是以 Arch Linux 為底的，那個不是內建，是有人做了一個衍生版本。 HC：LXQt 的。 PC：對，然後另外一個是以 Debian Sid 為基礎的一個 Distro，只有預設 Repository 裡面有，不過這些相對比較小眾，因為我們在今年初才做了第一個 release，那現在第二個在準備中，快要出了。 HC：你們有打算維持一個固定的 Release cycle嗎？ PC：Release cycle 目前可能比較難固定，以前 LXDE 的做法是每個元件分開更新，然後是使用 rolling release，就是哪個元件有新的，就會出那個元件的新版，不過轉到 LXQt 之後，我們這個部分有一些改變，就是會變成全部套件一起升，會變成比較規則的升級，所以會有一個大的版號，像我們第一次合併之後發行了 0.7，這次應該會發 0.8，0.8 比較重要的事情是已經全面支援 Qt5，不過 0.8 正在準備中，卡在一些小地方，本來是預計這個月要 release，不過這個月已經最後一天了，所以應該會變下個月。 HC：ok，了解，不過為什麼不像以前那樣？我覺得 Rolling release 還不錯，因為一次升級一大包，理論上出錯的機率比較大一點。 PC：對，不過不同的套件之間，如果都是不同的版本，有時候很難去做測試，QA 上會比較困難。 HC：okok。 PC：而且對於那些包套件的人也比較不方便，不是很容易去追蹤那一個版本現在出到哪裡了。 HC：ok。 PC：加上 LXQt 其中有過半的程式碼來自 RazorQt，那 RazorQt 原本Release的模式就是全部一起，不過它原本整個桌面環境是很大一包，我們其實做了很多事情去把它拆成小的元件。 MY：在 COSCUP 有聽到你的演講，你有提到說跟國外的 Open source 社群合作要花不少心力，可以跟聽眾分享一下就是這方面的經驗嗎？ PC：主要問題是大家在不同的時區，用的語言也不一樣，當然你會想說講英文就ok了，但事實上不是所有的國家都講英文，比如說我們會遇到古巴的開發者，或者是俄羅斯的開發者，其實他們的英文並不是預設都要學的，所以有時候會收到那個用 Google translate 翻譯的，那文法就怪怪的。另外是某些國家會連不上某些網站，譬如說像我之前用 SourceForge，後來才知道古巴連不到，中國也有些會連不到。 HC：他們有擋就對了。 PC：對，一開始我們不曉得，然後像 Google code 也有一些國家連不到，通常我目前聽到比較常發生是古巴，所以你有跟這些地區的朋友合作的時候，就是要注意你的那個 Source code 放的地方。另外一個就是時區的問題，像我們在台灣，坦白說自由軟體還是在歐美地區比較風行，那這些地方時區基本上都是跟我們差十二小時，那要大家 Online 一起討論，幾乎是非常困難，要就是你熬夜，不然他早起，所以一般我們都還是會喜歡用 mailing list，或是像 Google group，那大家就是在那邊討論會比較容易，而且文字在發出去之前可以有比較多的時間思考，通常你可以深思熟慮之後再發你的Mail。 HC：不過可能會遇到，比如說你回一封信之後，等到他回覆又是一天後，會不會相對就拖得很慢？ PC：有時候的確會有這個狀況，如果你真的很急，當然就可以不要睡覺，然後等他們上線。不過通常不會有這麼緊急的狀況，除非有些 Security 的問題，不然應該沒差到那幾個小時，而且一般我們的 Source code 都是用 Version control System，比如說我們是用git，那本來就很適合分散式多人線上協作，所以並不需要大家同一時間一起做同一個東西。不過大家要協調好，不要兩個人同時在做同一部分，這樣會有很多衝突，造成不必要的麻煩，所以其實很大的Overhead 是花在溝通上面，另外有一些就是像文化的不同，比如說像歐洲人對於休假這件事是非常重視的，譬如說他正在休假，你問他一個Bug，他基本上不會理你，這就是民情的不一樣，像我們是假日都可以工作，但是他們是不行的。我有遇過一次有一個Bug，我想要修，那我就問我們歐洲的同伴，他聽到我在休假馬上下線，就不再問我了，因為他們很重視這件事。 HC：他覺得你休假就應該要好好休假。 PC：對，他覺得我不應該弄那個東西，所以他就不跟我聊了，有時候是一些語言障礙會造成誤會，像我有時候會跟那個烏克蘭的朋友吵架，因為我們英文都不是很好，其實都聽不懂對方在講什麼，就會有很多誤會。這種時候就只好用 Source code 溝通，就是一人寫一份，然後直接看 code，反正 C 大家都看得懂，沒有什麼誤會。而且人一多起來之後，就是不可能每個人意見都一樣，有時候就會遇到有人的意見是完全相反的，那你又不可能取悅每個人，就會卡著不動，可是你又不能玩多數決，因為你多數決之後，被忽略那幾個人可能就不想玩了。 HC：真的非常麻煩。 PC：對，這蠻麻煩的，我們有時候會遇到這種狀況。 HC：可是怎麼辦？好像也沒有有比多數決更好的。 PC：這種情況多數決不一定會產生最好的Sollution，因為也有可能少數人技術比較好，他其實是對的，通常在反覆的溝通之後，大家會不斷的找出各種做法的優缺點，最後通常還是會有一個共識，一個最大公約數通常還是取得出來，如果真的取不出來，那就看誰有空誰要做。 HC：有空做的決定就對了。 PC：對，其實最後往往是會這樣，也許過一陣子，有人會想到說，我之前的想法，是不是有漏了什麼，他會改變主意，這是一個可能，另一個是放了一陣子之後，大家都覺得不行，大家都沒有空做，那我一直堅持，可是其實我也沒有空寫Code，那不然我們先嘗試別人的方法，如果真的行不通再改也可以，大家態度就會軟下來，各退一步之後，就有人出來把這東西解決就過了。 HC：你們怎麼決定說要做哪些功能？比如說你們有個列表，還是由誰來決定說要做什麼？ PC：其實沒有。 HC：還是直接有想做的功能就做？ PC：對，其實每個專案的狀況不一樣，有的人他的專案是會有比較大的架構，像 GNOME 有一個比較大的組織，他們通常會有一些 Roadmap ，不過像我們這種比較小型的專案的話，通常都是幾 commiter 討論一下，如果都ok就做了，或是其實每個人有自己負責的component，你改你那個地方，只要不要弄壞別人的，或是不要太誇張的修改，通常大家都會ok這樣，那像有些比較重要的變更，可能會動到其他地方的，通常我們會在 mailing list 上面先問，大家會討論。 HC：沒有意見就可以改這樣？ PC：就是等個一陣子，如果都沒有意見，或是有人有反對意見，但是經過討論之後，問題都解決了，其實我們就等著收 pull request。事前的溝通會減少很多麻煩，不要改了之後，發現大家不合，然後在那邊吵就會很難弄，所以我們都會遇到比較大的修改都會事前溝通，那或者是另一個做法是會開在一個git branch 裡面，那做完之後，這個 Branch 給大家 Review，大家如果看過都覺得沒有問題，才可以 merge 這樣，就可以避免這種問題。 HC：所以你剛剛說，放在 SourceFoege 和 Google code 都會有問題，所以你們後來是放在？ PC：我們目前是用 github，我在想可能也不是所有國家都可以連，要取決於你的成員是來自哪些國家，像有些國家有些網站就會連不到，所以可以先跟他們問問，或者是你可以在不同的網站多放幾分，因為 git 是可以 Clone 的，所以像我們就是自己的 Server 上放一份，然後 github放一份這樣，一方面也是當備份，一方面就是確保就是大家都連得到。 HC：反正有多個地方可以連就對了。 PC：對對對。 MY：你剛才有提到說，你們有幾個核心成員，大家負責不同的軟體模組，比如說上了一個 Pull Request 給你們，那你們審核的機制是大家一起要來決定這個 Pull Request 可以用，還是說只要這個核心模組的負責人說可以就可以讓 Pull Request 過？ PC：通常因為我們的專案規模比較小，所以沒有像那些 KDE 那種模組切得很細，我們比較沒有這樣，就是有大的維護人，但是其實大家都可以發表意見，有時候那個模組 Owner 事實上他也不一定有空，所以就是有空的人誰先看到，那給點Comment，那如果是真的很小的，很明顯就是不會有做修改，大家就會直接 Merge，如果是一些看起來有點疑問的，上面又有一些Comment，那我們就會討論這樣，大概會兩三個人看過，如果都沒問題，就還是會 Merge。 MY：那是由誰負責來做 Merge這個動作？ PC：基本上有空的人都可以做，因為我們的組織比較扁平。 HC：所以有這個權限的人，大概有幾個？ PC：目前的話，至少七八個跑不掉。 HC：那也還不少。 PC：對，但是實際上有在開發，目前大概三到四個。 HC：ok，比較活躍的就對了。 PC：對，自由軟體的東西，就是大家都有自己的生活，所以人都是來來去去，有空的時候就拼命寫，沒空的時候就休息，就是沒有辦法像那種上下班打卡，然後每天固定時間… HC：對，基本上不太一樣。 PC：對對。 HC：所以除了這七八個和新成員之外，從其他社群成員來的貢獻多嗎？ PC：其實也不少，我們還蠻常收到 Pull Request 的。 HC：但是可能就是一個兩個？ PC：對，不會很頻繁，但是往好處想，就是也許Bug也沒有真的那麼多，不過其實我們還是偶爾會收到 Pull Request ，所以我自己覺得換用 Qt 一個好處，就是會這東西的人真的比較多一點，而且它文件很完整又比較好學，相對你要找自己在那裡刻 GTK 的人，我真的覺得不是那麼容易。 HC：人做就很容易出錯。 PC：對，然後它為了怕出錯，就加了一大堆 Runtime 的檢查，所以就整個搞的很複雜，這些事情，如果你用 C++，基本上是一行都不用寫，但是用 C，你可能就寫了滿滿一個.H，然後一個.C 的檔案，寫了大概一二十行字以上跑不掉，而且是每一個 Case 都要寫，事實上這個帶來的Overhead 是很驚人，而且其實它的型別檢查，沒有辦法在 compile 的時候，像C+就做得很完整，而且它很多都是直接把一些指標強制轉型，所以其實很多錯誤在 compile 的時候都找不到，然後到 Runtime 的時候當掉才會找到。 HC：所以 Qt 就沒有這些問題？ PC：Qt 有另外的問題，Qt 在 5.0 以前的版本是沒有辦法在 compile 的時候做型別檢查，不過在 Qt5 之後，它有加入一個新的語法，是可以在 Compile 型別的時候，就檢查出錯誤了，所以這個部分是現在就比較改進。 HC：ok。你們都轉到 Qt5 了嗎？ PC：對，另外 QT5 的一個特點，也是被人家罵的地方，就是它的程式碼會先經過一個叫做Meta-Object Compiler (moc)，會先處理一下，然後再幫你產生一些 Code 再 compile 在一起，就為了這個，很多人就在講說這根本不是 C++，還要預先處理一次什麼特殊語法，可是你換個角度想，其實在 GTK 裡面，這些東西就是你自己手寫，所以你不用檢查。它只是把你原本手寫的東西，變成用一個程式產生而已。 HC：程式產生應該比較不容易出錯，理論上。 PC：對，而且它裡面還會檢查不同的版本號碼，所以你產生的不對會連不起來了。 HC：ok。 MY：你剛才有提到說，你們大家都蠻 Free，因為大家都有自己的事情要做，大概都是利用自己有空的時間在做這個專案，那你會給自己一個 Milestone，就是說我可能到今年的幾月幾號，我希望 Release 第幾版，你會給自己這樣的 Milestone 嗎？ PC：有，其實像我們專案有一位法國的開發者，他比較少在寫code，但是他就比較常在做這些專案管理規劃工作，那原本像這次我們也是規劃九月要release，不過後來因為突然又被發了一堆 bug report ，然後就延期了，所以其實我們是會有一個 Milestone，然後哪些 Bug 是這個期間要修好的。 HC：你們有專門的 QA，還是說都是 User report bug？ PC：我們自己會做 test，之前我們有一個瑞典人做 Release manager，不過他最近時間實在不太夠，所以他最近就沒有做了，所以我們每個人都會把這些 bug 測試過，看起來沒什麼問題，然後把比較重要 Bug 修一修，才會 Release ，因為我們的規模其實沒有到那麼大，所以沒有辦法分專門的 QATeam。以我們這種規模的，其實可以做到有好幾個人已經不是很容易了，因為大多數這種專案大概最後都剩一個人而已。 HC：一兩個人的專案。 PC：對，所以有時候很難切那麼細，但是有專門的 Team 是最好。 HC：ok，像那種比如說決定 Bug 的 Prority 基本上就是幾個核心成員找個時間討論之類的，還是說? PC：對，就是我看了比較多。 HC：你可能看了，你就直接設了，ok。 PC：對。通常還是會討論就是了。 MY：目前你們這個 Opensource 專案，有沒有被某些商業產品拿去採用，那它後來再貢獻回來的？ PC：目前看起來好像沒有。 MY：ok，所以等於大家都是類似志工一樣貢獻。 PC：應該說那些發 Patch 的人，我也不確定他們有沒有商業公司，不過目前市面上，好像沒有看過採用這個的產品，LXDE 之前有產品用過，不過 LXQt 還蠻新的，所以目前還沒有被廣泛的使用，而且我們其實最近一個穩定版還沒出。 HC：之前 LXDE 其實有 LUbuntu 這個版本。那個是社群做的嗎？還是？ PC：對，那個是社群做的，一個法國的開發者，那我們有跟他討論過，原則上，如果 LXQt 穩定了，我想他那邊應該也會轉，因為他現在也有幫忙 LXQt 包套件，不過目前是放在 PPA 裡面，還沒有正式的進去這樣子。 HC：就還不是變成一個 Distro。 PC：對，因為我們現在大部分程式都還在 git 裡面，還沒有發正式的版本，所以原則上就是用daily build，然後放在 PPA 裡面給大家裝這樣。 HC：okok。 PC：不過之後應該是有機會進 Ubuntu。 HC：所以之後 LUbuntu 可能就會變成 LXQt，不是 LXDE 就對了。 PC：很有這個可能性。 HC：LXDE 還有人在維護嗎？ PC：有，目前是一個烏克蘭的工程師在開發。其實那時候要轉到 Qt，他是覺得雖然轉過去了，但是我們也不應該馬上把原來的東西丟掉，因為就算是 GTK2 使用者也還很多，而且事實上，原來東西的運作不錯，很多使用者也蠻喜歡的，再加上他現在主要是在開發 File manager 的部分，就是本來是我開發，不過現在都是他接手，所以他在上面加了一大堆新功能，他目前是非常認真的在維護，他修完 File manager 以後，現在也是轉向修其他 component，所以最近他發了很多新的 Release，目前其實 LXDE 還是處在有維護的狀態，人力當然相對比較少，不過這個烏克蘭工程師真的很強，所以他一人可以當三人用。 HC：好，因為我看，它的網頁也都還有更新，然後每一版的Ubuntu，好像還有跟著 Release。 PC：對，最近還有新的 tarball 出來，大部分都是那個烏克蘭工程師。 HC：一個人做就對了。 PC：不過他之前有休息一陣子，因為那一陣子他們國家有點事情。所以他那一陣子就心情不是很好，就休息了一下，最近又恢復了。 MY：回到剛才你提到的，就是我想聽眾都非常感興趣，你大學念的是醫學系，是什麼樣的動機，你會想要去寫程式，而且還寫出蠻受歡迎的軟體，像 PCMan BBS 或 PCman FM 等等，可以跟我們的聽眾分享一下。 PC：其實一開始也沒有什麼動機，因為我高一的時候，家裡有一台電腦，剛開始都是跟大家一樣，就是打遊戲，可是打一打就覺得這台機器那麼貴，只有玩遊戲實在太浪費了，就覺得應該要學點東西，那時候就看那種電腦補習班，全部都是介紹一些文書處理或是影像處理，不然就是繪圖，當然有一些是程式設計，不過我看那個課程都非常的貴，所以後來我也捨不得去上，後來發現就是有一些東西，自己看書是學得會的，就自己慢慢看書，然後慢慢研究，就高中大概也是這樣玩了兩三年。 MY：你算蠻早期就接觸這種程式設計，那時候你大學的志願，為什麼沒有考慮說要念資工系這方面？ PC：有，我本來的確是有考慮，但是後來主要是覺得說，跨一些不同的領域，也許會有比較多的可能性，因為剛好也有考到，所以就想走看看不一樣的路。 HC：所以其實你現在是住院醫師嗎？還是？ PC：是之前。 HC：okok，可是那應該還是蠻忙的。 PC：對，就住院醫師還是比較忙。 HC：那你一個禮拜大概會有多少的時間在開發 Open source 的專案？ PC：不太一定，有空的時候就比較多，像最近就沒什麼空，其實就停下來，不過這種團隊合作的好處就是你休息，但是別人有空，所以這專案就可以繼續下去了，最近你可以看到 Commit 都是外國開發者在做。 HC：ok。 PC：那位開發者是在我們兩個專案 merge 之後才加入的，所以就像我剛剛講過的，其實你換一個相對比較多人使用的 Toolkit，文件比較完整的話，有時候也比較容易找到開發者，所以當時做了這個決定其實蠻困難，因為原來的基礎等於是全部打掉了，就是砍掉重練，但是我們看的是整個長遠的維護跟未來的發展，所以有些東西可能是必要的。 MY：像你剛才有提到就是說，你還是有維護一個就是說工作列表，就是大家負責哪些工作，那如果是你的 Team member 發現說，你目前可能屬於休息狀態，就是有人會自動接手去做就對了。 PC：應該是說我們大部分的時候還是在維護，新功能不會一口氣做太多，因為有時候，你中間在改的時候，會有一些不相容，或者是容易有 Bug，然後一方面，我們做一些新功能的時候，如果這個改變很大的話，當然我們會在 commit 先跟大家問一下，如果沒有什麼人反對，那大家都知道我們可以，什麼時候可以動手，或一開始會放在 Branch 裡面，就是確定已經測試好了，才會給它 merge，因為我們之前也有發生過，就兩個人在做同一個地方，結果後來就合不起來，變成有一邊要丟掉，所以後來我們就是都會先問一下，有沒有人在做。 HC：所以你們沒有 issue checking 嗎？ PC：有有有，我們有 issue checking，但是因為有一些功能是沒有在上面的。 HC：ok。 PC：就是你可能臨時想到這個很不錯，就會把它做下去。或者是有人其實已經 Assign，但是有的時候，又剛好又有人沒注意到。或是剛好已經有人提供 Patch，那就會有另外的人把它Review，然後再 merge 進去。 HC：OK。 PC：其實像這種專案相對小的時候，組織就不會那麼複雜。 HC：如果現在我想要試著裝 LXQt 的話，最簡單的方法就是你剛剛說的那兩個已經有 bundle 在一起的 distro，應該是最快對不對？ PC：不見得是最快，因為這兩套的話，一個底下是 Debian Sid，另外一個是 Arch Linux，那這兩套對初學者來說，相對沒有那麼好，如果你是用 Ubuntu 的話，最好的應該是裝 Ubuntu 的PPA，就是那個法國開發者有維護一個 PPA，應該Google一下，應該找得到，那如果是Debian 的話，現在應該還有一些還在打包，那如果是 Arch Linux 的話，有 AUR 可以裝，AUR上面那個已經是最新的，因為我們開發者大部分都是 Arch Linux 的使用者，所以那個東西是會比較 Update 的。 HC：Arch Linux 的人比較多就對了。 PC：對，我們用 Arch Linux 的比較多，那其他的 Distribution 的話，我目前不是很確定，因為目前他們有的可能還沒有包是因為我們還沒有正式的 Release，目前都是 git 上面的source code，那近期如果有 tarball 出來，我相信大家就會開始包了，那到時候裝就會比較方便了。 HC：應該等到下個 0.8 Release 出來以後，就會比較多了。 PC：順利的話，其實他們最近可以發，本來是這個月要發了，被一兩個Bug卡住了，那我們也是有討論了一下，因為有一些會造成不相容的修改，所以就像之前提過，有ㄧ些是意見不合，不過就這樣放了一陣子，大家沉澱之後，就會有人退一步，所以目前這個問題，應該是可以解了，就是需要一點時間。 HC：基本上這個解完，大概就會 Release 就對了。 PC：我覺得是這樣，就是使用者平常你在測試的時候，真的會很狂熱跟著你每天這樣 build 測試，使用者真的很少，很多時候，Bug 都是在要 Release 之前才會發現，比如說你放消息說，我們準備要 Release 了，這時候反而開始測試的人就突然變多，然後bug report 就暴增，所以你不 Release 的時候就沒事，那你要 Release 的時候，大家就突然都來測試了，然後Report就變很多，這時候就會有一些你必須要停下來修。 HC：的確會裝 daily build 的人比較少。 PC：對，這個也是自由軟體專案的一個特性，像你一般正常公司在開發，你會有自己的測試的時辰，除非你是像 KDE 那種很大的專案，如果一般比較小的專案，事實上很難做到這麼好的分工，通常還是需要依靠使用者幫忙測試，可是一個東西，你在開發你還在改，又沒有正式的版本，你要叫人家來測試，連套件都沒有，事實上很困難… HC：對。 PC：所以往往都是在 Release 前後，忽然發現 bug report 變多，或者是 Release 前，大家都在等別人包，然後套件包好 Release，結果就 bug report 突然暴增，通常都是會這樣子，所以有時候，很難在一開始就修好全部的Bug，因為這時候就沒有人願意幫你測試，所以很兩難。 HC：感覺就是先發了 beta 再來修嗎？ PC：對，我們現在也是喜歡先發 beta 或是 Release Candidate，然後收一些 bug report，把bug report 修一修再 Release。 MY：這邊有一個問題，就是你剛才提到說，因為你後來大學想念醫學系，想說是跨領域，那你現在你是橫跨就是醫學系跟資訊這兩個領域，你會去做一個Opensource，就是結合醫學跟資訊這兩塊的軟體嗎？你有這樣的計畫嗎？ PC：其實還沒有，很多事情都是就是計畫趕不上變化，以前就是兩個領域的了解都還不是那麼多的時候，都會想說跨個領域能不能結合，不過事實上沒有那麼容易，所以可能還需要一些時間。 MY：像你自己平常在工作上，如果說看到自己醫院的那個資訊系統，看起來很爛，你會有一種衝動，想要去把它重寫，或是再自己做一套？ PC：那種時候就是需要跟資訊室的這個同仁好好溝通，因為他們的那些系統都有歷史包袱，有時候不是他們不會改，是因為有歷史包袱，那資料量真的太大了，所以不好轉移，而且不能停機，中間轉移如果出錯的話會有法律問題，因為病歷的資料其實那個問題很多。 MY：所以也知道你本身算是資訊這方面的高手就對了。 PC：對，我舉個例子，像我以前服務過的醫院，有一家還在 IBM Mainframe 主機，1970年的那個，，然後前端是有接到可以有網頁，但是後面還有 Mainframe，所以基本上，這種東西你沒有辦法去改。而且這樣子的醫院不只一家，有一兩家我知道在用 Mainframe，然後還有一些公立醫院都用 DOS。 MY：還有Dos。 PC：對，它就用Dos，然後後面的資料庫是 dBase，我還知道有一些公立醫院的系統是用 Cobol 寫的，都是歷史名詞，但是現在都還在運作，這種系統，你大概不會想要輕易的把它移植… HC：真的。 PC：你也不會覺得說重寫是一個簡單的工作，所以當然就運作好就不會有這種狀態。 HC：沒錯，了解。 PC：其實他們是有很多的歷史包袱，並不是他們的工程師不強，是這種東西，你真的動不了。 HC：除非你砍掉重練或什麼的，但這都是很大的工程。 PC：而且那東西只要停機一小時，整個醫院都會大亂，因為你平常的檢驗、那些開藥，全部都是依賴這個，基本上停機用人工作業整個會大亂，所以除非不得已要進行維護，一般是不會隨便停機。 HC：真的是蠻難。 PC：所以像醫療醫院的話，其實像資訊的應用還處在很落後的狀況，可是有一些東西，並不是那麼容易改變，事實上他們的工程師很多能力也還不錯，不過有一些真的是歷史包袱沒有辦法。 MY：問題差不多了，你有沒有什麼想要補充的嗎？ PC：其實我不知道你的聽眾都是怎麼樣的族群，就是有沒有在開發自由軟體，或是… HC：應該蠻多都是工程師的，相關產業的比較多。 MY：要招募工程師嗎？ PC：其實我還是想要提某一件事情，事實上台灣有非常多軟體的人才，分佈在各個地方，不過你在網路上可以看到的，大部分的自由軟體專案還是來自國外，像對岸最近也越來越多，可是我們的工程師，其實也沒有比人家少，而且能力也不輸給國際上的其他國家，我是覺得這應該是一個提升我們的能見度的方法，就是希望大家一起加油。 HC：比如說，假設有人想對 LXQt 專案做一些貢獻的話，他要怎麼樣開始比較好？ PC：ok，通常的話就有幾個，一個是可以加入那個 mailing list 一起討論，然後可以學到比較新的資訊，那另外一個，當然就是一定要抓 Source code 下來編譯這，然後看看有哪些地方可以改，那如果有改就到 github 上面發 pull request，我們都很歡迎。 HC：那如果是不寫 Code 的話？ PC：不寫Code的話，像我們非常缺的就是文件跟美工人員，這一塊永遠都是缺的。 HC：你們有做那個 i18n 嗎？ PC：有，不過這個部分的話，因為我們翻譯的那個系統現在有點故障，我們之前是用Pootle，不過系統最近跟 Qt 連起來，有一些怪怪的，還好我們 Team 有一個剛好是Pootle 開發者，所以這一部分他會修，不過沒有辦法修得很快，所以目前我們暫時沒有翻譯系統可以用，就只能直接收 TXT 檔案。 HC：ok。也可以。 PC：對，比較不方便，那未來應該會上線，我想他需要一些時間把它修好，不過他的工作就是那個系統，所以應該沒有問題。希望未來可以在國際上看到更多來自台灣的專案，事實上我們的軟體人才很多，實力也都很強，比較可惜的是，很多都自己做一個小專案，也許只有中文版，如果可以把它想辦法推到國外去的話，我相信台灣也可以產出很多國際的專案。 HC：好，那不好意思，怕耽誤你之後還有事情，我們今天的訪問，差不多到這邊就告一個段落。 PC：好好。 HC：很高興 PCMan 能夠接受我們的訪問，今天訪問到這邊就到一個段落，謝謝大家收聽，謝謝，Byebye。 MY：Byebye。 PC：Bye 後續 >> TechTalk 專訪 Episode 29 逐字稿 – Interview with Anthony Chen about Dropwizard |
關於作者
由 Hao Cheng 和 Mao Yang 一同主持的中文 Podcast，主題涵蓋 Java, 程式語言, 軟體工程以及其他科技相關議題。 Podcast 下載網站: http://www.techtalk.tw/
