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 |